On the Importance of demand Consolidation in Mobility on Demand

TL;DR

This paper systematically studies how demand consolidation in Mobility on Demand services affects operator costs and user Quality of Service, demonstrating a trade-off between capacity and QoS through stop location density.

Contribution

It introduces a MoD system with limited stop locations, analyzing how adjusting stop density impacts capacity and QoS, and provides an open-source simulation tool.

Findings

Decreasing stop density increases system capacity.

Increasing stop density improves user QoS.

The system can adapt between taxi-like and bus-like modes.

Abstract

Mobility on Demand (MoD) services, like Uber and Lyft, are revolutionizing the way people move in cities around the world and are often considered a convenient alternative to public transit, since they offer higher Quality of Service (QoS - less waiting time, door-to-door service) at a cheap price. In the next decades, these advantages are expected to be further amplified by Automated MoD (AMoD), in which drivers will be replaced by automated vehicles, with a big gain in terms of cost-efficiency. MoD is usually intended as a door-to-door service. However, there has been recent interest toward consolidating, e.g., aggregating, the travel demand by limiting the number of admitted stop locations. This implies users have to walk from/to their intended origin/destination. The contribution of this paper is a systematic study the impact of consolidation on the operator cost and on user QoS. We introduce a MoD system where pick-ups and drop-offs can only occur in a limited subset of admitted stop locations. The density of such locations is a system parameter: the less the density, the more the user demand is consolidated. We show that, by decreasing stop density, we can increase system capacity (number of passengers we are able to serve). On the contrary, increasing it, we can improve QoS. The system is tested in AMoDSim, an open-source simulator. The code to reproduce the results presented here is available on-line. This work is a first step toward flexible mobility services that are able to autonomously re-configure themselves, favoring capacity or QoS, depending on the amount of travel demand coming from users. In other words, the services we envisage in this work shift their operational mode to any intermediate point in the range from a taxi-like door-to-door service to a bus-like service, with few served stops and more passengers on-board.

Equations

$$t_i\le {\hat{t}}_i<t_i+\Delta t_i.$$

$${\hat{t}}_i=t_0+\sum _{j=1}^i[{\tau }_v(q_{j-1},q_j)+b_j+t_{l,j}]$$

$$\rho (s{p}_i)=\{\begin{array}{ll}+1& \text{if }s{p}_i\text{ is a pickup}\\ -1& \text{if }s{p}_i\text{ is a dropoff}\end{array}$$

$$n_{i,v}=n_0+\sum _{j=1}^i\rho (s{p}_i)<C$$

$$c(S_v,q_0)=\sum _{j=1}^n[{\tau }_v(q_{j-1},q_j)+b_j+t_{l,j}]$$

$$S_v^i=[s{p}_1,\dots ,s{p}_{i-1},s{p}^a,s{p}_{i+1},\dots ,s{p}_n]$$

$$S_v^{i\ast ,j}=[s{p}_1,..,s{p}_{i^{\ast }-1},s{p}^a,s{p}_{i^{\ast }+1},..,s{p}_{j-1},s{p}^b,s{p}_{j+1},..,s{p}_n]$$

$$T(i,v)\equiv \frac{\ell (q_i,\dots ,q_{i+H})}{m_{q_i}\{q_{i+1},\dots ,q_{i+H}\}}$$

$$T(v)=\frac{1}{n-H}\sum _{i=1}^{n-H}T(i,v)$$

Full text

The contribution of this paper is a systematic study the impact of consolidation on the operator cost and on user QoS. We introduce a MoD system where pick-ups and drop-offs can only occur in a limited subset of admitted stop locations. The density of such locations is a system parameter: the less the density, the more the user demand is consolidated. We show that, by decreasing stop density, we can increase system capacity (number of passengers we are able to serve). On the contrary, increasing it, we can improve QoS. The system is tested in AMoDSim, an open-source simulator. The code to reproduce the results presented here is available on-line.

This work is a first step toward flexible mobility services that are able to autonomously re-configure themselves, favoring capacity or QoS, depending on the amount of travel demand coming from users. In other words, the services we envisage in this work shift their operational mode to any intermediate point in the range from a taxi-like door-to-door service to a bus-like service, with few served stops and more passengers on-board.

I Introduction

The landscape of transportation services (Fig. 1) has become in recent years much richer than some decades ago. We identify in it two poles: on the one side Mobility on Demand (MoD) and on the opposite side fixed transportation. These two poles differ in the way they adapt to the demand. In MoD vehicles do not have pre-determined fixed routes, which are instead constructed based on the trip request. The opposite holds for fixed transportation (bus, subway, trains). Historically, MoD has been represented by taxis, serving mostly one passenger at a time, which implies (i) high cost of operation and thus (ii) high price for the user and (iii) low capacity, i.e., number of passengers that can be served per unit of time. On the other extreme, fixed transportation aims to consolidate demand in time and space: users need to walk to/from a limited set of stops (spacial consolidation) that vehicles serve in a limited set of time instants (time consolidation). Consolidation generally achieves high capacity, low cost of operation and thus reasonable levels of price, compatible with the missions of a public service. However, this is achieved in exchange for a reduction in QoS.

The distance between taxis and fixed transportation has been recently filled by ride sharing services, like Uber and Lyft, which can afford to propose cheaper prices, thanks to the ability of consolidating trips: by merging several user trips in the same optimized route, the cost of operating one vehicle is split among different users. This effect is expected to be further amplified if the number of stops is limited, since the consolidation of demand around them allows to construct more efficient routes. This motivated the launch of the experimental Uber Express Pool in November 2017 [1], which “offers the cheapest fares yet in exchange for a little walking” ([2]). However, the capacity of ride sharing systems is still far from transit. This motivates a rich research on responsive buses [3, 4, 5, 6], aiming to combine the flexibility of MoD with high capacity. A question has been raised in many research studies of whether to deploy flexible or fixed route buses depending on the amount of demand. Articles as [3] compare the performance of the two extreme bus services, i.e., fixed vs. on-demand, and found that after a certain request rate threshold the former is superior. We interpret this result under the lenses of consolidation: when high capacity is needed, fixed bus consolidates the demand better than flexible routes.

What commented so far shows that consolidation is becoming a fundamental aspect in future flexible transportation systems. The contribution of this paper is a systematic study of the role of consolidation in MoD. To this aim, we introduce a MoD system that changes behavior depending on the value of admitted stop density: instead of admitting pick-ups and drop-offs everywhere, we limit them to occur only at certain predefined locations. Their density is the parameter determining consolidation (the more the stop density the more the amount of consolidation). We use this parameter as a knob to explore the trade-off between QoS (travel times suffered by users) and high capacity. We show that by just leveraging this knob, with no change in the vehicle dispatch logic, the system effectively changes behavior to shift its configuration toward the left or the right poles of the transportation landscape.

We simulate the system in AMoDSim [7] and made all the scripts to reproduce the scenarios available in the repository. We find that, under the assumptions considered here, MoD can effectively offer higher capacity if more consolidation is adopted in change of a reasonable loss in QoS. This holds true with high levels of demand, while consolidation is detrimental otherwise.

II Related Work

In this section we will first clarify the terminology around MoD and then discuss the work in which the important of consolidation emerges.

The transportation systems we study are given different names in the literature: Mobility on Demand [8], Dial-a-Ride (see [9] and §1.3.1 of [10] ), Demand-Responsive [11], Ride Sharing [12], Taxi-Sharing [13], Ride-Hailing [14]. The common figure is that vehicles do not have pre-determined routes, which are instead constructed on the fly based on requests received from users, either via a smartphone app or, in early days experiments, via telephone calls [15].

The research community has not yet aligned on the the same terminology. Moreover, different nuances exist between the different terms. Dial-a-ride and Demand-responsive transportation historically denote buses with dynamically determined routes, whose experiments started in the 70s, but which are rarely adopted in reality. The terms Ride-Sharing or Taxi-Sharing are now employed to denote systems like Uber and Lyft operated with taxi-like vehicles with low capacity. The system we studied here spans the range between ride-sharing taxis and demand-responsive buses: by limiting the number of stops we move from the former to the latter, increasing system capacity.

MoD systems need a driver for each vehicle, who works directly or indirectly for the operator and drives only to satisfy the mobility needs of the passengers. There exist other systems, known as carpooling, in which the driver owns the car, drives toward her intended destination and can make detours to pick-up and drop-off other passengers. Differently from MoD, in carpooling drivers do not work for the service operator and they primarily satisfy their own mobility needs. Carpooling systems are out of the scope of our paper. We warn the reader that some authors [16] call them “ride-sharing”, which may generate confusion.

From the Operations Research viewpoint, the problem that MoD systems need to solve is a Dynamic Pickup and Delivery Problem [17], which is a class of Dynamic Vehicle Routing problems. The term “dynamic” means that the requests are not known in advance but enter the system while it is working and already serving other requests. These kind of problems require thus to continuously modify vehicle routes. It is usually assumed that users are picked-up and dropped-off at their origin and destination, respectively. In this paper we are instead interested in dealing with another decision variable for the operator: the amount of admissible stop locations in which we restrict pick-ups and drop-offs. The impact of consolidating the demand by restricting stop locations lacks a systematic study in the literature. This work is a contribution toward filling this gap. We will now briefly survey some work in which the importance of consolidation emerges, although not explicitly mentioned and not systematically studied.

Quadrifoglio et Al. [3] shows the existence of a critical demand density, in terms of requests per hour per Km2, over which a demand-responsive service becomes inefficient and it is better to deploy a fixed-route bus. We read in this main finding of the paper the emergence of the benefit of consolidating demand around the few stops when high demand density (aka high capacity) has to be served. Their work is based on an idealized scenario based on the continuous approximation approach, where the studied area is a continuous space (in lieu of a road network) and demand is a continuous density function over that space. Differently from their work (i) we can vary the degree of consolidation by varying the admitted stop location density, (ii) we preserve the flexibility of vehicle routes across those stops, even when their density is low, (iii) the area under study is a network and the requests are generated from a discrete stochastic process, which is more realistic, (iv) many vehicles are coordinated to serve the same area, while in [3] only one vehicle is assumed.

Stiglic et Al. [16] study a carpooling system and tackle the problem of fixing convenient meeting points to make drivers and passengers meet. We interpret meeting points as a way to consolidate demand. Differently from [16], (i) we study a MoD system, so we do not have the constraints of a pre-defined pair of origin-destination of the driver; (ii) in [16] only one pick-up and one drop-off point can be added to the pre-defined route of the driver, while the routes in our systems can have an arbitrary number of stop-points; (iii) we assume we do not know future requests, while in [16] trips are announced in advance and the matching is performed off-line.

The benefits of consolidation also emerge in fixed-route transportation systems [18, 19]. The former found that the consolidation program implemented in Portland, Oregon, consisting in increasing stop spacing, improved bus running times by 6% and at the same time had no relevant impact on user activity. The latter constructs fixed routes based on hubs that aggregate demand.

None of the previously mentioned research studies the inter-dependence between the system performance, the demand density and the density of stop-locations, which is the focus of our paper.

III System model

The system model considered in this paper is an extension of the one presented in our previous work [7]. The system is composed by a fleet of vehicles and a coordinator managing them. Users send trip requests (§ III-A) to the coordinator which matches them to the available vehicles and modifies the routes (§ III-B), based on a dispatching algorithm (§ IV). Note that, however, the results of this paper would still be valid under a different computation model, e.g., also if the user-to-vehicle matching were not performed by a centralized coordinator but were instead computed in a fully distributed manner, which is outside the scope of this paper. The system is configured to serve a set of admitted stop locations $\mathcal{Q}$. For any given location $z$, we denote with $\phi(z)\in\mathcal{Q}$ the closest of the admitted locations. Given two location $q,q^{\prime}$, we denote with $\tau_{w}(q,q^{\prime})$ and $\tau_{v}(q,q^{\prime})$ the time needed to travel the shortest path between $q$ and $q^{\prime}$ by walking and by car, respectively. For simplicity, we assume the speed of walking and of that of cars is fixed and constant.

III-A Stop points and Trip requests

The elementary unit of information handled by the dispatching algorithm is the stop point. It is a tuple $sp_{1}=(q,t,\Delta t,a)$, where $q\in\mathcal{Q}$ is a location amongst the admitted, $t$ is a preferred time, $\Delta t$ is the maximum extra time and $a$ is a binary variable specifying if the stop point is a pick-up or a drop-off. A stop point denotes that a user wishes to be picked-up or dropped-off at location $q$ in the inteval $[t,t+\Delta t[$. The dispatching algorithm that we will discuss later constructs vehicle routes as a sequence of stops, each stop corresponding to some stop points, and ensures the time constraints are not violated.

A trip is described by an origin location $o$, a destination location $d$, a time $t$ denoting the time at which the request has been generated and a time constraint $\Delta t$. A user must go to the admitted stop location $\phi(o)$ closest to the origin, send a request and wait for a vehicle. She then takes a ride to the admitted location $\phi(d)$ closest to the intended destination, toward which she walks. Therefore, a trip corresponds to a pair of stop points: a pick-up stop point $sp^{a}=\left(\phi(o),t_{1},\Delta t,\text{pickup}\right)$ and a drop-off stop point $sp^{b}=\left(\phi(d),t_{2},\Delta t,\text{dropoff}\right)$. Here, $t_{1}$ is the time instant in which the user arrives at the stop location $\phi(o)$. Let us denote with $t$ the time at which the user “appears”, i.e., she starts to walk from her origin, and with $\tau_{w}\left({o,\phi(o)}\right)$ the walking time from $o$ to $\phi(o)$. We have $t_{1}=t+\tau_{w}(o,\phi(o))$. Denote with $\tau_{v}\left(\phi(d),d\right)$ the minimum time to go from $\phi(d)$ to $d$ by car, we have $t_{2}=t_{1}+\tau_{v}\left(\phi(d),d\right)$. We call $\tau_{v}\left(o,\phi(o)\right)$ and $\tau_{v}\left(\phi(d),d\right)$ ingress and egress time, respectively.

To clarify the meaning of the time constraint $\Delta t$, it must be observed that the dispatching algorithm will try to place $sp^{a}$ and $sp^{b}$ into the vehicle routes (we will explain this in § IV). The specification of stop-point $sp^{a}$ will force the system to pick-up the passenger from $\phi(o)$ in the interval $[t_{1},t_{1}+\Delta t[$. Similarly, the specification of stop-point $sp^{b}$ forces the dispatching algorithm to drop-off the user at $\phi(d)$ in the interval $[t_{2},t_{2}+\Delta t[$. If it is impossible to satisfy any of the two conditions, the request is discarded.

III-B Vehicle schedules

At any time instant, each vehicle $v$ is associated with a schedule $S_{v}=[sp_{1},sp_{2},\dots]$, which is the sequence of stop points the vehicle plans to serve. This sequence is associated with a time sequence $T_{v}=[\hat{t}_{1},\hat{t}_{2},\dots]$ denoting that stop point $sp_{i}=(q_{i},t_{i},\Delta_{i},a_{i})$ will be served at time $\hat{t}_{i}$. In order to satisfy the time constraints, the following condition must be satisfied

[TABLE]

Note that, if a vehicle is at a certain location $q_{0}$ at a time $t_{0}$, the time at which $sp_{i}$ will be served is deterministically computed as

[TABLE]

where $b_{j}$ is the time needed for a passenger to board/alight to/from a vehicle, depending of whether $sp_{j}$ is a pick-up or drop-off. The value $t_{l,j}$ is the time lost for accelerating after stop point $sp_{j-1}$ and decelerating before $sp_{j}$. Observe that it can happen that two consecutive stop points are in the same location, i.e., $q_{j-1}=q_{j}$. In this case, $\tau_{v}(q_{j-1},q_{j})=0$ and $t_{l,i}=0$, meaning that the pick-up and drop-off operations are performed one after the other, without any vehicle movements in between. For a more detailed explanation of the vehicle movement model and the computation of the time lost in accelerating and decelerating, refer to § 3.3 of [7]. Each vehicle has a capacity $C$. When constructing schedules, we must ensure that the number of passengers does not exceed $C$. Suppose a vehicle has at a certain point in time $n_{0}$ passengers on board and a certain schedule $S_{v}=[sp_{1},sp2,\dots]$. Obviously, the number of passengers changes only when certain $sp_{i}$ is served. Let us introduce

[TABLE]

The number of passengers onboard after $sp_{i}$ has been served is:

[TABLE]

This inequality must hold for any vehicle $v$ and any stop point $sp_{i}$ in $S_{v}$.

Definition 1

A schedule is feasible if it respects constraints (1),(2), i.e., if all pick-ups and drop-offs are guaranteed to be served within the expressed time requirements and the vehicle capacity is never exceeded.

IV Dispatching algorithm

We describe in this section how the system we consider associates users to available vehicles and how routes are constructed. We assume for simplicity all the logic is centralized in a single coordinator. Our dispatching logic is implemented by an on-line algorithm: every time a request arrives to the system, we associate it to a vehicle and we modify its schedule accordingly. The dispatch is based on the concept of schedule cost.

Definition 2

Consider any vehicle $v$ at a certain time instant, its schedule $S_{v}=[sp_{1},sp_{2},\dots,sp_{n}]$ and its current location $q_{0}$. Following the notation of § III-B, the cost of that schedule is the amount of time needed to execute it completely, i.e.

[TABLE]

The dispatching algorithm is given in Alg. 1. Let us consider a user with origin $o$, destination $d$, time constraint $\Delta t$ and suppose the user “appeared” at time $t$ (see § III-A). Suppose the user arrives at the ingress stop at time $t_{1}\geq t$ and generate her request from there. The corresponding pair of stop points are $sp^{a}=\left(\phi(o),t_{1},\Delta t,\text{pickup}\right)$ and $sp^{b}=\left(\phi(d),t_{2},\Delta t,\text{dropoff}\right)$, as in § III-A.

The dispatching algorithm seeks the “best vehicle” to serve this request. In order to do so, we associate a cost $c(v)$ to each vehicle and we choose the vehicle with the lowest cost. To compute $c(v)$ for a vehicle $v$, we compute different tentative schedules, based on the following explanation. We first try to find the best placement for the pick-up stop-point $sp^{a}$. To this aim, we create tentative schedules $S_{v}^{i}$ for $i=1,\dots,n$, obtained placing $sp^{a}$ in position $i$:

[TABLE]

If $S_{v}^{i}$ is feasible, we compute its cost $c(S_{v}^{i},q_{0})$. If for all $i=1,\dots,n$ we have that $S_{v}^{i}$ is infeasible, it means the request cannot be associated to the vehicle. We indicate this by assigning $c(v)=\infty$. Otherwise, we take the best tentative schedule, i.e., we take the $i^{*}$ such that $S_{v}^{i*}$ has minimum cost. We than try to place the drop-off stop point $sp^{b}$ into the tentative schedule $S_{v}^{i*}$. In order to do so, we consider different other tentative schedules $S_{v}^{i*,j}$, where $sp^{b}$ is placed in the $j$-position of $S_{v}^{i*}$, with $j>i$:

[TABLE]

If for all $j>i$, we have that $S_{v}^{i*,j}$ is infeasible, it means that the request cannot be served by vehicle $v$, which we denote with $c(v)=\infty$. Otherwise, we take $j^{*}$ such that the cost $c(S_{v}^{i*,j*},q_{0})$ is the minimum among $c(S_{v}^{i*,j},q_{0})$ for all $j>i$. We set $c(v)=c(S_{v}^{i*,j*},q_{0})$.

The operations described above allow to compute, for each arriving request, (i) the cost $c(v)$ of serving that request with any vehicle $v$ and, if $c(v)<\infty$ (ii) the modified schedule $S_{v}^{i*,j*}$ including the pick-up and the drop-off related to that request. The best vehicle is the one that guarantees the lowest cost, i.e. $v^{*}=\arg\min_{v}c(v)$. The request is thus assigned to $v^{*}$ and the schedule $S_{v}$ is modified in $S_{v}^{i*,j*}$. Note that if for all vehicles $v$ we have $c(v)=\infty$, it means there is no vehicle which can satisfy that request and we discard it.

We repeat the process every time a new request arrives. Note that the dispatching algorithm continuously modify vehicles route in order to satisfy incoming requests with the lowest cost possible, while at the same time meeting the requirements of the incoming request as well as the requirements of requests that have been previously assigned.

V Results

We present in this section the results of our simulation campaign that we ran on AMoDSim [7], an open-source simulation. The code to reproduce the results presented here is available in the AMoDSim’s repository. We will first describe the scenarios considered and then study the impact of consolidation on the operations of the system (capacity, vehicle routes, sharing degree) and on the QoS.

V-A Scenarios

As in [7], the network consists in a Manhattan grid of 60 Km2, representative of the city of Manhattan with static travel times as in [20]. The distance between east-west-oriented roads and north-south oriented roads is 80m and 200m, respectively.

Requests are generated as a Poissonian process with a certain rate $r$ ranging from 20 req/h/Km2 to 320 req/h/Km2, compatible with to the scenarios in the literature  [12, 21]. The origins and destinations are uniformly distributed in the surface. The time constraint $\Delta t$ (see § III-A) is fixed to 20 minutes. Note that not all the requests will be actually generated: if the origin-destination pair of a trip is within a distance of 1.6 Km, we assume the traveler prefers to walk and does not call the system.

Vehicle cruising speed is 35 Kmph. The acceleration and deceleration of the vehicle after/before it stops is 1.676 mpss in absolute value, which gives an additional time lost for accelerating and decelerating of 11.5 s (see § 3.3 of [7] and references therein for a description of the vehicle movement model). The walk speed is constant and fixed to 3.6 Kmph. The board and alight times are 5s and 10s, respectively, as in [22]. Observe that we do not want to make assumptions on the capacity of the vehicles, as we are exploring a service which is in the middle between a taxi-like and a bus-like service. For this reason, we set in our simulations the seat capacity to $C=45$ passengers, which in our simulation is never filled in our scenarios and thus corresponds de facto to not being limited by a pre-determined capacity. We consider a relatively small fleet (with respect to [12]), of 500 or 1000 vehicles, since our challenge is to offer a high capacity service with relatively low cost operations. In all the simulations, if not explicitly specified, the fleet size is 1000 and the request rate 320 req/h/Km2, which we fix as default values. We consider different values of spacing between admitted stops, ranging from 80m, which corresponds to admit stops, thus forcing non consolidation, up to 860m. All results are collected during 4h simulation, to wash out transient effects.

V-B Impact on system capacity

We show in this section the benefits of limiting the density of admissible stops when the demand, i.e., the request rate, is high with respect to the number of vehicles. In Fig. 2 we represent the number of requests over the simulation time. In particular, we represent the total number of requests sent by the users, the requests that the system has been able to assign to some vehicle, the number of drop-offs and pick-ups. Recall that a request remains unassigned if no vehicle can serve it within the time-limits. In this case, the requests are rejected, i.e., the user would receive a message saying that the system is not able to handle her request. The number of assigned requests is thus representative of the system capacity.

First, observe the load of the system with no consolidation (Fig. 2-left). The system is much slower to assign requests then the rate of incoming requests, which denotes overload. Note that the overload is instead alleviated reducing the stop density, e.g., increasing the stop spacing (Fig. 2-right): by consolidating the demand in fewer locations, the system is able to better serve a high request rate, thus offering more capacity.

We validate this finding by depicting the number of requests after 3h, with different values of stop spacing (Fig. 3). We chose 3h, since it is usually considered the maximum duration of peak periods in transportation.

We observe in the plot in the center, where 1000 vehicles are deployed and the request rate is 320 req/h/Km2, that the responsiveness of the system in terms of requests assigned, picked-up and dropped-off consistently improves when reducing stop density. Note that this holds only in situations where the request rate is high with respect to the deployed vehicles, i.e., in the central plot and also in the plot on the right, where 160 req/h/Km2 are served by just 500 vehicles. If we instead maintain the same request rate 160 req/h/Km2, but we serve it with more vehicles (figure on the left), we see consolidation is not important, as the system is not overloaded anyways. We obtain the same picture, which we omit here, when further reducing the demand. Therefore, the correct stop spacing to avoid overload depends on the proportion between request rate and the fleet size and consolidation by reducing stop density becomes important only when this proportion is high.

V-C Impact on route efficiency

Fig. 4 shows that aggregating demand in fewer stops reduces the kilometers traveled by the vehicles and thus operational cost. To explain this, we study how “efficient” are the routes constructed by the dispatching algorithm.

We adopt the convention that a route is ‘efficient’ if it visits all the stop locations contained in it traveling a small distance. The more routes are tortuous, e.g., passing more times than necessary through the same stops or making un-necessary long detours, the less the system is efficient. To quantify this aspect we define a measure of tortuosity.

Let us consider a trajectory of a vehicle $v$, i.e., the sequence $q_{1},\dots,q_{n}$, where $q_{i}$ is the location of stop point $sp_{i}$. Let us truncate the trajectory starting from $i$ and ending in $i+H$, i.e., thus considering the sub-trajectory $q_{i},\dots,q_{i+H}$. We call the parameter $H\in\mathbb{N}$ horizon. Let us consider the length $\ell(q_{i},\dots,q_{i+H})$ of this subtrajectory. Starting from $q_{i}$, we can visit all the other points $\{q_{i+1},\dots,q_{i+H}\}$ in $H!$ ways, each associated with a length. Let $m_{q_{i}}\{q_{i+1},\dots,q_{i+H}\}$ the minimum length to visit all the other points starting from $q_{i}$. We define the tortuosity of the trajectory at the $i$-th stop-point as

[TABLE]

The tortuosity of a vehicle is the average of the tortuosity at all its stop-points:

[TABLE]

The smaller the tortuosity, the more efficient the route of the vehicle. Note that the best we can have is $T(v)=1$ meaning that at every stop point the vehicle chooses the shortest trajectory. Note also that the shortest trajectory may be impossible for a vehicle to follow, if it violates the time constraints of § III-B. Therefore, one must not be tempted to associate a physical meaning to the measures of tortuosity in absolute. They are just useful when comparing different system configurations, which we do in this section. The results we report are the tortuosity, averaged across als vehicles, for a horizon $H=4$.

We observe in Fig. 5 that when the rate of requests is high consolidating demand around fewer stops helps decreasing the tortuosity, as expected. This explain the reduction in kilometers traveled (Fig. 4). However, the opposite effect is recorded with low request rates. One hypothesis to explain this behavior at low rates is that, while serving the users on board, each vehicle does not collect enough requests in a unit of time so that it can optimize the route. However, this deserves further investigation in future work.

It is interesting to emphasize again that all results do not depend on just stop spacing but also on the fleet size. Fig. 5 shows the beneficial impact of consolidation shows off earlier (i.e., already with smaller request rates) with a fleet of 500 vehicles than 1000 vehicles.

V-D Impact on sharing degree

Conceptually, the sharing degree of the system is its ability to aggregate together multiple trips in the same vehicle at the same time. We quantify the sharing degree as the average percentage of time a vehicle spends with certain number of passengers on-board. Fig. 6 shows that consolidating demand around fewer stops helps increasing the sharing degree: each vehicle is able to aggregate more trips. This explains why, with a fixed amount of vehicles, the system offers more capacity to serve high volume of requests, when more consolidation is put in place (less stops), as discussed in § V-B. Observe that with consolidation vehicles behave for a non-negligible amount of time as minibuses.

V-E Impact on quality of service

While in § V-B we have shown that it is advantageous for an operator to limit the density of possible stop locations, we need to study possible negative side effects on the quality of service offered to the users. It is obvious to observe that the more the stop spacing, the longer the ingress and egress times suffered by users. It is possible to compute the mean ingress and egress time for any given value of stop spacing with the help of Fig. 7.

Let us focus on the mean ingress distance walked by a user (the mean egress distance would be computed similarly). Let us denote with $D$ the stop spacing. Since we assume that a user always goes to the closest stop, we can partition the entire studied surface in a Voronoi tassellation where the seeds correspond to the stops. A Voronoi cell of a stop is the set of points that are closer to that stop than to any other. Since our stops are by construction located in a regular grid, the Voronoi cells are simply squares with edge measuring $D$. Let us consider any origin point $(x,y)$ in any certain Voronoi cell around a stop $(x_{0},y_{0})$. The distance traveled by a user to go from that origin to the ingress stop is $z=|x-x_{0}|+|y-y_{0}|$. Since $x$ and $y$ are generated uniformly at random, we are sure that $|x-x_{0}|\simeq\mathcal{U}(0,D/2)$. The same holds for $|y-y_{0}|$. Therefore the mean walked distance is $\mathbb{E}[z]=D/4+D/4=D/2$. Since we assume a fixed walking speed $v_{w}=3.6$ Km/h, we can immediately compute the mean ingress and egress time based on the value $\mathbb{E}[z]$. With maximum consolidation, i.e., $D=860$m, the mean ingress time is $D/2/v_{w}=7$ min and the maximum value of ingress time is $14$ min. In other words, the ingress and egress time imposed on users to aggregate the demand around fewer stops is, in our scenario, in a limited range of acceptable values.

It is interesting to observe (Fig. 8) that the waiting time slightly improves with less stop density and the on-board time (time spent by the user on board of a vehicle) is practically not affected, thanks to the increased overall efficiency of routes (§ V-C) that finally benefits users as well. However, we should recall that the more stop spacing, the more ingress and egress time suffered by users. It is thus important to compute the total travel time, which is the time passed from the moment the user appears at her origin to the moment where she arrives at the intended destination. The total travel time is the sum of ingress, waiting, onboard and egress times. The total travel time is plotted in Fig. 9, which shows, as expected, that maximum consolidation (stop spacing 860m) increases total travel time. This increase is severe with a low request rate (33% of increase with $r=20$ req/h/Km2), while it is less important with high request rate (23% with $r=320$ req/h/Km2). This confirms that consolidation is deleterious with low demand, since it reduces QoS without improving capacity, while it is desirable when high demand has to be satisfied, as high capacity can be achieved in exchange for an acceptable loss in QoS. Fig. 9 helps also to visualize the trade-off this paper is about: the more the consolidation, the higher service capacity (less requests are rejected) but the lowest the QoS for the requests that manage to be served.

VI Negative results and future extensions

Observe that the systems model we adopt is one of the many possible. A first element we emphasize is that the time constraint $\Delta t$ does not include the walking time. For example, if a user specifies a certain $\Delta t$, it means she wants to wait at most $\Delta t$ after she arrives at $\phi(o)$, independent of whether her ingress time is high or small. Moreover, the time constraint $\Delta t$ also means that if she arrives at the stop at time $t_{1}$ and the minimum time to drive from $\phi(o)$ to $\phi(d)$ is $\tau_{v}\left(\phi(o),\phi(d)\right)$, she wants to arrive at $\phi(d)$ within a time $t_{1}+\tau_{v}\left(\phi(o),\phi(d)\right)+\Delta t$, independent of whether the ingress and egress time are high or small. We have also experimented with alternative formulations, which take into account the ingress and egress time in the expression of time constraints, in order, for example, to compensate users with higher ingress time by making them wait less. However, we observed that the results were worse both in terms of operational costs for the operator and user QoS. We noticed that by including ingress and egress time in the time constraints translates in too strict conditions for the dispatching algorithm to construct efficient schedules. For instance, if a user has a $\Delta t=20$ min and has to walk 14 minutes, the system would see the request after the user arrives at the stop and would have to satisfy it within 6 minutes waiting time, which leaves no sufficient degree of freedom for the construction of vehicle routes: if a vehicle is able to make a detour to satisfy this strict constraint it would do it, even if it could be highly inefficient. While this type of behavior would be acceptable in a taxi-like service with few requests with respect to the fleet size, we observed that it is not appropriate for high capacity MoD, which should instead resemble a bus-like system, i.e., should be less sensitive to the single user time requirements and more sensitive to the overall system performance.

Observe that the system we presented can re-configure its behavior just by changing the admitted stop density and we showed that it has a relevant impact on capacity and QoS, although the dispatching algorithm does not change at all. We will explore in the future other algorithmic strategies which can improve both QoS and capacity by changing the algorithm behavior based on the value of stop density or input demand.

Another margin of improvement is given by the introduction of a reservation. While in the model adopted now a user sends a request only after she arrives at the closest stop, it would be possible to let her send the request immediately after she “appears” at the origin, specifying that she will arrive at the closest stop in a certain time interval. The algorithm could thus be able to handle this request in advance. We expect improvement in both operational cost metrics and QoS and we plan to study such possibility as part of future work.

To make our study more realistic, we also plan to introduce variable speed for vehicles, depending on the conditions of traffic, and to let traffic be impacted by MoD vehicles. However, as the goal of this paper is to study the high level impact of demand consolidation in MoD, the lack of these elements of realism does not invalidate the findings presented here.

VII Conclusion

In this paper we studied the importance of consolidation in Mobility on Demand (MoD) systems. We observed that by varying the parameter determining the spacial density of admitted stop locations, we can favor high capacity or Quality of Service (QoS). We showed that the benefits of consolidation cannot be evaluated in absolute. They depend on the vehicle fleet size and the amount of demand (request rate). In particular, consolidation is beneficial when the demand is high with respect to the number of available vehicles, but is deleterious otherwise.

Ride-sharing systems have mostly no-consolidation at all, being mainly door-to-door services. On the opposite side, fixed-route traditional transit has maximum consolidation, as only a restricted amount of stops are served. We show instead that a system can be engineered so as to function in any intermediate operational mode between those two extremes, varying the level of consolidation. This paper is a first step toward an investigation of such systems, which we will pursue in our future work.