Delivery systems with crowd‐sourced drivers: A pickup and delivery problem with transfers

Rapid urban growth, the increasing importance of e‐commerce and high consumer service expectations have given rise to new and innovative models for freight delivery within urban environments. Crowdsourced solutions—where drivers are not employed by a carrier but occasionally offer their services through on‐line platforms and are contracted as required by carriers—are receiving growing attention from industry. We consider a crowdsourced system where drivers express their availability to perform delivery tasks for a given period of time and the platform communicates a schedule with requests to serve. We investigate the potential benefits of introducing transfers to support driver activities. At transfer locations, drivers can drop off packages for pick up by other drivers at a later time. We frame the problem as a multidepot pickup and delivery problem with time windows and transfers, and propose an adaptive large neighborhood search algorithm that effectively identifies beneficial transfer opportunities and synchronizes driver operations. Computational experiments indicate that introducing transfer options can significantly reduce system‐wide travel distance as well as the number of drivers required to serve a given set of requests, especially when drivers have short availability and requests have high service requirements.

and at places where more capacity is needed. Another option, the one we assume is used in our research, is to ask individuals to commit to work for a specific period of time, a block, in return for a minimum pay assurance. Such a scheme is employed, for example, by Amazon Flex and Grubhub (a meal delivery platform).
Because blocks tend to be relatively short, as this provides flexibility both for the company and for the individuals, we consider a system in which goods to be delivered can be transferred, that is, be taken from their origin to their destination by more than one driver. This allows a company to make use of available crowd-sourced capacity to handle short-distance as well as long-distance transportation tasks.
To model the proposed crowd-sourced delivery system, we consider a pickup and delivery problem with time windows and transfers (PDPTW-T). At transfer locations, drivers can drop off packages for pick up by other drivers at a later time. The number and location of transfer points are strategic decisions and not considered in our study. A transfer location can be situated at accessible locations-facilitating the operations between drivers-such as gas stations, stores and supermarkets. It can also be an automated facility, such as a locker station, situated in one of those locations. Characterizing delivery settings that might benefit from the introduction of transfers has yet to be studied (to the best of our knowledge, this is only investigated by Mitrović and Laporte [20]).
When the transfer of requests is not an option, the problem is a pickup and delivery problem with time windows (PDPTW) and defined as follows. A fleet of vehicles is available to satisfy a set of transportation requests, each defined by a load to be transported (goods or people) by a single vehicle from a pickup location (origin) to a delivery location (destination), within given time windows for visiting each location. Multiple requests can be served by the same vehicle, as long as the vehicle capacity is never exceeded. When all requests are known in advance, the problem is referred as the static PDPTW; when requests arrive during the execution of planned routes and routes have to be updated to accommodate new requests, the problem is referred to as a dynamic PDPTW. The objective is to determine a set of vehicle routes serving all requests, where the function that drives the costs is chosen according to the application at hand (e.g., distance, duration, number of vehicles, or pollution; see Savelsbergh and Sol [27]). The reader is referred to Berbeglia et al. [5] for a survey on dynamic pickup and delivery problems.
As mentioned above, transfer points are locations in the network where requests can be transferred between vehicles and temporarily stored. Hence, more than one vehicle can be used to serve a single request, for example, a request may be picked up at its origin by one vehicle, then dropped at a transfer point where another vehicle (potentially with other characteristics) picks it up and delivers it at its destination. Note that direct transportation from the pick up location to the delivery location by the same vehicle is still possible. Transfer points allow, among others, service by a mixed fleet of vehicles ((electric) truck, van, or bike), but also allow integration of freight and passenger transportation. As any pickup and delivery problem can be seen as a special case of a pickup and delivery problem with transfers, pickup and delivery problems with transfers are NP-hard. A critical challenge when solving pickup and delivery problems with transfers is synchronization. Whereas allowing goods to be temporarily stored (or people to wait) at an intermediate location provides more flexibility and, thus, may allow more effective use of resources, these resources need to be carefully synchronized in order to obtain a feasible solution.
Our contributions can be summarized as follows. We analyze the potential benefits of transfers in pickup and delivery operations in urban areas, focusing specifically on settings in which drivers operate short shifts (as is likely to happen in crowdshipping settings models). In such settings, the flexibility provided by transfers may allow serving long-distance requests that would otherwise be impossible. We propose a heuristic for the solution of instances of the multiple-depot PDPTW-T. The heuristic produces high-quality solutions in a reasonable amount of time. We compare the performance of the heuristic to that of a state-of-the art heuristic for the (multiple-depot) PDPTW. The main limitation of our approach, at this point in time, is that it assumes that all information is available at the start of the planning horizon. In the future, we plan to extend our technology to a dynamic setting, where information arrives over time during the planning horizon. Nevertheless, we believe that our current analysis already provides relevant and informative insights into the potential benefits of transfers for transportation systems relying, in part, on crowd-sourced capacity.
The remainder of the paper is organized as follows. The relevant literature and related problems are discussed in Section 2. The notation used throughout the text is introduced in Section 3, as well as a formal problem definition of the problem and a mathematical programming formulation. The heuristic, an adaptive large neighborhood search (ALNS) heuristic, is introduced in Section 4, and the results of an extensive computational study are presented in Section 5. Finally, we present conclusions and directions for further research in Section 6.

LITERATURE REVIEW
The literature considering the use of transfer points in pickup and delivery problems can be divided in two groups: (a) pickup and delivery problems with transshipment (PDP-T) and (b) pickup and delivery with cross-docking (PDP-CD). Whereas both, transfers and cross-docks, act similarly in providing a consolidation mechanism in which short term storage for a limited amount of requests allows vehicles to potentially improve their loading plans, a few differences are worth mentioning. First, in a cross-docking system transportation requests are executed by a set of separate pickup and delivery routes. Inbound vehicles collect the items, bring them to the CD where they are consolidated, and then a set of outbound vehicles delivers them to their final destinations [17]. Transfer locations, on the other hand, can be seen as a possible transfer opportunity that is, a request can be carried out either through transfers and, in this case, one vehicle collects the load and another one delivers it to its final destination, or the request can be served directly by the same vehicle. Second, the CD is the start and end location for each route in the plan, whereas a transfer can be any location where vehicles can exchange loads throughout their routes. Third, in some CD applications, consolidation activities can only be executed when all vehicles are in the CD. In the PDP-T, this is not required as long as synchronization requirements are met.
The static (i.e., all transportation requests are known in advance of the optimization) PDP variants have given rise to a substantial amount of research, for an overview, the reader is referred to Berbeglia et al. [4]. Only recently the possibility of allowing transfers of goods (or people) is addressed in the literature. Mitrović and Laporte [20] propose a two-phase heuristic to solve the PDP-T consisting of a construction phase, in which a start solution is obtained, and an improvement phase defined by iteratively removing and inserting requests in a candidate solution. Nakao and Nagamochi [21] consider the PDP-T, without time windows on the requests, and analyze lower bounds for the case where one transfer location is available and vehicles are allowed to visit the transfer at most once. The authors show that z( where k is either the number of routes in an optimal solution of the PDP-T or the number of requests, z(PDP) and z(PDPT) are the optimal travel costs for the PDP and the PDP-T, respectively. Cortés et al. [10] propose the first mathematical formulation for the PDP-T and a branch-and-cut approach able to solve small instances. Motivated by an air cargo carrier application, Qu and Bard [23] introduce an insertion heuristic to identify profitable circumstances to exploit the transshipment option. The authors develop a GRASP algorithm and propose a set of randomly generated instances. More recently, Rais et al. [24] propose a new model for the problem, distinguishing between vehicle (routes) and request flows and using multicommodity flows to match these two. Masson et al. [18] propose an ALNS algorithm for the problem, and tackle the dial-a-ride problem (DARP) with transfers in Masson et al. [19]. A similar problem is proposed by Ghilas et al. [13], where requests are allowed to be transferred to/from scheduled lines such as bus, train and metro, operating between two terminals. In a recent survey from Guastaroba et al. [14], pickup and delivery problems with transfers are mentioned as one of the extensions of the PDP with cross-docking.
An increasing number of new start-ups within the shared-economy context, exploring different ways of monetizing underused assets for example, cars, rooms, is giving rise to new strategic and operational issues that have to be addressed in order to support such systems. It is only recently that crowdsourced delivery systems have received academic attention. Based on the crowdshipping concept envisioned by Walmart, Archetti et al. [1] introduce the vehicle routing problem with occasional drivers (VRPOD). Occasional drivers are in-store customers willing to fulfill the delivery for an online customer on their journey (performing a small detour, if necessary) after leaving the store. The authors highlight the challenges associated with designing appropriate compensation mechanisms and the importance of employing company drivers in order to ensure a certain service level. Dayarian and Savelsbergh [12] explore using in-store customers to supplement company drivers to deliver dynamic incoming, on-line customer orders. Dahle et al. [11] build on the VRPOD and introduce the pickup and delivery problem with time windows and occasional drivers (PDPTW-OD). The authors propose compensation schemes for the occasional drivers and show that cost savings of 10%-15% can be achieved even when the company utilizes a suboptimal scheme.
Behrend and Meisel [3] investigate a form of crowdshipping, in which private drivers offer to execute delivery jobs for other people on trips they would make anyway, within item-sharing contexts, where assets for example, tools, leisure equipment, can be temporarily rented. Whereas the prevalent practice on item-sharing platforms is that the transportation of an asset is delegated to the consumer (either the consumer actually performs the task or hire a courier company), the authors show that crowdshipping can increase profits and service levels for an item-sharing platform. Arslan et al. [2] consider a service platform that dynamically creates matches between parcel delivery tasks and private drivers. Since the platform is only able to control the available number of drivers, a regular, dedicated vehicle fleet is also operated by the platform. The authors introduce a new variant of the dynamic pickup and delivery problem, and propose a rolling horizon framework for its solution. Results show that, compared to traditional delivery systems, crowdshipping systems can provide savings of up to 37%.
In another realization of the crowdshipping concept, similar to the approach considered in this work, drivers willing to perform transportation services use an online platform (Uber-Freight, Amazon Flex) and are matched to demand for such services in real-time. The drivers are independent, work for a given period of time and are paid in a hourly basis. To the best of our knowledge, there is no work dealing specifically with such scenarios. Nevertheless, in a similar context, taxi drivers might be willing, at times, to move freight within the city. Li et al. [16] introduce and explore the share-a-ride problem taking into account different requirements to transport people and freight using a taxi network. Taxis are allowed to deliver parcels as long as the service level for the passenger does not deteriorate significantly. A Freight Insertion Problem is proposed to insert parcel collections in a given routing plan for passengers aimed at minimal passenger disruptions (e.g., maximum ride-time for passengers, maximum detours, number of stops). Chen and Pan [7] refers to a "crowd of taxis" to propose, in the same vein as the solution for reverse flows in Chen et al. [8], using the taxi fleet and a network of 24/7 shops to satisfy last-mile delivery requests.
The use of intermediate locations in crowdsourced delivery systems, as an interface between company drivers and the crowd, is investigated by Kafle et al. [15]. The authors propose a two-tiered delivery system, in which the second tier is crowdsourced to cyclists and pedestrians (the crowd). In the system, a truck carrier posts pickup and delivery requests on a platform and individuals in the crowd bid to carry out a subset of those requests. Parcels can be transferred between a truck and (one or more) individuals at relay locations. The company decides on the winning bids and plans the truck routes that visit the relay points and delivery addresses of requests for which no bids were received or were too expensive. Chen et al. [9] introduce the the multidriver multiparcel matching problem (MDMPMP), in which parcels may be transported by a single or by multiple drivers, using existing planned routes of the drivers. Parcels can be transferred between drivers, allowing for a more flexible matching of drivers and parcels, since drivers do not need to fulfill the complete parcel's journey and use transfer opportunities to bring the parcel closer to its final destination.

PROBLEM DEFINITION
The PDPTW-T is defined as follows. We are given a set of transportation requests R = {(i + , i − ) | i + ∈ P, i − ∈ D}, where P and D are the set of pickup and delivery locations, respectively, and where a request r i = (i + , i − ) concerns the pickup of a load at i + and its delivery at i − within time window [E i + , L i − ], specifying the earliest time, E i + , when the load is available at the origin and the latest time, L i − , when the load must be delivered at the destination. A fleet of vehicles, V, is available to serve the requests. Each vehicle v ∈ V starts and ends its shift at a depot located at m v ∈ M, with M the set of all depot locations. Each vehicle v ∈ V has a duty period, or shift, [E v , L v ]; the vehicle can depart its depot at E v and has to return to its depot by L v . There is a set Γ of transfer locations. A request r i ∈ R can be served by one vehicle visiting both i + and i − , or by two vehicles with one vehicle visiting i + and the other visiting i − . In the latter case, the request is transferred at a location t ∈ Γ. Note that we allow only a single transfer. Two vehicles serving a request are not required to be at the transfer location at the same time, that is, transfer locations offer short-term storage (a vehicle can drop off a request and leave, while another vehicle can come and pick up the request at a later time). Multiple vehicles can visit a transfer location at the same time and vehicles can wait at a transfer location. We focus on settings where the number of drivers is large and shift durations are short (relative to the planning horizon)-which is representative of crowdshipping settings. We also assume, for simplicity of exposition, that the size of loads is small compared to the vehicle capacity, and that the vehicle capacity is never restricting.

Mathematical formulation
The PDPTW-T can be modeled on a directed graph G(W, A) with node set W = P ∪ D ∪ M ∪ Γ and A = {(i, j) | i, j ∈ W, i ≠ j}. It takes a vehicle ij > 0 units of time to travel from i to j, (i, j) ∈ A, and incurs a cost c ij > 0. We assume travel times satisfy the triangle inequality. The PDPTW-T seeks to find a minimum cost set of vehicle routes serving all requests (either by one vehicle or by two vehicles). Rais et al. [24] propose a flow-based mixed integer programming formulation for the PDPTW-T, in which request flows are linked with vehicle flows. The vehicle flow is modeled by binary variables x v , indicating the traversing of arc (i, j) ∈ A by vehicle v. Request flows are modeled by binary variables y indicating whether vehicle v ∈ V carries request r ∈ R over arc (i, j) ∈ A. Synchronization of transfer operations is achieved through variables a v i and v i , for arrival and departure times of vehicle v at location i, respectively, and binary variables s indicating whether request r is transferred between vehicles v and w at transfer location t. The formulation is given below x The objective (1) is to find a minimum cost set of routes satisfying all requests. Constraints (2) enforce that each vehicle executes at most one route and constraints (3) enforce that a vehicle starts and ends a route at the same depot. Vehicle flow conservation is expressed by constraints (4). Constraints (5) and (6) guarantee that each request is served, that is, it is picked up and delivered, respectively. The flow conservation for requests, at transfer locations, is enforced by constraints (7), and at nontransfer locations by constraints (8). Note that for transfer locations, a request entering the transfer is allowed to leave in a different vehicle, whereas for nontransfer locations a vehicle entering the location with a given request must leave the location with that request. Request and vehicle flows are linked by constraints (9), which enforce that a request has to travel in a vehicle. Consistency of arrival and departure times is enforced by big-M constraints (10) and time windows are enforced by constraints (11). Transfer operations are synchronized by constraints (12) and (13): if request r ∈ R is transferred between vehicles v and w, v, w ∈ V, at location t ∈ Γ, then vehicle w can depart from transfer location t only after the arrival of vehicle v at transfer location t.
As in the above formulation, we will assume for the remainder that a request is only transferred once, that a vehicle visits a given transfer location only once, and that two vehicles meet and exchange requests only once. A vehicle can visit multiple transfer locations on its route.

Benefits of transfers
To illustrate and assess the potential benefits of using transfers, we analyze a set of stylized instances and compare solutions with and without transfers.
Consider an instance in which the pickup and delivery locations are vertices of a regular n-sided polygon with side length S, inscribed in a circle of radius Υ. A single depot (m ∈ M) is located at the center of the circle and also acts as a transfer location (t ∈ Γ). Let the common shift for vehicles be [0, 4Υ] and let the common time window for requests be [0, 4Υ] as well, with S > Υ.
Next, we locate the pickup and delivery locations of the requests in such a way that the ratio k 1 k 2 can get very large, where k 1 is the minimum fleet size required to serve all requests when transfers are not allowed and k 2 is the minimum number of vehicles required when transfers are allowed. Figure 1A-D illustrates instances with 3, 4, 5, and 6 requests, respectively.
In Figure 1A, for example, six requests, (1 + , 1 − ), …, (6 + , 6 − ) are shown. If fewer than six vehicles are available to serve all requests when transfers are not allowed, then two requests must be picked up and delivered by the same vehicle. However, this is impossible, because two requests with a common pickup location do not have a common delivery location, which implies that the vehicle needs to visit three locations and the travel time is at least Υ + S + S + Υ, which exceeds 4Υ. Observe that, if more requests are added, a fleet of six vehicles would still be enough to serve all requests, no matter where the pickup and delivery locations for the added requests are located. Thus, in the best solution without transfers, k 1 = 6 vehicles (routes) are required, each departing from the depot, visiting two vertices of the polygon (one with the pickup and another with the delivery), and returning to the depot.
When transfers are allowed, the best solution requires k 2 = 3 vehicles, each performing a route departing from the depot, visiting one vertex of the polygon, then the transfer location, followed by a vertex and returning to the depot. All loads are picked up and taken to the transfer location where they are consolidated and then taken to their final destination. It is not possible to use fewer that three vehicles. If two vehicles are used, then one of them has to visit two locations to pickup loads and take them to the transfer location, which would not leave enough time for delivery. Thus, for this setting, we have k 1 k 2 = 2. Figure 2, illustrates the potential benefits of transfers in a setting with two depots and a single transfer location. In the example, the six requests (1 + , 1 − ), …, (6 + , 6 − ) can be serviced by vehicles from any depot. Deliveries 1 − , 2 − and 3 − are located in a line and spaced by S time units. The time windows for those locations are such that if a vehicle picks all three requests, the deliveries should be visited in the order 3 − , 2 − , 1 − . In particular, latest delivery times are set as L 1 − = L 3 − − S and L 2 − = L 1 − − S and L 3 − small enough such that a vehicle visiting 1 − or 2 − before visiting 3 − is not able to reach 3 − before L 3 − . Moreover, the shift length is such that a vehicle departing from 1 − after visiting 3 − and/or 2 − is not able to return to m 1 in time. As a consequence, when transfers are not allowed, requests (1 + , 1 − ), (2 + , 2 − ), (3 + , 3 − ) have to be served by a different vehicle ( Figure 2A). Observe that for requests (4 + , 4 − ), (5 + , 5 − ), (6 + , 6 − ) we have a similar situation, as the locations are positioned on symmetrical positions, with depot m 2 replacing m 1 . When transfers are allowed, two vehicles, one from depot m 1 and one from depot m 2 , can serve all requests ( Figure 2B). Note that, after visiting transfer t and swapping the requests, the deliveries still have to be visited in the

ADAPTIVE LARGE NEIGHBORHOOD SEARCH
Solving instances of the mathematical model presented in Section 3 in a reasonable amount of computation time is only possible for small instances; Rais et al. [24] presents results for instances with 10 and 14 locations (5 and 7 requests, respectively) and where transfers are allowed at every location. This is due, in part, to the symmetry (vehicles are indistinguishable) and the use of big-M constraints, which results in weak linear relaxations. Therefore, we develop an ALNS algorithm which is able to handle large instances in short computation times. ALNS algorithms have been successfully applied to many hard combinatorial problems, in particular to many variants of the vehicle routing problem (see Pisinger and Ropke [22]). An ALNS algorithm specifically designed for solving instances of the PDPTW is described in Ropke and Pisinger [25]. A successful ALNS algorithm relies on the availability of several fast-to-explore local search neighborhoods for modifying a solution. We focus on neighborhoods that remove requests from the current solution and reinsert them to create a modified solution. At each iteration, one of the neighborhoods is selected, giving priority to neighborhoods that have been successful in earlier iterations. Improving solutions are always accepted, but a diversification mechanism is incorporated which sometimes accepts worse solutions. The basic flow of our ALNS algorithm is given in Algorithm 1.
An initial solution, in which some of the requests are transferred, is obtained as described in Section 4.1. A removal and insertion operator are chosen (line 4) based on weights that reflect past performance (line 14). The removal and insertion operators are applied in sequence (line 5). The acceptance of the resulting solution is controlled by a scheme that is similar to those found in simulated annealing (SA) algorithms, that is, an exponential function with a cooling rate (line 12). The initial temperature (T 0 ) is given by − ln(0.5) z 0 , where z 0 is the cost of the initial solution and 0 < < 1, i.e., a solution with cost (1 + )z 0 has probability 0.5 of being accepted. A higher value (and consequently T 0 ) allows for more diversification throughout the search, especially during the early stages, but may still be insufficient to avoid getting trapped in local optimum. Therefore, we take a similar approach to Stenger et al. [28] and reset the temperature to − ln(0.5) z * after iterations in which no improving solution has been found, where z * is the cost of the best solution found so far.

Initial solution
A critical aspect of an ALNS algorithm for solving the PDPTW-T concerns the strategies embedded for deciding which requests to transfer and at which locations. Such strategies have to be embedded in the solution improvement framework (i.e., removal/insertion operators that explicitly consider transfers), but starting with an initial solution in which some requests are being transferred might help guide the search-requests are considered one at a time and introducing a (new) transfer is not likely to look attractive as it involves detours to visit a transfer location. Thus, by having (some) transfers in the initial solution, an ALNS algorithm is more likely to make effective use of transfer options.
Any solution, s, is characterized by a subset R ′ s ⊂ R of requests being transferred. We create an initial solution, s 0 , by forcing a subset of requests to be transferred in the initial solution. Next, we describe how we obtain R ′ s 0 ⊂ R (4.1.1) and how we decide on the transfer locations to use (4.1.2) when constructing s 0 (4.1.3).

Selecting requests to transfer
For a request r i = (i + , i − ) ∈ R, let i be the (direct) travel time between i + and i − . Selecting the requests that are forced to use a transfer in the initial solution is controlled by a threshold ′ . We let requests in the initial solution.
Transferring of requests having relatively long travel times might yield cost savings as it may induce "regional" vehicle routes in which requests with pickup and delivery locations in a region are served without a transfer and requests with pickup and delivery locations in different regions are served using a transfer. The threshold ′ is defined based on the characteristics of an instance, for example, half of the longest possible travel time.

Selecting a transfer location
Given the set of candidate requests to be transferred in the initial solution, the next decision concerns which transfer location to use. To prevent transfers that require a large detour (compared to traveling directly from pickup to delivery location), transferring where > 1 is a parameter controlling the maximum allowed ratio between the detour i + ,t + t,i − and the direct travel time i . Moreover, transferring request r i via t has to be feasible for at least one combination of depots m a and m b , that is, feasible routes m a − i + − t − m a and m b − t − i − − m b that can be timed and synchronized to induce a feasible transfer at t have to exist. If there is no feasible transfer location for a request in the candidate set, the request is removed from the candidate set. Among the feasible transfer locations t ∈ Γ for request (i + , i − ) we select the one that minimizes the difference between i + ,t and t,i − . This strategy favors transfer locations that are located more centrally between the pickup and delivery locations of a request, thus better balancing the detour required to visit the transfer between the two vehicles serving the request. Figure 3 illustrates the possible transfer assignment for a request (i + , i − ).

Constructing the initial solution
The initial solution, s 0 , is constructed such that all requests in R ′ s 0 are served by two vehicles and transferred at the location selected using the strategy presented in Section 4.1.2. All other requests r i ∈ R∖R ′ s 0 are served by a single vehicle. To construct a feasible solution, all requests in R∖R ′ s 0 are put in the "request bank" and one iteration of the ALNS algorithm for the PDPTW by Ropke and Pisinger [25] is executed to obtain a partial solution for those requests. Then, for each request r i ∈ R ′ s 0 , we use a "Greedy insertion with transfer" operator of our ALNS framework (described in Section 4.2) to (try and) insert r i using the selected transfer location. If unsuccessful, two new routes are created: are chosen such that the total travel time of the two new routes is minimized.

Improvement phase
At the heart of any ALNS algorithm is a set of operators, each modifying the current solution in a specific and limited way, that is, making small modifications to the current solution, and, thus, defining a neighborhood. As is common in many ALNS algorithms for routing problems, our operators either remove or insert sets of locations (either pickup or delivery locations).
For a given solution, let (i) and (i) denote the direct (on the same route) predecessor and successor nodes, respectively, of node i. The detour cost associated with node i is is not yet served in the solution, then the cost to insert its pickup, i + , between nodes u and v = (u) is the detour cost c u,i + + c i + ,v − c u,v , which we also denote as i + . In case of inserting i − , the cost is given by for the pickup and delivery nodes, respectively, is the detour

Removal operators
A removal operator deletes a number of requests from the current solution and adds them to a request bank (from which insertion operators select requests to be inserted). Let O − k (s) denote the (partial) solution that results after removal operator O − k is applied to solution s, and let R − k (s) denote the set of requests deleted from solution s by operator O − k . Algorithm 2 illustrates the steps performed by a removal operator. The operator uses a biased selection procedure to choose a route to delete from the current solution. Only routes that do not visit a transfer are considered. The probability that a route is selected to be deleted is proportional to the ratio of the waiting time in the route and the number of requests served in the route. Thus, the operator favors the deletion of less efficient routes. All requests in the chosen route are deleted. If the number of requests deleted is less than q, then another route is selected. The process continues until at least q requests are deleted.

4.
Transfer-based request removal (O − 4 ): This operator considers requests that have been transferred in one or more previous solutions. For each request r i = (i + , i − ), let t * i denote the number of times request r i has been transferred in an incumbent solution encountered during the search. The probability that a request r i is selected is proportional to 1 − t * i I * , where I * denotes the (total) number of incumbent solutions encountered during the search. Note that requests that are seldom transferred in incumbent solutions are more likely to be deleted than requests that are often being transferred in incumbent solutions. 5. Cluster removal (O − 5 ): This operator is an adaptation of an operator used in Masson et al. [18,19] and based on the idea that if the pickups (deliveries) of a set of requests form a cluster, it may be beneficial if they are picked-up (delivered) by the same vehicle and dropped off at (collected from) a transfer location. In our implementation, we randomly pick a "root" request (i + , i − ) and compute sets C + i and C − i , where C + i contains pickup locations within radius = 60 units of distance from i + being serviced by a different vehicle (and the delivery location is not within from i + ) and C − i contains delivery locations within radius from i − being serviced by a different vehicle (and the pickup location is not within from i − ). The requests in the larger set are deleted. The parameter q is ignored.
After the deletion of requests, it may happen that a vehicle visits a transfer location, but no transshipment of any request takes place. We allow such unnecessary visits to remain in the current solution for at most iterations. If in consecutive iterations a transfer location t is not used to transfer any request, it is removed from the route(s). Allowing unnecessary visits to transfer locations can be beneficial, because inserting a request involving a transfer location that is not yet in the solution results in additional detour costs and, consequently, a deterioration in solution quality. If the transfer location is already in the solution, even if it is currently not used to transfer requests, the increase is only due to the detour cost incurred for the inserted request itself. Moreover, it also increases the likelihood that the transfer location is already visited by multiple vehicles. A downside of keeping transfer locations with unnecessary visits in the solution is that the time required to visit the transfer location may render an otherwise feasible insertion infeasible. Moreover, more insertions with transfers are evaluated and, as a consequence, execution time is longer. Despite these downsides, our experiments have shown that keeping transfer locations with empty visits provides a good mechanism for exploring transfer opportunities. A postprocessing step at the end of the search removes any unnecessary visits at transfer locations in the best solution found.

Insertion operators
The objective of an insertion operator is to reintroduce requests in the set R − i (s), that is, the requests deleted by removal operator O − i . Let O + j (s) denote the solution obtained after applying insertion operator O + j to a (partial) solution s. Algorithm 3 presents the steps performed by an insertion operator that does not consider transfers, and Algorithm 4 presents the steps performed by an insertion operator that does consider transfers.

1.
Greedy insertion without transfer. Requests are sequentially inserted in the least-cost position and route. If a request cannot feasibly be inserted, it remains in the request bank. The sequence in which requests are inserted defines an operator: • O + 1 : Requests are selected in decreasing order of direct travel time from pickup to delivery location. • O + 2 : Requests are selected in increasing order of insertion cost. More formally, if Δ rk represents the least cost to insert request r in route k (Δ rk = ∞ if the insertion is infeasible), then the operator selects request r ′ to be inserted in route k ′ as (r ′ , k ′ ) = arg min r∈R − i (s), k∈K Δ . Values Δ rk are updated after the selected request has been inserted in its associated route.
• O + 3 : Requests are selected in decreasing order of regret, that is, the absolute difference between least insertion cost and the second least insertion cost. More formally, if Δ 1 is the least-cost insertion of request r in a route k and Δ 2 is the second least-cost insertion of request r in a route k (where k may be the same or a different route), then the operator selects request r ′ to be inserted in route k ′ as (r ′ , k ′ ) = arg max r∈R − i (s), k∈K (Δ 2 − Δ 1 ). Values Δ 1 and Δ 2 are updated after the selected request has been inserted in its associated route.
• O + 4 : Similar to operator O + 2 , but the request is selected randomly among the best insertions, where, after initial experiments, is set to 30% of the feasible insertions.

2.
Greedy insertion with transfer. Requests are sequentially inserted in the least-cost positions and routes. If a request cannot feasibly be inserted, it remains in the request bank. Given a request r = (i + , i − ), an operator seeks two routes, k a and k b , and a transfer location, t, such that the possible visit times at t for k a and k b overlap (ie, there exist a time when both vehicles can be at t). If it is possible to insert i + before t in k a and i − after t in k b (properly accounting for any change in the arrival time at t of route k a due to the insertion of i + ), the insertion is considered feasible. The sequence in which requests are inserted defines an operator: • O + 5 : Requests are selected in decreasing order of direct travel time from pickup to delivery location.
• O + 6 : Requests are selected in increasing order of insertion cost. More formally, if Δ 1 k 2 is the cheapest cost to insert request r = (i + , i − ), where i + and i − are inserted in routes k 1 and k 2 , respectively (Δ 1 k 2 = ∞ if the insertion is infeasible), then the operator selects a request r ′ and routes k ′ 1 and k ′ 2 by (r ′ , k ′ 1 , k ′ 2 ) = arg min r∈R − i (s), k 1 ,k 2 ∈K Δ 1 k 2 . Values Δ 1 k 2 are updated after the selected request has been inserted in its associated routes.
• O + 7 : Requests are selected in decreasing order of regret. More formally, if Δ 1 1 k 2 represents the least-cost insertion of request r using a transfer, and Δ 2 1 k 2 represents the second least-cost insertion of request r using a transfer (where the routes in which the pickup and delivery location are inserted may be the same or may differ), then the operator selects request r ′ and its associated routes as arg min r∈R − i (s), k 1 ,k 2 ∈K (Δ 2 1 k 2 − Δ 1 1 k 2 ). Values Δ 1 1 k 2 and Δ 2 1 k 2 are updated after the selected request has been inserted in its associated routes.

Transfer insert
(not yet in the solution), this route is created. If there are multiple transfer locations in C i , the one minimizing the difference | i + ,t − t,i − | is chosen.
It is possible that an insertion operator does not succeed to insert all requests deleted by a removal operator. In this case, the remaining requests are inserted as follows: find a route k a with transfer location t a maximizing the number of of delivery locations that can be feasibly inserted in k a after t a . Let the set of these delivery locations be denoted by D. Similarly, find a route k b with transfer location t b maximizing the the number of pickup locations that can be feasibly inserted in k b before t b . Let the set of these pickup locations be denoted by P. If |D | ≥ | P|, the delivery locations in D are inserted in k a (if feasible) after t a . For each inserted delivery location, if it is not possible to insert the corresponding pickup in a route already in the solution, a new route m v − i + − t a − m v is created (assuming a vehicle v is available). If |D | < | P|, a similar process is used, but starting with the pickup locations. If, at the end, there are still remaining requests, these are inserted in new routes without transfers.

Operator selection
The adaptive weight mechanism used to control the selection of a removal and insertion operator is implemented by a roulette wheel procedure, as described in Pisinger and Ropke [22]. If the weight of operator O i , i ∈ 1, …, Π, is i , expressing the desirability of selecting operator O i , then the probability of selecting O i is given by i ∕ ∑ Π j=1 j . The removal and insertion operators are chosen independently, that is, with different roulette wheels. At the start of the search, all operators have equal weights. During the search, the weights are updated every iterations, similarly to Pisinger and Ropke [22]. As discussed above, in our ALNS algorithm, two types of insertion operators are considered: operators in which transfers are considered, and operators in which transfer are not considered. Since the insertion of a node (request) can be feasible for one type, but not for the other, our ALNS algorithm selects two insertion operators, one of each type. The operator with the largest weight is applied first, and if there are remaining nodes (requests), then the other operator is applied.
The performance of each operator is recorded in its weight based on the solutions obtained after the operator is applied. In particular, the score i for operator O i starts at 0 at the start of each segment of iterations, and is incremented by: 1 if an overall best solution is found, 2 if an improving solution is found, and 3 if a worse solution is found and accepted (as part of the annealing scheme). If a i is the number of times operator O i was used during the current segment (of iterations), then the

Efficiency
The performance of an insertion-based neighborhood search heuristic relies heavily on its ability to efficiently evaluate the feasibility of an insertion, as a very large number of insertions will be attempted. We provide an appendix with supplementary material where we discuss the information that is kept with the current solution to allow fast (constant time) evaluation of the feasibility of an insertion. Moreover, we show how to update this information when the current solution changes.

COMPUTATIONAL EXPERIMENTS
In this section, we present the results of a set of computational experiments conducted to evaluate the performance of the ALNS algorithm and to characterize transportation settings which might benefit from the introduction of transfers. The ALNS algorithm was coded in C++ and the experiments were conducted using an Intel Core i5-2450M machine, running at 2.5 GHz × 4 with 4 GB of RAM, under Ubuntu 16.04. To investigate the benefits of transfers, we compare the solutions obtained by our ALNS algorithm to the solutions obtained by the ALNS algorithm of Ropke and Pisinger [25], which does not consider transfers. Furthermore, we analyze the impact of different problem characteristics, in particular, the vehicle's shift length, the number of transfer locations, the geographic distribution of transfer locations, and the geographic distribution of customers.

Instance generation
To assess the potential benefits of transfers in freight transportation systems employing crowdsourced drivers, we generate sets of instances that capture characteristics of such systems. We consider a squared geographical area of 120 × 120 units of distance and assume that one unit of distance can be traveled in one time unit (e.g., 60 km/h). Four depots are located in the area as shown in Figure 4A, requests can be served from any depot, and the number of vehicles in each depot is unlimited. Pickup and delivery locations are drawn uniform randomly in the area, but we consider different scenarios, , for origin-destination proximity: long-distance requests only (L), that is, at least 60 units of distance between a pickup and a delivery location, short-distance requests only (S), that is, no more than 60 units of distance, but at least 30 units between a pickup and a delivery location, and a third scenario having both long-distance and short-distance requests (M). We generate instances with 50, 75, and 100 requests, each with a 180 units of time (e.g., 3-hour) time window, that is, E i + = 0 and L i − = 180 for all r i ∈ R, for each class L, M, and S. If = 1 |R| ∑ r i ∈R i indicates the origin-destination proximity of an instance, then for the generated instances in classes L, M, and S, we have, on average, = 74.67, = 57.69, and = 45.82, respectively. We consider vehicle shift lengths H ∈ {180,240,300} (i.e., drivers operate for three, four, or five hours). The instances are created such that even for the shortest shift length (H = 180), all requests can be served (i.e., there is at least one depot such that a vehicle from that depot can feasibly visit the pickup and delivery locations of a request on a route). Moreover, we consider two geographies for the transfer locations, MD-4T and MD-5T, shown in Figure 4A,B, respectively. In the former there are four transfer locations, and in the latter there are five transfer locations, with one additional transfer location in the center of the region. The full set of instances can be downloaded at https://doi.org/10.17632/pywzcgyzrv.2. We note that Mitrović and Laporte [20] generated instances of the PDPTW-T motivated by an application in last-mile freight transportation, and used these in their computational experiments. Furthermore, Masson et al. [18] generated instances of the PDPTW-T motivated by an application in which transportation requests of disabled people need to be served. As indicated earlier, our research is motivated by an environment in which crowd-sourced drivers, working for short periods of time, transport shipments from origin to destination. As a consequence, the instances available in the public domain are not representative of the operating environment we are exploring, and, thus, the instances are not well-suited for testing our methodology. Nevertheless, for the sake of completeness and as a validation of our methodology, we present results for a subset of the instances proposed by Mitrović and Laporte [20] in the appendix.

ALNS algorithm parameter tuning
In Table 1, we show the parameters (column Par.) and the values used in our ALNS. In the left side of the table, we present the parameters that are set to similar values used in Ropke and Pisinger [25]. In the right side of the table, we present the parameters we believe have a significant impact on the performance of our proposed ALNS algorithm and for which the values have been carefully calibrated (Table 2).
Parameter tuning was done using a set of six instances, three with 30 and three with 50 requests-one instance for each scenario of origin-destination proximity, L, S and M-, as described in Section 5.1. All parameters to be tuned are given a default value. Then, a single parameter value (or single parameter set values) is varied while the others are kept fixed. For each parameter value considered (of the parameter being tuned), we solve each of the six instances five times. The parameter value yielding the best results is chosen. The process continues until all parameters have been assigned a value. The parameters to be tuned, and their respective default values, are (( 1 , 2 ), ( 1 , 2 , 3 ), ) = ((6, 10), (10,10,10), 100), where parameters 0 < 1 < 2 < 1 control the fraction of requests to be removed, 1 , 2 , and 3 are the reward values for operators and is the maximum number of iterations an unused transfer is allowed to remain in the current solution. In the initial solution for an instance, each request is served individually by a single vehicle without a transfer. To assess the quality of different parameter values, we assign a score to each solution obtained: z * z , where z is the cost of the solution and z * is the cost of best solution encountered during an experiment. Because we also want the proposed ALNS algorithm to be reasonably efficient, we adjust the score to take run times into account as well: 0.
where t is the run time and t * is the fastest run time encountered during an experiment. Thus, a value close to 1.0 for a parameter value (the average score over the five runs) indicates superior performance. First, we tune the interval from which the number of requests to be removed by a removal operator is drawn uniform randomly, that is, [ 1 | R| , 2 | R| ]. The results show that ( 1 , 2 ) = (0.1,0.2) performs best. Allowing for a larger fraction of requests to be removed may lead to a wider exploration of the solution space, but it also increases time per remove-and-reinsert combination as requests are inserted one by one and execution time primarily depends on the number of requests inserted.
Next, we tune the reward values for the operators, where we note that their relative difference is more important than the values themselves. We consider three sets of parameters: one in which finding new best and better solutions is highly rewarded, that is, ( 1 , 2 , 3 ) = (40,10,1), one in which success in finding new best and better solutions is recognized as a positive and rewarded, but not as much, that is, ( 1 , 2 , 3 ) = (4,2,1) and, finally, one in which we do not actively "encourage" the search for new best and better solutions, but rely on the randomness in the search process to encounter high-quality new best and better solutions, that is, ( 1 , 2 , 3 ) = (1,1,1). With the exception of one instance, the best results are obtained by highly rewarding success in finding new best and better solutions. This indicates that the SA acceptance mechanism, in combination with the restarting procedure, is enough to provide a satisfactory level of diversification in the search, and avoids getting trapped in local optima.
Finally, we calibrate the maximum number of iterations an unnecessary transfer location visit is allowed to remain in the current solution, . We consider two scenarios: one in which an unnecessary transfer location visit is removed immediately, that is, = 0, and one in which an unnecessary transfer location visit is kept much longer, that is, = 100. Even though run times increase when an unnecessary transfer location visit is kept longer, it appears to be worthwhile to do so. This is likely due to the fact that it significantly simplifies the search for beneficial transfer opportunities.

Stylized instances
We have used the proposed ALNS algorithm to solve stylized instances as shown in Figure 1, with 4-, 5-, 6-, 7-, and 8-sided polygons inscribed in a circle with radius 100 (where instances for 7-and 8-sided polygons are created as expected). We compare the solutions obtained by the proposed ALNS algorithm, where the center of the circle can be used as transfer location, to the solutions obtained by the ALNS algorithm of Ropke and Pisinger [25] (i.e., without any transfers), and to the optimal solutions. The results can be found in Table 3. For each instance, we report the total travel distance (Dist), the number of vehicles used (Veh), the total computational time in seconds (Time) and the number of requests transferred (Trans).
Our proposed ALNS is able to obtain the optimal solution for all but one of the instances. In constructing the polygons, we took distance and time to be equivalent (traveling one unit of distance requires one unit of time) and forced distances and travel times to be integer valued. As a result, for the 7-sided polygon it was not possible to obtain a completely regular shape. This hinders synchronization at the transfer points, and hence a lower quality solution resulted. The higher run times of our proposed ALNS algorithm compared to the one of Ropke and Pisinger [25] are the result of more complex and more time consuming insertion operators, because the need to consider transfers. This is especially true for these stylized, highly symmetrical instances, where proper synchronization of transfers is critical.

An example of transfer benefits
We first illustrate the potential benefits of transferring requests by analyzing the results of a single instance of class L with 25 requests, shift length 180, and transfer location geography MD-4T. Figure 5 shows two solutions, one in which transfers are not considered ( Figure 5A) obtained with the ALNS by Ropke and Pisinger [25], and one in which transfers are considered ( Figure 5C) obtained with our proposed ALNS (squares indicate depots, triangles indicate transfer locations, and circles indicate pickup and delivery locations).
In the solution without transfer ( Figure 5A) all but six requests are served by a dedicated vehicle (i.e., a vehicle serving a single request), and 22 vehicles are used. In the solution with transfers ( Figure 5C) only two requests are served by a dedicated vehicle and all other requests are transferred, and only 10 vehicles are used. To facilitate comparing the solutions with and without transfers and to better understand the benefits of transfers, we show, in Figure 5B,D, four rectangles, one for each depot, representing the area containing the routes originating from that depot. Observe that in Figure 5B, corresponding to the solution without transfers, there is a much larger overlap between the rectangles than in Figure 5D, corresponding to the solution with transfers. This illustrates that when transfers are possible, vehicles can stay closer to the depots and can perform pickups and deliveries of multiple requests within the shift; it is as if the transfer locations induce subregions within the region. When transfers are not possible, a vehicle performing a pickup has to also perform the corresponding delivery and consolidating multiple requests withing the shift becomes more difficult. Similar settings that is, transfer location geography MD-4T, 3-hour time window, shift length 180, are used to generate a set of 15 instances with 10 requests, where five instances have long-only, five instances have short-only and five instances have mixed-distance requests. These instances are solved using the IP formulation presented in Section 3 and employing Gurobi 8.01 as the IP solver with a time limit of two hours. For each instance, we compute a solution without transfers, using the ALNS algorithm by Ropke and Pisinger [25], and provide it as an initial solution to the solver. We also compute a solution using our proposed ALNS algorithm and provide it as an initial solution. The results can be found in Table 4, where we report the total distance (Dist), the number of vehicles used (Veh), and the optimality gap after two hours (Gap). Solutions in which one or more requests are transferred are labeled with a superscript t. The results show that for most instances, Gurobi is unable to improve the initial solution provided in two hours (note the large optimality gaps after two hours of computing). If a solution without transfers is provided, a better solution is found for five instances, where in four of them the improved solution has at least one request that is transferred. The solutions produced by our ALNS algorithm are equal or better (in terms of total distance and number of vehicles used) in 14 out of the 15 instances. When the solutions produced by our ALNS algorithm are provided as initial solution, Gurobi again finds a better solution for five instances, where in three of them the improved solution uses fewer vehicles.

Results for proposed generated instances
A set of 10 instances was generated for each combination of number of requests, origin-destination proximity, and vehicle shift length, as described in Section 5.1. Each instance in a set is solved five times using the ALNS algorithm by Ropke and Pisinger [25] and our proposed ALNS algorithm, and the average cost of the solutions as well as the lowest cost among them are reported. Two initial solutions were considered in the runs with our proposed ALNS algorithm: the solution obtained with the ALNS algorithm by Ropke and Pisinger [25] and the initial solution constructed as described in Section 4.1 using ′ = 0.8max r i ∈R { i } and = 1.25. To evaluate the potential benefits of transfers, we compare the gap between solutions with transfers and solutions without transfers: Δ = (c w − c)/c, where c is the cost of the solution without transfers and c w is the cost of the solution with transfers. Note that, because the solution found by the ALNS algorithm of Ropke and Pisinger [25] is not necessarily optimal, we cannot claim that the benefits are solely due to adding transfers. The solutions (routes) found for each instance in the experiments can be found online, following the data set link mentioned in Section 5.1.
First, we consider transfer location geometry MD-4T. In Table 5 we report the results for instances with 50 requests for each origin-destination proximity class () and vehicle shift lengths 180, 240, and 300 (H). Each row in the table presents average results over all instances for the given combination (H, ). Column RP ALNS reports the cost (c) and the fleet size (Veh) of the solutions obtained with the ALNS algorithm by Ropke and Pisinger [25] (in each of the five runs, the same solution was found). Column Proposed ALNS reports the results obtained using our proposed ALNS algorithm. Column Best reports results for the best among the five solutions, whereas column Average reports the average over the five solutions. Column s 0 indicates the initial solution used: s r , solution produced by the ALNS algorithm of Ropke and Pisinger [25], or s t , solution produced by the scheme described in Section 4.1. Column Δ D (%) reports the reduction in distance, column Δ V (%) reports the reduction in the number of vehicles used, column Trans reports the number of transferred requests, and column t(s) reports the run time in seconds, excluding the time to obtain the initial solution. Note that scheme s t requires little time (less than one second) whereas scheme s r requires running the ALNS algorithm by Ropke and Pisinger [25] which takes a considerable amount of time (on average 60% of the running time of our proposed ALNS algorithm). Detailed results can be found in the supplementary appendix.
We observe that transfers can provide significant benefits, especially when the driver shift length is short (H = 180) and the distance between pickup and delivery locations is long (L)-we see a reduction of almost 50% for both the total distance and the number of vehicles used. When the distance between pickup and delivery location is short (S), the benefits are minor, in the Note: Column RP ALNS reports results obtained with Ropke and Pisinger [25] (no transfers) and results obtained with our proposed ALNS (with transfers) are reported in column Proposed ALNS. In row s r , the initial solution to our method is given by the solution found with the ALNS by Ropke and Pisinger [25] and, in row, s t , the initial solution is a solution in which some requests are initially transferred, as described in Section 4.1. Results for an instance in each class are the average over five runs. The ALNS of Ropke and Pisinger [25] provided the same solutions in all runs, thus we do not present Best of Average values for c or Veh.
order of 1%-2%, regardless of driver shift length. As expected, the benefits decrease when driver shift lengths increase, because with longer driver shift lengths routes can cover larger distances and serve more requests in the same route, which tends to be less costly than using transfers. The effect of the initial solution appears to be minor. Starting from an initial solution in which requests are transferred tends to result in final solutions with slightly more requests being transferred than starting from an initial solution in which no requests are transferred. This is likely due to the fact that insertions with transfer operators are more likely to be rewarded during the early stages of the search when the initial solution already has some transfers. When starting from a high-quality (locally optimal) solution without transfers, introducing transfers in the solution is likely to increase the total distance and insertions with transfer operators are less likely to be rewarded. For instances in which the distance between pickup and delivery location is short (S), and where transfers have a limited value, especially for larger shift lengths (H = 240 and H = 300), starting from an initial solution with transfer is in fact detrimental to the quality of the final solution. We also note that the run time is slightly higher when starting from an initial solution with transfers, because, as noted earlier, the more time-consuming insert with transfer operations are performed more often.
Next, we consider transfer location geometry MD-5T. The results can be found in Table 6. The benefits are similar to what we have seen for transfer location geometry MD-4T, but for the fact that, on average, more requests are transferred, and, consequently, slightly higher CPU times are observed.
To show that our proposed ALNS algorithm scales well, we present results for instances with 75 and 100 requests in Tables 7  and 8, respectively. In each table, we show the results obtained for transfer location geometry MD-5T and using an initial solution with transfers. We observe once more that for instances in which there are requests with a long distance between pickup and delivery location (L and M) and the shift lengths are relatively short (180 and 240), the proposed ALNS algorithm is able to find solutions that reduce both the total distance and the number of vehicles used.

Evaluation of remove and insert operators
The performance of the remove and insert operators employed in our ALNS algorithm has been evaluated on two representative instances. The first instance, I 1 , has 50 long-only requests, shift length 180, and transfer location geometry MD-4T. As we have seen, such an instance is likely to benefit from transfers. The second instance, I 2 , has 50 short-only requests, shift length 300, Note: Column RP ALNS reports results obtained with Ropke and Pisinger [25] (no transfers) and results obtained with our proposed ALNS (with transfers) are reported in column Proposed ALNS. In row s r , the initial solution to our method is given by the solution found with the ALNS by Ropke and Pisinger [25] and, in row, s t , the initial solution is a solution in which some requests are initially transferred, as described in Section 4.1. Results for an instance in each class are the average over five runs. The ALNS of Ropke and Pisinger [25] provided the same solutions in all runs, thus we do not present Best of Average values for c or Veh. and transfer location geometry MD-4T-an instance less likely to benefit from transfers. We analyze which operators are used throughout the search when solving these two instances and also if this depends (strongly) on the initial solution.
Recall that the likelihood of an operator being selected is proportional to its weight, where the weight is initialized and updated during each segment of iterations (within a segment, operators are rewarded scores based on whether or not an operator advances the search, that is, obtains a new best solution, obtains an improving solution, or obtains a worse, but accepted solution). Therefore, to analyze the performance of an operator during the search, we report how the weight of the operator changes during the search and its contribution to advancing the search (the ratio of the number of times the operator advanced the search and the total number of times the search advanced).  Figure 6 shows that for both initial solutions, insertion operators using transfers are the ones contributing the most for advancing the search (note that the scales of the vertical axis of the weight charts are not same). The stacked bars show that, in many iterations, an insertion with transfer operator alone is able to advance the search (because in many cases the stacked bars for the insertion without transfer operators sums up to less than 1, indicating that the they were not used). The larger weights of the insertion with transfer operators also demonstrate that these operators are more successful in finding new best and better solutions. We see that insertion with transfer operator O + 8 is mostly used at the start of the search process and more so when the initial solution does not have transfers. None of the other three insertion with transfer operators clearly dominates the others. However, we see that when the initial solution already has transfers, insertion with transfer operator 0 + 5 is able to quickly find good transfer options for the requests with long distances between pickup and delivery locations (the initial spike in the weight chart shows the operator finds new best solutions). Regarding removal operators, note the important contribution of the transfer-based removal O − 4 , especially when starting with a solution without transfers. When an instance benefits little from transfers, as is the case for instance I 2 , the proposed ALNS algorithm recognizes this and adjusts accordingly (Figure 7). When the initial solution has no transfers, the search advances mainly using insertion without transfer operators. Even though insertion with transfer operator O + 8 introduces a few unnecessary transfer visits early in the search, the transfer location is eventually removed from the solution. When the initial solution has transfers, improving solutions involving transfers are found in the early iterations, but as the search progresses and the insertion without transfer operators successfully insert more and more requests, the search advances primarily due to these operators (the turning point appears somewhere around iteration 17 000).

Block-based crowd-sourced transportation systems
In this section, we evaluate the impact of transfers in a block-based crowd-sourced systems, that is, system in which drivers are available for certain periods of time (blocks) during the planning. In particular, drivers commit to provide their services in one or more offered blocks, time slots of a given duration.
In the following experiments, we consider only instances with short and long requests (class M) and with only long requests (class L), as instance with only short requests (class S) do not benefit from transfers. Given a request r = (i + , i − ), the time window [E i + , L i − ] is generated as follows: L i − = F + i + ,i − , where F is a number drawn uniform randomly from [60,480 − i + ,i − ], and E i + = F −60 (i.e., there is one hour of flexibility to perform the request). The planning horizon is nine hours, and crowd-sourced drivers sign up for three-hour blocks. We consider a geography similar to the one depicted in Figure 4B, but without locations m 1 − m 4 , and where crowd-sourced drivers start and end their blocks at location t 1 . Firstly, we consider a setting in which the planning horizon [0,540] is divided into three nonoverlapping blocks [0,180], [180,360], and [360,540]. To assess the possible benefits provided by considering transfers, we compare the number of requests not served in a solution with and without the use of transfers (these requests would have to be served by dedicated, professional drivers). A visualization of the results can be found in Figure 8, which is based on 10 instances with 50 and 100 requests for class L and M (a total of 40 instances). We see, as expected, that the number of requests that cannot be served decreases when drivers are able to transfer requests. More requests with long direct travel times between pickup and delivery locations can be served using a transfer and drivers in different blocks. On average, 22% more requests can be satisfied by crowd-sourced drivers when transfers are utilized.
Next  [360,540]. The additional flexibility provided by overlapping blocks results in all requests being served in the instances, both with and without transfers. Therefore, to assess the benefits of transfers, we focus on the number of drivers required in each of the blocks. Figure 9 shows results for two specific instances, one in class M and the other in class L, both with 100 requests. For each instance, the figure shows the number of open requests in the system at time t (x-axis), where a request r = (i + , i − ) with time windows [E i + , L i − ] and E i + ≤ t ≤ L i − is considered open, and the number of drivers used in a solution with and without the use of transfers. (Additional results, in which we average over all instances in a class, can be found in the appendix.) The two instances, however, are representative of the results observed.
First, we see that fewer drivers are needed when sharing is allowed, especially when there are only long requests. Second, we see that when transfers are allowed, the number of drivers in the system in the first block is larger than when transfers are not allowed. This signals that when transfers are allowed, many requests are picked up in the first block and brought to transfer points to be consolidated and delivered in subsequent blocks (which requires more drivers in the first block). As a consequence, fewer drivers are required in subsequent blocks, as it takes less time to deliver consolidated requests. As a result, which may be advantageous, the number of drivers required across the blocks is more balanced.

FINAL REMARKS
Our research has focused on investigating the potential benefits of using transfers in urban freight delivery systems. Our results show that these benefits can be significant, especially in settings where pickup and delivery locations are relatively far apart and driver shifts are relatively short. Thus, transfers may be especially valuable for urban freight delivery systems that rely, in part or completely, on crowdsourced delivery capacity, because crowdshippers tend to work for relatively short periods of time. Our results also show that the ability to transfer requests can substantially reduce the number of drivers required to serve a given number of requests. This too may be especially valuable in urban freight delivery systems that rely on crowdsourced delivery capacity, because crowdshippers are often compensated based on the number of requests they serve, and when the number of requests served per driver increases, it will become easier to attract crowdshippers to the system.
We are currently modifying our ALNS algorithm for use in dynamic environments, where requests appear throughout the operating period and (some of the) drivers may also enter and leave the system during the operating period, as this better reflects real-life settings.