1 Introduction
Dynamic ridesharing and ridesourcing have gained significant traction in recent years (Agatz et al. 2012, Mourad et al. 2019) as ondemand mobility services for transporting customers from one city location to another. For US cities only, it is estimated that 2.61 billion passengers were transported by these services in 2017, reporting a 37 increase compared to 2016 (Schaller Consulting 2018). Ridesourcing provides prearranged and ondemand transportation services where drivers of personal vehicles are matched with the passengers and receive compensation (Jin et al. 2018). Ridesourcing services are also referred and associated with several other names including transportation network companies (Pratt et al. 2019), realtime ridesharing (Masoud & Jayakrishnan 2017, Vivoda et al. 2018), ridehailing (Xu et al. 2019, Alemi et al. 2019, Young & Farber 2019, Contreras & Paz 2018), ehaling (He & Shen 2015) and ondemand rides (Rayle et al. 2016). The founding concept of ridesourcing is that a customer hires a driver to take her/him to a specific destination, characterizing itself as a personal transportation experience (Lavieri & Bhat 2019). Known possible drawbacks of ridesourcing are the problem of empty vehiclesmilestraveled and congestion phenomena (Nie 2017). As a possible attempt to mitigate this, ridesharing, also referred as carpooling or vanpooling, facilitates shared rides between drivers and passengers with similar origindestination pairings, and allows travelers going from one destination to the other to pick up other passengers on the way (Shaheen et al. 2015, Coulombel et al. 2019). Scheduling routes that are matching customers’ preferences and needs requires to consider a specific class of vehicle routing problems, namely the dialaride problems (Ho et al. 2018, Fu 2002b). In dialaride services, the provider aims to minimize operations costs or level of service, while satisfying demand and customers’ constraints (Cordeau & Laporte 2003, Parragh et al. 2008). Addressing the human end economic perspectives in largescale network increases the problem complexity, and necessitates tailored solution approaches (Muelas et al. 2015, Bongiovanni et al. 2019) and taking conflicting objectives into account (Guerriero et al. 2014, Marković et al. 2015). Dialaride problem arise in transport services such as paratransit, or demand responsive transit, for mobilityimpaired individuals (NguyenHoang & Yeung 2010, Deka & Gonzales 2014, Phun et al. 2018). Paratransit enhances the public transport means with individualized trips and doortodoor services; it involves challenging implementation problems, specifically the scheduling of routes in largescale networks (Dikas & Minis 2014, Karabuk 2009) , the integration in the existing traffic levels (Phun et al. 2018), evaluation of operational costs (Schalekamp 2017, Fitzgerald et al. 2000, Gupta et al. 2010) and coping with uncertain demand (Bearse et al. 2004) and traffic conditions (Fu 2002a).
In this research, we focus on the ridesourcing services, including the possibility of ridesplitting (Li et al. 2019), meaning to encompass ondemand sharedmobility services. We adopt the term ridesharing to refer to this kind of services: this helps to position this paper in line both with established Transportation literature for ondemand sharedmobility services (see, e.g, AlonsoMora et al. (2017a), Simonetto et al. (2019), Chen et al. (2017a), Wang et al. (2019), Lei et al. (2019), Di et al. (2018)), and the recent tendency of ridesourcing providers (e.g., Uber and Lyft) to offer ridesplitting/carpooling services and therefore entering in the ridesharing space (Schwieterman & Smith 2018, Moody et al. 2019). The possibility that passengers have to share vehicle routes is heavily exploited in the design of the services proposed in this paper, by dynamically inserting pickup and dropoff requests in the vehicle schedules.
The effects of ridesharing services are mixed: on the one hand, they offer a convenient and reliable way to meet travel demand, and enable to increase car occupancy (Fiedler et al. 2018), but on the other hand they can also lead to increased congestion when there is excess supply of vehicles. It is estimated that ridesharing mobility added 5.7 billion miles of driving (Schaller Consulting 2018) in the metropolitan areas of Boston, Chicago, Los Angeles, Miami, New York, Phildelphia, San Francisco, Seattle, and Washington DC alone. An evergrowing number of private ridesharing companies (e.g., Uber, Lyft, Didi Chuxing, and Via) participate in the ridesharing market. These companies naturally compete for the same set of resources (i.e., customers) to gain a significant market share. In an unregulated environment, this competition certainly leads to nonoptimal behaviors, in terms of the number of vehicles present on the roads, and of the quality of the service achieved. As indicated by the NYC Taxi and Limousine Commission Summary Reports (NYC 2019), the number of daily trips for Taxis, Uber, and Lyft has changed from roughly 500k, 80k, and 0k in the first quarter of 2015 to 300k, 500k, and 140k in the last quarter of 2018. At the same time, the same reports find that while the number of taxis has decreased from about 20k to 15k, the number of vehicles for Uber has increased drastically from 12k to 76k, and for Lyft went from 0k to 46k (see Schneider (2016)). Therefore, it is clear that the two main ridesharing companies, Uber and Lyft, have supplanted the New York taxi company, and that their growth is still ongoing. This raises questions about the fairness of the competition and the level of congestion that such growth may be causing.
The development of largescale ridesharing solutions, dealing with thousands of requests and vehicles in realtime, is an emerging and challenging topic of research. Very recent research investigates the advantages of introducing meeting points in terms of cost savings and congestion mitigation (Stiglic et al. 2015), the consideration of riders’ satisfaction and privacy rights (Aïvodji et al. 2016), the integration of ridesharing in multimodal systems (Yan et al. 2018, Liu et al. 2018), the offering of tailored pricing schemes (Sayarshad & Gao 2018) (e.g., for regular such as commuters (Liu & Li 2017, Ma & Zhang 2017)), the study of the changes in travel patterns induced by such ridesharing systems (Dong et al. 2018), the evaluation of performance metrics (Najmi et al. 2017), and the consideration of ridesplitting as a binary classification problem (Chen et al. 2017b).
In this paper, we consider as a building block the works of AlonsoMora et al. (2017a), Simonetto et al. (2019), which provide solutions for solving the centralized realtime cityscale ridesharing problem, by mapping incoming batches of requests with available vehicles, in a threestep procedure: (i) selecting candidate vehicles to serve requests, based on vehicle location and seat occupancy; (ii) computing assignment costs incurred for serving a request with a selected vehicle, while meeting customer constraints, by solving a DialaRide problem (DARP) (Cordeau 2006, Häme 2011, Liu et al. 2015);(iii) performing optimal assignments of requests to vehicles, given the assignment costs determined in step (ii). In Simonetto et al. (2019), it is highlighted that linear assignments can perform as good as more elaborated assignments, when run at a high enough sampling rate. Simonetto et al. (2019) shows that optimizationbased approaches for ondemand ridesharing can provide a high level of service while limiting the growth of the fleet size. Specifically, it is shown that of the current trip demand in Manhattan, available via the New York Taxi dataset (NYC Taxi and Limousine Commission dataset 2019), can be satisfied with only 20 of the current taxi fleet (AlonsoMora et al. 2017a). In a similar fashion, the work of Lokhandwala & Cai (2018) argues that the taxi fleet size can be reduced by 59 if shared autonomous taxis are used while considering individual customer preferences. Such largescale ridesharing solutions propose a centralized way of dealing with customer requests, which requires a central coordinating agent or broker. However, in practice, there is no such centrality, as every customer will book a ride via the proprietary smartphone app of a given company. In fact, companies will compete for accommodating as many customers as possible, and the overall behavior of the system may be far from the centralized one.
The consideration of decentralization due to the multiple actors of the transportation network, which may involve some degree of cooperation and competition between these actors, is often overlooked, as noted by Wang & Zhang (2017). In fact, as for ridesharing mobility, few works focus on noncentralized systems. A first work focusing on the taxi industry is the one of Cairns & ListonHeyes (1996) which shows that regulation of fares and fleet sizes is essential in a multicompany competition context. In another pioneering work (Yang et al. 2002), a demandsupply equilibrium of competitive taxi services is formulated based on a network model. The model can then be used for the regulation of taxi fleet sizes and fares across companies. In the recent work of Qian & Ukkusuri (2017), the taxi market is modelled as a multiple leaderfollower game, where the leaders are the passengers, while the traditional and third party taxi services are the followers. An approximate Nash equilibrium is proved to exist for the model and the fleet size and pricing policy are shown to be tied to the level of competition, which in turn has several impacts in terms of the quality of the service achieved. These decentralized models rely on the assumption that companies are willing to share information on their vehicles (e.g., location). This may not be a realistic requirement for competing ridesharing providers.
In this work, we aim at providing a first analysis to quantify the effects of competition between ridesharing companies at a cityscale. This effort fits well into the ongoing reconsideration of mobility services, including the emerging Mobility as a Service (MaaS) business models (Goodall et al. 2017). The recent contribution of (Séjournè et al. 2018) quantifies the rebalancing burden caused by the demand fragmentation between multiple companies, but neglects competition forms. In the context of the above literature, we move away from the centralized cityscale ridesharing solution and propose a cooperative and a competitive approach, which consider the current multicompany ridesharing landscape. The proposed Cooperative model does not require companies to share any proprietary information about their fleet, and may be well suited to the use of Mass platforms. The Competitive model does not require any information sharing inbetween companies: it first corresponds to the situation of customers booking rides via a broker that provides the best offer among the companies, and it also enables to evaluate the brokerfree situation where customers book rides via one ridesharing company app on their smartphones.
In order to evaluate advantages and limitation of the Cooperative and Competitive models, we compare them with a Centralized model, obtained by adapting the work of Simonetto et al. (2019) to the multicompany setting. Hence, a suitable proxy for an efficient Centralized model for multicompany ridesharing systems is as follows: (i) the system collects batches of customer requests for a given time period, e.g., 10 , (ii) the companies compute the costs for inserting requests in each vehicle route, by solving a DARP problem, (iii) those costs are shared with the broker, (iv) the broker solves the Linear Assignment Problem (LAP) to optimality and sends the updated assignments of vehicles to requests (v) the broker adopts a rebalancing strategy for the unserved requests, which means running steps (i)(iv) with loose time constraints. This process is repeated for every batch of requests. In particular, in Simonetto et al. (2019), the authors highlight that onetoone assignments of customer requests to vehicles provide very high service rates in a dynamic context, and suggest that a myopic search for optimal multipletoone assignments of customer requests to vehicles is not necessary, and not beneficial from the computational point of view. In this context, the centralization of the ridesharing solution comes from the need for a broker that collects the costs and solves a centralized LAP.
In this work, we put emphasis on ridesharing services where the companies participating in the cityscale ridesharing demand and supply process either share limited information or do not share information with a central broker. In these settings, the implementation of a centralized communication protocol is not possible. To our knowledge, this is the first work to bring insights on the quality of the ridesharing services in such realistic communication and information sharing settings.
The contributions of this work are the following:

We propose a Cooperative model of ridesharing that relies on a broker receiving only limited information from all companies. Variants of this model include the consideration of noise, i.e. the bids shared with the broker are not exact, and bias, i.e. a company may systematically under, respectively overestimate the costs it shares – the underestimation may be even wanted as a proxy to discount costs and appeal to a larger number of customers.

We prove that this Cooperative model, in the absence of noise and bias, achieves optimal assignment solutions, i.e. its solution is the same as the centralized approach. Our result is based on the work of Naparstek & Leshem (2014).

We propose a Competitive model that aims at capturing the current status of ridesharing in cities, where companies route their vehicles to serve as many requests as possible, and each customer may choose the best offer across these noncooperative companies. A very relevant variant of the model is the consideration of customer preferences, where the customers may prefer to be served by a certain company, even if another company would offer a lower cost. Preferences can be flexible and ignored, if the difference between the cost offered by best company and by the favorite one is lower than a certain threshold, or they can be strict if, e.g., customers book rides through the proprietary app of a given company and only have access to the offering of that company. We consider both these cases and a mix thereof.

We prove that the Competitive model degrades the centralized optimal cost by a factor 2 in the worst case when two companies are involved, and by a factor 3 in the worst case when more than two companies are involved.

We test the performance of the cooperative and competitive models and their variants on different cost matrices, in a static setting, which confirms the previous results and allow us to draw first conclusions regarding the influence of the protocols on the gap to optimality.

We conduct tests on largescale ridesharing instances, using the NYC Taxi dataset (NYC Taxi and Limousine Commission dataset 2019). and we provide recommendations on ridesharing control policies, in particular in the context of MaaS platforms.
The remainder of this article is organized as follows. Section 2 presents the overall architectures for Centralized, Cooperative, and Competitive models. Section 3 and Section 4 present a theoretical analysis on the Cooperative and Competitive models, respectively, with results proving optimality for the cooperative case, and bounds on the gap to optimality for the competitive case. Section 5 reports the computational results on the New York City taxi fleet data set, for the different considered protocols and their variants. We conclude in Section 6 with a summary of our findings and future research perspectives.
2 Models and architectures for dynamic ridesharing algorithms
We present here the models and architectures for the dynamic ridesharing algorithms. We start from the centralized algorithm put forward in Simonetto et al. (2019), which serves as a stepping stone to investigate cooperative and competitive approaches for multicompany ridesharing. One key feature of Simonetto et al. (2019) is that the optimal assignment problem is reduced to a Linear Assignment Problem (LAP), which scales very well in terms of number of requests and fleet size. This reduction is possible by the design assumption that only one new request can be assigned to a given vehicle per sampling period. We call such assignments singlerequest assignments. As shown in Simonetto et al. (2019), on one hand, if the sampling period is small enough, then singlerequest assignments are not detrimental to service quality; on the other hand, this assumption unlocks important computational and algorithmic advantages, e.g., lower computational effort, and the possibility to run the algorithm in a distributed fashion, which will be further exploited here.
2.1 Preliminary: Ridesharing logic
We formalize here the ridesharing problem under consideration. The centralized ridesharing logic is the one considered in Simonetto et al. (2019) for the singlecompany case. The reader is referred to Simonetto et al. (2019) for detailed discussions.
Let denote a set of customer trip requests at time and denote a set of companies. For a given batch of requests, each company has a fleet of available vehicles, denoted by set , which are available for the customers to request. The set contains all the available vehicles, i.e., . Let denote the company to which a vehicle belongs. Each vehicles has its own seat capacity. The ridesharing problem consists in providing a realtime assignment of requests (customers) to available vehicles and their correspondent routes, while minimizing the total travel times of vehicles. Available vehicles are those that can pick up customers, while complying with the time constraints associated with the requests, and without exceeding their seat capacity.
The ridesharing logic is run at specific time instants ():

It obtains the customer requests submitted during the time interval .

It sends requests to context mapping module, which filters the closest vehicles to each customers pickup point (see Section 3.2. of Simonetto et al. (2019)).

It asks customer assignment costs to the vehicles filtered by the context mapping module, by solving a DialaRide Problem (DARP).

It calls an optimization module to determine optimal assignment of requests to vehicles. Simonetto et al. (2019) showed that, if the sampling window is small enough, then the assignment of requests in batches leads to minimal losses of service quality (see Section 4.2).

It sends the assignments and their corresponding routes to customers and vehicles.

If some customers cannot be served, it calls an internal rebalancing module, which runs the logic again from (2. to 5.) with relaxed time preferences and for idle vehicles (i.e., without passengers) only (see Section 3.5. of Simonetto et al. (2019)).
The ridesharing logic involves two optimization problems: a DARP which estimates the assignment costs of requests to vehicles, and an assignment problem to allocate the requests to available vehicles, at minimum travel time.
DialaRide Problem.
At the level of each company, and independently of the communication protocol in place, every time a new batch of customers is processed, each vehicle is required to estimate the time duration of the route that serves the already scheduled customers and each new customer . This is accomplished by solving a singlevehicle DialaRideProblem (DARP) Häme (2011), Liu et al. (2015), Ropke et al. (2007), with the aim of minimizing the route duration. In particular, the input for DARP for vehicle is: (i) the customers to be served in the future, consisting of the new request , and the scheduled customers in the current route (determined in the previous optimization run), (iii) pickup and delivery locations and time limitations/preferences of the scheduled customers, (iv) current location of the vehicle and its capacity , and (v) the matrix of the travel times between pickup/delivery locations, location and request . The output of the DARP is expressed as:
(1) 
where:

is a route for vehicle , with a pickup and dropoff schedule that serves request and the customers scheduled in route

is the time duration of .
The DARP (1
) is solved via an insertion heuristic (formalized in Algorithm 1 by
Simonetto et al. (2019)), which evaluates the extra travel time that vehicle incurs to when adding request in a feasible position in the scheduled route . In our implementation, the first feasible insertions of request in route are evaluated and the best of the (in terms of travel time) corresponds to the new route in equation (1). Being a constructive heuristic, this solution approach does not require to consider subtour elimination constraints. We remark that, for each request , only the vehicles filtered by the context mapping module are required to estimate the insertion cost: this limits the number of singlevehicle DARPs to solve in each optimization run. Under the assumption that only one request can be assigned to the previously scheduled routes, multiple new requests are not interfering in the DARP of a fixed vehicle in a given time instant.In the ridesharing optimization, is the cost for assigning vehicle to request required in Step 4 of the logic.
Assignment Problem.
As described in Steps 4 and 6, a linear assignment problem, is solved twice in each sampling period: first, to seek an optimal assignment of requests to available vehicles, and then to rebalance vehicles to satisfy unserved requests, by relaxing time preferences specified in the requests. Let denote a set of customer trip requests at time and denote a set of companies. For a given batch of requests, each company has a fleet of available vehicles, denoted by set , which are available for the customers to request. The set contains all the available vehicles, i.e., . Let denote the company to which a vehicle belongs. Each vehicles has its own seat capacity and can accommodate multiple customers at any time.
Having computed the assignment costs, let
be the set of binary variables:
only if vehicle is assigned to customer , otherwise . We further denote by the customer assigned to a vehicle , that is, .For our optimization structure, in each sampling step we seek to assign each vehicle to exactly one new customer. In other words, vehicles can be assigned to multiple customers over successive time steps, but never within the time step. This is formalized by the following linear assignment problem: equationparentequation
(2a)  
subject to:  (2b)  
(2c) 
where, without loss of generality, we assume that the number of vehicles is equal to the number of new customers, . Note that if this is not the case, one can augment the vehicle set or the customer set with dummy vehicles/customers with infinite assignment costs.
The goal of the optimization is to minimize the total assignment costs (2a): in our implementation, is expressed as the time duration (or TD) of the route of vehicle that serves the already scheduled customers and the new customer . The solution of the assignment problem needs then to be interpreted for practical feasibility, given the value of the assignment costs. If an infinite cost is in solution, then vehicle will not insert request in the route, and customer would be a candidate for the relocation phase. Provided that all the costs are precomputed, then (2a2c) can be casted as a symmetric LAP (Kennington & Helgason 1980, H. Papadimitriou & Steiglitz 1982, Bijsterbosch & Volgenant 2010). It is well known that LAPs have a totally unimodular constraint matrix, hence their continuous relaxation (i.e., substitute with ) is exact. We exploit the available efficient solution algorithms for LAPs, in particular the auction algorithm (scaling up to requests), see e.g. (Bernard et al. 2016, Bertsekas 1990).
2.2 The three models of multicompany ridesharing
In this section, we give further detail on the three models of interaction between ridesharing companies, ie., the Centralized, Cooperative, Competitive models, along with their variants of practical interest:

The Centralized model where a broker (or central authority) collects all the customer requests, asks the companies to compute the costs associated with assigning their vehicles to any customer, receives their costs, which are then collected in a linear assignment problem LAP(), which it solves. The LAP can be solved using efficient and scalable algorithms, e.g., centralized auction algorithms (Bertsekas 1990).

The Cooperative model where the broker does not require access to the matrix of all the costs for every vehiclerequest pair (from which it could reconstruct companyprivate information, e.g., vehicle locations in the Centralized model), instead the broker interacts with each company by iteratively asking for the best prices for the yet unassigned customers. This model, which is essentially an extension of the distributed auction algorithm of Naparstek & Leshem (2014), runs until all customers are assigned to vehicles. It relies on a distributed architecture, and it minimizes information sharing (no proprietary information of the companies is shared) but, as we shall prove, still enables to solve LAP to optimality. Extensions of this protocol introduce stochastic noise in the computation of the ’s, which can come from the vehicle positioning errors and the routing computations, and bias as the routing/map service may be different among the companies and a given routing service may provide consistently shorter/longer travel times compared to others, or a company may use discounted costs to attract more customers. Models of cooperation have been investigated in applications such as logistic shipping (see Irannezhad et al. (2018)).

The Competitive model where there is no broker to coordinate the assignment process, and customers send their requests either to a webservice (which finds the best deal) or to a company application on their smartphone. Each company solves a companywide LAP() and submit potential assignments directly to the webservice or to the customer apps. The customers who receive an offer (either through the webservice or to the app) then select the best offer among the companies (considering them rational agents) and are considered assigned. Each company then resolves the assignment considering all unassigned customers. The process continues until all customers are assigned. An extension of this protocol is to consider customer’s preferences. Specifically, each customer is willing to pay an extra cost to his preferred ridesharing company even if another company would offer a lower cost. Preference can be flexible and ignored, if the difference between the cost offered by best company and by the favorite one is lower than a certain threshold, or they can be strict if, e.g., customers book through the proprietary app of a given company and only have access to the offer of this company, in which case each company solves a companywide LAP(). Noise and bias can be incorporated in the Competitive model, as well.
We argue that the Centralized protocol is not suitable for the practical implementation of multicompany ridesharing. This is because each companyowned vehicle would need to communicate directly to the broker the assignment costs. Hence, each company would disclose proprietary information with the broker. For this reason, the scope of paper is to analyze the solutions of the Cooperative and Competitive models.
In Figure 1, we present the Centralized architecture. The requests are collected in batches of few seconds by a broker which lives on the public/city cloud or it is provided via a MaaS platform. The broker sends the requests to all the registered companies. Each company cloud, denoted , consumes at time instant the entire group of requests arrived in interval . First it runs a context mapping algorithm, which consists in filtering the vehicles that could serve the new customers, given their mutual geographic location. In other words, there is no reason to ask a vehicle on a route that is on that side of the city to see whether it could accommodate a new customer on this side of the city. This module considerably reduces the communications and computational requirements: in other words, if requests have arrived, and is the number of vehicles that can serve a request upon applying context mapping of company , then at most DARPs are solved in each optimization run. As will be discussed in Section 5.2, the number is set to for every company . However, the centralized architecture could also be able to cope with company clouds with different context mapping capabilities.. Second, each company asks its selected proprietary vehicles to compute the cost of incorporating customer into the schedule of vehicle (this is done solving a DARP with possible timewindows constraints, as described in Section 2.1). Third, the company cloud sends the collection of for all the requests and all its vehicles to the public cloud. The broker collects all the costs coming from all the companies and builds the LAP(), which it is solved on the public cloud and determine the final vehicletocustomer assignment and schedule. This information is sent both to the customers and to the companies.
The unmet requests are then reprocessed in the same way. The broker sends to the company clouds the unmet requests flagged as unmet. The companies run the context mapping with a much looser search radius and ask their selected vehicles to determine the cost of accommodate the requests, with much looser constraints (e.g., no time windows). The costs are collected and then sent to the broker who instantiate another linear assignment problem. The assignments that result from the LAP may not be suitable for the customers, who can refuse the match, or accept it at a lower price. The reason to run the rebalancing is that idle vehicles will move towards areas where the demand is higher. We refer the reader to Simonetto et al. (2019), AlonsoMora et al. (2017a) for further details on this rebalancing strategy.
As discussed, the need for centralization arises from the collection and solution of LAPs. We present next two different ways to overcome this point which yields cooperative and competitive solutions.
In Figure 2, we present the Cooperative architecture. We explicitly exploit the distributed auction algorithm of Naparstek & Leshem (2014) to solve the LAP. In this architecture, the broker collects and sends customer requests and it receives bids from the companies and by successive iterations of the distributed algorithm, it can deliver the same optimal solution as if all the costs were collected and the centralized LAP() was solved. We will elaborate on these claims in Section 3. The routing engine is the service that helps compute the costs needed for the DARP and assignment problems. It is important to note here that the initial LAP and the rebalancing one are solved iteratively (for each batch) via a distributed algorithm which collects the required information from the companies. In particular, the bids consisting of the difference between the 2 lowest costs for vehicles to serve each customer are collected by the broker. Customers are then assigned to vehicles with the highest bids, independently of the company. The process is repeated until all vehicles are assigned. The toplayer, i.e. the broker/city authority, coordinates this bidding process. Note finally that as we shall see in Section 3 the number of iterations to reach optimality is bounded and, if latencies are handled correctly, one can expect this bidding process to be much faster than the sampling period.
In Figure 3, we present the Competitive architecture. In this architecture, the companies do not share costs or bids, but only desired customers to be served. In fact, the companies receive the trip requests via the broker and decide internally how to best accommodate them, by solving their own assignment problems LAP(). These LAP yield wanted onetoone assignments that are then shared with the public cloud. Here the broker selects the best assignments for all the customers in their best interest, i.e. it select the lowest costs. The companies then reiterate the competition on the unassigned customers, until all the customers that can be assigned, i.e., whose trip constraints are met, are assigned. The same process can be applied to rebalancing.
This architecture may be slightly modified to accommodate customer preferences, which are known to affect the use of sharedmobility resources (see, e.g., Krueger et al. (2016)) . Indeed, with customers preferences, the requests may be directly sent to the companies as opposed to the webservice, which corresponds to the situation in which customers directly book via the smartphone app of the ridesharing company.
There is an important difference in the role of the broker between the Cooperative and Competitive architecture. In the Cooperative architecture, it coordinates and computes quantities. In the Competitive architecture, it is just collecting the assignments and selecting the best assignment, but that could also be done by the customers selecting the company offering the best deal.
We are now ready to present the details of the solution approach for both the Cooperative and Competitive models. We have seen that the solution approach for the Cooperative model relies on the auction algorithm, particularly its distributed version (Zavlanos et al. 2008, Naparstek & Leshem 2014), which we introduce in the Section 3 (see Chopra et al. (2017) for a distributed version of the Hungarian algorithm, which could be alternatively used here).
A note with respect to mechanism design
As one can infer by the proposed models, we are not considering here cases in which the companies are lying about what they can provide (in terms of travel times and constraint satisfaction) to achieve personal gain by gaming the system in their favor. Our models are, in general, not incentive compatible at a given time
, in the sense that companies have no incentives in telling the truth at a given time. Readers interested in mechanism that would enforce truth telling are referred to the vast literature in VickreyClarkeGrove mechanisms and game theory, e.g.
Nisan et al. (2007).In this paper, we consider the realistic perspective that, if the companies would lie about what they could offer at time , soon their customers would realize that change their preferences and go to another company at time . This is realistic, especially in very competitive settings like dynamic ridesharing in big cities with many companies, which are driven by customer satisfaction. In this context, companies have the incentive to tell the truth for competitive reasons in the long run (i.e., to keep customers) and truthtelling is a weaklydominant strategy, that is: one is better off by being truthful, regardless of what the others do.
It is also important to point out that the main scope of the paper is to show that multicompany ridesharing could jeopardize the benefits of ridesharing (less vehicle on the road, better service), even when all the companies are telling the truth, and following customers’ preferences. We leave for future research the analysis of incentivecompatible mechanisms in the short and long time horizon.
3 Cooperative model
In this model, each company interacts with the broker which does not require access to the full matrix of the costs. The broker orchestrates the cooperation between companies via a distributed auction algorithm, which is an adaptation of the implementation presented in Naparstek & Leshem (2014). As in the classical auction algorithm (Bertsekas (1988)), the bidding is the core concept of our implementation. In the distributed implementation, the players of the auction (i.e., the companies) send to the broker only the information needed to compute the bids of each proprietary vehicle on the customer request . Winning an iteration of the auction means having a vehicle assigned to a customer. The unassigned vehicles would raise their bids in the next iteration, resulting in a lower profit for the company. After a finite number of steps, the vehicles reach a condition of “almostequilibrium”, where there is no incentive for any vehicle to raise its bids. This condition corresponds to a feasible assignment of vehicles to requests, which is communicated to the companies by the broker. In other words, the Cooperative protocol provides an assignment solution where no company has any incentive to unilaterally seek another customer (by bidding higher). The almostequilibrium condition is formally expressed by the socalled local complementary slackness (LCS) condition
(3) 
which ensures that each vehicle serves a customer that is within of the best current estimate of bid prices. Note that, in this context, profits are expressed as the assignment costs with opposite sign. Differently to the classical implementation of Bertsekas (1988), the distributed auction of Naparstek & Leshem (2014) does not require the vehicles to disclose their best prices with the central broker, but their bids only. Specifically, in order to compute the bids at each iteration, the broker needs to receive the difference between the two best rewards for the unassigned vehicles, and not the entire assignment cost matrix (as a centralized protocol would require).
Algorithm 1 describes the procedure for solving the assignment in the Cooperative protocol. At the beginning, all vehicles that are available are considered unassigned and the initial vehicle bids are set to zero. At each iteration, locally, each unassigned vehicle computes the difference between the two best possible net rewards obtained by serving (i.e., being assigned to) a customer. To participate to the auction, the unassigned vehicle raises its bid by and the perturbation . Vehicles assigned to customers in previous iterations do not need to update their bid. The bid prices are collected by each company and sent to the broker, which assigns each customer to the highest vehicle bidder. The auction continues until all vehicles of each company are assigned, or a maximum number of iterations is reached. As mentioned in Section 2.1, the assignment returned by the auction algorithm needs to be interpreted for feasibility: vehicles assigned to requests with infinite costs (or in our implementation , see Section 2.1) will not add the associated customers into their routes.
Example.
To illustrate this, consider the simple scenario with two companies competing for two customers. The companies have one vehicle each. The two companies at the same time bid on the best customer for their vehicles, and send to the broker their favorite customer along with the difference in gain they would have if the second favorite customer was assigned to them. The broker updates the bid price for the customer and tentatively assigns the customers to the companies. The companies then can continue to bid, till no company has any incentive to unilaterally seek another customer by bidding higher (or the maximum number of iterations is reached), the final assignment is then enforced, and the algorithm terminates.
We next recall convergence properties of Algorithm 1. Proofs are omitted, given that they follow by those provided by Naparstek & Leshem (2014). Theorem 1 ensures that the distributed auction algorithm terminates in a finite number of steps and quantifies the deviation of the solution to optimality.
Theorem 1.
The Cooperative algorithm converges to a feasible solution in a finite number of iterations. For a total fleet of vehicles, the solution is within of the being the optimal assignment solution. If the assignment costs are integer and , then Algorithm 1 terminates with the optimal assignment, as in the centralized case.
For the practical implementation of Algorithm 1, a primary question is the rate of convergence. Theorem 2 shows that the communication and computational complexity of the algorithm is polynomial in fleet size and the highest cost magnitude. This yields an upper bound on the communication overhead between companies and broker.
Theorem 2.
Let be the number of requests, the number of vehicles, . Then the worst case maximum number of iterations for Algorithm 1 to converge is . The worst case complexity of the Cooperative model is instead .
Proof.
Let be the number of iterations in which vehicle is not assigned, and the total number of iterations. First, note that the problem of maximizing is equivalent to that of maximizing , where . Since the auction matrix is nonnegative, from Lemma by Naparstek & Leshem (2014),
(4) 
Since each iteration takes
computations (the computation of max for a vector of length
is ), then the computational complexity of the algorithm is .The communication and computational complexity is polynomial in the number of customers (note that ) and dependent on the magnitude of the perturbation factor .
4 Competitive model
In this model, the companies and the customers interact with a simpler broker logic. The companies solve a companywide LAP to determine their best onetoone assignments, which are then collected by the broker, which picks the best assignments among all, in an iterative way. The companywide assignments are performed over a set of available customers for company . Initially, for all . Once the LAP is solved, the wanted assignments along with their costs are posted on the broker.
If for a given customer multiple assignments are available (coming from different companies), the broker selects the company with the lowest cost and the corresponding vehicle/customer pair is considered assigned. This pair is then removed from the available vehicle and unassigned customer sets. Each company continues to search for optimal assignment over the revised sets, until all customers are assigned. The algorithm terminates when all customers that can be assigned (i.e., all the ones for which all their time constraints are feasible) are assigned.
Example.
To illustrate this, consider the simple scenario with two companies competing for two customers. The companies have one vehicle each. The first company solves its LAP and assigns its vehicle to customer with cost ; the second company also assigns its vehicle to customer with cost . The broker assigns then customer to the second company, and leave customer unassigned. In the next iteration, the first company chooses customer for its vehicle and the algorithm terminates.
Algorithm 2 shows the architecture of the algorithm.
We now present a few properties of the algorithm. First, we find an upper bound on the number of iterations that needed for the algorithm to terminate (since the number of assignable customers is finite and at each iteration we assign at least one customer, finite termination is ensured). Second, we look at its worst case performance and derive a bound on the optimality gap between this algorithm and the centralized auction. Both properties are interesting: the first provides a tight communication overhead bound on the interaction between companies and the broker, the second provides an insight on the suboptimality of the competitive solution.
Theorem 3.
The maximum number of iterations for termination of the Competitive protocol with companies and new customers is upper bounded as .
Proof.
We assume the number of vehicles to be equal to the number of customers ; this is actually a worst case scenario, since at each iteration an equal number of customers/vehicles will be removed and if and are not equal, then vehicles or customers will not be assigned and the algorithm will terminate earlier.
Let now denote the number of unassigned customers in iteration . As per the algorithm initialization, . Let denote the number of unassigned vehicles for company at the beginning of iteration .
At each iteration , each company solves its assignment problem and sends its wanted assignments. At the end of iteration , at least new customers will be assigned, where , i.e., we assign at least a number of customers equal to the number of vehicles of the biggest company (since in the worst case all the other companies will compete for the same customers). Therefore, the maximum number of unassigned customers in iteration , is given by . We now put ourselves in the scenario in which all the companies have an equal number of vehicles; this is again a worst case scenario for , and in particular we can write
(5) 
where is the number of companies, and is the floor operator. The number of iterations for is the one for which , so that , and solving for , . Therefore a bound for the maximum number of iterations, such that if the algorithm terminates, is the righthand side of the previous inequality and the proposition is proven.
Theorem 3 states that the number of iterations goes logarithmically with the number of requests .
We then move on to proving a worstcase bound for the competitive algorithm. In contrast to the distributed assignment case, the competitive case is not guaranteed to converge to optimal. Rather, we next show that in the worst scenario, the competitive case can lead to solutions which are at least three time worse than the optimal solution. For this theorem, we will need a reasonable additional assumption: the costs need to satisfy a trianglelike inequality: given the costs , , , , then we require that ; that is the cost of vehicle moving from its position to the position of is less than the cost of moving from to plus moving from to and to .
In our case the costs represent travel times, so the assumption is reasonable assuming that travel time from point to are close enough to travel time from to (in this case the inequality just say that the travel time from point to is not longer than the sum of the travel times between and passing through position and ).
Theorem 4.
Assume that the costs satisfy a trianglelike inequality: given the costs , , , , then . Under this assumption, the following upper bounds hold.
For two companies, the competitive algorithm’s total cost in the worst case is two times as much as the one of the best cooperating solution. For three companies, it is at worst three times as much. For an higher number of companies, the worst case is at least three times as much.
Proof.
The proof is constructive and finds the worst possible scenario. We will proceed in the following way, (i) we argue that worst case is the one with vehicles and requests; (ii) we argue that the worst case is the one with companies with vehicle each; (iii) we find the worst possible case for
by linear programming and show that the competitive protocol delivers a solution at most twice as much as the one of the best cooperating solution;
(iv) we generalize the case for in the same way; finally (v) we generalize for .Point (i). Imagine that there are vehicles and requests; if then only vehicles can be assigned. Indicate with the set of assigned vehicles for the cooperating solution and the set of assigned vehicles for the competitive solution. If , we can safely remove vehicles and nothing will change. If , it means that in the competitive scenario, selecting the vehicles in would incur in a higher cost, therefore sticking with the vehicles in is the worst case. We can proceed analogously for the case and conclude that the case is the worst possible case.
Point (ii). Imagine that a company has multiple vehicles, then the company would chose the bidding optimally within its fleet and avoid conflicts. This lowers the total cost. Therefore the worst case is the one when each company is competing with each other one, and they have vehicle each.
Point (iii). Consider Figure 4.A, where circles represent vehicles and squares represent requests. Here we indicate costs with the notation to avoid labelling confusion. Let the best cooperating solution be and , meaning that we are selecting the costs and , and the total cost is . Set the scale without loss of generality to , so that . The worst possible case is that, in the competitive protocol, we switch the solution to and , so that . For this to happen, either both and have to select or , and then one of them has to “settle” for the less appealing request. With no loss of generality, we choose that selects with highest bid, while selects , but then has to settle for . For this case, we need that , ; for optimality of the cooperating solution, , while for triangle inequality, . Putting all these relations together, we want to maximize subject to some linear equalities and inequalities, i.e., we want to solve the linear program:
subject to  
The solution of the linear program is , with very small positive constants, and . Therefore and the competitive protocol delivers a solution at most twice as much as the one of the best cooperating solution (shown in Figure 4.B).
Point (iv). We proceed for the case in the same way that in the case , by constructing worst cases linear programs. Let the best cost be . The worst cost is achieved when all the vehicles pick up different customers, and we can fix it w.l.g. at . To reach such configuration, we can either have two conflicts (e.g., all of the vehicles selecting customer , then vehicles both selecting customer ), or one conflict (e.g., vehicle selecting customer , and vehicles both selecting customer ). In both cases, we can write the resulting linear program and obtain . Therefore .
Point (v). We could proceed as in the cases for the cases , yet the number of possible cases increase and therefore it becomes more complicated to construct all the possible linear programs. In general however, one can say that in the worst case, if , then is at least .
Theorem 4 indicates that the solution provided by competing companies may be significantly suboptimal at each time with respect to the best cooperating solution. This is worrisome in the context of dynamic ridesharing; however, we will show in the simulations in Section 5.2 that, although the solution for each of the LAP is suboptimal, in the long run (that is considering dynamic scenarios and a week long simulation) the performance of the competitive algorithm is not so poor. This is an important point, also made in Simonetto et al. (2019): optimality at a given time is not a proxy for optimality in the long run.
5 Numerical studies
In this section, we present the numerical studies to test our algorithms and model. In Section 5.1, we conduct a sensitity analysis present results from a static analysis to showcase the performance of the different algorithms in solving singleperiods ridesharing models. Then, in Section 5.2 we report realistic 1week simulations, using the New York City data set. Finally, Section 5.3 describes the main findings obtained by the simulations.
5.1 Sensitivity analysis of the ridesharing models
We aim to compare the performance of the Centralized model with the Cooperative and Competitive models and their variants. We conduct tests on three types of randomly generated cost matrices with 100, 500, and 1000 customers. The cost matrix elements are sampled from the travel time values between different locations from the New York City taxi public dataset (NYC Taxi and Limousine Commission dataset 2019). Three other control variables are regulated in the experiments including the number of companies, the vehicletocompany mapping, and the proportion of vehicles belonging to each company, i.e. the market share. The following results are reported as an average over 20 random instances of each cost matrix.
First we report analysis for the Cooperative
model. We compare the percent cost difference from the optimal, i.e. optimality gap, if the cost matrix is stochastic or has a percent bias for each player. A true cost matrix is first randomly sampled as discussed earlier. Then, a stochastic noise is added on to it following a Gaussian distribution with the mean as the true cost matrix value and the chosen value of standard deviation. Then, a bias term is added to the cost value. The bias may be positive or negative. Three levels of standard deviation are considered: no standard deviation, low standard deviation of 1 minute (
LowSD), and high standard deviation of 2 minutes (HighSD). Three levels of bias are considered: no bias, low bias ranging randomly between 010%, and high bias ranging randomly between 4050%. The bias term may be randomly positive or negative. The perturbation is set to 0.01 (see Algorithm 1). Table 1 shows the average optimality gap in % in the case of two companies with equal market share. The average is reported over 500 different instances of stochasticity and bias for the case of 100 customers and two companies with equal market share.No bias  Low bias (010%)  High bias (4050%)  
No stochasticity  0.00  0.07%  1.72% 
LowSD  20.78%  21.93%  41.61% 
HighSD  55.88%  56.81%  98.16% 
As expected, the optimality gap increases with the standard deviation and the bias. It is interesting to note the high sensitivity to stochastic noise.
We now report results for the Competitive model. We consider a varying number of companies, respectively 2, 3, 4 and 5 companies. We generate 500 randomized instances of market settings with varying vehicletocompany mapping and varying market share for each company. For each instance, the cost of Competitive model is compared with the optimal costs and the average difference over the 500 instances is reported. Figure 5(a) reports the optimality gaps for different number of customers, and different number of companies.
We make following observations. First, when the number of companies increase, it increases the optimality gap. The increase is the highest when a third company is added: the optimality gap increases by an average 2.17% after going from a twocompany scenario to a threecompany scenario. This confirms the intuition that more competition worsens the system performance. Second, the optimality gap also increases with the number of customers. This is also as expected where having more customers amplifies the impact of competition and leads to higher percent cost difference.
We also evaluate the optimality gap for varying market share in the twocompany scenario. Again, we generate 500 instances of the vehicletocompany mapping for each given market share. Figure 5
(b) shows the evolution of the optimality gap with respect to the market share of the company with lowest market share. We observe that the more skewed the market share is in favor of one company, the lower the optimality gap is, and, as expected, the costs are optimal when the market is monopolistic. It is interesting to note that the situation of equal market share leads to worse assignments.
We finally look at the evolution of the optimality gap in the presence of customers preferences. Each customer may have a preference for any company and may have a switching threshold. As stated in Section 2.2, this means that if the travel time offered by the nonpreferred company is lower than the travel time offered by the preferred company minus the given threshold, then the customer chooses to switch to the other company. We evaluate varying percentage of customers with preferences and varying values of switching threshold. We perform the tests for twocompany scenario with equal market share and with 100 and 1000 customers. Again, the average percent cost difference is reported over 500 instances of vehicletocompany mapping. Table 2 shows the evolution of the optimality gap for different values of switching threshold and different percentage of customers with preferences. The cells with the highest optimality gap are highlighted.
100 riders  1000 riders  
Switching threshold  Switching threshold  

1 min  5 min 


1 min  5 min 


0%  10.17%  10.17%  10.17%  10.17%  0%  25.42%  25.42%  25.42%  25.42%  
20%  10.17%  14.19%  13.48%  14.14%  20%  25.42%  26.17%  26.20%  26.14%  
40%  10.17%  16.18%  16.71%  16.24%  40%  25.42%  26.79%  27.03%  26.61%  
60%  10.17%  17.99%  18.67%  17.36%  60%  25.42%  27.28%  27.32%  27.26%  
80%  10.17%  19.58%  18.99%  19.75%  80%  25.42%  27.92%  27.70%  28.16%  
Percent riders with preference  100%  10.17%  21.27%  20.89%  21.29%  100%  25.42%  28.76%  28.57%  28.78% 
As expected, an increase of the percentage of customers with preferences and of the switching threshold deteriorates the quality of the assignments. It is interesting to note that the deterioration caused by the increase of the switching threshold is not that consequent.
We shall corroborate these findings in the subsequent section, in the light of realworld data.
5.2 Realtime dynamic simulations
We now consider realtime ondemand ridesharing and the effect of cooperation and competition on the quality of the service provided.
We consider the New York City taxi public dataset (NYC Taxi and Limousine Commission dataset 2019) and extract one week of data trips from 00:00 hours on Sunday, May 5, 2013 to 23:59 hours on Saturday May 11, 2013. This dataset contains the time and location of all of the pickups and dropoff locations visited by the 13,586 active taxis, for each day. From these data, we extract the origindestination requests, as well as the time of pickup (which is the time of request). The number of requests each day varies between 382,779 (Sunday) and 460,700 (Friday). We consider the complete road network of Manhattan as encoded in Open Street Map, amounting at 17,446 nodes.
The fleet is initialized in random locations within Manhattan at 22:00 hours on Saturday, May 4, 2013, (and the requests between 22:00 and 23:59 are used to warm start the fleet, so that the vehicles are not all empty at the beginning of the service, while the requests are batched and sent to the ridesharing service every seconds. We consider that each trip has constraints on the maximum delay time (how much a customer is willing to wait for the ride) and detour time (how much additional trip time from the original schedule the customer is willing to accept to allow the vehicle to accommodate other customers) of minutes for both. In all the simulations, the cost function is the total trip duration. The ridesharing algorithms are implemented in Python 2.7 on a 2.7GHz Intel i5 laptop with 8GB RAM memory.
In this section, we want to assess the Cooperative and Competitive models for multicompany ridesharing. We consider three companies, with a number of vehicles proportional to the number of trips per day reported in NYC (2019). In particular, company 1 has 265 vehicles, company 2 has 175, and company 3 has 60, for a total of 500 vehicles on the road. All the vehicles have 4 seats available. With this setting, as reported in AlonsoMora et al. (2017a), Simonetto et al. (2019), a centralized ridesharing service would be able to offer a very high quality of service to about 1/6 of the NYC current demand. Therefore, in our simulations we consider 1/6 of the total trip requests. Indeed, as explained in Simonetto et al. (2019), considering the whole demand and a corresponding vehicle fleet would lead to quantitatively similar results and the main conclusions that we report here will not change. The reason to use a smaller fleet size and corresponding demand is to keep the computational time manageable to run several representative scenarios.
The number of vehicles considered in the context mapping module for each company is set to . Specifically, it is assumed that each company has similar computational resources and attempts to allocate each request to a maximum of candidate vehicles within a given radius from the requests by solving DARPs. It is important to note that this is an upper bound, but in many cases (especially for small companies), even fewer vehicles will be inside the considered radius from each request. This choice in the context mapping seeks a tradeoff between computational requirements and quality of the ridesharing service. It is reasonable to assume that the software and hardware requirements are similar for the comparnies. All algorithmic variants include a rebalancing service described in Simonetto et al. (2019), which the customers are accepting: AlonsoMora et al. (2017b) and Simonetto et al. (2019) showcased the greatly positive impact of rebalancing in dynamic ridesharing.
We measure performance with different metrics. Firstly, we consider the service rate (SR), defined as the ratio of serviced customers on the total number of customers. Clearly, the higher the SR is, the better the quality of a ridesharing service is. Secondly, we look at customers’ waiting times and vehicles’ detour times, both cumulatively and per company. Low values of both indicators imply a high level of service. However, a comparable value across the companies is usually desired as well, in order to limit the dissatisfaction of customers. Finally, we look at how the customers are assigned among the companies. If the assignment is proportional to the number of vehicles, we say that the algorithm reaches an egalitarian solution, otherwise an unbalanced high level of service of specific companies may be deemed as unfair.
In the simulations, we remark that searching myopically for optimality at a given time is not a proxy for optimality in the long run. In other words, suboptimal vehicle routes at a given time do not necessarily degrade the performance in the long run (e..g, after a week), because they might help to accommodate more requests in future time periods. We observed that this is true also for the Cooperative and Competitive cases. This is an important concept in dynamic in realtime ridesharing, as pointed out and discussed by Simonetto et al. (2019) in the singlecompany setting.
We test and compare the Cooperative model (simulations 28) to the Centralized model (simulation 1) in Table 3. We report: the number of iterations of the distributed auction algorithm for the Cooperative model, the stochasticity and bias added (which will be explained in detail in the next paragraph), the service rate obtained, the difference in percentage with a perfect egalitarian solution of customers served (which sums up to 0) and the total percentage of served customers (which sums up to the SR), the waiting time and detour time (cumulative and per company), the vehicle occupancy per company, and the average computational time for each assignment. As expected, the results of the centralized algorithm in row 1 are inline with the ones presented in Simonetto et al. (2019). In particular, note the level of service is greater than , and the assignment solutions are close to the egalitarian share of customers assigned to the three companies, respectively. The discrepancy with a perfect egalitarian partition is due to the local context mapping, which restricts the number of available vehicles for each customer, and alleviates the computational burden. The computational time is well less than 10 , and therefore the algorithm can be implemented in realtime.
sim.  no. iters  stoch  bias  SR  customers  waiting  detour  occupancy  comp. time 
[min]  [%]  [%]  [%]  [min]  [min]  [cust./vehicle]  [s]  
1  Centr.  0,0,0  0,0,0  99.4  0.7, 0.8, 0.9  1.5  
2  1000  0,0,0  0,0,0  98.9  0.6, 0.7, 0.8  7.3  
3  500  0,0,0  0,0,0  92.4  0.6, 0.6, 0.6  5.8  
4  250  0,0,0  0,0,0  90.6  0.5, 0.6, 0.6  4.0  
5  1000  5,5,5  0,0,0  98.5  0.7, 0.7, 1.0  5.7  
6  1000  10,10,10  0,0,0  97.9  0.7, 0.8, 1.1  4.8  
7  1000  0,0,0  0,0,10  98.9  0.6, 0.6, 1.0  7.1  
8  1000  0,0,0  0,0,20  98.9  0.6, 0.6, 1.2  7.0 
Cooperative model.
The performance assessment of the Cooperative model is presented in Table 3:

Baseline (row 2): a distributed auction algorithm that implements the Cooperative model and uses 1000 iterations for each linear assignment problem. No stochasticity or bias is considered. The distributed auction algorithm (Algorithm 1) obtains very similar results as the centralized one (and as we have proved would converge to the same result, if the number of auction iterations would be large enough). We note here that 1000 iterations are considered to keep the algorithm realtime on our machine. Interestingly, the distributed auction yields a more egalitarian solution in terms of serviced customers by the three companies.

Low communication heuristics (rows 34): the distributed auction algorithm is run with and iterations. This is to evaluate the degradation of performance with the decrease of the number of iterations: in the distributed auction, fewer iterations mean that fewer customers get assigned. For the simulation with iterations, the service rate decreases by %, and waiting and detour times are not afftected. When iterations are limited to , detour times are lowered by , at the price of a drop in service rate by .

Stochasticity (rows 56): the travel times are added a zeromean Gaussian noise scalar with standard deviation indicated in the table (the noise is independent and identically distributed (IID) over the ). This is to model errors in the cost computations, and therefore to evaluate the robustness of the algorithm to over/underestimations of the travel times. With respect to the baseline, the waiting times increase by and , the detour times increase by and , however the SR degrades only slightly (–%). In all these simulations, the smallest company is able to serve more customers than in the baseline, both in a relative and absolute way, and this, in turn, degrades the overall performance.

Bias (rows 78): assignment costs are discounted by a percentage indicated in the table, for the smaller company (underestimator bias). In particular, a reduction means that the respective cost in the linear assignment problem is times the original cost: the bias is considered in the assignment algorithm, but not in the actual implementation of the routing schedule, so the actual trip time is not affected. A bias introduced in this way simulates situations such as: a company entering in the market by discounting the rides to attract more clients, a city council that helps a new company to break in by waiving part of the new company rides, etc. The simulations show that the SR is seemingly not affected, the waiting and detour times decrease or do not change for the two bigger companies (having less customers to serve), but increase for the third company. The customer share increases slightly for the third company (both in relative and absolute terms), and the customer assignment share is similar to the centralized solution. This increase in shares enables to handle a bit more than 1000 additional rides per day (in the 20% discount simulation): this suggests that the bias variant may be a worthy choice, especially because the performance in terms of waiting and detour times degrades slightly.
In brief, the Cooperative model appears promising for reaching an egalitarian partitioning of the customers and, if a sufficient number of iterations are run, it obtains a performance similar to the centralized model. It is fairly robust to noise (both when travel times are over and under estimated), and it accommodates market incentives, like discounting prices to attract more customers for small companies.
Competitive model.
The performance assessment of the Competitive model is presented in Table 4. The maximum number of iterations is set to .
sim.  pref.  stoch  bias  SR  customers  waiting  detour  occupancy  comp. time 
[]  [%]  [min]  [%]  [%]  [%]  [min]  [cust./vehicle]  [s]  
1  Centr.  0,0,0  0,0,0  99.4  0.7, 0.8, 0.9  1.5  
2  0  0,0,0  0,0,0  99.5  0.6, 0.7, 1.7  1.8  
3  0  5,5,5  0,0,0  99.2  0.7, 0.8, 1.5  1.8  
4  0  10,10,10  0,0,0  98.9  0.7, 0.9, 1.5  1.7  
5  0.5  0,0,0  0,0,0  99.0  0.6, 0.8, 1.3  2.0  
6  0.5  0,0,0  0,0,20  99.0  0.6, 0.7, 1.5  1.8  
7  1.  0,0,0  0,0,0  97.9  0.7, 1.0, 0.5  1.8  
8  1.  0,0,0  0,0,20  98.1  0.7, 1.0, 0.6  1.8  
9  0.5  0,0,0  0,0,0  98.9  0.6, 0.8, 1.3  2.1  
10  0.5  0,0,0  0,0,20  98.8  0.6, 0.8, 1.5  2.1  
11  0.5  0,0,0  0,0,40  98.8  0.6, 0.8, 1.7  2.0  
12  1.  0,0,0  0,0,0  96.8  0.6, 1.1, 0.5  1.8  
13  1.  0,0,0  0,0,20  96.8  0.7, 1.1, 0.5  1.7  
14  1.  0,0,0  0,0,40  97.1  0.6, 1.1, 0.6  1.8  
15  0.95  0,0,0  0,0,0  92.9  0.6, 1.1, 0.5  1.6 

Baseline (row 2): the Competitive algorithm (Algorithm 2) without stochasticity, bias, or preferences. Note that each company solves the assignment problem with its fleet to optimality. Competition in its pristine form only slightly degrades the waiting and detour times significantly with respect to the centralized model, and it achieves a better SR. However, a suboptimal partition in terms of waiting and detour times is found, putting more load on the third company. This can be explained by the fact that the companies with a higher number of vehicles have higher chances to secure the best assignments (i.e., win their auctions), while the third company is left with the less attractive ones. Interestingly, the third company increases its market share, because of the context mapping. This simulation indicates that a certain level of competition does not deteriorate the service rate.

Stochasticity (rows 34): as in the Cooperative scenario, the travel times are added a zeromean Gaussian noise scalar with standard deviation indicated in the table (the noise is IID over the ). The SR degrades slightly (by % for simulation 3 and % for simulation 4), while the waiting times and detour times increase by  and  minutes, respectively. There is very little difference between the “robustness” of the Competitive algorithm and the Cooperative one. Although the Competitive algorithm generates lower variation in SR percentage, it is difficult to compare the variation in the share of customers assignment among companies.

Customer preferences (rows 515): since the third company seems to offer a worse service, customers may have a preference to be associated with the first two. We divide this study in three parts: low preference (indicated with ), medium preference (), and high preference () settings, see Table 4 (rows 515). Preferences are introduced in the simulation by giving the customers a certain propensity to choose a certain company despite the other companies offering a better “deal” (in terms of trip duration). A preference of in the table means that we set % of the customers to have a preference (preferences are divided equally between company 1 and company 2, since on average they offer a similar quality of service.
We also set the switching threshold, i.e., the maximum difference between the deal (i.e., trip duration) of their preferred company with the best deal of another company that would make them change their mind. This is to model the natural tendency of people to have a preference for a given provider, but be willing to switch to another one if what they get is better than a personspecific amount. We randomly assign the switching threshold to the customers by sampling from the vector (vector expressed in MATLAB notation, and in minutes), so that some customer would be easy to switch, other less so. To say it in another way, e.g., if , we decide the switching threshold of a customer by sampling one element from the vector minutes, so that some customers may have low thresholds ( minutes), others larger ones.
In the simulations, is set to: 5 minutes for the low preference setting () (simulations 58), so more customers are willing to switch to another company; 15 minutes for the medium setting () (simulations 914); finally, 30 minutes for the high setting (). This last setting is meant to model the realistic situation in which customers use their provider app and if a deal is not available that suits them, they would rather use a different means of transportation. We remark that the preferences override any other preference or hard constraints in terms of waiting and detour times.
The results show that introducing preferences has a detrimental effect on the overall performance, pushing down SR by –
% and pushing up the waiting and detour times. Also the equal division of preferences among the two bigger companies (i.e., the probability of preferring company 1 is equal to the probability of preferring company 2), puts a high workload on company 2 (having less vehicles than company 1), as shown by the increases of waiting and detour times. As natural for competitive settings, the third company has a more difficult time in securing customers and entering in the market. A bias term discounting the trips, as can be seen in simulations 6, 8, 10, 11, 13, 14, has a positive effect to counteract the preference competition, but this is limited by the fact that the third company is the one offering fewer vehicles.
Another option that companies and cities have to augment their level of service is to increase the number of vehicles in service.
This is explored in Table 5 (where simulations 1 and 2 are the centralized auction and the baseline Competitive model, respectively). Here we increase the vehicles uniformly across companies, so an increase of means that the number of vehicles are . We do not model the potential localized effects of congestion resulting from such an increase. In all the preference models, an increase of of the fleet is required to obtain a similar performance (at least in terms of SR) to simulations 1 and 2. In the case of a highpreference model, i.e. customers booking with a company app, an increase of is instead needed. If such an increase is possible and not regulated, in a purely competitive market, this irremediably leads to more vehicles in cities, which in turn may jeopardize the early promises of ridesharing in terms of sizing down the number of vehicles. Note also that in a realistic scenario, not all the companies can leverage fleet sizing to increase their SR, which in turn may affect the market dynamics.
sim.  vehicle increase  pref.  SR  customers  waiting  detour  occupancy  comp. time 
[%]  []  [%]  [%]  [min]  [%]  [cust./vehicle]  [s]  
1  0  Centr.  99.4  0.7, 0.8, 0.9  1.5  
2  0  0  99.5  0.6, 0.7, 1.7  1.8  
3  0  1.  97.9  0.7, 1.0, 0.5  1.8  
4  +20%  1.  99.7  0.6, 0.9, 0.3  2.4  
5  0  1.  96.8  0.6, 1.1, 0.5  1.8  
6  +20%  1.  99.8  0.5, 0.8, 0.2  3.0  
7  0  0.95  92.9  0.6, 1.1, 0.5  1.6  
8  +20%  0.95  98.4  0.6, 0.9, 0.3  2.6  
9  +40%  0.95  99.4  0.5, 0.7, 0.2  3.2  
10  +60%  0.95  100.0  0.4, 0.6, 0.2  5.8 
The increase in fleet size also has an adverse effect on the egalitarian partitioning, which is expected as the 2 preferred companies have more availability in terms of low occupancy vehicles that can pick up new customers. The % of customers served by company 3 goes down to as low as to 3.9% in the case of 100% of customers having a preference for company 1 or 2 with threshold b and 20% more vehicles, and 5.8% in the case 95% of customers having a preference for company 1 or 2 with threshold c and 60% more vehicles.
In brief, the competition of ridesharing companies may be as good as the centralized case in terms of the SR, however not as good in terms of average detour and waiting times, and in realistic settings where preferences are naturally present, it can lead to a significant loss in performance. In such a context, ridesharing companies may decide to significantly increase their operating fleet size to improve their service, to only get to a similar SR to the one achieved in the centralized and cooperative case without this fleet size increase.
5.3 Main findings
The results highlighted in the previous Section 5.2 should be put in perspective of the rise of Mobility as a Service platforms for city transport. We summarize them as follows:

The Cooperative solution performs very closely to the Centralized solution, is robust to noise, and responds well to incentives in market mechanisms.

The Cooperative solution however requires communication with a MaaS platform and the agreements of companies to share bids at each iteration of the algorithm. Notice that our solution does not require the company to share proprietary information such as their vehicle locations but instead their best bids at each iteration, which could be implemented in a privacyaware solution.

The Competitive solution achieves good performance in terms of SR but exhibits a deterioration in waiting and detour times compared to the Centralized solution.

The Competitive solution also requires communication with a Maas platform but requires less iterations for convergence. It does require the sharing of assignments at each iteration of the algorithm.

The Competitive solution tends to favor the company with the lowest market share.

Considering customers’ preferences is a proxy for modeling either the possibility for customers to choose specific companies, or the absence of a MaaS platform, i.e. customers book through the proprietary smartphone applications of the preferred companies. The Competitive model coping with customers’ preferences sensibly deteriorates the SR, as well as the waiting and detour times.

The Competitive solution, when considering customers’ preferences, has a serious impact on the long term quality of ridesharing services, and an increase of the number of operating vehicles is needed to achieve similar service rate to the Centralized solution.
In brief, we advocate for the needs to regulate the settings of MaaS platforms and the possibility for customers to choose their preferred companies. First, MaaS platforms must be specific about the information that is wanted from the ridesharing companies and a regulatory framework is needed to agree on the level of information sharing, keeping in mind the common good of ridesharing mobility and the privacy of the involved companies. Second, MaaS platforms cannot behave as plain brokers, leaving the final choice to the customers. The possibility for customers to have company preferences sensibly leads to suboptimal performance of the system. Finally, a regulatory framework is needed for fleet sizing in a way that is fair to all companies involved, in order to avoid an unhealthy increase of supply by each company in order to gain market shares.
6 Conclusions
Sharedmobility services are facing an evergrowing trend in cities. The benefits of ridesharing may be jeopardized by an unregulated design and maintenance of those, especially in case multiple companies are competing for their market share. In this work, we have presented optimizationbased approaches to model cooperation and competition between ridesharing companies. A cooperative model, which could make use of Mobility as a Service platforms, is shown to solve to optimality the problem of assigning vehicles to customer request, by following closely results from the literature: in such a model, the distributed auction algorithm is exploited to limit the amount of information that the companies are required to share. We have investigated how a realistic model of competition deviates from this optimality and provided worst case bounds. We have evaluated the performance of both models in terms of service rate, waiting and detour times on oneweek instances of the New York City taxi dataset. Model variants coping with noise in the travel time estimations, bias in the assignment costs, and preferences in the competitive case have been presented and validated. The computational results suggest that cooperation among ridesharing companies can be conducted in such a way to limit the degradation of the level of service with respect to a centralized model. The competition can instead lower the quality of the ridesharing service, especially in the case customer preferences are accommodated. Finally, we envision several research directions as future work: (i) formulating companywise strategies to gain market share in a defavorable market (e.g., fine tuned strategies related to the spatiotemporal distribution of vehicles in response to the spatiotemporal SR per company achieved); (ii) dynamic fleet sizing at the city level: what is the minimum of vehicles needed to achieve satisfactory SR, waiting and detour times.; (iii) model the congestion feedback effect caused by uncontrolled supply in competitive settings.
7 Acknowledgments
This project has received funding from the European Union Horizon 2020 research and innovation programme under grant agreement No. 731993 (AUTOPILOT).
References
 (1)
 Agatz et al. (2012) Agatz, N., Erera, A., Savelsbergh, M. & Wang, X. (2012), ‘Optimization for dynamic ridesharing: A review’, European Journal of Operational Research 223(2), 295–303.

Alemi et al. (2019)
Alemi, F., Circella, G., Mokhtarian, P. & Handy, S.
(2019), ‘What drives the use of ridehailing
in california? ordered probit models of the usage frequency of uber and
lyft’, Transportation Research Part C: Emerging Technologies 102, 233 – 248.
http://www.sciencedirect.com/science/article/pii/S0968090X18318849  AlonsoMora et al. (2017a) AlonsoMora, J., Samaranayake, S., Wallar, A., Frazzoli, E. & Rus, D. (2017a), ‘Ondemand highcapacity ridesharing via dynamic tripvehicle assignment’, Proceedings of the National Academy of Sciences 114(3), 462–467.
 AlonsoMora et al. (2017b) AlonsoMora, J., Samaranayake, S., Wallar, A., Frazzoli, E. & Rus, D. (2017b), ‘Ondemand Highcapacity Ridesharing via Dynamic TripVehicle Assignment’, Proceedings of the National Academy of Sciences 114(3), 462 – 467.
 Aïvodji et al. (2016) Aïvodji, U. M., Gambs, S., Huguet, M.J. & Killijian, M.O. (2016), ‘Meeting points in ridesharing: A privacypreserving approach’, Transportation Research Part C: Emerging Technologies 72(Supplement C), 239 – 253.

Bearse et al. (2004)
Bearse, P., Gurmu, S., Rapaport, C. & Stern, S. (2004), ‘Paratransit demand of disabled people’, Transportation Research Part B: Methodological 38(9), 809 – 831.
http://www.sciencedirect.com/science/article/pii/S0191261504000037  Bernard et al. (2016) Bernard, F., Vlassis, N., Gemmar, P., Husch, A., Thunberg, J., J., G. & Hertel, F. (2016), Fast correspondences for statistical shape models of brain structures, in ‘SPIE Medical Imaging’.
 Bertsekas (1988) Bertsekas, D. P. (1988), ‘The auction algorithm: A distributed relaxation method for the assignment problem’, Annals of operations research 14(1), 105–123.
 Bertsekas (1990) Bertsekas, D. P. (1990), ‘The auction algorithm for assignment and other network flow problems: A tutorial’, Interfaces 20(4), 133–149.
 Bijsterbosch & Volgenant (2010) Bijsterbosch, J. & Volgenant, A. (2010), ‘Solving the rectangular assignment problem and applications’, Annals of Operations Research 181(1), 443–462.

Bongiovanni et al. (2019)
Bongiovanni, C., Kaspi, M. & Geroliminis, N. (2019), ‘The electric autonomous dialaride problem’, Transportation Research Part B: Methodological 122, 436 – 456.
http://www.sciencedirect.com/science/article/pii/S0191261517309669  Cairns & ListonHeyes (1996) Cairns, R. D. & ListonHeyes, C. (1996), ‘Competition and regulation in the taxi industry’, Journal of Public Economics 59(1), 1–15.

Chen et al. (2017a)
Chen, X. M., Zahiri, M. & Zhang, S. (2017a), ‘Understanding ridesplitting behavior of ondemand ride
services: An ensemble learning approach’, Transportation Research Part
C: Emerging Technologies 76, 51 – 70.
http://www.sciencedirect.com/science/article/pii/S0968090X16302728  Chen et al. (2017b) Chen, X. M., Zahiri, M. & Zhang, S. (2017b), ‘Understanding ridesplitting behavior of ondemand ride services: An ensemble learning approach’, Transportation Research Part C: Emerging Technologies 76, 51–70.
 Chopra et al. (2017) Chopra, S., Notarstefano, G., Rice, M. & Egerstedt, M. (2017), ‘A Distributed Version of the Hungarian Method for MultiRobot Assignment’, IEEE Transactions on Robotics 33(4), 932 – 947.

Contreras & Paz (2018)
Contreras, S. D. & Paz, A. (2018),
‘The effects of ridehailing companies on the taxicab industry in las vegas,
nevada’, Transportation Research Part A: Policy and Practice 115, 63 – 70.
Smart urban mobility.
http://www.sciencedirect.com/science/article/pii/S0965856417300538  Cordeau (2006) Cordeau, J. F. (2006), ‘A BranchandCut Algorithm for the DialaRide Problem’, Operations Research 54(3), 573 – 586.
 Cordeau & Laporte (2003) Cordeau, J.F. & Laporte, G. (2003), ‘The DialaRide Problem (DARP): Variants, modeling issues and algorithms’, 4OR – Quarterly Journal of the Belgian, French and Italian Operations Research Societies 1, 89 – 101.

Coulombel et al. (2019)
Coulombel, N., Boutueil, V., Liu, L., Viguié, V. & Yin, B.
(2019), ‘Substantial rebound effects in
urban ridesharing: Simulating travel decisions in paris, france’, Transportation Research Part D: Transport and Environment 71, 110 –
126.
The roles of users in lowcarbon transport innovations: Electrified,
automated, and shared mobility.
http://www.sciencedirect.com/science/article/pii/S1361920918303201 
Deka & Gonzales (2014)
Deka, D. & Gonzales, E. J. (2014),
‘The generators of paratransit trips by persons with disabilities’, Transportation Research Part A: Policy and Practice 70, 181 – 193.
http://www.sciencedirect.com/science/article/pii/S0965856414002602 
Di et al. (2018)
Di, X., Ma, R., Liu, H. X. & Ban, X. J. (2018), ‘A linknode reformulation of ridesharing user
equilibrium with network design’, Transportation Research Part B:
Methodological 112, 230 – 255.
http://www.sciencedirect.com/science/article/pii/S0191261517304861 
Dikas & Minis (2014)
Dikas, G. & Minis, I. (2014),
‘Scheduled paratransit transport systems’, Transportation Research Part
B: Methodological 67, 18 – 34.
http://www.sciencedirect.com/science/article/pii/S0191261514000745  Dong et al. (2018) Dong, Y., Wang, S., Li, L. & Zhang, Z. (2018), ‘An empirical study on travel patterns of internet based ridesharing’, Transportation Research Part C: Emerging Technologies 86(Supplement C), 1 – 22.
 Fiedler et al. (2018) Fiedler, D., Čertickỳ, M., AlonsoMora, J. & Čáp, M. (2018), The impact of ridesharing in mobilityondemand systems: Simulation case study in prague, in ‘2018 21st International Conference on Intelligent Transportation Systems (ITSC)’, IEEE, pp. 1173–1178.

Fitzgerald et al. (2000)
Fitzgerald, J., Shaunesey, D. & Stern, S. (2000), ‘The effect of education programs on paratransit
demand of people with disabilities’, Transportation Research Part A:
Policy and Practice 34(4), 261 – 285.
http://www.sciencedirect.com/science/article/pii/S0965856499000142 
Fu (2002a)
Fu, L. (2002a), ‘Scheduling dialaride
paratransit under timevarying, stochastic congestion’, Transportation
Research Part B: Methodological 36(6), 485 – 506.
http://www.sciencedirect.com/science/article/pii/S0191261501000145 
Fu (2002b)
Fu, L. (2002b), ‘A simulation model for
evaluating advanced dialaride paratransit systems’, Transportation
Research Part A: Policy and Practice 36(4), 291 – 307.
http://www.sciencedirect.com/science/article/pii/S0965856401000027  Goodall et al. (2017) Goodall, W., Dovey, T. & Bonthron, B. (2017), ‘The rise of mobility as a service’.

Guerriero et al. (2014)
Guerriero, F., Pezzella, F., Pisacane, O. & Trollini, L.
(2014), ‘Multiobjective optimization in
dialaride public transportation’, Transportation Research Procedia
3, 299 – 308.
17th Meeting of the EURO Working Group on Transportation, EWGT2014,
24 July 2014, Sevilla, Spain.
http://www.sciencedirect.com/science/article/pii/S2352146514001720 
Gupta et al. (2010)
Gupta, D., Chen, H.W., Miller, L. A. & Surya, F. (2010), ‘Improving the efficiency of demandresponsive
paratransit services’, Transportation Research Part A: Policy and
Practice 44(4), 201 – 217.
http://www.sciencedirect.com/science/article/pii/S0965856410000133  H. Papadimitriou & Steiglitz (1982) H. Papadimitriou, C. & Steiglitz, K. (1982), Combinatorial Optimization: Algorithms and Complexity, Vol. 32.
 Häme (2011) Häme, L. (2011), ‘An adaptive insertion algorithm for the singlevehicle dialaride problem with narrow time windows’, European Journal of Operational Research 209(1), 11 – 22.

He & Shen (2015)
He, F. & Shen, Z.J. M. (2015),
‘Modeling taxi services with smartphonebased ehailing applications’, Transportation Research Part C: Emerging Technologies 58, 93 – 106.
http://www.sciencedirect.com/science/article/pii/S0968090X15002387  Ho et al. (2018) Ho, S. C., Szeto, W., Kuo, Y.H., Leung, J. M., Petering, M. & Tou, T. W. (2018), ‘A survey of dialaride problems: Literature review and recent developments’, Transportation Research Part B: Methodological 111, 395–421.

Irannezhad et al. (2018)
Irannezhad, E., Prato, C. G. & Hickman, M. (2018), ‘The effect of cooperation among shipping lines on
transport costs and pollutant emissions’, Transportation Research Part
D: Transport and Environment 65, 312 – 323.
http://www.sciencedirect.com/science/article/pii/S1361920918305935  Jin et al. (2018) Jin, S. T., Kong, H., Wu, R. & Sui, D. Z. (2018), ‘Ridesourcing, the sharing economy, and the future of cities’, Cities 76, 96–104.

Karabuk (2009)
Karabuk, S. (2009), ‘A nested decomposition
approach for solving the paratransit vehicle scheduling problem’, Transportation Research Part B: Methodological 43(4), 448 – 465.
http://www.sciencedirect.com/science/article/pii/S0191261508000957  Kennington & Helgason (1980) Kennington, J. L. & Helgason, R. V. (1980), Algorithms for Network Programming, John Wiley & Sons, Inc., New York, NY, USA.

Krueger et al. (2016)
Krueger, R., Rashidi, T. H. & Rose, J. M. (2016), ‘Preferences for shared autonomous vehicles’, Transportation Research Part C: Emerging Technologies 69, 343 – 355.
http://www.sciencedirect.com/science/article/pii/S0968090X16300870 
Lavieri & Bhat (2019)
Lavieri, P. S. & Bhat, C. R. (2019), ‘Investigating objective and subjective factors influencing the adoption,
frequency, and characteristics of ridehailing trips’, Transportation
Research Part C: Emerging Technologies 105, 100 – 125.
http://www.sciencedirect.com/science/article/pii/S0968090X18307307 
Lei et al. (2019)
Lei, C., Jiang, Z. & Ouyang, Y. (2019), ‘Pathbased dynamic pricing for vehicle allocation in
ridesharing systems with fully compliant drivers’, Transportation
Research Part B: Methodological .
http://www.sciencedirect.com/science/article/pii/S019126151831141X 
Li et al. (2019)
Li, W., Pu, Z., Li, Y. & Ban, X. J. (2019), ‘Characterization of ridesplitting based on observed
data: A case study of chengdu, china’, Transportation Research Part C:
Emerging Technologies 100, 330 – 353.
http://www.sciencedirect.com/science/article/pii/S0968090X18316413  Liu et al. (2015) Liu, M., Luo, Z. & Lim, A. (2015), ‘A branchandcut algorithm for a realistic dialaride problem’, Transportation Research Part B: Methodological 81, 267 – 288.

Liu et al. (2018)
Liu, Y., Bansal, P., Daziano, R. & Samaranayake, S.
(2018), ‘A framework to integrate mode
choice in the design of mobilityondemand systems’, Transportation
Research Part C: Emerging Technologies .
http://www.sciencedirect.com/science/article/pii/S0968090X18313718  Liu & Li (2017) Liu, Y. & Li, Y. (2017), ‘Pricing scheme design of ridesharing program in morning commute problem’, Transportation Research Part C: Emerging Technologies 79(Supplement C), 156 – 177.

Lokhandwala & Cai (2018)
Lokhandwala, M. & Cai, H. (2018),
‘Dynamic ride sharing using traditional taxis and shared autonomous taxis: A
case study of NYC’, Transportation Research Part C: Emerging
Technologies 97, 45 – 60.
http://www.sciencedirect.com/science/article/pii/S0968090X18307551  Ma & Zhang (2017) Ma, R. & Zhang, H. (2017), ‘The morning commute problem with ridesharing and dynamic parking charges’, Transportation Research Part B: Methodological 106(Supplement C), 345 – 374.
 Marković et al. (2015) Marković, N., Nair, R., Schonfeld, P., MillerHooks, E. & Mohebbi, M. (2015), ‘Optimizing dialaride services in Maryland: benefits of computerized routing and scheduling’, Transportation Research Part C: Emerging Technologies 55, 156–165.

Masoud & Jayakrishnan (2017)
Masoud, N. & Jayakrishnan, R. (2017), ‘A realtime algorithm to solve the peertopeer
ridematching problem in a flexible ridesharing system’, Transportation
Research Part B: Methodological 106, 218 – 236.
http://www.sciencedirect.com/science/article/pii/S0191261517301169 
Moody et al. (2019)
Moody, J., Middleton, S. & Zhao, J. (2019), ‘Ridertorider discriminatory attitudes and
ridesharing behavior’, Transportation Research Part F: Traffic
Psychology and Behaviour 62, 258 – 273.
http://www.sciencedirect.com/science/article/pii/S1369847818306181 
Mourad et al. (2019)
Mourad, A., Puchinger, J. & Chu, C. (2019), ‘A survey of models and algorithms for optimizing
shared mobility’, Transportation Research Part B: Methodological .
http://www.sciencedirect.com/science/article/pii/S0191261518304776 
Muelas et al. (2015)
Muelas, S., LaTorre, A. & Peña, J.M. (2015), ‘A distributed vns algorithm for optimizing
dialaride problems in largescale scenarios’, Transportation Research
Part C: Emerging Technologies 54, 110 – 130.
http://www.sciencedirect.com/science/article/pii/S0968090X15000790 
Najmi et al. (2017)
Najmi, A., Rey, D. & Rashidi, T. H. (2017), ‘Novel dynamic formulations for realtime
ridesharing systems’, Transportation Research Part E: Logistics and
Transportation Review 108, 122 – 140.
http://www.sciencedirect.com/science/article/pii/S1366554517300017  Naparstek & Leshem (2014) Naparstek, O. & Leshem, A. (2014), ‘Fully Distributed Optimal Channel Assignment for Open Spectrum Access’, IEEE Transactions on Signal Processing 62(2), 283 – 294.

NguyenHoang & Yeung (2010)
NguyenHoang, P. & Yeung, R. (2010), ‘What is paratransit worth?’, Transportation Research Part A: Policy
and Practice 44(10), 841 – 853.
http://www.sciencedirect.com/science/article/pii/S0965856410001278 
Nie (2017)
Nie, Y. M. (2017), ‘How can the taxi industry
survive the tide of ridesourcing? evidence from shenzhen, china’, Transportation Research Part C: Emerging Technologies 79, 242 – 256.
http://www.sciencedirect.com/science/article/pii/S0968090X17301018  Nisan et al. (2007) Nisan, N., Roughgarden, T., Tardos, É. & Vazirani, V. V. (2007), Algorithmic Game Theory, Cambridge University Press.
 NYC (2019) NYC (2019), ‘NYC Taxi and Limousine Commission aggregated reports’, http://www.nyc.gov/html/tlc/html/technology/aggregated_data.shtml. [Online; accessed 24January2019].
 NYC Taxi and Limousine Commission dataset (2019) NYC Taxi and Limousine Commission dataset (2019). available online.
 Parragh et al. (2008) Parragh, S. N., Doerner, K. F. & Hartl, R. F. (2008), ‘A survey on pickup and delivery problems’, Journal für Betriebswirtschaft 58(1), 21–51.

Phun et al. (2018)
Phun, V. K., Kato, H. & Yai, T. (2018), ‘Traffic risk perception and behavioral intentions of
paratransit users in phnom penh’, Transportation Research Part F:
Traffic Psychology and Behaviour 55, 175 – 187.
http://www.sciencedirect.com/science/article/pii/S1369847816306209 
Pratt et al. (2019)
Pratt, A. N., Morris, E. A., Zhou, Y., Khan, S. & Chowdhury, M.
(2019), ‘What do riders tweet about the
people that they meet? analyzing online commentary about uberpool and lyft
shared/lyft line’, Transportation Research Part F: Traffic Psychology
and Behaviour 62, 459 – 472.
http://www.sciencedirect.com/science/article/pii/S1369847818305424  Qian & Ukkusuri (2017) Qian, X. & Ukkusuri, S. V. (2017), ‘Taxi market equilibrium with thirdparty hailing service’, Transportation Research Part B: Methodological 100, 43–63.
 Rayle et al. (2016) Rayle, L., Dai, D., Chan, N., Cervero, R. & Shaheen, S. (2016), ‘Just a better taxi? a surveybased comparison of taxis, transit, and ridesourcing services in san francisco’, Transport Policy 45, 168–178.
 Ropke et al. (2007) Ropke, S., Cordeau, J. & Laporte, G. (2007), ‘Models and BranchandCut Algorithms for Pickup and Delivery Problems with Time Windows’, Networks 49(4), 258 – 272.

Sayarshad & Gao (2018)
Sayarshad, H. R. & Gao, H. O. (2018), ‘A scalable nonmyopic dynamic dialaride and
pricing problem for competitive ondemand mobility systems’, Transportation Research Part C: Emerging Technologies 91, 192 – 208.
http://www.sciencedirect.com/science/article/pii/S0968090X18304637 
Schalekamp (2017)
Schalekamp, H. (2017), ‘Lessons from building
paratransit operators’ capacity to be partners in cape town’s public
transport reform process’, Transportation Research Part A: Policy and
Practice 104, 58 – 66.
http://www.sciencedirect.com/science/article/pii/S0965856415302445  Schaller Consulting (2018) Schaller Consulting (2018), ‘The New Automobility: Lyft, Uber and the Future of American Cities’, http://www.schallerconsult.com/rideservices/automobility.pdf. July 25, 2018.
 Schneider (2016) Schneider, T. W. (2016), ‘Taxi, Uber, and Lyft Usage in New York City’, http://toddwschneider.com/posts/taxiuberlyftusagenewyorkcity/.

Schwieterman & Smith (2018)
Schwieterman, J. & Smith, C. S. (2018), ‘Sharing the ride: A pairedtrip analysis of uberpool
and chicago transit authority services in chicago, illinois’, Research
in Transportation Economics 71, 9 – 16.
Journal of the Transportation Research Forum, Volume 57.
http://www.sciencedirect.com/science/article/pii/S0739885918302683 
Séjournè et al. (2018)
Séjournè, T., Samaranayake, S. & Banerjee, S.
(2018), ‘The price of fragmentation in
mobilityondemand services’, Proc. ACM Meas. Anal. Comput. Syst. 2(2), 30:1–30:26.
http://doi.acm.org/10.1145/3224425  Shaheen et al. (2015) Shaheen, S., Chan, N., Bansal, A. & Cohen, A. (2015), Shared mobility: Definitions, industry developments, and early understanding, Technical report.

Simonetto et al. (2019)
Simonetto, A., Monteil, J. & Gambella, C. (2019), ‘Realtime cityscale ridesharing via linear
assignment problems’, Transportation Research Part C: Emerging
Technologies 101, 208 – 232.
http://www.sciencedirect.com/science/article/pii/S0968090X18302882  Stiglic et al. (2015) Stiglic, M., Agatz, N., Savelsbergh, M. & Gradisar, M. (2015), ‘The benefits of meeting points in ridesharing systems’, Transportation Research Part B: Methodological 82(Supplement C), 36 – 53.

Vivoda et al. (2018)
Vivoda, J. M., Harmon, A. C., Babulal, G. M. & ZikmundFisher, B. J.
(2018), ‘Ehail (rideshare) knowledge, use,
reliance, and future expectations among older adults’, Transportation
Research Part F: Traffic Psychology and Behaviour 55, 426 – 434.
http://www.sciencedirect.com/science/article/pii/S1369847817305922  Wang & Zhang (2017) Wang, H. & Zhang, X. (2017), ‘Game theoretical transportation network design among multiple regions’, Annals of Operations Research 249(12), 97–117.

Wang et al. (2019)
Wang, J.P., Ban, X. & Huang, H.J. (2019), ‘Dynamic ridesharing with variableratio
chargingcompensation scheme for morning commute’, Transportation
Research Part B: Methodological 122, 390 – 415.
http://www.sciencedirect.com/science/article/pii/S0191261518307689 
Xu et al. (2019)
Xu, Z., Yin, Y. & Ye, J. (2019),
‘On the supply curve of ridehailing systems’, Transportation Research
Part B: Methodological .
http://www.sciencedirect.com/science/article/pii/S0191261518311494 
Yan et al. (2018)
Yan, X., Levine, J. & Zhao, X. (2018), ‘Integrating ridesourcing services with public
transit: An evaluation of traveler responses combining revealed and stated
preference data’, Transportation Research Part C: Emerging Technologies
.
http://www.sciencedirect.com/science/article/pii/S0968090X18310398  Yang et al. (2002) Yang, H., Wong, S. C. & Wong, K. I. (2002), ‘Demand–supply equilibrium of taxi services in a network under competition and regulation’, Transportation Research Part B: Methodological 36(9), 799–819.

Young & Farber (2019)
Young, M. & Farber, S. (2019),
‘The who, why, and when of uber and other ridehailing trips: An examination
of a large sample household travel survey’, Transportation Research Part
A: Policy and Practice 119, 383 – 392.
http://www.sciencedirect.com/science/article/pii/S096585641830764X  Zavlanos et al. (2008) Zavlanos, M. M., Spesivtsev, L. & Pappas, G. J. (2008), A distributed auction algorithm for the assignment problem, in ‘Decision and Control, 2008. CDC 2008. 47th IEEE Conference on’, IEEE, pp. 1212–1217.
Comments
There are no comments yet.