MOBiNET envisages a new Internet of Mobility where transport users meet providers of next-generation mobility services. The MOBiNET Marketplace will be used for all types of travel-related services, including both those that are connected to in-vehicle devices and those that are based on smartphone applications. Any service that requires integration of multiple data sources is a candidate for MOBiNET.

In parallel with the MOBiNET platform development, MOBiNET designed and developed 10 reference applications ("services") for trialing in pilot sites in 8 countries. A number of partners in the Project have brought their services to the project and taken an active part in developing the technical solutions for implementing them. Applications chosen will show substantial value gain thanks to MOBiNET.

Services implemented act as platform use case demonstration.

To view the architecture of each individual service without and with MOBiNET, click on the relevant service.

To read the full report click here. The report (deliverable submitted to the EC in November 2016) describes the selected services, how MOBiNET functionalities were integrated and how the platform benefits or enables the service. In doing so, the document details the actors involved in each service and their roles, and the concept behind each service, specifying the architectures with and without the MOBiNET platform.

This service provides drivers with advice on optimal driving speed to pass a traffic junction on green.

Use of MOBiNET within the service

  • GLOSA uses MOBiAGENT for positioning and timing information
  • GLOSA uses the connected communication management functionality (Geocast from back office to vehicles in an area).

Benefit of using MOBiNET

  • Avoiding the need to implement a geocasting service and to have open connections to many end users
  • Enabling device -independent location and timing updates.

GLOSA has been extensively trialled in a number of C-ITS projects across Europe and is implemented in some ongoing pre-deployment pilots such as the COMPASS4D cities. As a cooperative system it does not need MOBiNET directly. However, what could be useful for large-scale deployment – that until now is not happening – would be to implement GLOSA as a service in the cloud, and to provide GLOSA-equipped intersection data as an online service for navigation maps in vehicles and in personal navigation devices and smartphones. MOBiNET could enable such additional deployment if this information were published in the Service Directory and if GLOSA real-time data and GLOSA location data were to be available to end users via apps.

User benefits

  • More sustainable city (smoother traffic, less CO2, etc.)
  • Smarter city (better integration of different types of traffic users)
  • Increased comfort and cost reduction for drivers.

GLOSA Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
Without MOBiNET the Customer has to interact with many different GLOSA service providers who each have their own app. Since this is not a situation a consumer is going to accept, it is unlikely that the service is viable without a platform such as MOBiNET. Alternatively a service provider can make separate contracts with content providers, but this is going to pose a large overhead especially when considering international interoperability.

Architecture with MOBiNET
Two models are possible:

  • Road authority pays to have it offered to users for free (to reduce emissions),
  • End-user pays to save fuel.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service calculates vehicle insurance cost based on real usage of a vehicle.

Use of MOBiNET within the service

  • The Identity Manager is responsible for authenticating and authorising 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 consists of widgets running in the Dashboard which, offer 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.

Benefit of using MOBiNET

Possible mechanisms for added value for an insurance company to use MOBiNET for its UBI service include:

  • Gaining access to extra customers via in-vehicle telematics devices in vehicles and fleets managed by several telematics service providers (TSPs), not just to those of their own TSP. This is possible thanks to the TSP manager software that allows a service provider to access standard data coming from any on-board telematics device.
  • In addition, an insurance company could discover new customers and propose new kinds of product through direct marketing to connected travellers who have MOBiAGENT in their smart device, for instance a low-cost short-term insurance or breakdown assistance service limited in time and/or space.
  • Lastly, an insurance company could sell on third-party insurance-related products to other B2C service providers who could add these to their main service such as navigation, tourism or freight distribution and delivery.

User benefits

  • More sustainable city traffic (less CO2)
  • Smarter city (less cars since the use of each single car will increase)
  • Cost reduction for individual car user.

UBI Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
At the present time, providers of UBI connect to devices that are supplied to buyers of their own insurance products. These devices are specified by the UBI insurance provider or its agent and built to these specifications by selected hardware manufacturers. The UBI insurance provider or its agent is responsible also for specifying the performance and paying the costs for all mobile communications. The relationships among the parties in the current UBI service provision are shown in the figure below.

Architecture with MOBiNET
Key benefits of MOBiNET would be access by an insurance provider to multiple devices beyond those offered by the insurance provider, and access by insurance customers that have already installed UBI devices in their cars to insurance offered by other insurance companies. We see this being accomplished by the solutions MOBiNET will develop for both business (B2B) users and end (B2C) users (drivers and travellers):

  • A comprehensive directory of Europe-wide mobility and transport-related data and services will allow UBI insurance provider on-board unit customers to discover new products and services;
  • An e-Marketplace with a single sign-on MOBiNET membership will function as an e-commerce network linking End Users, content- and service providers and will permit customers to order and pay for products and services that would complement those being purchased directly from the UBI insurance provider. (A single payment account for End Users may not be used for insurance accounts, depending on regulations);
  • Membership of the MOBiNET B2B Supplier Community will enable providers to add third-party content and services contract-free to their own products; and,
  • The MOBiAGENT on end-user devices will allow access to MOBiNET service directory and an intelligent communication and connectivity manager that hosts end-user services. With MOBiNET, any insurance company or content and service provider who is part of the MOBiNET Supplier Community would be able to reach the on-board devices connected to UBI insurance provider and contract with car owners.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service provides a multimodal journey planner and necessary information to a traveller during a journey.

Use of MOBiNET within the service

  • MMTA integrates existing routing services in different cities, which are registered in the MOBiNET platform service directory.
  • MMTA executes end-user payment through the Payment Manager functionality of the billing component.

Benefit of using MOBiNET

  • Geographical extensiveness
    Simplified discovery and integration of different existing routing services in different European cities (without MOBiNET, one-to-one negotiations for integration or building of new routing engine for each city would be necessary).
  • Identification process
    MMTA service providers can use the identification (identity manager) and payment (billing) services of the MOBiNET platform.

Providing a user app for multimodal travel assistance (journey planning, booking, ticketing, payment, delay & cancellation management, itinerary updating...) that works everywhere in Europe is impossible today. The best multimodal travel apps have limited coverage and/or functionality. MOBiNET would open the door to creating such a complete travel assistant service through its Europe-wide Service Directory. An app developer would be able to find, link to and integrate the API for all needed online data sources as well as third-party services such as mobile payment & ticketing, travel booking, real-time traffic and travel information etc. From the user side, these extra features of such a travel assistant would be of sufficient value that the app could be priced in the app store, and the integrated service could be sold too. Finally, those providing individual transport services (road traffic management, public transport operations, on-demand and shared services etc.) could get insight into (anonymised) traveller demand such as the requested destination, trip stage time of day & use of individual transport modes.

User benefits

  • More sustainable city (encourages modal shift and increased use of eco-friendly public transport services)
  • Increased comfort, time and cost savings for individual travellers.

MMTA Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
The Multimodal Travel Assistant (MMTA) is composed by different travel planning services developed by different service providers, as backend modules. Figure 36 represents the functional architecture of the MMTA service without the MOBiNET platform. As a matter of fact, without the integration allowed by the platform, each service provider would need to develop a dedicated frontend module to provide their journey planner data and routing engine. In addition, in this case, only a very specific and limited city/region/area is covered by the services offered to the end-users. Figure 36: Functional architecture of the MMTA service, without MOBiNET Figure 37 shows more in detail the exchange of data and money flows among the service provider, the MMTA and a potential customer, of one of these single services.

Architecture with MOBiNET
Within MOBiNET, these services are published on the MOBiNET e-marketplace, where end-user have the possibility to access and use just one MMTA app to plan trips in cities managed by different service providers. The App in fact is linked to different travel planning services through a broker (see Figure 35), and a common specification is published on the MOBiNET Service Directory. The Broker has then the function of dispatching the requests coming from the app to the different backend services. More specifically, Figure 38 represents the MMTA data and money flows.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

What does the service do

This service is to plan and implement a fast and secure route through the network for ad-hoc use such as VIP vehicles, heavy goods vehicles and emergency service vehicles. Vehicles involved can get priority at intersections (depending on the service level; e.g. fire brigade very high, visiting VIP moderate). The implementation of the service will include an app and a backend. The service will use MOBiNET components such as Communication Agent, Communication Manager, MOBiAGENT, Identity Manager and Service Directory. The service has been implemented at Helmond pilot site.

Use of MOBiNET
There are several actors involved in the provision of this service. The following table shows their roles and characteristics:

Actor Role Description
Driver End user The driver supplies the route to the AH-prio app and will benefit from traffic light priority where possible.
TLC owner Service provider The TLC owner has to ensure priority is functionally possible in the TLC. This can be done through a service provider, but some do this themselves.
Priority Broker Service provider/B2C service user The priority broker collects the locations where priority is possible and acts as an intermediary between the requester and the TLC.
App provider Service provider The app provider interacts with the Priority broker, collects the route from the driver through a user friendly app (possibly integrated with other functionality) and passes the information to the priority broker.
Road authority Road authority A road authority can decide to give priority to a certain group of vehicle drivers, such as emergency vehicles and/or truck drivers, for example, to reduce CO2 emissions. The city traffic planner will arrange this with its infrastructure provider.

Use of MOBiNET components
The following figure shows the MOBiNET components that are used in the deployment of AHPrio in the MOBiNET platform:

  • Communication Agent: Communication from consumer app to AH prio service provider
  • Communication Manager: Communication from consumer app to AH prio service provider
  • MOBiAGENT: Incorporate the Communication Manager, identity management and positioning
  • Identity Manager: Authentication required for granting priority
  • Analytics components: Usage statistic
  • Dashboard/Service Directory: Register services and apps.

Benefits of using MOBiNET
Several benefits are enabled by the utilisation of the MOBiNET platform and they are listed here below:

  • MOBiAGENT: Same components can be used by many different apps, make App development more efficient
  • Dashboard/Service Directory: Register services and apps, in order for B2B partners to find and connect to each other.

Architecture without MOBiNET
Without MOBiNET the customer has to contact each priority service provider it will encounter on its route separately. This will result in the user having several apps for each service provider to supply its route in order to notify intersections in advance about the arrival and turn direction. The main difference here is that the customer interacts directly with the priority actuator (the service provider that is actually changing the light to green for them), without a market place there is no possibility for a service provider to coordinate between the route supplied by the driver and the different priority actuators. Note that 3 actuators are in this picture, but for an international freight trip over multiple European countries, this can easily exceed 20.

Architecture with MOBiNET
With MOBiNET there can be a service provider that connects through the MOBiNET platform with different actuator and offer the customer the convenience of only having to supply their route once. Both the actuator service providers and the one interacting with the customer will publish in the service directory and pay a registration fee. Also, the identity manager is required for administrating access rights of customers. The actuator type service providers interact directly with the road authorities and can in some case be the same party. The business model here is uncertain; some road authorities seek to reduce CO2 and would pay the actuator service provider, while others may even charge for it.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service transfers the weight information from a truck directly to the road administrator, while the truck is driving. When the vehicle passes a road-side ITS-Station, the in-vehicle ITS-Station broadcasts the weight of the vehicle together with an identifier to the road-side ITS-Station.

Benefit of using MOBiNET

  • Shorter development time due thanks to MOBiNET functionalities for identity management, service registration/lookup, etc.
  • With the possible exchange of various national databases information via the Platform, easier cross border control by public authorities of foreign trucks infringing weight regulations.

Weigh-in-motion (WiM) is a well-established technology for enforcing truck weight limits. This uses physical sensors in the road and a way of identifying each truck (e.g. camera/automatic number plate recognition). MOBiNET offers a possible advantage for trucks that can weigh themselves using in-built vehicle sensors and communicate the data by mobile communication to the enforcement authority. The benefits would accrue to both the truck operator (that could avoid stopping at a weighbridge) and to the road authority (that could save on roadside equipment and operating costs).
Thanks to MOBiNET this service functions on a Europe-wide basis. The European dimension of this service will be demonstrated by adding a second public authority (Swedish Public Authority) to the NST use case.

MOBiNET would extend these advantages to trucks that cross national borders and allow a fully pan-European WiM service. Volvo Trucks has developed the Non-Stop Truck application to prove the concept of integrating the national enforcement authorities with the vehicles via the MOBiNET Platform. This means that the authorities in each country would have only one interface to all vehicles entering the country, via MOBiNET, rather than requiring all truck manufacturers that wish to use their WiM service to adapt their systems to their speci_c message protocol or sensor technology. Fleet operators, from the largest to the smallest, would as a result have a major incentive to install the necessary technology to use the WiM service.

User benefits

  • Increased business conditions for the fleet operators by cost savings
  • Better working conditions for truck drivers because of less waiting time.

NST Use case from ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
The diagram below shows how the NST service would have been implemented for both Norwegian Public Road Administration and Swedish Trafikverket without using the MOBiNET platform. Each authority would have needed to implement a closed and complete system.

Architecture with MOBiNET
By using MOBiNET, a single NST service listed in the service directory glues different road authority services together through central integration and management of R-ITS-Ss.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service gives information to drivers on available parking spaces and navigates the driver to find the space and use the service to automatically pay the parking cost.

Use of MOBiNET within the service

  • Parking data services: MOBiNET Dashboard, Mobinet Services directory, MOBiNET Payment
  • Parking services: MOBiNET Dashboard, MOBiNET Services Directory, MOBiNET App Directory, MOBiNET Identity, MOBiNET Payment, MOBiAGENT.

Benefits of using MOBiNET

  • Publishing data through Directory
  • Access to data via Directory
  • Publishing functionality to users via Directory
  • Non-proprietary identity manager
  • B2B / C2B Payment via MOBiNET Payment.

The MOBiNET use case includes the publication in the Service Directory of two parts:

  • a B2B real-time data feed for other service providers to add to their own offering (navigation, trip planning, travel assistance etc.), and an end user service including functions such as automatic parking payment, support for time-limited parking, “find my car” and QR code validation
  • tools for B2C providers, such as automatic parking payment and clearing, support for time-limited parking, “find my car” and QR code validation.

As well as the Service Directory this use case uses the billing and clearing, identity management and app store features. By using the MOBiNET functionality, together they make it easy for a parking service provider to add new cities to their own parking services, and for cities and car park owners to get their car parks included in parking services from different suppliers.

User benefits

  • More sustainable city by optimisation of available parking facilities and less nuisance for the city community
  • Increased comfort for individual travellers
  • Increased business opportunities for car parking business.

PARKING SERVICES Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
Without MOBiNET the systems would have to be developed as stand-alone systems. A company wishing to implement a parking service with functions like those described above, would have to make separate agreements with all car parks owners, concerning real time data usages and payment collection. Even if this would be possible for a region, it would be a very time consuming task, and almost immense for a country and impossible for the whole Europe. The ‘architecture’ without MOBiNET, would thus be a number of isolated systems with different function and coverages. A driver passing through different areas would thus have to have a range of systems with different user interfaces, languages, functionality and agreements, and it would not be possible to shift automatically between the systems based on the localization. Or more likely, he would have one agreement and system in his hometown and would not have the benefit of parking assistance system when outsides the coverages.

Architecture with MOBiNET

MOBiNET Parking Service and Payment Flow Figure 49 illustrates the architecture with MOBiNET for a setup including as well the B2B data services, the B2C end user services as an optional second B2C services utilizing the B2B data services. The diagram is explained by the text in the previous sections. The important learning from the diagram is the positioning of the MOBiNET system as the unifying element in the middle of the architecture.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

What does the service do
The most valuable traffic data are generated using Floating Vehicle Data (FVD), formerly known as Floating Car Data – i.e. GPS positions of vehicles. However, the current market scenario is still very fragmented and still lacks a point of aggregation. For instance, it is still not easy to look for data in a new country for a company moving its business to a new country.

The B2B Traffic Services (B2BTS) provides two tools to extract valuable information from a sample dataset:

  • FVD profiler, and
  • data quality analyser.

A sample data set may measure several hundred megabytes or a few gigabytes and contain at least tens of millions of positions.

1. FVD profiler
This tool provides as out the following indicators:

  • Status: ok/error description
  • FVD count: day, hour, category name, area name, GPS count
    - day is Monday-Sunday
    - hour is [0-24] where 0 means 00:00:00 - line with hour = 24 report the total
    - the area name of the full dataset is “full_dataset”
  • Travel count: day, hour, category name, area name, count of unique vehicleID/TravelIDs

A travel in general is equivalent to a TravelId unless the difference between two consecutive (in time) records is greater than 30 minutes. In case the difference is greater than 30 minutes a travel is considered ended and a new travel is begun.

This definition is used both when counting travels and when calculating travel durations.

  • Travel duration – hours: time range, count, category name

    Travel durations are divided in ranges of 30 minutes up to 8 hours (16 records). A further record (17th) collects all the longer travels.

    Travel durations are calculated only on the full dataset.

  • Travel duration – first hour: time range, count, category name Travel durations are divided in ranges of 10 minutes up to 1 hour (6 records). Travel durations are calculated only on the full dataset.
  • Output processing

    The output of the tool can be then imported in a database, spreadsheet or other tools to the customer analysis.

2. Data quality analyser

The tool produces as output the following indicators

  • Granularity

    This indicator gives insight about the GPS sampling rate within a dataset, meaning the overall frequency of GPS transmissions within a dataset. The granularity thus measures the regularity of the information in comparison to the expectation we have based on a specific context.

  • Missing Data

    GPS devices generally transmit data at a fixed rate. However, due to malfunctions or human error, datasets may present gaps i.e. black-holes between some GPS transmissions.

  • Reliability

    This indicator assesses how logical the data is in describing mobility traces, i.e. if the provided data is reliable.

The service is composed of a business process and tools

Use of MOBiNET
There are several actors involved in the provision of this service. The following table shows their roles and characteristics:

Actor Role Description
Data Operator (Data Provider) B2B service provider This actor represents the Fleet or System operator that is interested in selling its data
Traffic Telematics Platform (tools to support) B2B service provider This the MOBiNET platform
Mobility/Content provider B2B service provider/B2C service user This actor is interested in buying additional data and to verify it
Technology Service Provider B2B service provider This actor represents additional service providers that gives tool to evaluate the FVD data

Benefits of using MOBiNET
The MOBiNET platform can support the B2BTS mainly providing a e-marketplace as a unique point of contact among data sellers and data vendors.

In addition, the capability of the platform to host services developed by third parties allows to create an eco-system where providers of data analysis tools can

  • make easy and cheap to analyse FVDs
  • allow data providers to advertise their data along with quality results
  • allow data buyers to analyse a sample data set during the business negotiation
  • allow competition among data provider
  • allow competition among providers of data analysis tools.

Architecture without MOBiNET
Currently the FVD market is up and running but without MOBiNET

  • the process of looking for GPS or sensor data providers has to be done via internet searches, personal/business contacts, etc.
  • profiling and quality analysis tools has to developed internally.

Architecture with MOBiNET

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service provides a booking system for door to door travel for people with disabilities. Users will receive automated alerts sent to them warning of imminent vehicle arrival.

Use of MOBiNET within the service

  • Service directory where new data/service feeds will be provided from vehicle tracking and traffic analysis, as well as existing public data feeds provided by the city of London
  • Billing usage to invoice third parties who want to use the ETA service component
  • MOBiAGENT can provide better access our (and others) data feeds to 3rd party developers.

Benefit of using MOBiNET

  • Improve the efficiency of the London (TfL) fleet thanks to the development of a generic Automatic Vehicle Location (AVL) solution, its trial across different vehicle types (minibus, van, car), and use of the data feed from these vehicles for modelling, alerts, scheduling purposes
  • Provide ideas to other cities of possible uses for such technology
  • Allow third party developers to implement innovative applications from the published data feeds and services.

The DaR (dial-a-ride) use case was developed for a dial-a-ride service for elderly and disabled passengers in London. MOBiNET allows the combination of real-time bus arrival data with traffic information (to estimate arrival times), payment and user identification. It helps to connect the passengers, the bus driver and the operations centre through a single back office. A user app is available from the app store, and could be used by service providers elsewhere than London via the service directory. The service needs multiple online elements to be discovered and brought together, and would allow Transport for London to market the B2B and B2C applications to other users.

User benefits

  • More sustainable society with cost benefit and increased well-being for citizens
  • Increased effectiveness and cost benefit for public transport providers by better segmenting their markets and refocus their service offerings
  • Increased comfort for travellers with disabilities and the nurturing communities who support them.

Architecture without MOBiNET
The current DaR services controlled and regulated by a management control centre which handles all calls received from the passengers for making bookings. The drivers are provided with the bookings information at the start of their journey to complete during the course of the day. In the events of cancellations, the control centre informs the driver by leaving a voicemail message on the driver’s mobile phone (the figure below represents the current system architecture). The schedule from Trapeze takes into account traffic historical information: typical travel speeds of road elements are stored in Trapeze DB. A user can modify or cancel the reservation the same day of the departure. In this case Trapeze system updates the schedule in its system. However, there is no telematics communication between Trapeze Back End and the Vehicle. This means that the DaR BackOffice operator has to phone the driver to update the schedule (cancellations, modifications). This is the reason why it is important to interface Trapeze via web services (a static method would not allow dynamic changes).

Architecture with MOBiNET
Dial-a-Ride service is a not chargeable service.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service is to provide information on real time incident warning a driver who registers for the service.

Use of MOBiNET within the service:
  • Service Directory
    – Link to data/content providers
  • Road authorities, FCD data providers, map providers
  • TNO is content provider for A270 motorway
    – Provide RTTI service
  • App Directory
  • Dashboard & SDK
  • Communication Agent
    – Communication Manager
    – TNO develops an Android RTTI app.

Benefit of using MOBiNET

  • Distribution of RTTI services to other locations
  • Easy for third party content providers to provide data (without necessity to implement the whole chain)
  • Easy migration of the integrated 3G/G5 RTTI service from the Netherlands.

The RTTI use case shows the benefits of MOBiNET Service Directory for publishing real-time traffic incident and speed advice data from a specific road network in the Netherlands. This could be easily added to the services of any provider of traffic information (i.e. for dynamic route guidance) to users; it decouples traffic data from the user services and expands the potential customer base for B2C service providers. It means the service provider can find everything needed for service composition at a single source, and can add this particular data source automatically to his user app (that can also be advertised in the app store).

User benefits

  • More sustainable society by optimisation of traffic, increased productivity of businesses and increased human well being
  • Increased comfort and productivity for drivers by better time management.

RTTI Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
ZOOF is a service similar to the RTTI services ( and is developed in the ‘A58 Traffic Jams” project. ZOOF is based on functionality that is similar to RTTI in the back office, V-ITS-S, R-ITS-S and smartphones. ZOOF, however, does not use the architecture or components of MOBiNET. In this project the traffic data is directly provided to the RTTI service, and the RTTI advices are provided by a proprietary web service to its own end-users. In this project, there is no functionality like a Service Directory, and the functionality of the Communication Agent and MOBiAGENT are proprietary.

Architecture with MOBiNET
Two (B2B) data providers, offering real time traffic data, such as traffic status, and locations of road works:

  • The B2B data provider for the real time traffic status asks a fee for this to B2C service providers (not to end-users, there is no relation between the B2B data provider and the end-user) and publishes the link to the data in the SD;
  • The B2B data provider for traffic events, such as road works, offers this for free and publishes the link to the data in the SD as well. Two B2C service providers:
  • The B2C RTTI service provider uses the data (both real time traffic status and RWW) to give speed advices and warning to end-users who have their RTTI app. The RTTI app is published in the SD;
  • The end-user pays a monthly fee to the B2C RTTI service provider and that he “pays” with his FCD data as well. Also a second B2C service provider who has an app for end-users (published separately in the SD) and wants to incorporate the RTTI speed advices in his app. This service provider pays a fee to the RTTI B2C provider (monthly or per end-user).

Cross reference with deliverable
You will find a fully updated report on this service in the following report.

This service is a mobile, location-based social media service which uses audio messages to enable contextual voice communication between end users, location-based audio information distribution from 3rd party service providers, and crowdsourcing of mobility related data.

Use of MOBiNET within the service

  • Service Directory for the VoiceInfo service registration, to dynamically change the VoiceInfo backend depending on the context (e.g. location) and preferences, as well as to check which B2B content and service provider to use depending on the end user context. The VoiceInfo service backend also utilizes text-to-speech service found in the Service Directory for speech synthesis
  • MOBiNET User Interface & Identity Manager for end users sign up and sign in
  • VoiceInfo app discovery via the MOBiAGENT, which is also used to obtain positioning and vehicle data.

User benefits
VoiceInfo uses several MOBiNET components & features to allow users to report traffic incidents to a service centre that also distributes traffic information back to its customers. The needed third-party services and service enablers are accessed from the Service Directory, allowing the app and the service to be made available anywhere in Europe.

  • More sustainable society by optimisation of travel for individual travellers
  • Increased comfort for individual travellers.

VoiceInfo Use case demo @ ITS World Congress, Bordeaux, October 2015

Architecture without MOBiNET
The general architecture of VoiceInfo (Figure 71) is based on a client-server model where:

  • users are communicating using audio messages with their VoiceInfo client applications,
  • VoiceInfo server is conveying the audio messages to other users depending on the location or selected channels according to (optional) predefined rules, and
  • third party information systems are connected to VoiceInfo server offering additional information to the users as well as to collect traffic related data and user generated information.

Architecture with MOBiNET
Figure 72 depicts how VoiceInfo general architecture integrates MOBiNET components. MOBiNET Service Directory is used to dynamically contextualize VoiceInfo and orchestrate the third party services utilized by VoiceInfo. Timing and positioning sub-component of MOBiAGENT is used to obtain position in user terminal information, which enables easily the use of additional positioning methods to complement mere GPS information where needed. Furthermore, the Identity Manager is used both for automatic login to VoiceInfo with MOBiNET credentials and for checking the authorization of the VoiceInfo client. See further information later in this document.

Cross reference with deliverable
You will find a fully updated report on this service in the following report.