Collaborative transportation for attended home deliveries

Attended home deliveries (AHDs) are characterized by dynamic customer acceptance and narrow customer‐specific delivery time windows. Both impede efficient routing and thus make AHDs very costly. In this article, we explore how established horizontal collaborative transportation planning methods can be adapted to render AHDs more efficient. The general idea is to enable request reallocation between multiple collaborating carriers after the order capture phase. We use an established centralized reallocation framework that allows participating carriers to submit delivery requests for reallocation. We extend this framework for AHD specifics such as the dynamic arrival of customer requests and information about delivery time windows. Using realistic instances based on the city of Vienna, we quantify the collaboration savings by solving the underlying routing and reallocation problems. We show that narrow time windows can lower the savings obtainable by the reallocation by up to 15%. Therefore, we suggest enhancing the decision processes of request selection and request bundling using information about delivery time windows. Our findings demonstrate that adapting methods of request selection and bundle generation to environments with narrow time windows can increase collaboration savings by up to 25% and 35%, respectively in comparison to methods that work well only when no time windows are imposed.


INTRODUCTION
The last mile of freight transportation is regarded as the most polluting, inefficient, and cost-intensive part of a supply chain [24] and is thereby a promising target of optimization efforts for practitioners and logistics research.Growing e-commerce and the increasing number of people living in urban areas exacerbate the negative environmental impacts of urban logistics [11,15,31].At the same time, citizens and authorities strive to make cities more livable by decreasing CO 2 emissions and reducing traffic congestion [40].
For logistics services such as the delivery of white ware, groceries, or precious goods, customers are required to be present at the time of delivery to complete the order fulfillment process.However, customers are not willing to wait all day for their attended home deliveries (AHDs).Thus, to reduce costly delivery failures on the one hand and to increase customer convenience, on the other hand, AHD service providers offer to deliver within a narrow, predefined delivery time window.Such time windows entail strong temporal constraints on the underlying routing problem which enhance the negative externalities of the delivery process [6,13].
Many approaches have focused on internal optimization to attenuate inefficiencies, for example, by finding better routing algorithms [8] or by deploying advanced revenue management techniques [2].In our study, we explore the external cost savings potential of centralized request reallocation between horizontally collaborating logistics service providers ("carriers") for the application of AHD.Studies have repeatedly proven the effectiveness of horizontal transport collaborations of otherwise competing carriers [4,9,26].In such collaborations, the carriers form a collaboration network that allows them to re-assign accepted customer requests through an auction-like process that preserves much of their autonomy and data privacy [7].Despite theoretical and practical evidence of the effectiveness of such collaborations, carriers might still be reluctant to participate due to, for instance, trust issues [3].In that case, municipalities could legally enforce collaboration by limiting freight vehicles' access to certain areas of a city, similar to congestion zones [42].
In the following, we will focus on the impact of time windows on horizontal collaborations and show that the constraints they impose on the routing problem should not be neglected in the crucial steps of auction-like request exchanges.Using realistic instances, the effectiveness of the collaborative framework for AHD service operations is demonstrated by extending an established auction framework by the dynamic order capture phase.We investigate tailored approaches for the request selection problem faced by carriers and the bundle generation conducted by a central planner.For both problems, we take temporal information into account.Additionally, we quantify the overall effect of time window lengths on the collaboration savings that can be achieved.
Our contribution is twofold: First, we show that time windows and their lengths have a significant impact on the economic potential of reallocation-based collaboration networks.We quantify this effect and explain the interactions with other characteristics of the collaboration.Second, we design specific measures to (i) help collaborating carriers identify requests to submit for reallocation and (ii) let the central planner generate attractive request bundles to be made available for reallocation.
In Section 2, we give an overview of the relevant literature for AHDs and collaborative transportation.Section 3 describes the problem of order capture and auction-like request reallocation, followed by our solution approaches in Section 4. We describe the computational experiments and their results in Sections 5 and 6, respectively.Finally, Section 7 concludes our work and gives further research directions.

LITERATURE REVIEW
We first give an overview on the established literature on AHDs to provide a solid foundation for the order capture phase in our collaboration framework.We then review the literature on collaborative transportation, starting from a broad classification and ending with a distinction of our work from existing publications.

Attended home deliveries
AHD services require the presence of the customer during delivery.Hence, it is common that customers and service providers mutually agree on delivery time windows, which is usually done via an online interface at the time of booking in an order capture process.Waßmuth et al. [41] provide a recent review of literature related to the carriers' operational decision problem of offering time windows to requesting customers.
Campbell and Savelsbergh [6] describe the practice of static customer acceptance based on accepting a fixed number of requests per available time window.van der Hagen et al. [38] call this the order threshold per time slot (OTTS) strategy as it sets a threshold on the number of requests to accept for each time window.Waßmuth et al. [41] classify this as an approximate technique, as it can overestimate the acceptance capacity and thus lead to overutilization of resources.This will cause delivery delays, overtime expenses, etc.
During booking, customers expect to almost instantaneously be presented with the offer set of time windows upon request [25].This is possible for OTTS as it only requires comparing the number of already accepted orders for a time window with the threshold to decide whether to offer a certain time window.However, to obtain realistic acceptance rates and fewer violations of delivery time promises, more precise methods are required that do not overestimate resource availability.Campbell and Savelsbergh [6], therefore, propose to compute the time window offer set dynamically: a certain time window is offered to a requesting customer only if its respective delivery location can feasibly be inserted into the existing route plan during that time window.As checking whether a feasible solution of the underlying vehicle routing problem with time windows (VRPTW) exists is NP-hard [34], the authors iteratively build preliminary routes using an insertion heuristic (IH) and use those to check the feasibility of serving a customer in a given time window much faster.They show that this approach increases profitability significantly and eliminates the risk of not meeting time window agreements at the expense of a short computation time.
More advanced routing heuristics can be used for feasibility checks.However, there is a trade-off between solution quality and run time.Hungerländer et al. [23] develop an adaptive neighborhood search to find a maximum number of time windows that are feasible.Compared to the IH, their approach clearly finds better objective values at the expense of an acceptable amount of additional run time.van der Hagen et al. [38] show that machine learning (ML) methods can approximate the feasibility of the VRPTW quickly and more reliably than the OTTS approach.Particularly for large instances, their ML model outperforms IHs in terms of acceptance rate and run time.
The trade-off between improved customer service through shorter and reduced routing efficiency for narrow time windows has been confirmed repeatedly.According to Campbell and Savelsbergh [6], decreasing the length of offered time windows from 3 hours to 30 minutes decreases profit by 18% for densely populated areas.Furthermore, Ehmke and Campbell [13] show that reducing the size from 2-hour to 30-minute time windows also leads to a reduction of 17% in the number of accepted requests, making the operation less cost-efficient.As routing is subject to dynamic and unforeseeable traffic conditions, they also include buffer times for each time window to decrease the likelihood of missing agreed-upon service time targets.
In our study, we dynamically build preliminary routes using a simple IH.For each new incoming request, we ensure for each time window that a feasible solution to the corresponding VRPTW exists before presenting that time window option to the requesting customer.

Collaborative transportation
Transport collaborations between logistics service providers can be dichotomized as being either vertical or horizontal.In vertical collaborations, collaboration partners operate at consecutive levels of the supply chain.The benefit of their collaboration is in the efficient exchange of information and goods.Horizontal collaboration networks comprise entities operating at the same level of the supply chain, meaning they offer identical services, and outside of the collaboration, they often act as competitors [7,10].The benefits of horizontal collaborations include cost savings due to better resource utilization and improved quality of service for customers.
Similarly to Ferrell et al. [16], we identify two important streams: (i) research that identifies general opportunities and difficulties of implementing horizontal collaborations or research that deals with the design of collaborative frameworks, and (ii) research that quantifies the effects of a given collaboration.
In the first category, Cruijssen, Dullaert, and Fleuren [10] provide an early discussion of general opportunities (cost savings, increased customer service, and better market position) and impediments (partner selection, fair gain distribution, malevolent negotiations, and insufficient information and communication technology) for horizontal collaborations.Pan et al. [30] conduct a broad survey of horizontal collaborative transport including publications from 2007 to 2017.They categorize publications based on the collaborative scheme and on the implementation issue they deal with.The scheme is defined mainly by the collaborating entities (shippers, carriers, receivers) and the way their collaboration is carried out (e.g., as a carrier alliance or via a transport marketplace).The implementation issues they identify include but are not limited to transport planning optimization, mechanism design, and game theoretic issues of gain sharing.Most of these are not tied to a specific scheme.
If collaboration partners have agreed to full information disclosure and a central authority takes on all planning and decision-making, the collaboration is referred to as a centralized one.If collaborating firms still act autonomously and use some mechanism to interact, their collaboration is decentralized.The latter is often the case for marketplaces.The interaction can be based on direct partner-to-partner cooperation.In that case, the transfer of information and resources happens between two carriers directly.Alternatively, auction-based mechanisms interpose an auctioneer that receives bids on the offered items and solves the winner determination problem to identify an appropriate allocation of items to bidders [19,30].
Based on the planning level at which the collaboration takes place, it can be of a strategic, tactical, or operational nature.In our collaboration framework, AHD service providers submit and receive delivery requests that must be executed the next day.Thus, their collaboration can be described as a "joint execution" [39] on an operational level.
In this analysis, we focus on a marketplace design in which all carriers are sellers and buyers at the same time.They offer customer requests to all participating carriers of the network to engage in a multilateral collaboration.
Based on the simplifying assumption of truthful bidding, our study is concerned with an auction-like road-transport collaboration: collaboration partners reallocate customer requests via a central authority to globally optimize vehicle route plans.Since only partial information disclosure is required, it is not fully centralized.
We aim to quantify the cost savings that can be obtained by AHD providers operating in an urban area that apply such a mechanism.It, therefore, falls in the second stream defined by Ferrell et al. [16].In the following, we provide an overview of earlier related publications in that area.
The established collaboration framework which we deploy in our study has first been suggested by Berger and Bierwirth [4].It is designed such that carriers reveal as little information as possible.It comprises five steps: In their framework, Berger and Bierwirth [4] consider a set of horizontally collaborating carriers, each holding some pickup-and-delivery transportation requests.In the request selection phase, each carrier submits a subset of those requests to a common auction pool for sale.When bidding on the released requests, carriers use the marginal profit as the bid value by computing costs for the route plan with and without the additional requests.Besides reassigning requests from the auction pool one by one, the authors also suggest bundled reassignment to consider sub-and super-additive utility functions through a combinatorial auction.Assuming that m carriers have each released k requests, 2 m⋅k − 1 bundles are created for the carriers to bid on.It must be ensured that each request is serviced, that is, all requests must be reallocated among carriers, potentially to the original owner of the request.To obtain a good allocation that ideally has a lower transportation cost than the initial one, the Combinatorial Auction Problem (CAP) [12] is solved.Finally, the resulting profit increase due to the reduced routing costs is distributed fairly among collaborating carriers.
For the collaboration framework of Berger and Bierwirth [4], the strategies that carriers apply to select a subset of requests to be offered in the auction can use different information.Gansterer and Hartl [17] show that including location features such as the proximity to foreign depots enhances collaboration gains significantly compared to the purely profit-based approach applied by Berger and Bierwirth [4].
The exponentially large number of potential bundles that carriers must report values for (by solving NP-hard routing problems) makes it intractable to solve even medium-sized problem instances exactly.An effective way to reduce the computational complexity of the reallocation process is to limit the number of necessary value reports.If carriers can create attractive bundles themselves, leftover requests that are not covered by any bundle or overlapping bundles cause problems in the CAP [1].However, if the central planner generates a limited set of bundles, it can be guaranteed that feasible solutions to the CAP exist.Gansterer and Hartl [18] model the central planner's challenge of selecting a subset of bundles as a stochastic decision problem maximizing the collaboration gain of the reallocation process in which the reported values are the stochastic variable.They use isolation, density, and tour length to approximate the attractiveness of a bundle under incomplete information.Generating candidate solutions to the CAP using the approximation as the objective function to a Genetic Algorithm, they show that by just considering 12% of all 2 m⋅k − 1 possible bundles, the loss in collaboration gain is only around 5%.
Gansterer and Hartl [18] also explain that the mechanism by Berger and Bierwirth [4] is not incentive compatible, that is, carriers have the incentive to act strategically, for example, by reporting untruthful bundle valuations in the bidding phase to gain an advantage over the other carriers.In a preliminary study, they show, however, that manipulating the auction with alternative strategies is not trivial.To achieve incentive compatibility, other properties such as budget balance or individual rationality have to be compromised [21].
Scientific investigations of horizontal auction-based collaboration in dynamic environments are sparse.A large-scale collaboration is simulated in Los et al. [27].They model a platform that shippers use to assign orders to carriers but that also acts as a central planner for reassigning orders between carriers to minimize global delivery costs.For dynamically arriving requests, small bundles are offered in iteratively triggered combinatorial auctions.Request bundles are reassigned through these auctions until time window constraints do not allow further postponement.The authors run experiments with up to 1000 cooperating carriers and report cost savings of up to 79%.
Rüther and Rieck [33] use a bid-proxy function to generate a stochastic distribution of bids for bundles.Repeatedly solving the CAP for scenarios based on random draws of bids from that distribution allows them to identify bundles that are part of the CAP solution more frequently.Offering only these promising bundles in the auction reduces the computational burden of determining bid prices but still guarantees to find near-optimal assignments.The authors acknowledge that their bid-proxy cannot be evaluated for all exponentially many possible bundles and suggest two filtering approaches to preselect a subset of bundles that enter the scenario-based process.
In contrast to our work, all of the above quantitative studies consider a pickup and delivery problem (PDP) with time windows.Although some consider instances with long and short time windows, the impact of their length is not reported.To the best of our knowledge, research on auction-like horizontal carrier collaborations for road transportation has exclusively focused on requests in a PDP setting.Motivated by the ever-increasing demand for AHD services, we instead consider delivery requests and particularly quantify the influence of time windows in more detail than before.To this end, we extend the framework of Berger and Bierwirth [4] by an upstream dynamic order capture phase.

PROBLEM DESCRIPTION
We first present a high-level problem narrative, followed by a formalization of the process of customer acceptance and centralized request reallocation.A process overview is given in Figure 1.

Problem narrative
Following the process overview given in Figure 1, in the order capture phase, customers request goods delivery from one of a set of carriers.For each request, the customer and carrier agree on a delivery time window.Once accepted, the time window of a request cannot be changed anymore.At some cut-off time (e.g., the evening before delivery execution), no more customers are accepted, and each carrier decides which requests to select for submission to the shared pool.We assume that carriers are not willing to submit all accepted delivery requests to the common pool because they fear a loss of sovereignty by publishing too much sensitive business data [3].In the bundle generation step, the central planner assembles the released requests into bundles.This is crucial, as the utility of a combined set of requests usually differs from the sum of the utilities of individual requests.All carriers then report their values for these bundles in the bidding/value reporting phase.Since the focus is on cost minimization, we mimic a reverse combinatorial auction to determine the reallocation.Thus, a reported value represents the marginal costs of serving the bundles' requests and when all reports are in, the central planner solves the CAP by finding the allocation of bundles to carriers that minimizes the sum of corresponding value reports [12].Afterward, the cost savings generated via this new allocation must be shared in a fair manner among the collaboration partners.On the next day, each carrier executes its final route plan, including the requests allocated to itself, and excluding those that got allocated to others.We do not consider reallocation costs for requests that have been accepted by one carrier but are now served by another.It is assumed that the respective parcels are delivered to the executing carriers' depots.

Problem formalization
Let C = {0, ..., m} be the set of collaborating logistics service providers, called carriers in the following, and R = {0, ..., n, ..., 2 ⋅ n, ..., m ⋅ n} be the set of transportation requests.We denote the depot of carrier c as  c .Each carrier has a set of u vehicles.The cost to travel between two locations i and j is equivalent to the required driving time and denoted as t i,j .Carriers minimize the total driving time of their vehicle routes.

3.2.1
Order capture Each carrier c ∈ C dynamically receives n transportation requests R c ⊂ R with unit load over a given order capture horizon that ends before the delivery vehicles start service.While receiving delivery requests, each carrier maintains a set of preliminary route plans, one for each vehicle.Carrier c must serve an enquiring customer r ∈ R c immediately.To ensure request fulfillment, the customer and the carrier must agree on an earliest and a latest delivery time [e r , l r ], defining the customer's service time window.For that purpose, the carrier will assemble a time window offer set O r that includes only time windows during which delivery to the new customer is feasible based on the already accepted requests and the preliminary route plans.The feasibility of an insertion for the VRPTW can be checked in constant time [5].Customer r may then freely pick a time window from O r according to its personal preferences, and the carrier c will update the route plan to accommodate the new service location.If none of the offered time windows in O r fit the customer's preferences, we assume that they walk away, not placing a request.Once committed, the time window assignment of accepted customers cannot be altered.We denote as R acc c ⊂ R c the set of carrier c's accepted requests for which a time window has been agreed upon, and as R acc = ⋃ c∈C R acc c the set of all accepted requests.

3.2.2
Request selection After some cut-off time, no more requests are accepted by the carriers, and the auction-like reallocation process is triggered.To engage in the collaboration, each carrier c ∈ C must select and release a subset of size k of its accepted requests R acc c to the common auction request pool to be reallocated.Releasing a request means announcing the willingness to outsource the delivery service for that customer to some other carrier of the collaboration.The releasing carrier will publish the corresponding delivery location, the agreed-upon delivery time window, and other details regarding the object to be delivered.The following information, in particular, is not published: details about non released requests, the current route plan, the carrier's fleet size and vehicle capacity, and the reason for selecting a particular request over others for outsourcing.The set of released requests of c is denoted as R rel c ⊆ R acc c , and the set of all requests in the shared pool is denoted as The selection of R rel c may be totally random but rational carriers are interested in releasing requests that maximize the cost savings for their route plans.To maximize cost savings from the auction, a carrier should therefore identify the requests for which it can expect (I) a high likelihood of reallocation, (II) high savings should it actually be reallocated, and (III) many resources freed should it actually be reallocated.
In Section 4.2, we discuss various approaches for request selection.
Together with the information about the selected requests, each carrier also transfers a payment to the central planner that is equivalent to the marginal cost of serving those requests; that is, this reflects the maximum cost that the carrier would be willing to pay for outsourcing the requests.

3.2.3
Bundle generation Due to complementary or substitution effects of customer requests, carriers value combinations of requests, called bundles.Let b ⊆ R rel denote a bundle (i.e., a set of one or more released requests).To reduce the computational complexity of the bidding process, not all 2 m⋅k − 1 bundles are considered.In combinatorial auctions, it is common to let bidders choose the bundles to place bids on.However, in the case without free disposal, this will often lead to infeasibility of the CAP [20].Therefore, we follow the bundle generation approach of Gansterer and Hartl [18] and let the central planner generate bundles: the goal is to find a limited set of attractive bundles by generating and evaluating candidate solutions to the CAP.We denote this set of bundles as B, with |B| ≤ 2 m⋅k − 1.
A candidate solution to the CAP partitions the shared request pool R rel into at most m bundles.Hence, for a partition P it holds that ⋃ b∈P b = R rel .For a given partition P, all its bundles b ∈ P are considered for reallocation if P is attractive according to some quality measure that is a proxy for the objective function of the CAP.In Section 4.3, we discuss various proxy functions.

3.2.4
Bidding In the bidding step, carriers report values for all the offered bundles.We denote the value of bundle b for carrier c as v b c and the set of all submitted values as V. v b c is computed as the difference in routing costs between a route plan for all currently owned requests including the requests in b and that route plan excluding these requests.
Note that the deployed auction-like framework is not incentive compatible [18].Thus, to get an advantage over the other collaborators, a carrier has an incentive to report false values to change the outcome of the reallocation in its favor.Gansterer et al. [21] show that incentive compatibility can only be achieved by compromising other important properties such as budged balance or individual rationality.Budget balance is satisfied if the mechanism is self-funded and does not require any external subsidies, that is, in the end, there will be no loss for the coordinating authority.Individual rationality is given when no carrier is worse off after taking part in the collaboration.
We assume truthful carriers, that is, all carriers report their true cost for a bundle of requests.Thus, the mechanism might rather be seen as a centralized optimization problem under partial information than an auction because we omit strategic behavior.

3.2.5
CAP If all bids are in, the central planner solves the CAP by finding the allocation of bundles to carriers that minimizes the sum of corresponding bids [12].Let y b c be the decision variable, taking a value of 1 if bundle b is allocated to carrier c.Then: The CAP minimizes the sum of reported bid values of the bundles that are reallocated (1a).Constraints (1b) ensure that each request is allocated to exactly one carrier and constraints (1c) limit the number of assigned bundles for each carrier to at most one.

Reallocation
The solution to the CAP defines which bundle from B is allocated to which carrier in C. R win c denotes the customer set that is assigned to carrier c according to the CAP solution.Note that if R win c = R rel c ∀c ∈ C, then the most cost-efficient bundle-to-carrier assignment is the original assignment.

Savings sharing
If, by solving the CAP, the central planner has found an allocation that is cheaper than the original request-to-carrier-allocation, then a positive amount remains with the auctioneer after paying the winners their reported bundle values.
Fairly distributing the remaining surplus is a particularly interesting problem of game theory [22].Gansterer et al. [20] show that the well-known Shapley Value cannot guarantee individual rationality if the intractably complex routing and combinatorial auction problems are not solved to optimality.Another problem preventing its use in this application is the Shapley Value's high computational cost.The authors propose a new sharing approach that satisfies the property of individual rationality: it first compensates all carriers for potential individual losses and then further distributes any remaining profit in a way that has negligible computational costs and respects carriers' individual contributions to the collaboration.In our computational study, we omit the sharing step and assume that an appropriate savings sharing mechanism (like the one by Gansterer et al. [20]) is available, and confine ourselves to showing that the costs with the collaboration are lower than those in an isolated planning scenario as this proves the value creation of the collaboration.

SOLUTION FRAMEWORK
In this section, we detail our solution framework for the problem at hand.To this end, we follow the structure of the process as described above -namely by adding an upstream order capture phase for the dynamically arriving customer requests to the framework by Berger and Bierwirth [4].

Order capture
Upon customer arrival, the corresponding carrier offers a set of nonoverlapping time windows of length h during which service is feasible to an incoming customer.Whether it is feasible to service a customer within a given time window depends on the already accepted requests including their assigned time windows and the resulting route plan, and the location of the currently enquiring customer.The underlying VRPTW is NP-hard and is therefore solved heuristically: as soon as an incoming customer has selected a feasible time window, the corresponding delivery location is inserted into the route and at the position that causes the lowest cost increase.Note that this dynamic cheapest insertion procedure is a greedy heuristic and produces route plans that are not optimal, particularly since we do not consider changing the order of already accepted requests.The customer then chooses one of the feasible time windows according to a customer choice model as used in Köhler et al. [25], for example.

Request selection
After reaching the cut-off point, all carriers select a subset of size k = l ⋅ n from R acc c and submit them to the central request pool according to some evaluation process.Evaluating all possible subsets is computationally too expensive which is why we instead let carriers evaluate each of their requests on its own and release those k requests that have the best individual evaluation.
Because carriers act under incomplete information (e.g., they do not know the route plans of other collaboration partners), they can only determine good candidates by sound estimates.We consider various proxy functions z ∶ R acc ĉ → R to assess the expected contribution of an accepted request r of carrier ĉ to the total collaboration savings.The k requests having the lowest evaluation of the deployed proxy function will be released to the central request pool.
Below, we first describe proxy functions that are based on basic request characteristics.We also show how to combine multiple basic features to create more elaborate selection strategies thereafter.

Random (R)
The random strategy is used as a benchmark.The value assigned to any accepted request is a randomly drawn number between 0 and 1. (2)

Marginal cost proxy (MCP)
As proposed by Berger and Bierwirt [4], the marginal fulfillment cost of a request r is calculated as the difference between the routing cost for a VRPTW route plan including r and the VRPTW route plan excluding r.Due to the high computational effort of computing this exactly, we instead refer to an approximation of the marginal cost as follows.
The marginal routing cost of r is approximated by the negative travel duration delta obtained by removing the delivery location of request r from its route and reconnecting the preceding and succeeding locations.That is, if r is at position i in its route, then MCP is defined as: ( A high negative value indicates that the request currently causes the vehicle to drive a large detour.If it is offered in the auction, chances are high that another carrier can service the customer at a lower cost.In the case of narrow time windows, large detours are more likely to appear.Thus, this measure indirectly takes time windows into account.

Duration to own depot (DOD)
Similarly, requests that are located far away from the carrier's depot will also induce high costs, and serving them from another carrier's depot is probably cheaper.Thus, we define the negative value of the driving duration between the depot and the customer as another request feature.

Minimum duration to foreign depot (DFD)
A customer with a delivery location close to a foreign carrier's depot can be expected to have a high likelihood of being reallocated as it is probably cheaper to include it in that carrier's route plan.Pursuing goal (I), we define DFD as the minimum of the travel durations from the customer location of r to any of the foreign depots.It is assumed that depot locations are publicly available information.

Forward time slack (FTS)
In a time window-constrained setting, maximizing the routing flexibility is a meaningful way to achieve goal (II) of freeing resources.The amount of flexibility of r can be estimated by the forward time slack, which we denote by s r [35].Releasing own requests with little flexibility allows easier insertion of new requests.

Time window fill level (TWFL)
Assuming that customer choice behavior is similar for its collaboration partners' customers, a carrier can release requests that are within rarely chosen time windows.It can be expected that other auction participants have lots of free resources at these times, making it more likely that they can feasibly insert those requests.Formally, where I(r, r) is an indicator function, returning 1 if and only if the time windows assigned to requests r and r are the same and 0 otherwise.

Request time (RT)
During customer acceptance, carriers must act under uncertainty when they compile the time window offer set.Due to the dynamic nature of the order capture phase and the sequential routing heuristic, insertion decisions cannot be changed in hindsight.Therefore, customers that got accepted early on, have a higher chance of entailing inefficient detours.
The RT strategy selects those customers who pose their delivery request earliest.Let q r denote the request time of customer r:

Linear combinations
Any number of the above request features can be combined to create a new feature.For a linear combination, a carrier computes the values for an individual feature for all requests and min-max normalizes them into a common range before weighting and adding them together.For some weights w 1 , w 2 , … , w x and features z 1 , z 2 , … , z x this is denoted as: Gansterer and Hartl [17] propose to combine DFD, MCP, and DOD in this manner.We include this approach in our experiments and test many other combinations, too.

Bundle generation
The central planner generates a limited but attractive set of bundles (i.e., a set of subsets of requests from R rel ).As it cannot be guaranteed that a limited assortment of bundles contains good combinations that form a feasible solution to the CAP, we directly generate candidate solutions for the CAP.A candidate solution to the CAP partitions the aupool R rel into at most m bundles.Hence, for a partition P it holds that ⋃ b∈P b = R rel .For a given partition P, all its bundles b ∈ P are considered for allocation if P is attractive according to some quality measure that is a proxy for the objective function of the CAP.
To find partitions that include high-quality bundles, we adopt the Genetic Algorithm (GA) of Gansterer and Hartl [18] with some minor adjustments to make it applicable to AHD requests.We highlight the most important parts and our modifications of the GA and refer the interested reader to Gansterer and Hartl [18].

4.3.1
Decoding In the GA, an individual is a candidate solution P, and it is decoded by a string of numbers, one for each request in R rel .Figure 2 shows an example for the partition P = {{1, 4}, {6}, {3, 9}}.By ordering the request IDs in R rel , we can map them to the bundle index of P to obtain the individual where the number at a specific index position j in the individual indicates to which bundle the request at position j in R rel is assigned.

4.3.2
Bundle features The fitness function of the GA is a proxy for the objective function of the CAP.Whether a partition P is a good candidate is based on the bundles that it is made of.We can evaluate a bundle internally, that is, based on the requests that it contains, or externally, that is, based on characteristics of the other bundles that are part of the partition as well as additional available information such as the carrier depot locations.We denote the bundle feature function as f (b).First, we define various basic features that will then be used to define a fitness function for the GA.

Random (R)
For benchmark purposes, this approach assigns a random number to a bundle:

Spatial cohesion (SC)
Spatial cohesion is defined as the average pairwise travel duration between requests in the bundle:

Temporal cohesion (TC)
Similarly, temporal cohesion is defined as the average pairwise difference between customers' time windows: TSPTW duration (TSPTW) The travel duration of a bundle is determined by solving the traveling salesman problem with time windows (TSPTW) for the bundle's requests, that is, building a route that traverses all the bundle's requests using the dynamic insertion procedure and that also respects the time window constraints.Let (p, q, u) denote the total driving duration of a VRPTW tour plan for u vehicles starting and ending at node p and serving the set of requests q.Let  b be the request of bundle b with the earliest to open time window: If no feasible TSPTW route is found by the heuristic, ∞ is returned.

TSPTW with carrier depot (TSPTW+)
Computes m routes for the bundle using the carriers' actual depots.Another function Φ ′ is used to aggregate travel durations over all the possible depot tours: If no feasible tour can be constructed, ∞ is returned.

RP cohesion (RP-C)
Based on Ropke and Pisinger [32], Los et al. [27] define a dissimilarity measure for pickup and delivery requests with time windows to compute a bundle's cohesion.We modify their formula for AHD requests.Request dissimilarity of two requests r and r ′ is based on the travel duration between the respective customer locations as well as the minimum waiting time w r,r ′ at one of the vertices if a vehicle serves both locations in direct succession.
Following Los et al. [27], the weighting factor  is set to 2. The cohesion of a bundle is then defined as the average pairwise dissimilarity:

Sum of squared error (SSE)
For this bundle feature, we compute for each carrier c ∈ C the sum of squared driving durations of the bundle members to the carrier depot  c .Φ ′ aggregates the values.

Fitness function
The fitness of a partition P is used to steer the GA towards finding better candidate solutions to the CAP.Note that our GA aims to minimize fitness, as, in our setting, good solutions have a low fitness value.The fitness of a partition is determined by aggregating some feature f (b) of its bundles.Let Φ denote an aggregation function (e.g., average, sum, minimum, maximum).Then the fitness of a partition is

Crossover and mutation
For our implementation of the GA, we slightly adapted the framework of Gansterer and Hartl [18] to be applicable to VRPTW requests.The initial population contains one individual that we generate using the k-means clustering algorithm (based on Euclidean distance between customer coordinates).The remaining individuals are randomly generated partitions of the request pool.We do not allow duplicates.To fill the generation gap with new individuals, two parents are picked via roulette wheel selection.One of the below two crossover approaches is used to obtain an offspring from these parents.

Uniform crossover
From the two parent solutions A and B, the assignment of a request to a bundle is copied from a randomly selected parent.

Geographic crossover
This operator preserves geographically dense areas from the parents: two random points A and B are generated in the delivery area.They correspond to the two parents A and B. If the Euclidean distance from a request to point A is smaller than to point B, the assignment of the request to a bundle is copied from parent A and vice versa.
Each offspring has a certain chance of being mutated.If so, one of the following four mutation operators is chosen at random.

Move mutation
From an individual's decoding representation, a random-size subset of randomly selected elements is selected and their bundle assignment is changed randomly without increasing the number of available bundles.

Create mutation
A randomly selected request is assigned to a new bundle.If there are now more bundles than carriers for the offspring, two random bundles are merged.

Join mutation
If the offspring has more than one bundle, two random ones are joined into one.

Shift mutation
After calculating every bundle's geographic centroid, a request is shifted into the bundle whose centroid is closest to that request.

Extraction of the bundle pool
As carriers bid on bundles, the set of available bundles must be extracted from the final population of partitions.To that end, partitions are selected in nondecreasing order of their fitness evaluation (recall that lower fitness values are better).The bundles of a given partition are added to the bundle pool B if they have not been added yet, that is, no duplicates are allowed.The next best partition is selected and its bundles are added until |B| ≥ .Partitions are always added as a whole.This guarantees that no dangling bundles enter the bundle pool for which no solution to the CAP can exist.This entails that  ≤ |B| <  + m.

Bidding
For every bundle b in the limited bundle pool B, carrier c computes the value v b c .We use the dynamic cheapest IH described above to compute the cost of a route plan that comprises all currently held requests R acc c ⧵ R rel c .Similarly, the cost of a route plan for all currently held requests and the available bundle b can be computed ((R acc c ⧵ R rel c ) ∪ b).The value v b c is the difference between these two, stating the approximate marginal routing duration for b.Then a bid is defined as: At the time of bidding, all requests are known, and a static routing heuristic could theoretically be applied.Note, however, that it is crucial to adopt the insertion sequence from the order capture phase for the determination of bundle values as well as for the final route planning after reallocation.Always inserting delivery requests in the order in which they became known is required to guarantee that a carrier c can reconstruct a feasible solution for its own set of accepted requests R acc c .

CAP
The central planner collects all bundle values and solves the CAP to find the perfect reallocation of requests.We make sure that B always includes the partition {R rel 1 , R rel 2 , … , R rel m } and denote this as the original partitioning.Also, as the same insertion sequence as in the order capture phase is applied during bidding, the lower bound for the CAP is based on the original partitioning.

COMPUTATIONAL SETUP
We introduce our instances first and then provide details on the parameters for the computational experiments.

Instances
We create a set of realistic instances for the problem at hand by querying driving durations using the Open Source Routing Machine (OSRM) [28] and OpenStreetMap data [29] between random addresses of the city of Vienna [36].The instances can be described by a tuple (n, o), where n ∈ {50,100} is the number of incoming delivery requests per carrier and o ∈ {0, 25, 50, 75,100} describes the degree of service area overlap.This can also be thought of as the degree of competition within the delivery area.The city of Vienna is divided into 23 geographical districts [37], which we denote by a ∈ {1, ..., 23}.
Let a * be the geographic centroid of a district a.The service area overlap o is used to assign customers to carriers as follows: customer r ∈ R from district a has a uniform chance of being assigned to any carrier ĉ for which it holds that For each combination of n and o, 20 randomized instances are created.All instances have m = 3 carriers, each operating a fleet of u = 3 vehicles.The depot locations of these carriers are equidistant from one another and positioned on the circumference of a circle of radius 7 km around the city center.An example instance including the vehicle routes without any service area overlap (o = 0) is presented in Figure 3.The instances can be downloaded from https://doi.org/10.11587/VJ01D5.

Parameters
As we are interested in the impact of service time windows on the horizontal collaboration, we test the instances with different time window lengths of h ∈ {0.5, 1, 2, 4, 8}.Note that because the driver shift is 8 hours, setting h = 8 is equivalent to a scenario without time window constraints.All customers have a service duration of 4 minutes.
Based on Köhler et al. [25], we model customer choice behavior as follows: 90% of customers will select a delivery time window uniformly at random from the time windows that lie in the second half of the service horizon.The remaining 10% select a random time window from the first half.If for a given customer no time window in the preferred half of the day is part of the offer set, they will cancel the request process without placing an order.
Each carrier releases k = l ⋅ n requests to the central reallocation pool.We set l = 0.1.Thus, for n = 50 and n = 100, there will be 15 and 30 requests in the pool, respectively.
For the GA-based bundle generation procedure of Gansterer and Hartl [18], we set the population size to 500 individuals (partitions) per generation.The generation gap is 0.2 and the mutation rate is 0.8.We limit the number of generations to 30 as preliminary experiments have shown that the average fitness of the current generation does not significantly improve beyond that.The number of bundles to be offered to the collaborating carriers is set to  = 500.
The framework was implemented in Python 3.8, and experiments were conducted on a Xeon-G 6226R machine with 2.9 GHz and 384 GB RAM running CentOS Linux 7. We solve the CAP using Gurobi 9.0.2.

RESULTS
We first investigate the impact of varying time window lengths on collaborative routing for AHDs in a basic configuration.Then, we provide detailed insights on request selection and bundle generation mechanisms when time window-based information is taken into account.
For the values reported here, we have computed the solutions for the collaborative transportation planning (CTP) problem (i.e., including the auction-like request reallocation), and for the isolated transportation planning (ITP) problem (i.e., without collaboration).The reported values are the savings of CTP over ITP.

Time window length
To measure the impact of varying time window lengths, we will use basic approaches for request selection and bundle generation that do not take time window information into account explicitly.In particular, we use the marginal routing cost approximation MCP (see Equation ( 3)) for request selection.For bundle generation, the quality of a partition in the GA is measured by the mean spatial cohesion of its bundles SC as defined in Equation (11).We use bar charts for ease of interpretation.Results in table form are in Online Appendix A.
Figure 4 shows the average cost savings in hours of CTP in comparison to ITP across 20 randomized instances.The nested x-axis indicates the number of requests per carrier n and the degree of service area overlap o.The different legend entries correspond to the time window length h.
We focus on n = 50 first.For the whole collaboration network, the reallocation pays off for all settings of service overlap and time window length.Almost all savings increase with a higher level of overlap of service areas except for the tight 30-minute time windows.For instance, without time window constraints (h = 8), 0.11 hours of travel time can be saved if service areas do not overlap (o = 0), whereas around 3.23 hours can be saved if carriers share the same service areas (o = 100).Relative to ITP, this means savings of 1% and 17%, respectively.Furthermore, the absolute savings vary across different time window lengths for a fixed parameter of service area overlap: generally, they are at a maximum for 1-hour time windows (with an overall absolute maximum of 4.36 hours, that is, 12% for o = 100).The case of 30-minute time windows is particularly interesting since the savings are at around 1 hour for o = 0, reach a peak at only 1.96 hours for o = 50, and then decrease again to 0.59 hours for o = 100, dropping below the initial level.Interestingly, having time window lengths of no more than 2 hours (h ≤ 2) leads to greater absolute savings than without them (h = 8) in all but two settings with very tight time windows (o = 75, h = 0.5; o = 100, h = 0.5).We see the largest relative savings increase between time window lengths for o = 100: with 30-minute time windows, only 2% savings can be attained.With increasing length, it reaches its peak of 17% for 8-hour time windows (i.e., no time windows).
For n = 100, the general impression is a bit different.For 30-minute time windows, only between 57% and 76% of customer requests can be accepted during the order capture phase because capacities will soon be exhausted, and preferred time window options cannot be offered anymore.Here, for all overlap settings, no savings can be attained for the 30-minute time windows and only negligible savings for the 1-hour time windows.However, with 4-hour time windows and larger overlaps, significant savings of up to 6.62 hour (14% less than ITP) are possible.
To analyze the collaboration in more detail, we now investigate to which extent the central planner reallocates requests.Figure 5 shows the average degree of reallocation, that is, the fraction of requests in R rel that got allocated to a different carrier than the one who released it to the request pool.The x-axis follows the same style as in Figure 4, indicating varying number of customers (n = 50,100) and service area overlaps (o = 0, 25, 50, 75,100).For n = 50, o = 0, and h = 8, only 11% of submitted requests change carrier ownership, while 28% of submitted requests change ownership for 2-hour time windows.For o = 100, the trend is the opposite: for narrow 30-minute time windows, only 8% get allocated to a new carrier while 70% do so without time windows, indicating that there is not sufficient flexibility to accommodate other carriers' requests in the narrow FIGURE 6 Savings per reallocated requests per time window length, grouped by the number of received requests and the degree of service area overlap.

FIGURE 7
The relative number of times cannot place a bid on a bundle per time window length, grouped by the number of received requests and the degree of service area overlap.time-window case.Again, the picture is somewhat different for n = 100, where a significant degree of allocation is limited to time windows of at least 2 hours.Overall, the fraction of ownership changes is about 80% lower than for n = 50.
Combining Figures 4 and 5, the absolute cost savings per one successfully reallocated request (in hours) are shown in Figure 6.Major cost savings can be seen for 1-hour time windows (n = 50) and 4-h time windows (n = 100), respectively.With n = 50 customers and no time windows, the average saving in travel duration per reallocated request increases from 0.05 to 0.31 hours with increasing degrees of overlap.On the contrary, for the tight 30-minute time windows, savings per request show a decreasing trend with increasing overlap and are at a minimum of 0.07 hours for complete service area overlap.For the larger instances (n = 100), major cost savings are again restricted to the long time windows (h ≥ 2), with 4-hour time windows achieving the highest savings per reallocation of 0.39 hours for completely segregated service areas.
In Figure 7, we plot the fraction of times carriers cannot report a value for a bundle because insertion of all requests in this bundle is infeasible with the sequential cheapest IH.We see a sharp incline in failures of the IH for decreasing time window length.The numbers also increase with increasing overlap, but less steeply.If no time windows are applied, all carriers can always report valid marginal insertion cost values for all bundles.For n = 50 and h = 2, in 2% of the cases, carriers report infeasibility (averaged across all o).That number drastically increases to 35% if h = 1 and to 82% for h = 0.5.We observe an even stronger jump for n = 100: for h = 4, the IH reports infeasibility in 4% of attempted value reports while this number increases to 81% for h = 2.This highlights the difficulty of finding a cost-saving reallocation if customers must be visited within narrow time windows.
In summary, the inflexibility caused by narrow time window constraints and the routing efficiency enabled by very wide or no time windows both lead to the same outcome in different ways.On the one hand, routes with narrow time windows are less adaptable, that is, there is very little leeway to shift arrival times without violating time windows.This makes it very difficult for a bidding carrier to insert foreign customers, as the carrier has not executed feasibility checks for these requests during the acceptance phase.Whether it is viable to serve another carrier's accepted request is uncertain, and the probability decreases drastically with shorter time windows.On the other hand, long time windows leave more leeway for changing arrival times.However, this also means that the route plans are already very efficient prior to the auction.In these cases, the feasibility of insertion is not a problem.Instead, fulfilling the delivery at a lower cost than the original holder of a request is the main hurdle for successful reallocation.If time windows are imposed, the relative savings can drop by up to 15% compared to no time windows.
We now investigate how the reallocation mechanism can be improved by considering more detailed time-window information.

Request selection
In the following, we examine how different request selection strategies influence the collaboration's cost savings for different settings of time window length h and service area overlap o.

6.2.1
Basic strategies A summary of the results for the basic strategies is given in Table 1.It displays the best-performing request evaluation function for each o-h combination if n = 50.
Although MCP is robust and yields good outcomes in all settings, it is worth considering RT or DOD for specific conditions.Not doing so, and naively using MCP may result in considerable missed savings potential (e.g., 0.61 hours for o = 0 and h = 1, see Table 2).
Detailed results are discussed based on Table 2, which shows the absolute amount of driving hours saved through the collaboration for different request selection strategies and service area overlaps for n = 50 (results for n = 100 are in Online Appendix B).The first two columns contain the parameter settings for o and h.Each of the remaining columns shows the values for one of the basic request selection proxy functions z(r).The figures reported are average values across 20 randomized instances each.The maximum value in each row is highlighted in bold.For bundle generation, we again use the GA as introduced with Equation ( 11) as the bundle feature.
First, we note that our random selection benchmark R is outperformed by the other request selection strategies on average, indicating that there is disposable information that can be used to optimize the request selection decision in general.Overall, the MCP strategy performs best, closely followed by DOD, with 1.97 hours (8.33%) and 1.93 hours (8.23%) saved on average, respectively.This is considerably more than the savings of 1.04 hours (5.8%) achieved by R.
Second, let us analyze how the request selection strategies perform for the different levels of o and h.Moving along the dimension of overlap, we observe that RT is best for no or little service area overlap (o ∈ {0, 25}) with an average saving of 0.95 and 1.43 hours, respectively.For o ∈ {50, 75}, DOD performs best, generating 1.88 and 2.91 hours of average savings, respectively.Finally, MCP is particularly strong for o = 100 where it outperforms RT and DOD by 0.19 and 0.32 hours, respectively.It performs twice as well as R. It is this outstanding performance for o = 100 that puts MCP in first place overall.Altogether, for low overlap, RT performs well despite fully ignoring spatial information.Distance from the own depot (DOD) and proximity to preceding and succeeding requests in the routing sequence (MCP) gain importance only for higher degrees of service area overlap.
We want to analyze which request selection strategy works best for which time window length.We have averaged the values per time window length across all overlaps and appended the result to the bottom of Table 2.For different lengths h, different request selection strategies z(r) are best.For 30-minutes and 1-hour time windows, MCP does remarkably well compared to the alternatives, saving 1.32 and 2.99 hours, respectively.For h = 2, RT saves 2.60 hours compared to the ITP scenario, beating MCP by 0.15 hours.After that, MCP achieves the maximum average savings of 1.83 hours for h = 4, and DOD saves 1.34 hours for h = 8.In summary, the best choice of a request selection strategy depends on the degree of service area overlap as well as the deployed time window length.By looking at the degree of reallocation and the savings per reallocated request, it becomes clear that RT can reallocate relatively few requests (37% on average) but that these few requests have exceptionally high per-request savings (0.32 hours on average).On average, 55% of the requests released through DOD change ownership, but any reallocated request only generates 0.18 hours of savings.Finally, MCP strikes a good balance: it achieves 47% degree of reallocation with 0.25 hours saved per request.We also want to highlight that DOD is generally superior to DFD, suggesting that it is more important to select requests that are remote and thus generate high savings in case of a change of ownership than selecting those requests that are close to a foreign depot and thus have a high expected chance of changing ownership.Consequently, goal (II) should have priority over goal (I).Interestingly, although TWFL and FTS were specifically designed to put some focus on the temporal aspect, they do not have any significant advantage for the time window-constrained settings.
Note that for h = 8, TWFL and FTS will report the same value for all requests and therefore carriers will select the earliest-to-request customers due to tie-breaking based on request indices.Thus, results will be almost equivalent to RT, slight differences result from the randomness of the GA.We also tested linear combinations of request selection strategies.The savings obtained through these combinations are given in Table 3.Although many combinations have been tested, we report only those that outperform MCP on average, that is, where the Grand total is at least 1.97.Firstly, we see that combining multiple features yields higher savings than the basic approaches could yield on their own.DFD+MCP+DOD is best overall with savings of 2.23 h which is 12% better than MCP alone.This strategy is equivalent to Combo by Gansterer and Hartl [17].While it works consistently well for many settings, it falls behind for o = 0 and o = 100.For o = 0, the better alternative to DFD+MCP+DOD (0.86 hours) is MCP+DFD+RT, with 1.02 hours of collaborative savings.For o = 100, MCP+RT (3.34 hours) has a small edge over DFD+MCP+DOD (3.24 hours) which still ranks second here.
For the shortest time window length of h = 0.5, DFD+MCP+DOD can generate savings of 1.80 hours across all o, outperforming MCP+RT by 91%.For longer time windows, the gap between the different approaches shrinks significantly.MCP+DFD+RT is best for h = 1, but with 3.41 hours it is just 12% better than the worst alternative.For h = 2, the combination of MCP+DOD+DFD+RT achieves 2.97 hours saved.For h = 4, the same approach saves 1.96 hours, on par with DFD+MCP+DOD.And finally, for h = 8, MCP+DOD can identify bundles that generate savings of 1.37 hours.
Summarizing, MCP is present in all of the well-performing linear combinations, underlining the importance of this feature.In our experiments, including DOD or DFD is only beneficial if the overlap of service areas is ≤ 75%.Of the temporal features, only RT can enhance the request selection when combined with other features.Combining three or four features is not always better than combining only two features.DFD+MCP+DOD is a clear winner only for small time windows.For any other variations of o and h, the differences between the approaches are not as clear-cut.Choosing a request selection function that performs well for no time windows and applying it in a setting with 30-minute time windows leads to missed savings potential: choosing MCP+DOD (1.35 hours) over DFD+MCP+DOD (1.80 hours) will lower the global savings by 25%.
Most general observations also hold for n = 100, but we highlight a few key differences.The exact results can be found in Online Appendix B. Across all overlap values that we tested, TWFL was a dominated approach for n = 50.For n = 100, it is comparable to RT. Due to the increased customer density on the map, DOD has become much better at identifying expensive customers.For o = 100, 3.31 hours can be saved with DOD, which is now also better than MCP with 2.93 hours.For no overlap (o = 0), we also observe that temporal features (FTS, RT, and TWFL) clearly stand out against the rest.For the disjoint areas and n = 100, the increased density of one carrier's original customers lets spatial features lose their informative value regarding which customers to release.Similarly, we observe that for the narrow 30-minute time windows (aggregated across all o), TWFL clearly outperforms all other approaches with 0.26 hours saved.As time windows are getting longer, DOD and RT dominate.Although MCP was delivering very good results for n = 50 it cannot cope with the increased customer count and loses its dominance across all time window length settings.Combinations of request features are not consistently better than the isolated features.For instance, if h = 0.5, none of the combinations can reach any savings greater than or equal to 0.02 hours.However, for the overall average across all o and h, MCP+DFD+RT and MCP+DOD+DFD+RT attain savings of 2.07 hours which is 0.2 hours above the best single feature DOD.

Bundle generation
To investigate the fitness functions based on bundle features discussed in Section 4.3.2,we use the marginal cost proxy MCP (3) for request selection and keep the time window length and the service area overlap variable.
In Table 4, for n = 50, we have averaged the savings obtained by the different bundle features from Section 4.3 for varying overlap at the top (averaging across all h) and for varying time window length at the bottom (averaging across all o).
Starting with the service area overlap at the top, we can see that mean absolute savings increase from 0.59 hours for o = 0 to 3.08 hours for o = 100.The standard deviation does not grow accordingly and in relation to the mean values, dispersion across f (b) is high for low overlap and relatively low for high overlap.Similarly, for varying time window lengths, the bottom table's mean column re-illustrates the pattern discovered above: low savings of 0.84 hours for narrow time windows that sharply increase to 2.8 hours for 1-hour time windows.Then, the mean absolute savings drop again with increasing h and reach 1.27 hours for no time windows.On the other hand, the standard deviation across the different bundle features f (b) constantly decreases with increasing time window length from 0.4 hours to 0.1 hours.
The relatively high dispersion indicates that the choice of the bundle evaluation feature f (b) has a much higher impact in low overlap and narrow time window settings than for settings where service areas are identical and no time windows are applied.Let us, therefore, look into the details of how the alternative bundle features from Section 4.3.2perform for varying o and h.
For n = 50, Table 5 shows the savings obtained by the different bundle features.We report values for Φ ∶ mean and Φ ′ ∶ min here as they generally yield the best results.The subtotals for each level of o are given in the table and the subtotal for each value of h is appended to the bottom of the table.Across all parameter combinations for o and h, the average time saving  obtained by the different fitness functions ranges from 1.45 hours to 2.02 hours.However, some fitness functions steer the GA towards poor solutions, yielding no savings at all (e.g., TC, o = 0, h = 8).The overall maximum of 4.48 hours is achieved by TSPTW+ for h = 1 and o = 100.With 2.02 saved hours on average, SSE is a good and robust overall bundle feature.For varying service area overlap, it is clear that SSE dominates for o ∈ {0, 25, 50}.However, for an overlap of 75%, at least one out of SC, TSPTW, or TSPTW+ beats SSE for all but the longest time windows.And also for 100% overlap, SSE is generally inferior to these three alternatives.We observe that for o = 100, the two routing-based approaches perform particularly well.
Next, let us also investigate the sensitivity of the bundle generation to changes in time window length h.For h ∈ {0.5, 1, 2}, SSE generally dominates the other methods, exceeding the random benchmark by 66%, 9%, and 8%, respectively.For h ≥ 4, TSPTW and TSPTW+ catch up or even beat SSE.We explain the poor performance of the routing-based heuristics for shorter time windows as follows: the IH often fails to create a feasible route that includes all the bundle members if the time windows are too narrow and will assign a feature value of ∞ such that the GA will regard the corresponding partition as a bad solution.As time windows become longer, they no longer restrict the IH as much, and for h = 4 and h = 8, the two approaches can find considerably better bundles.Nevertheless, their superiority compared to SSE remains small.If the bundle generation process was designed without delivery time windows in mind, using TSPTW would be a good decision.However, if h = 0.5, deploying TSPTW (0.87 hours) rather than SSE (1.34 hours) would decrease savings by 35%.
To conclude, if carriers have service areas that do not overlap by more than 50%, SSE should be used to identify promising partitions as it takes foreign depots into account.Beyond that level of overlap, the proximity to foreign depots is not a sufficiently distinguishing characteristic of a bundle.Therefore, it becomes more relevant to focus on internal metrics of the bundles.For o ≥ 75, it is then also worthwhile to differentiate between longer and shorter time windows: for the shortest time windows, SC becomes the best choice.For longer time windows, TSPTW(+) is a more accurate proxy as it can compute tours without the time windows creating infeasibility issues.If the fitness of a partition is defined by its bundles' values for R, TC, RP-C, or DTD, considerably lower savings can be achieved in most cases.
Results for n = 100 are reported in Online Appendix C. We observe identical behavior as for n = 50 regarding varying overlaps and varying time window lengths.Differences between the different features for f (b) are slightly more pronounced.TC performs particularly poorly under increased demand.

CONCLUSION
In urban AHDs, it is customary to define narrow delivery time windows to increase customer convenience and minimize the risk of delivery failure due to the absence of the receiver.Joining forces in a collaborative network is one way for freight carriers to reduce the costs of this inefficient and expensive last-mile delivery process.In this study, we modeled and implemented a horizontal collaboration network for multiple carriers that allows a reallocation of their AHD requests in a process that mimics a combinatorial auction.To that end, we extended the auction-based collaboration framework of Berger and Bierwirth [4] by an upstream order capture process that is necessary to assign a time slot to dynamically incoming customer requests.
The length of delivery time windows is a tactical decision and we were interested to see how this affects the subsequent reallocation mechanism.Simulating the order capture and reallocation processes for realistic instances of the city of Vienna, the results show that narrow time windows considerably limit the carriers' planning and insertion flexibility.This results in reduced reallocation potential.On the other hand, if no time windows are used, finding a reallocation that results in lower routing costs is difficult because the ex ante route plans are already very efficient.Time windows of medium length (e.g., 1 hour) strike a balance by reducing the efficiency of the initial route plan while still leaving sufficient flexibility for request reallocation.
For the request selection phase, we tested a set of request features to see whether time window information can be exploited to enhance the outcome of the combinatorial reallocation process.We found that the conventional approach of considering marginal costs works well even under time window constraints.However, in combination with disjoint carrier service areas, narrow time windows require tailored request features that put direct emphasis on special characteristics of the dynamic and time window-constrained environment.We observe that in extreme cases, refusing to adapt the request selection strategy to the AHD environment may decrease attainable savings by 25%.
Also, the central planner should be aware of the time window lengths employed by the carriers.Known route-based concepts for bundle generation perform poorly when time windows are narrow.Adapting the bundle generation process to the restrictive impact of narrow delivery time windows, the outcome of a horizontal auction-like collaboration can be enhanced by up to 35%.
Seeing that multiple hours of driving time can be saved through reallocation, a natural question arises: How can the freed resources be used to further optimize carrier operations?Anticipating the reallocation, carriers may decide to overbook their own capacities in the order capture phase because they expect to give away a sufficient number of requests in the centralized collaboration.
We have observed that for narrow time windows, the route plans lack flexibility, which limits the savings potential.Carriers may decide to trigger reallocations already during the order capture phase when the insertion of foreign requests is still feasible.Such dynamic mechanisms have been explored to some extent by Los et al. [27] but applying them to the AHD case is expected to deliver new and interesting findings.
Incentive compatible mechanisms that also satisfy other desirable properties such as budget balance and individual rationality do not exist yet for the reallocation framework presented in this work.This remains an open issue and we encourage further research into these game-theoretic aspects of the process.
The implemented three-step process of bundle generation, bidding, and CAP solving is leaving some potential for finding the best allocation untapped.An integrated approach that takes the CAP into account already at the stage of selecting bundles is expected to further improve the achievable collaboration gains.This will be the focus of our future work.
Finally, travel times in an urban setting can be subject to considerable uncertainty [14].Including stochastic travel times in the model would further increase the significance for realistic settings.Moreover, they might have a measurable impact on the cost savings that can be achieved, for example, because, in the bidding phase, carriers may factor in additional costs for the risk of time window violations.We hope that our work inspires researchers to work on collaborative transportation planning with stochastic travel times.

FIGURE 3
FIGURE 3 Instance example.The three nonoverlapping service areas are shaded in different colors.Abstract vehicle routes represent a noncollaborative solution.

FIGURE 4 5
FIGURE4 Absolute savings per time window length, grouped by the number of received requests and the degree of service area overlap.

TABLE 1
Best basic z(r) (in terms of absolute savings) per o-h combination for n = 50.

TABLE 2
Mean cost savings (in hours) of each z(r) per o-h combination (n = 50, f (b) = SC).Benchmark R is highlighted in grey.The best performing request selection strategy per row is highlighted in bold.

TABLE 3
Mean cost savings (in hours) of each z(r) per o-h combination (n = 50, f (b) = SC).The benchmark is highlighted in grey.The best performing request selection strategy per row is highlighted in bold.

TABLE 4
Mean and standard deviation of average savings across all f (b) (in hours).

TABLE 5
Mean cost savings (in hours) of each f (b) per o-h combination (n = 50, z(r) = MCP).The benchmark is highlighted in grey and the best value per row is highlighted in bold.