MaaSP – Mobility as a Service Protocol

Mobility as a Service (MaaS) is the seamless combination of transport modes for a customer’s mobility needs – almost like code sharing of different airlines for one trip. MaaS trips could comprise own vehicles, public transit, bike share, car share, ride hail, taxis and more. Mobility as a Service could reduce traffic, emissions and congestion and improve customer experience at once.  Currently it fails as the different mobility service providers cannot exchange information about a traveler’s needs and matching multimodal or intermodal mobility services. They are lacking a common language – a MaaS Protocol. This blog post outlines some first steps into this directions and their contributors.

Potential Benefits

Mobility as a Service only works if all players combine their services into one single customer journey. The potential benefits are obvious:

Passenger Benefits

• Perfect combination of transport modes for every mobility use case
• One ticket for the entire trip with all modes of transportation
• No need to own a vehicle – or they leave their car at home
• Cost-efficient and convenient to pay with one ticket

Mobility Provider Benefits

• More business through network effects
• Focus on core competency

At the Berlin mobility think tank Institute for Urban Mobility, this topic has recently been discussed and a third beneficiary was uncovered: the society.

Benefits for the Society

• Improved mobility, i.e. optimized combination of mass transit for longer distances and individual transit on the first and last mile allows passengers to get faster from A to B
• Reduced emissions and and so improved health and reduced risk of traffic bans
• Reduced traffic area needed, i.e. less need for parking lots and streets

Purpose of a Common MaaS Protocol

A common protocol would serve as a common language for all transport providers. It could enable the following functions of a MaaS system:

• Matching
  of a passenger’s request with available transport services
• Orchestration / Coordination
  of multiple services for intermodal mobility
• Ticketing and Billing
  of the combined mobility services in one single ticket and invoice – splitting the revenues between all involved mobility service providers
  

Matching demand with supply is the core functionality. There is a minimum set of essential information which must match, i.e. enough seats for all passengers in a vehicle with runs from the origin to the destination at the right date and time. Additional information are of less importance but still relevant for a good match, e.g. a passenger would not be happy if their taxi can take all passengers but has no space left for the luggage or the wheel chair and costs more than they can afford. 

All these information need to be provided in a standardized way, which allows an automated matching of demand and supply. Once the services are selected, the orchestration of the single services can become highly complex. Delays and missed connections need to be considered as well as modifications or cancellations both from passengers as well as from mobility service providers. Also combining all used mobility services into one single ticket with one invoice and sharing the revenues between them is everything but trivial.

Existing Protocols: Supply Side

A lot of work on defining standards has been done on the supply side already. Players in this field often approach it from very different view points:

There are quite some more or less open protocols describing the availability of mobility services

• General Transit Feed Specification (GTFS)
  Google’s global protocol was designed to allow public transport providers to describe their time tables for a visualization in Google Maps
• Network and Timetable Exchange (NeTEx)
  VDV/CEN standard for the exchange of scheduled data (network, timetable, fare) of public transport services
• Open Journey Planner (OJP)
  Open API for distributed journey planning of public transport, based on former standards with a similar purpose, i.e. JourneyWeb, DELFI, TRIAS, and EU-Spirit 
• Open Travel Alliance (OTA)
  Open API for trip planning with a clear focus on the travel industry incl. trains, rental cars and travel itinerary data
• VDV-Schrift 453 and 459 (VDV)
  On-demand protocol for shared taxi services of the VDV (Verband Deutscher Verkehrsunternehmen = Association of German Transport Companies)
• MaaS Transport Service Provider API (MaaS TSP API)
  Open Source protocol developed by MaaS pioneers behind the famous Whim app provides MaaS core functionality
• New Distribution Capability (NDC)
  IATA’s XML-based data transmission standard enhances the communication between airlines and travel agents
• Mobility Data Specification (MDS)
  The City of Los Angeles has developed this open data standard and API spec for micro mobility providers, who work within the public right of way.
  A new initiative has been derived from the development of MDS: the Open Mobility Foundation
  
• General Bikeshare Feed Specification (GBFS)
  GBFS has been established for bike sharing services
• TSio Protocol
  Mobility account infrastructure from TravelSpirit Foundation and Iconic Blockchain
• Mobility on Demand Alliance of the ITS America

Gap 1: Supply either covers public transport or travel industry services only but no ride hailing, car, scooter or bike sharing, … and no combination of the two sectors

Gap 2: No consideration of the user’s own means of transport, i.e. their own car, bicycle, walking capability, …

Existing Protocols: Demand Side

Passengers can currently request schedules of different means of transport or request taxis or ride hailing services on demand but they cannot capture their transportation need in a standardized format to be shared with multiple mobility service providers.

• No known open protocol describing the demand side of intermodal mobility requests

Gap 3: No open standard for trip requests

Travel Itinerary

After booking a trip, it can be documented in an travel itinerary including all means to transportation often in combination with accommodation.

• Passenger Name Record (PNR)
  Airline industry standard for travel itineraries
  … available only for booked tickets but not for booking requests

The existing standards are an important step into the right direction but they are lacking some modes of transport, do not consider the passenger’s own means of transport and they are lacking the demand side for an automated matching. In 2015 the Interoperable Transit Data Consortium of the Rocky Mountain Institute (RMI) and Trillium Solutions started to work on this topic.  They might be a good point of contact for everybody working on this topic.

Any protocol or API definitions which should get widely accepted in a global mobility ecosystem would also require a global, neutral and respected consortium governing the standard.