Adaptive Large Neighborhood Search Metaheuristic for the Capacitated Vehicle Routing Problem with Parcel Lockers

Abstract

Background: The growth of e-commerce necessitates efficient logistics management to address rising last-mile delivery challenges. To overcome some of the last-mile delivery costs, parcel lockers as a delivery option, can be an alternative solution. This study presents the Capacitated Vehicle Routing Problem with Delivery Options (CVRPDO), which includes locker delivery. Methods: this problem is solved with An Adaptive Large Neighborhood Search (ALNS). The solution suggests some specific destroy and repair operators and integrates them with various selection schemes. The proposed method results are compared with the exact solution of the MIP model of the problem for validation. Results: Objective function values improved by 25%, 30%, 7%, 5%, and 6% for 1000, 800, 600, 400, and 200 customers, respectively, when using a 120-s ALNS runtime compared to the MIP model with a 3-h runtime. Conclusions: the CVRPDO problem involves creating a set of routes for ve-hicles that visit each customer at their delivery location or deliver their parcels to one of the lockers. These routes should respect the capacity of each vehicle and locker while minimizing the total routing costs and the number of utilized vehicles. The problem is resolved by ALNS algorithm, which outperformed the MIP model.

1. Introduction

The logistics industry has experienced significant growth due to the rapid expansion of e-commerce, further accelerated by the COVID-19 pandemic in 2020. This growth is expected to continue as consumers maintain their online shopping habits in the foreseeable future [1]. The substantial increase in e-commerce presents a considerable challenge in the final stage of the supply chain, known as the “last mile”, which involves delivering goods directly to consumers. These last-mile challenges are compounded by the introduction of new customer-centric options by logistics companies. For instance, depending on an Alternate Delivery Program allows packages to be delivered to designated Shared Delivery Locations (SDLs) rather than the recipient’s primary residence or workplace [2]. SDLs, such as parcel lockers, are generally located in places that are open throughout the day, e.g., supermarkets and railway stations [3].Similarly, customers may request package delivery to the trunk of their cars at predetermined locations [4]. Consequently, logistics companies are motivated to offer flexible last-mile services while ensuring prompt deliveries.

The traditional approach of delivering products directly to consumers’ residences incurs significant operational expenses in fulfilling numerous requests [5]. However, introducing parcel lockers as an alternative delivery method can yield substantial cost savings of up to 66% in some cases compared to conventional logistic systems [6]. Furthermore, integrating parcel locker systems offers enhanced flexibility and efficiency in both product delivery and retrieval, thereby improving the overall service experience and granting a competitive edge within the logistics industry [7].

Various research studies have extensively examined delivery alternatives, including parcel lockers, from various perspectives. One crucial aspect is determining the optimal configuration of parcel lockers, which includes factors such as the number of lockers, their locations, and sizes to maximize overall profitability [7,8,9]. Other studies, like the present one, concentrate on optimizing the Capacitated Vehicle Routing Problem with Delivery Options (CVRPDO) by considering a specific number of parcels with predetermined destinations. The primary objective of this study is to minimize travel costs and optimize fleet utilization by effectively managing vehicle and locker capacities while planning routes.

Despite the recognized potential benefits of incorporating delivery options into the Capacitated Vehicle Routing Problem (CVRP) and the cost savings it can offer [10], the subject needs to receive more attention [11]. This lack of research has motivated the authors to address this gap and contribute to understanding this practical problem. In this paper, the authors extend the study of the capacitated vehicle routing problem by incorporating delivery options.

This paper presents various noteworthy contributions. First, it addresses a gap within the current literature since existing studies on the vehicle routing problem in the context of delivery options often either disregard vehicle capacity constraints entirely or overly simplify them, reducing them to the maximal count of customers that a vehicle can accommodate. In contrast, this paper introduces a more nuanced treatment of vehicle capacity constraints, encompassing the customer’s request size, quantified by the number of units (demand size) within each request. Moreover, this paper incorporates consideration of the SDL capacity, denoting the count of utilized lockers within a SDL, allowing for synchronization among SDL capacity and vehicle capacity. Additionally, this paper provides an efficient implementation of the Adaptive Large Neighborhood Search (ALNS), which was tailored to solve the problem in question. An innovative solution representation is introduced. Furthermore, several repair and destroy operators have been incorporated into the framework’s implementation. While most of the existing literature primarily focuses on problem instances with up to 400 customers, this paper extends the scope by considering instances with up to 1000 customers.

This paper is structured as follows: Section 2 comprehensively reviews the relevant literature. Section 3 presents a detailed description of the problem at hand. In Section 4, the mathematical model is formulated. The specifics of the ALNS approach are outlined in Section 5. In Section 6, the authors present the computational results obtained for various problem sets. Finally, Section 7 offers concluding remarks and suggests potential avenues for future research.

2. Relevant Literature

The CVRPDO is known to be an NP-hard problem, as it is an extension of the Vehicle Routing Problem (VRP) [2]. Due to its recent emergence, the CVRPDO has received limited attention in the literature. However, its significance has been underscored by the substantial growth of online shopping and e-commerce, particularly during and after the COVID-19 pandemic [12]. This study discusses the VRP variants that delve into the realm of flexible delivery options aimed at mitigating the inherent challenges associated with elevated delivery costs, bolstering customer satisfaction, and curbing the rate of delivery failures.

2.1. The Multiple Time Windows Vehicle Routing Problem

The vehicle routing problems with flexible delivery options were initially investigated by de Jong et al. (1996) [12], who introduced a new variant known as the Multiple Time Windows Vehicle Routing Problem (VRPMTW). Subsequent studies by Doerner et al. (2008) [13], Favaretto et al. (2007) [14], Belhaiza et al. (2014) [15], and Beheshti et al. (2015) [16] also tackled the VRPMTW. Nevertheless, none of these studies incorporated the provision of alternative delivery locations as an option for customers. Another relevant approach to flexible delivery is the Generalized Vehicle Routing Problem (GenVRP), proposed by Ghiani and Improta (2000) [17]. In this problem, customers are grouped into clusters, and it suffices for a delivery vehicle to visit one of the nodes within each cluster.

2.2. The Vehicle Routing Problem with Roaming Delivery Locations

In 2017, G. Ghiani and G. Improta introduced an extension to the VRPMTW [4], known as the Vehicle Routing Problem with Roaming Delivery Locations (VRPRDL). This advanced variant facilitates the delivery of goods to customers’ vehicle trunks at different times throughout the day. Ozbaygin et al. [18] developed a branch and price algorithm to solve the VRPRDL effectively. Subsequently, in 2019 [19], Ozbaygin et al. extended their research to the dynamic variant of the VRPRDL, where customers can modify their plans within a pre-planned schedule. Consequently, the initially planned schedule is no longer optimal or even feasible. To address this challenge, the authors proposed a branch-and-price algorithm to reoptimize the vehicle routes and delivery locations.

2.3. The Vehicle Routing Problem with Transshipment Facilities

The Vehicle Routing Problem with Transshipment Facilities (VRPTF), as described by Baldacci et al. (2017) [20], allows consumers to be supplied either directly from a central depot or by paying to use a transshipment facility. They outline numerous legitimate inequalities for the VRPTF in their work and offer a mathematical solution. Additionally, they obtain lower bounds by using a formulation of the VRPTF based on set partitioning (SP). Alcaraz et al. (2019) [21] examined the transportation of customer requests, which can be delivered directly to the customer or via a transshipment facility. In the latter case, a third-party subcontractor is responsible for the last-mile deliveries, charging a fee for their services. The researchers focused on a complex vehicle routing problem characterized by long-distance travel and additional factors such as driving hour restrictions, item incompatibility, heterogeneous vehicles, and time windows. To tackle this challenge, they proposed a construction heuristic approach incorporating these characteristics and adapting several established improvement heuristics from the existing literature.

2.4. The Capable Vehicle Routing Problem with Pickup and Alternative Delivery

Sitek and Wikarek (2019) [22] conducted a study on the Capable Vehicle Routing Problem with Pickup and Alternative Delivery (CVRPPAD). Their research considered factors such as time windows and fleets with different characteristics. They also considered the possibility of delivering customer requests to alternative destinations such as parcel lockers or postal outlets. To tackle this problem, the researchers proposed a precise method based on mathematical programming and a heuristic solution suitable for larger problem instances. In their heuristic approach, they employed a set of rules to assign customer requests to routes and resolved a travelling salesman problem for each route.

2.5. The Vehicle Routing Problem with Delivery Options

To the best of the authors’ knowledge, the earliest reference to the Vehicle Routing Problem with Delivery Options (VRPDO) can be traced back to 2005 [23], when Furmans et al. introduced it as a mixed integer programming model. Their proposed solution adopted a branch and price approach with a decomposition scheme. Optimal route selection was achieved through linear programming, while constraint programming was employed for modelling and calculating the optimal vehicle routes. In a subsequent extension, the pickup and delivery problem with shared delivery locations and diverse preferences was considered [24]. To solve this problem, an ALNS was employed, and the resulting solutions were compared to those generated by a commercial solver.

Dumez et al. (2021) [10] conducted research on the Vehicle Routing Problem with Delivery Options (VRPDO), which focuses on various delivery locations available to customers. In this problem, customers can express their preferences for multiple delivery options, with weights assigned to each option. Unlike the VRPTF, the shared delivery options do not incur additional costs, and the objective is to meet customer preference levels while respecting the capacity limits of shared delivery locations. The authors propose a solution to the VRPDO by using a Large Neighborhood Search (LNS) approach. They conducted computational experiments that solved instances with 50, 100, 200, and 400 customers within specified runtime limits of 30, 90, 300, and 2000 s, respectively. The authors assessed the efficacy of the heuristic approach by comparing it with alternative solution approaches documented in various variants of Vehicle Routing Problems. However, when presenting the results of the LNS approach applied to VRPDO, they solely reported the average and best outcomes obtained from five independent runs without comparing them with other methods or the MIP model.

Mancini and Gansterer (2021) [2] have presented two matheuristic approaches, namely the LNS matheuristic (MH) and Iterated Local Search (ILS), as efficient solution procedures for solving large instances of the Vehicle Routing Problem with Delivery Options (VRPDO) containing up to 75 customers. In their model, they incorporated an additional cost that compensates customers who opt to collect their parcels from shared delivery locations. The researchers formulated the problem mathematically and employed a Mixed Integer Programming (MIP) model, with a maximum runtime of 1 h, to obtain the optimal solution. They compared the MIP solution with the results generated by the two heuristics for instances of sizes of 25, 50, and 75 customers. The MH heuristic demonstrated average runtimes of 5.32, 63.75, and 283.47 s for the respective instance sizes, while the ILS heuristic exhibited average runtimes of 18.53, 276.7, and 772.38 s, respectively.

Table 1. Classification of reviewed papers.

Papers	Problem Variants	Solution Approach	Instance Size	Avg. Runtimes (Sec.)	Parcel Size
Doerner et al. [13]	VRPMTW	Branch and Cut and Price	50	3600	🗴
Favaretto et al. [14]	VRPMTW	Ant Colony	71	250	🗸
Belhaiza et al. [15]	VRPMTW	Hybrid Variable Neighborhood Tabu Search	200	90	🗸
G. Ghiani et al. [17]	VRPRDL	Variable Neighborhood Search	120	-----	🗸
Ozbaygin et al. [18]	VRPRDL	Branch and Price	120	720,000	🗴
Ozbaygin et al. [19]	VRPRDL	Branch and Price	60	68	🗸
Baldacci et al. [20]	VRPTF	Constructive heuristic Lagrangian heuristic	150	229	🗸
Alcaraz et al. [21]	VRPDO	Mixed Integer Programming	20	1800	🗴
Dumez et al. [10]	VRPDO	Large Neighborhood Search	400	2000	🗴
Mancini et al. [2]	VRPDO	Large Neighborhood Search Iterated Local Search	75	283 772	🗴
Saker et al. [3]	VRPDO	Mixed Integer Programing	75	3600	🗸
This paper	VRPDO	Adaptive Large Neighborhood Search	1000	120	🗸

summarizes various papers with different solution approaches, maximum numbers of customers, and average runtimes. Additionally, in the last column we mentioned if the parcel size of the customer demand is considered or not.

The literature extensively highlights the emerging and highly promising research area of incorporating delivery options into the traditional VRP. However, considering capacity constraints within the VRPDO has not yet been thoroughly explored in the existing academic literature. Consequently, this paper addresses this research gap by adapting the mathematical model (MIP) of Saker et al. [3], incorporating capacity constraints and relaxing time window constraints. Additionally, the ALNS heuristic is proposed and compared against the MIP approach.

3. Problem Description

In the context of the VRP, the deliveries are exclusively made to the predetermined locations of the customers. However, in the specific problem examined within this research, referred to as the CVRPDO, the requests assigned to customers may be delivered either directly to their designated locations or to a SDL proximate to them. Subsequently, the customers have the flexibility to retrieve their parcels from this SDL at their convenience. The CVRPDO problem entails a scenario where a specific number of customers (I) are considered, with each customer having a different demand size. The problem is formulated with the central depot ($O$) as the starting point for all vehicles’ routes. The SDLs (f) are represented as customer nodes. The objective is to deliver each customer’s demand either directly to their location or to one of the SDLs, from which the customer can subsequently collect their requests. However, customers are limited to being assigned only to a subset of SDLs that fall within a specified distance limit denoted as “ρ”, as shown in Figure 1.

Capacity Synchronization

The CVRDO entails the consideration of two distinct types of capacities. Firstly, the SDL capacity, denoted as Bf, is influenced by factors such as the availability of unutilized lockers at each SDL. It is assumed that these lockers possess a predetermined size. Consequently, when a customer’s request is allocated to a SDL, it is accommodated by only one of the available lockers, irrespective of the size of the request. The capacity of a SDL is contingent upon the quantity of customers that can be served within this SDL. Secondly, vehicle capacity constraints encompass the consideration of the size of customer requests, specifically the number of units (demand size) within each request.

When examining the capacity of the SDLs, the demands of individual customers are considered as a single unit. This approach assumes that the size of the lockers is not a determining factor. However, when considering the capacity of the routes, it becomes crucial to account for the request size associated with each customer. For example, suppose customer x has five parcels to be delivered to SDL f. In that case, the capacity value for the route will be incremented by five, and one additional locker in the SDL will be occupied as a result.

Figure 2 presents a graphical depiction of a proposed solution (S). The depicted scenario portrays a singular depot characterized by the node denoted as (0), encompassing a total of eight customers denoted by nodes (1–8), and two SDL nodes identified as (9, 10). Considering this example, let us assume that the capacity of each SDL is uniformly set at three (thus, the length of the SDL lists will not exceed three). Additionally, the vehicle capacity constraints are defined as 15 units per vehicle. Consequently, when attempting to add a customer to a SDL, it is essential to follow the subsequent sequence of capacity checks:

• Verification of the SDL list length: ensure that the number of customers associated with the SDL is less than or equal to the SDL capacity (in this example, three).
• Calculation of the SDL demand after incorporating the new customer: assess the total demand attributed to the SDL by considering the demands of all customers assigned to it, including the new addition.
• Recheck the vehicle capacity constraints if a customer is assigned to a SDL visited by that vehicle. This verification step is necessary as the SDL’s demands may differ from the initial check for this constraint.

If any of the aforementioned capacity checks fail to meet the designated criteria, the addition of the customer violates one or more of the capacity constraints.

4. Mathematical Model Formulation

The network can be described by the sets of nodes N = I ∪ F and N₀ = N ∪ 0. The private locations of requests i and j (i, j ∈ I) are denoted by the nodes i and j, respectively. The travel expenses between each pair of nodes i and j in N₀, C_ij is proportional to the journey Euclidean distance d_ij. Each route originates and terminates at the depot, signifying the presence of a single vehicle with its associated vehicle cost (γ). Customers who opt to retrieve their parcels personally are eligible for compensation payment (δ).

Table 2. Mathematical model notation.

Sets:
I	Set of all customers
F	Set of all shared delivery locations
N	Set of all customers and shared locations
N0	Set of the depot, customers, and shared locations
Parameters:
Cij	The travel cost from node i to node j
dij	The travel distance from node i to node j
$\gamma$	Fixed cost for utilized vehicle
$\delta$	Compensation to shared location customer
Bf	Shared location capacity
Q	Vehicle Capacity
Cdi	The customer demand
Decision Variables
$X_{ij}$:	binary variable indicating whether $j$ is visited directly after node $i$
$Y_{if}:$	binary variable indicating whether $i$ is delivered to SDL $f$
$Z_f:$	binary variable indicating whether SDL $f$ is visited
$u_i:$	non-negative variable tracking the total load of a vehicle when it arrives at node $i\in N$

summarizes the notation and decision variables of the mathematical model.

The CVRPDO was formulated as an MIP model with constraints (1)–(10), as shown in

Table 3. MIP model formulation.

Min ${\sum }_{i\in N_0}{\sum }_{j\in N_0}{c}_{ij}{X}_{ij}+\delta {\sum }_{i\in I}{\sum }_{f\in F}{c}_{if}{Y}_{if}+\gamma {\sum }_{n\in N}{X}_{0n}$		(1)
$\sum _{i\in N_0}{X}_{ij}+\sum _{f\in V(j)}{Y}_{jf}=1$	$\forall j\in I$	(2)
${\sum }_{i\in N_0}{X}_{ij}={\sum }_{i\in N_0}{X}_{ji}$	$\forall j\in N_0$	(3)
$Z_f\ge \frac{1}{\left|I\right|}{\sum }_{i\in I}{Y}_{if}$	$\forall f\in F$	(4)
${\sum }_{i\in N_0}{X}_{if}=Z_f$	$\forall f\in F$	(5)
${\sum }_{i\in I}{Y}_{if}\le B_f$	$\forall f\in F$	(6)
$Y_{if}=0$	$\forall i\in I \forall f\in F:f\notin V_i$	(7)
$C{d}_f={\sum }_{i\in \mathrm{I}}{Y}_{if}\ast C{d}_i$	$\forall f\in F$	(8)
$\mathrm{if} x_{ij}=1\Rightarrow u_i+C{d}_j=u_j$	$\forall i,j\in N:i\ne j$	(9)
$C{d}_i\le u_i\le Q$	$\forall i\in I$	(10)

. Constraints (1)–(7) were derived from Simona Mancini et al. [2], who formulated the VRPDO [25], while constraints (8)–(10) were added to account for the vehicle capacity. The model’s objective function is formulated as a minimization problem to optimize the total distribution cost. This cost is computed as the sum of three different terms: the transportation cost, compensation cost paid to shared location customers, and a fixed cost for vehicles. Constraint (2) guarantees that each request is either delivered to a shared location or directly to a customer’s location. In order to maintain the continuity of flow in the model, constraint (3) is enforced. Constraints (4) and (5) are responsible for allocating shared locations only if at least one customer intends to visit them.

To ensure compliance with the capacity restrictions of the shared locations, constraint (6) is imposed. If the distance between a customer and a shared location exceeds a predetermined limit, constraint (7) prevents the assignment of the customer to that shared location. Constraints (8)–(10) are implemented to prevent the total route capacity from surpassing the predefined limit.

5. Solution Using Adaptive Large Neighbourhood Search Approach

Ropke and Pisinger (2006) [26] extended Shaw’s (1998) [27] notion of Large Neighbourhood Search (LNS) by introducing Adaptive Large Neighborhood Search. The primary stage of the ALNS involves generating an initial solution. Subsequently, operators are employed to perturb and restore segments of routes. Destroy operators are responsible for removing a specified number of requests from the current solution, while repair operators reintroduce the previously deleted requests to construct a different feasible solution.

In the ALNS, each neighborhood is assigned a score. A neighborhood is defined for every possible combination of the destroy and repair methods, assuming that each repair operator can reconstruct a solution from an incomplete solution generated by any destroy operator. The score indicates how likely it is that a neighborhood will be chosen by using a selection scheme. These scores are dynamically adjusted throughout the search process based on the performance of the respective neighborhoods. Acceptance criteria govern whether to adopt a new solution developed by the neighborhood.

In summary, the ALNS methodology consists of the following sequential phases: (1) solution initialization, (2) ALNS implementation involving the application of a pair of destructive and reparative operators at each iteration, and (3) the execution of a selection process. The iterative execution of steps (2) and (3) persists until a predetermined stopping criterion, such as the expiration of a specified time interval or the attainment of a specified number of iterations, is satisfied. The algorithm framework is shown in Figure 3.

This research paper benefits from successfully implementing the alns package, originally developed by N. Wouda [28], using Python. This package was originally developed to provide solutions to simple vehicle routing and cutting stock problems. The authors have embraced this overarching framework and extended it to address the CVRPDO problem variant. The framework was extended by introducing a solution representation suitable for the problem in question. Furthermore, the objective function was adjusted, and custom repair and destroy operators have been incorporated into the framework’s implementation.

5.1. Solution Representation

The solution representation is a list of lists, as shown in Figure 2 These lists consist of two distinct groups: the first group of lists represents tours which contains home delivery customers and shared locations that have been assigned customers. The routes of these tours can be introduced by adding the depot at both the beginning and end of each tour. The second group of these lists illustrates details about the customers who will pick up their parcels from the SDLs that have appeared in the first section of the solution representation. For example, in Figure 2, there are two routes: R1 (0, 1, 2, 3, 9, 0) and R2 (0, 10, 7, 8, 0). In this scenario, customers (4, 5) are assigned to pick up their requests from SDL (9), whereas customer (6) is responsible for picking up their parcels from SDL (10).

To the best of the author’s knowledge, this compact representation approach has yet to be expounded upon in the literature. Indeed, this representation deals with the second group, SDL and pickup customers, as routes with special characteristics. Consequently, the VRPDO can be considered the same way as the classic VRP. This novel approach has enabled the solution of problem instances encompassing up to 1000 customers, a notable advancement beyond what is found in the literature, in which, problem instances featuring only up to 400 customers have been solved.

The demands associated with the SDL must be incorporated to ascertain compliance with vehicle capacity constraints. If a SDL remains unoccupied, its demand is deemed zero, negating the requirement for any vehicle to visit it. Conversely, if the SDL contains parcels to be picked up, the aggregate demand is computed as the sum of the demands corresponding to the customers assigned to retrieve their parcels from this SDL. This aggregation can be expressed mathematically as solution (S) in Figure 2 as follows:

d[9]	=	d[4] + d[5]	=	5
d[10]	=	d[6]	=	6
Capacity [R1]	=	d[1] + d[2] + d[3] + d[9]	=	13
Capacity [R2]	=	d[10] + d[7] + d[8]	=	15

In the routes’ representation part, any list […] represents a vehicle, and the number of these list is the number of utilized vehicles. As a result, the empty list ([]), which signifies vehicles without any customers, must be removed. Routes lacking customers are deemed invalid and subsequently removed from the solution. However, if a SDL exists but remains unvisited, it will be denoted as an empty list ([]) and this list will not be removed from the solution representation. Indeed, this representation denotes the presence of the node while acknowledging that it is non-visited.

In any variant of the VRP, solution representation is crucial to the success of search procedures and algorithms. Incorrect or invalid representations can lead to errors, inefficiencies, and incorrect results. Several types of errors must be avoided in the solution representation such as overlapping routes, missing visits, duplicate visits, ordering violations, among others. Such types of errors in the representation are not unique to the CVRPDO. They are rather global to all variants of the VRP, which makes checking for these errors a matter of routine in any such implementation. While the proposed implementation is designed to avoid all types of erroneous representations, in writing this paper, the choice was made to focus solely on detailing the errors uniquely associated with the proposed new solution representation of the CVRPDO to alert their presence. Consequently, Figure 4 is deployed as an illustrative paradigm, elucidating the instantiation of two erroneous solutions denoted as S1 and S3, juxtaposed with their respective rectifications embodied in solutions S2 and S4. Solution S1 is considered incorrect as it includes empty routes, which must be removed from the solution set. Similarly, solution S3 is deemed erroneous since SDL (10) remains unvisited by any customers. Consequently, SDL (10) should not be considered in any route within the solution.

5.2. Initial Solution

The selection of an initial solution, which will be destroyed and repaired by the ALNS heuristic, can significantly impact the performance and quality of the optimization algorithm. A well-chosen initial solution can significantly expedite the convergence towards an improved solution by starting from a configuration that is close to the optimal solution, thereby reducing the time and number of iterations required to reach an improved solution.

In this research, the initial solution was obtained by using a greedy algorithm known as the “Nearest Neighbor (NN)” heuristic [29]. The NN heuristic begins with an empty solution and proceeds iteratively by assigning a set number of the nearest customers to each SDL. The allocation of the remaining customers to routes is determined based on proximity to the current node (starting from the depot node), while ensuring that the vehicle capacity is not exceeded. In cases where no feasible routes are available due to the addition of a customer surpassing the vehicle capacity, a new route is established to accommodate the unassigned customers.

Figure 5 represents an example of 10 customers with two SDLs. After allocating the two closest customers to each shared delivery location, these customers are subsequently excluded from the pool of available customers, while the SDLs are incorporated into the list of nodes that must be visited by a vehicle. Subsequently, commencing from the depot, a search is initiated for the nearest node to be visited. At each juncture, if the vehicle’s capacity limits are surpassed, the solution is interrupted, and a new search is initiated starting from the depot for the nearest available node that will be assigned to a new vehicle.

5.3. Destroy Operators

Destroy operators play a vital role in ALNS metaheuristics as they systematically dismantle sections of a solution, rendering it infeasible. This initial step is integral to each iteration of the ALNS algorithm, wherein a repair operator is subsequently employed to restore the incomplete solution. Within the context of this study, six destroy operators were studied. The first five destroy operators were random removal destroy operators with varying degrees of destruction; the last was Slack Induction by String Removal (SISR). The destroy operators are presented in Figure 3 as the first step of each ALNS iteration.

5.3.1. Random Removal

The random removal destroy operator is designed to introduce randomness and exploration into the search process, facilitating the exploration of alternative solution spaces and potentially improving the overall solution quality. This randomness is determined by the proportion of nodes that are randomly eliminated from the solution, represented as a percentage of the total number of customers. Following experimentation with various percentages, it has been observed that the degrees of destruction (5%, 10%, 15%, 20%, and 25%) significantly enhance solution diversification and thus contribute more effectively to the optimization process.

5.3.2. Slack Induction by String Removal (SISR)

The Slack Induction by String Removal (SISR) was initially proposed by Christiaens and Vanden Berghe (2020) [30]. The destruct operator used by the SISR eliminates adjacent partial routes (referred to as “strings”) that are all situated close to one another rather than randomly eliminating customers.

Figure 6 provides a visual representation of the process involving the removal of adjacent strings. In Figure 6a, a selective removal approach is employed, targeting solely two adjacent strings. The resulting solution, depicted in Figure 6b, reflects the state of destruction incurred by this specific removal operation. The spatial slacks associated with both tours exhibit considerable overlap, thereby intensifying the potential for a better solution. Figure 6c presents the solution after introducing a repair operator aims to replicate the devastated state achieved through the implementation of the slack removal in Figure 6b.

5.4. Repair Operators

The repair operator is a critical component within the framework of the ALNS algorithms, serving the purpose of rectifying incomplete or disrupted solutions and restoring them to a feasible state subsequent to the application of a destroy operator. The repair operator’s primary objective is to modify the disrupted solution through the application of specific rules or heuristics, ensuring the restoration of feasibility while considering the optimization objectives pertinent to the problem at hand. In this study, two repair strategies, namely simple greedy and weighted greedy, were implemented. These strategies iterate over the set of unassigned customers and identify the optimal route and insertion index with the least increase in cost. Additionally, a weighted value was incorporated in the weighted greedy repair strategy to enhance the likelihood of selecting SDL insertion.

5.5. Operator Selection Scheme

The Operator Selection Scheme refers to a strategy or mechanism used in metaheuristic algorithms to determine which operators to apply at each iteration or stage of the search process. It involves selecting the most appropriate combination of operators based on various factors such as problem characteristics, solution quality, and exploration-exploitation balance. In this paper, the implemented selection scheme was the roulette wheel selection. It is a probabilistic method for selecting operators based on their fitness or performance metrics.

The roulette wheel scheme updates operator weights as a convex combination of the current weight, and the new score. When the algorithm starts, all operators $i$ are assigned weight ${\omega }_i=1$. In each iteration, a destroy and repair operator $d$ and $r$ are selected by the ALNS algorithm, based on the current weights ${\omega }_i$. These operators are applied to the current solution, resulting in a new candidate solution. This candidate is evaluated by the ALNS algorithm, which leads to one of four outcomes:

• The candidate solution is a new global best.
• The candidate solution is better than the current solution, but not a global best.
• The candidate solution is accepted.
• The candidate solution is rejected.

Each of these four outcomes is assigned a score $s_j$ (with $j=1,\dots ,4$). After observing outcome $j$, the weights of the destroy and repair operator $d$ and $r$ that were applied are updated as follows:

$$\begin{array}{c}{\omega }_d=\theta {\omega }_d+\left(1-\theta \right)s_j,\\ {\omega }_r=\theta {\omega }_r+\left(1-\theta \right)s_j,\end{array}$$

where $0\le \theta \le 1$ (known as the operator decay rate) is a parameter.

5.6. Acceptance Criteria

The acceptance criteria for the ALNS algorithm determine whether a new solution is accepted or rejected during the search process. The ALNS uses a flexible acceptance strategy to balance exploration and exploitation. In this paper, hill climbing [31] and record-to-record [31] travel criteria were implemented.

5.6.1. Hill Climbing

Hill climbing (HC),

Table 4. Hill Climbing Pseudocode.

, is a local search algorithm which starts with an initial solution and iteratively explores neighboring solutions. The algorithm moves to the neighboring solution that yields the best improvement at each step, thus “climbing up the hill” toward a local optimum. Hill climbing only accepts progressively better solutions, discarding those that result in a worse objective value [31].

5.6.2. Record-to-Record Travel

The Record-to-Record Travel (RRT) pseudocode,

Table 5. Record-to-Record Pseudocode.

, outlines the RRT criterion. RRT refers to a criterion or measure used in optimization algorithms to determine the acceptability of a new solution. It compares the difference or gap between the new solution and the best solution found so far. If the gap falls below a specified threshold (T), the new solution is considered acceptable and replaces the previous best solution. Initially, the threshold is set to a higher value, gradually decreasing with each iteration until it reaches a predetermined final threshold [31].

6. Results and Discussion

These solution algorithms were coded in Python 3.11, and the MIP model was solved by using Gurobi version 10. The computations were performed on an Intel^® Core^™ i7-6820HQ CPU running at 2.70 GHz with 64 GB RAM.

To the best of the authors’ knowledge, no standard instances exist for the CVRPDO in the literature. Section 6.1 introduces the adopted and modified CVRPDO instances. Section 6.2 presents the validation of the ALNS method. The performance of various ALNS parameters is checked in Section 6.3. In Section 6.4, the quality of the ALNS algorithm is checked. Section 6.5 presents the results of attempting to solve the test instances by using the MIP model and a commercial solver or using the ALNS algorithm.

6.1. Instances of the CVRPDO

As mentioned, there are no standard instances of the CVRPDO in the literature; as a result, a classical benchmark set of the VRPTW was adopted and modified for this study. These benchmark instances are the 50 customers instances of Simona Mancini and Margaretha Gansterer [2], 100 customers data set of Solomon and Desrosiers [32], and (200, 400, 600, 800, and 1000 customers) of Gehring and Homberger [33]. These instances were adopted by considering additional parameters as follows SDLs (with x and y coordinates), the capacity of the routes (vehicle capacity), and the capacity of the SDLs (number of lockers), as shown in

Table 6. Details of shared delivery location number and capacity and the capacity of the vehicles for each instance size.

Number of Customers	Number of SDLs	SDL Capacity (Bf)	Vehicle Capacity (Qv)	Vehicle Cost (γ)	Distance limit (ρ)
1000	25	30	1500	50	70
800	25	25	1300	40	70
600	25	20	1000	30	70
400	16	20	500	20	70
200	16	10	300	15	30
100	10	8	200	10	20
50	5	8	150	10	20

.The inclusion of these parameters was determined based on the inherent characteristics of the instances, specifically considering their correlation with these factors: spatial characteristics, customer demands, and the total number of customers [2]. Time windows data from these instances were ignored. The x and y coordinates of the customers of the R1 and R2 instances have a uniform distribution across a two-dimensional plane, the C1 and C2 instances are clustered, and semi-clustered instances are denoted by RC 1.

The travel cost (c_ij) between two nodes, i and j, is fixed, and it is calculated as three times the Euclidean distances, d_ij, between these nodes. The value δ is equal to (c_ij/3). The value of γ is set from three to five percent of the vehicle capacity. For each size of the instances, it is assumed that each request is compatible with all the SDLs located within a travel distance radius ρ from the customers’ location [2].

6.2. Validation of the ALNS

To validate the ALNS, small instances, with 8, 10, and 12 customers, were solved by the MIP model and ALNS algorithm. The ALNS was iterated 20 times. Figure 7 presents an example of the solution obtained by the two methods for an instance of ten customers and two SDL instances. In

Table 7. Comparison of the ALNS and MIP solution approaches applied to 8, 10, and 12 customers.

Number of Customers	Radar Chart of 20 Iterations	ALNS Runtimes	MIP Runtimes	Objective Function Values
8		10−5 s	0.4 s	429
10		0.02 s	0.7 s	490
12		0.9 s	14 s	578

, the ALNS obtained the optimum objective function value in all runs of 8 customer instances and 18 and 17 times when the number of customers was 10 and 12, respectively. Although, in a few iterations for 10 and 12 customers, the ALNS did not obtain the optimum solution to the problem, the solution obtained was of very high quality, differing, in each case, from the optimal solution for the assignment of a single customer.

6.3. Testing the Performance of the ALNS Parameters

To comprehensively evaluate the diverse parameters employed within the ALNS algorithm, a series of iterative analyses were conducted on a dataset encompassing various instance sizes. The results of these investigations, encapsulated in

Table 8. Comparative analysis of various destroy and repair combinations for ALNS solution approaches.

Instance	Data Size	1D1R	1D2R	2D1R	2D2R	3D1R	3D2R	4D1R	4D2R	5D1R	5D2R
r50_5_1	50	205	179	193	177	177	177	184	187	180	177
r50_5_2	50	209	185	204	182	201	184	184	199	184	184
r50_5_3	50	190	188	188	190	190	188	188	188	190	188
C101	100	2514	2513	2497	2498	2518	2494	2501	2477	2464	2403
RC1_2	200	7284	7093	7268	7070	7280	7020	7322	7148	7116	6842
RC_6	600	23,858	22,170	23,732	22,066	22,779	21,221	21,847	21,121	21,104	20,436
R1_8	800	37,783	37,971	36,148	36,087	36,117	36,028	37,071	36,299	36,269	34,759
R2_8	800	37,720	36,786	38,643	38,131	36,684	36,572	36,551	35,832	36,047	35,131
C1_10	1000	44,856	46,461	41,718	43,429	44,029	41,369	44,130	44,810	41,711	41,131
C2_10	1000	42,551	41,086	42,450	42,085	43,454	40,553	40,883	40,593	40,906	40,114

, meticulously document the computed averages of objective function values derived from five individual runs. These runs were conducted by utilizing an assortment of distinct destroy (D) and repair (R) operator combinations, affording a comprehensive understanding of algorithmic performance across varied operational scenarios.

6.4. Testing the Performance of the ALNS aginst Extended MIP Runs

To prove the ALNS algorithm quality, large instances of (1000 customers) were solved by the MIP model with five hour runtimes and compared with the heuristic solutions at 2, 5, and 10 min (the average of five runs are considered). Gaps between the two solutions’ methods were reported in

Table 9. Comparison of the MIP and ALNS solution approaches applied to 1000 customer instances. For MIP, the found solutions after five hours of runtime were reported. For ALNS, the found solutions after (2, 5, 10 min) and the percentage gap to the best solution found by MIP at these runtimes were reported.

Instance	MIP (5 h)		ALNS (1 min)		ALNS (2 min)		ALNS (5 min)		ALNS (10 min)
	Sol	BKB * Gap	Sol	BKS ** Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_10	37,811	72%	39,268	4%	37,751	0%	36,287	−4%	35,624	−6%
C2_10	39,753	54%	41,483	4%	38,968	−2%	36,912	−7%	35,648	−10%
R1_10	54,370	47%	47,738	−12%	47,017	−14%	45,731	−16%	44,526	−18%
R2_10	52,413	45%	48,730	−7%	47,272	−10%	45,443	−13%	44,340	−15%
RC1_10	53,400	57%	45,671	−14%	44,642	−16%	43,020	−19%	42,127	−21%
Avg.	47,549	55%	44,578	−5%	43,130	−8%	41,478	−12%	40,453	−14%

BKB * best known bound obtained by the 3-h run of the MIP; BKS ** best known solutions obtained by the 3-h run of the MIP.

. The detailed results for each instance are reported in

Table A1. Comparative Evaluation of the Results between the MIP Model (5-h Runtimes) and the ALNS for 1000 Customers.

Instance	MIP	ALNS		ALNS		ALNS		ALNS		ALNS
	5 h	1 min		2 min		5 min		7 min		10 min
	Sol	Sol	Gap	Sol	Gap	Sol	Gap	Sol	Gap	Sol	Gap
C1_10	37,811	40,923	8%	39,417	4%	36,425	−4%	35,856	−5%	35,730	−6%
C1_10	37,811	37,962	0%	36,870	−2%	36,381	−4%	35,855	−5%	35,491	−6%
C1_10	37,811	39,487	4%	37,958	0%	36,360	−4%	36,300	−4%	36,259	−4%
C1_10	37,811	39,479	4%	37,727	0%	36,327	−4%	35,781	−5%	35,487	−6%
C1_10	37,811	38,488	2%	36,783	−3%	35,940	−5%	35,649	−6%	35,155	−7%
Avg.	37,811	39,267.8	4%	37,751	0%	36,286.6	−4%	35,888	−5%	35,624	−6%
C2_10	39,753	39,920	0%	38,711	−3%	36,916	−7%	36,411	−8%	35,652	−10%
C2_10	39,753	43,640	10%	38,406	−3%	36,584	−8%	35,933	−10%	35,460	−11%
C2_10	39,753	40,867	3%	38,973	−2%	37,622	−5%	36,754	−8%	36,183	−9%
C2_10	39,753	44,202	11%	41,441	4%	38,032	−4%	36,332	−9%	35,706	−10%
C2_10	39,753	38,786	−2%	37,307	−6%	35,406	−11%	35,317	−11%	35,241	−11%
Avg.	39,753	41,483	4%	38,968	−2%	36,912	−7%	36,149	−9%	35,648	−10%
R1_10	544,370	50,035	−8%	49,092	−10%	46,518	−14%	45,541	−16%	44,868	−17%
R1_10	544,370	45,784	−16%	44,844	−18%	44,841	−18%	44,570	−18%	44,373	−18%
R1_10	544,370	47,334	−13%	46,587	−14%	45,045	−17%	44,894	−17%	44,867	−17%
R1_10	544,370	49,061	−10%	48,177	−11%	46,925	−14%	46,020	−15%	44,130	−19%
R1_10	544,370	46,478	−15%	46,387	−15%	45,324	−17%	45,042	−17%	44,394	−18%
Avg.	544,370	47,738.4	−12%	47,017	−14%	45,731	−16%	45,213	−17%	44,526	−18%
R2_10	52,413	48,892	−7%	46,499	−11%	45,399	−13%	44,820	−14%	44,658	−15%
R2_10	52,413	49,090	−6%	48,056	−8%	46,409	−11%	45,553	−13%	44,487	−15%
R2_10	52,413	48,322	−8%	47,554	−9%	45,233	−14%	44,611	−15%	44,540	−15%
R2_10	52,413	50,280	−4%	48,412	−8%	45,280	−14%	44,001	−16%	43,853	−16%
R2_10	52,413	47,067	−10%	45,839	−13%	44,896	−14%	44,359	−15%	44,164	−16%
Avg.	52,413	48,730.2	−7%	47,272	−10%	45,443	−13%	44,669	−15%	44,340	−15%
RC1_10	53,400	45,553	−15%	44,756	−16%	42,905	−20%	42,426	−21%	42,122	−21%
RC1_10	53,400	45,219	−15%	43,298	−19%	41,922	−21%	41,897	−22%	41,894	−22%
RC1_10	53,400	46,389	−13%	44,957	−16%	43,542	−18%	43,040	−19%	43,040	−19%
RC1_10	53,400	46,272	−13%	45,720	−14%	43,493	−19%	42,496	−20%	41,159	−23%
RC1_10	53,400	44,922	−16%	44,480	−17%	43,236	−19%	42,960	−20%	42,421	−21%
Avg.	53,400	45,671	−14%	44,642.2	−16%	43,020	−19%	42,564	−20%	42,127	−21%

in Appendix. Although it is not practical to run the MIP model for this considerable time, and it will occupy a massive amount of the RAM, this is performed to validate the algorithm’s performance.

Each line in the tables corresponds to the average result for one type of instance. Instance groups are listed in column 1. Columns 2 and 3 encapsulate the results pertaining to the solution derived from the MIP model and the optimality gap (BKB Gap). Moreover, the fourth, sixth, eighth, and tenth columns provide the average cost associated with the ALNS across varying runtimes. Furthermore, the fifth, seventh, ninth, and eleventh columns present the average gap between the ALNS algorithm’s outcomes and those provided by the MIP model’s solutions (BKS Gap). Indeed, a negative BKS gap means the ALNS solution is better than the one obtained by the MIP model.

6.5. Comprehensive Evaluation of the ALNS Performance

In this part of the computational study, the performance of the proposed solution approach ALNS is compared with the commercial solver applied to the MIP model in Section 4. The results are summarized in tables from

Table 10. Comparative analysis of MIP and ALNS solution approaches on 1000 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_10	48,058	78%	41,131	−14%	39,268	−18%	38,366	−20%	37,751	−21%
C2_10	47,728	62%	43,114	−10%	41,483	−13%	40,036	−16%	38,968	−18%
R1_10	69,597	59%	49,655	−29%	47,738	−31%	47,321	−32%	47,017	−32%
R2_10	69,010	59%	50,866	−26%	48,730	−29%	47,981	−31%	47,272	−32%
RC1_10	55,882	59%	47,048	−16%	45,671	−18%	44,702	−20%	44,642	−20%
Avg.	58,055	63%	46,363	−19%	44,578	−22%	43,681	−24%	43,130	−25%

,

Table 11. Comparative analysis of MIP and ALNS solution approaches on 800 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_8	43,489	81%	27,893	−36%	27,279	−37%	26,891	−38%	26,646	−39%
C2_8	40,022	63%	30,549	−24%	29,330	−27%	28,770	−28%	28,422	−29%
R1_8	49,105	59%	35,861	−27%	34,752	−29%	33,983	−31%	33,490	−32%
R2_8	43,725	54%	35,131	−20%	34,763	−20%	34,042	−22%	33,722	−23%
RC1_8	45,585	64%	35,623	−22%	34,639	−24%	34,139	−25%	33,807	−26%
Avg.	44,385	64%	33,012	−26%	32,153	−28%	31,565	−29%	31,217	−30%

,

Table 12. Comparative analysis of MIP and ALNS solution approaches on 600 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_6	17,706	64%	18,862	7%	18,452	4%	18,140	2%	17,884	1%
C2_6	21,190	46%	21,491	1%	20,709	−2%	19,935	−6%	19,663	−7%
R1_6	22,780	43%	21,458	−6%	21,072	−7%	20,873	−8%	20,729	−9%
R2_6	23,286	44%	21,733	−7%	21,209	−9%	21,003	−10%	20,796	−11%
RC1_6	20,978	49%	20,325	−3%	19,871	−5%	19,618	−6%	19,392	−8%
Avg.	13,441	49%	20,774	−2%	20,263	−4%	19,914	−6%	19,693	−7%

,

Table 13. Comparative analysis of MIP and ALNS solution approaches on 400 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_4	12,518	69%	12,662	1%	12,518	0%	12,283	−2%	12,133	−3%
C2_4	12,523	51%	12,697	1%	12,343	−1%	12,252	−2%	12,218	−2%
R1_4	14,414	45%	14,424	0%	13,877	−4%	13,579	−6%	13,524	−6%
R2_4	14,490	49%	14,638	1%	14,105	−3%	13,985	−3%	13,916	−4%
RC1_4	14,034	55%	13,811	−2%	13,501	−4%	13,211	−6%	13,026	−7%
Avg.	13,596	54%	13,646	0%	13,269	−2%	13,062	−4%	12,963	−5%

,

Table 14. Comparative analysis of MIP and ALNS solution approaches on 200 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C1_2	6757	70%	6834	1%	6679	−1%	6555	−3%	6489	−4%
C2_2	6998	57%	6734	−4%	6667	−5%	6626	−5%	6583	−6%
R1_2	7735	55%	7054	−9%	6973	−10%	6944	−10%	6917	−11%
R2_2	7368	52%	7112	−3%	6962	−6%	6911	−6%	6887	−7%
RC1_2	6725	55%	6779	1%	6617	−2%	6593	−2%	6567	−2%
Avg.	7117	56%	6903	−3%	6780	−5%	6726	−5%	6689	−6%

,

Table 15. Comparative analysis of MIP and ALNS solution approaches on 100 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
C101	2390	63%	2403	1%	2403	1%	2389	0%	2389	0%
C201	2615	55%	2720	4%	2717	4%	2637	1%	2636	1%
R101	2274	37%	2284	0%	2284	0%	2245	−1%	2183	−4%
R201	2192	37%	2173	−1%	2165	−1%	2165	−1%	2106	−4%
Rc101	2904	53%	3054	5%	3045	5%	2907	0%	2907	0%
Avg.	2475	49%	2527	2%	2523	2%	2469	0%	2444	−1%

and

Table 16. Comparative analysis of MIP and ALNS solution approaches on 50 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 3 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 3 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
r50_5_1	168	28%	177	5%	177	5%	177	5%	177	5%
r50_5_2	139	30%	185	33%	184	32%	184	32%	184	32%
r50_5_3	150	31%	188	25%	188	25%	188	25%	188	25%
r50_5_4	196	34%	194	−1%	184	−6%	184	−6%	183	−7%
r50_5_5	184	33%	185	1%	185	1%	174	−5%	174	−5%
Avg.	167	31%	186	13%	184	12%	181	10%	181	10%

for different sizes of instances. For all instance sizes, the MIP model ran for 3 h runtimes. While the ALNS runtimes were (30, 60, 90 and 120) seconds. For each instance, an average of five runs are considered. The detailed results for each instance are reported in Appendix A from

Table A2. Comparative Evaluation of the Results between the MIP Model (3-h Runtimes) and the ALNS for 1000 Customers.

Instance	MIP	ALNS		ALNS		ALNS		ALNS
	3 h	30 s		60 s		90 s		120 s
	Sol	Sol	Gap	Sol	Gap	Sol	Gap	Sol	Gap
C1_10	48,058	42,594	−11%	40,923	−15%	39,497	−18%	39,417	−18%
C1_10	48,058	40,071	−17%	37,962	−21%	37,274	−22%	36,870	−23%
C1_10	48,058	41,827	−13%	39,487	−18%	38,582	−20%	37,958	−21%
C1_10	48,058	40,398	−16%	39,479	−18%	39,094	−19%	37,727	−21%
C1_10	48,058	40,766	−15%	38,488	−20%	37,384	−22%	36,783	−23%
Avg.	48,058	41,131	−14%	39,268	−18%	38,366	−20%	37,751	−21%
C2_10	47,728	41,088	−14%	39,920	−16%	39,433	−17%	38,711	−19%
C2_10	47,728	44,683	−6%	43,640	−9%	40,504	−15%	38,406	−20%
C2_10	47,728	43,333	−9%	40,867	−14%	39,516	−17%	38,973	−18%
C2_10	47,728	45,648	−4%	44,202	−7%	42,416	−11%	41,441	−13%
C2_10	47,728	40,816	−14%	38,786	−19%	38,311	−20%	37,307	−22%
Avg.	47,728	43,114	−10%	41,483	−13%	40,036	−16%	38,968	−18%
R1_10	69,597	51,818	−26%	50,035	−28%	49,951	−28%	49,092	−29%
R1_10	69,597	48,113	−31%	45,784	−34%	44,850	−36%	44,844	−36%
R1_10	69,597	49,353	−29%	47,334	−32%	46,603	−33%	46,587	−33%
R1_10	69,597	51,534	−26%	49,061	−30%	48,724	−30%	48,177	−31%
R1_10	69,597	47,455	−32%	46,478	−33%	46,478	−33%	46,387	−33%
Avg.	69,597	49,655	−29%	47,738	−31%	47,321	−32%	47,017	−32%
R2_10	69,010	51,342	−26%	48,892	−29%	47,909	−31%	46,499	−33%
R2_10	69,010	51,240	−26%	49,090	−29%	48,656	−29%	48,056	−30%
R2_10	69,010	50,067	−27%	48,322	−30%	47,856	−31%	47,554	−31%
R2_10	69,010	51,422	−25%	50,280	−27%	49,384	−28%	48,412	−30%
R2_10	69,010	50,261	−27%	47,067	−32%	46,100	−33%	45,839	−34%
Avg.	69,010	50,866	−26%	48,730	−29%	47,981	−30%	47,272	−31%
RC1_10	55,882	47,124	−16%	45,553	−18%	44,756	−20%	44,756	−20%
RC1_10	55,882	46,869	−16%	45,219	−19%	43,308	−23%	43,298	−23%
RC1_10	55,882	47,239	−15%	46,389	−17%	45,117	−19%	44,957	−20%
RC1_10	55,882	48,463	−13%	46,272	−17%	45,762	−18%	45,720	−18%
RC1_10	55,882	45,547	−18%	44,922	−20%	44,570	−20%	44,480	−20%
Avg.	55,882	47,048	−16%	45,671	−18%	44,703	−20%	44,642	−20%

. Comparative Evaluation of the Results between the MIP Model (3-h Runtimes) and the ALNS for 1000 Customers. to

Table A7. Comparative Evaluation of the Results between the MIP Model (3-h Runtimes) and the ALNS for 100 Customers.

Instance	MIP	ALNS		ALNS		ALNS		ALNS
	3 h	10 s		20 s		30 s		40 s
	Sol	Sol	Gap	Sol	Gap	Sol	Gap	Sol	Gap
C101	2390	2460	3%	2405	1%	2402	1%	2402	1%
C101	2390	2489	4%	2399	0%	2396	0%	2396	0%
C101	2390	2419	1%	2412	1%	2407	1%	2407	1%
C101	2390	2411	1%	2411	1%	2411	1%	2411	1%
C101	2390	2550	7%	2399	0%	2399	0%	2398	0%
Avg.	2390	2466	3%	2405	1%	2403	1%	2403	1%
C201	2615	2754	5%	2723	4%	2701	3%	2701	3%
C201	2615	2906	11%	2875	10%	2747	5%	2741	5%
C201	2615	2759	6%	2746	5%	2737	5%	2728	4%
C201	2615	2898	11%	2803	7%	2778	6%	2762	6%
C201	2615	2734	5%	2637	1%	2636	1%	2636	1%
Avg.	2615	2810	7%	2757	5%	2720	4%	2714	4%
R101	2274	2387	5%	2340	3%	2280	0%	2280	0%
R101	2274	2387	5%	2340	3%	2280	0%	2280	0%
R101	2274	2292	1%	2290	1%	2290	1%	2290	1%
R101	2274	2387	5%	2340	3%	2280	0%	2280	0%
R101	2274	2292	1%	2290	1%	2290	1%	2290	1%
Avg.	2274	2349	3%	2320	2%	2284	0%	2284	0%
R201	2192	2268	3%	2189	0%	2183	0%	2166	−1%
R201	2192	2161	−1%	2161	−1%	2157	−2%	2152	−2%
R201	2192	2194	0%	2178	−1%	2167	−1%	2167	−1%
R201	2192	2186	0%	2186	0%	2185	0%	2176	−1%
R201	2192	2212	1%	2194	0%	2175	−1%	2175	−1%
Avg.	2192	2204	1%	2182	0%	2173	−1%	2167	−1%
RC101	2904	3258	12%	3233	11%	3218	11%	3109	7%
RC101	2904	3142	8%	3087	6%	3027	4%	3017	4%
RC101	2904	3156	9%	3022	4%	3005	3%	2987	3%
RC101	2904	3087	6%	3087	6%	3045	5%	3016	4%
RC101	2904	3108	7%	3022	4%	2977	3%	2976	2%
Avg.	2904	3150	8%	3090	6%	3054	5%	3021	4%

.

Table 10, Table 11 and Table 12 present the results of 1000, 800, and 600 customer instances. The results reveal a clear superiority of the ALNS algorithm over the MIP model for all instances. In a matter of seconds, the ALNS algorithm outperformed the MIP model, which took 3 h to solve the problem, by achieving significantly better results. For 1000 customer instances, the gap of the ALNS is 19%, 22%, 24%, and 25% better than the MIP for 30, 60, 90, and 120 s runtimes, respectively. Across 800 customer instances, the ALNS algorithm demonstrates a remarkable performance advantage over the MIP model, achieving a significant improvement ranging from 35 to 40% within a mere two-minute runtime. Across a dataset of 600 customer instances, the utilization of the ALNS algorithm resulted in a noteworthy average improvement ranging from 2 to 7% compared to the MIP model.

Table 13, Table 14, and Table 15 showcase the outcomes obtained from 400, 200, and 100 customer instances, respectively. In the case of 400 customer instances, the ALNS algorithm accomplished a solution comparable to that of the MIP model after only 30 s of runtime. Furthermore, the results improved to achieve a 5% advantage over the MIP model at the 120-s mark. Across a dataset of 200 customer instances, the ALNS algorithm consistently exhibits a notable performance advantage over the MIP model, showcasing average improvements ranging from 3% to 6% within a mere two-second runtime. Despite the ALNS algorithm operating on a dataset of 100 customer instances with a gap ranging from −1 to 2%, the ALNS runtime remains within two minutes, while the MIP model takes approximately three hours to complete.

Table 16 presents the results of the 50 customer instances with MIP runtimes 3 h, while in

Table 17. Comparative analysis of MIP and ALNS solution approaches on 50 customer instances: solution outputs and percentage gap relative to MIP’s solutions (after 0.5 h of runtime) at ALNS runtimes of 30, 60, 90, and 120 s.

Instance	MIP 0.5 h		ALNS 30 s		ALNS 60 s		ALNS 90 s		ALNS 120 s
	Sol	BKB Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap	Sol	BKS Gap
r50_5_1	180	29%	177	−2%	177	−2%	177	−2%	177	−2%
r50_5_2	185	31%	185	0%	184	−1%	184	−1%	184	−1%
r50_5_3	188	34%	188	0%	188	0%	188	0%	188	0%
r50_5_4	187	36%	194	4%	184	−2%	184	−2%	183	−2%
r50_5_5	197	37%	185	−6%	185	−6%	174	−12%	174	−12%
Avg.	187	33%	186	−1%	184	−2%	181	−3%	181	−3%

the runtimes is 0.5 h for the same instances. Across the 50 customer instances, the ALNS heuristics demonstrate an average deterioration of 10% in comparison to the MIP model with 3 h runtimes. For 0.5 h. MIP runtimes, the ALNS heuristics slightly improved the solutions obtained by the MIP model by an average of 1% within less than two minutes.

To conclude, the results of the objective function values were noticeably improved when solving the problem with the ALNS with a 120 s runtime compared with the MIP model (with a runtime of 3 h) by 25%, 30%, 7%, 5%, 6%, and 1% for 1000, 800, 600, 400, 200, and 100 customers, respectively.

From the results it is found that the instance size is not the only factor that defines the complexity of the problem. As a result, instances with a higher number of customers may achieve better results (a smaller gap to optimality) than instances with a lower number. Other factors may play a role in increasing the complexity of the problem such as the structure of the solution space, heuristics and relaxation techniques that are used by the solver to efficiently search for solutions, and the quality of the initial solution.

7. Conclusions

Last-mile delivery poses significant cost implications in the ecommerce sector and directly impacts online purchases. To effectively address the challenges associated with last-mile delivery, companies must devise dependable distribution strategies that consider various aspects, including cost efficiency, customer satisfaction, delivery alternatives, and sustainability. Among the various methods available, parcel lockers have emerged as a promising delivery option for handling the final stage of the delivery process.

The Capacitated Vehicle Routing Problem with Delivery Options, a new extension of the CVRP allowing for various delivery options for each customer, is paramount, as it enables businesses to optimize their transportation operations, minimize costs, maximize efficiency, and ensure timely deliveries to customers. This article defines the Capacitated Vehicle Routing Problem with Delivery Options. It consists of designing a set of routes for a fleet of vehicles that deliver to customers directly or to shared delivery locations. These routes should respect the capacities of the vehicles and the lockers at the shared delivery locations while minimizing the total routing costs.

To solve this problem, a solution is proposed by utilizing an Adaptive Large Neighborhood Search approach (ALNS) incorporating various destroy and repair operators and selection schemes. The performance of the proposed Adaptive Large Neighborhood Search approach is compared to a Mixed-Integer Programming model, where each instance is given a maximum runtime of 3 h.

Remarkably, the proposed approach (ALNS) yields favorable outcomes, as it achieves superior solutions within a mere 30-s timeframe compared to the MIP model. On average, the ALNS approach outperforms the MIP by 19%, 26%, 2%, and 3% for instances with 1000, 800, 600, and 200 customers, respectively. When dealing with instances consisting of 100 customers, the ALNS approach with 120-s runtimes produces slightly better solutions, averaging 3% better than those obtained by the MIP model within its 0.5-h runtime.

The authors plan to expand the CVRPDO for future research by including additional factors such as time windows and considering different customer preferences. Furthermore, to enhance the quality of the generated solutions, the authors intend to incorporate a greater variety of destroy and repair operators into the heuristic algorithm.