Optimal Route Crowd-Shipping System for Sustainable Rapid Delivery: Algorithm, Simulation, and Feasibility Evaluation

: Delivery systems are ubiquitous in today’s economy. However, those systems usually operate through purpose-built vehicles, which are inefficient, expensive, and highly harmful to the environment. We propose an optimal route crowd-shipping (OR-CS) system, a delivery service based on crowd transportation. The OR-CS system utilizes service points (SPs) and occasional couriers (OCs) to transfer deliveries. Senders drop packages at SPs, while receivers collect them from different SPs. The system is based on a new algorithm that assigns to each package an optimal route. The route is chosen individually for the package and is personally tailored according to the sender’s preferences and to the predefined routes of the OCs. To assess the real-life feasibility of the system, we developed a general simulator that emulates a city environment with authentic service points specifically selected based on desired attributes. The routes of OCs and the origins and destinations of packages were generated using a random process that differed between simulations. The results indicate that the system can be implemented and utilized. In addition, it yields positive results when the number of OCs surpasses a minimum threshold, which is feasible in most cities, given existing traffic loads. By adopting OR-CS, we can expect lowered delivery costs, reduced traffic congestion, and enhanced environmental sustainability.


Introduction
Today's economy relies heavily on the ability to deliver products to consumers [1].Over $5 trillion was made in global eCommerce sales in 2022, and it is expected that sales will reach $6.31 trillion in 2023 (https://www.insiderintelligence.com/content/worldwideecommerce-forecast-update-2022, accessed on 16 November 2023).However, delivery systems such as those used by USPS, FedEx, UPS, DHL, or smaller local companies are usually built around vehicles tailored to this purpose.Furthermore, those vehicles are typically not loaded to their full capacity-on average, they are less than 50% full.Additionally, trucks may drive back empty after making a delivery [2].This situation increases traffic congestion, which is harmful to the environment and to the population.Concurrently, traffic contains other vehicles passing the delivery route for various reasons.The drivers of these vehicles might be interested in serving as occasional couriers (OC) to deliver the packages for a reward.This approach, known as crowd-shipping, will reduce traffic congestion, cause a substantial reduction in carbon emissions and environmental impact, and decrease transit costs.
The utilization of crowd-shipping can be done in several ways; one of them is using a network of service points (SPs) (e.g., gas stations, local groceries or automated parcel machines).In detail, the deliveries are made by OCs who input their route into the system.The OCs move packages from one SP to another along their predefined route.The sender dispatches a package in an SP, and the receiver ultimately picks it up at an SP close to the agreed destination.
Various studies and implementations have recently been proposed for crowd-shipping delivery systems to solve diversity challenges in various fields, including technology, engineering, security, economy, marketing, and others.This manuscript focuses on the core algorithmic problem of route planning optimization.
Several crowd-shipping delivery systems that optimize the routes for packages were offered [3][4][5].These systems consider factors such as time or distance and optimize them for all packages accordingly.However, from the sender's point of view, the optimal route for a package relies on different parameters, each of which has a different priority.One is the time it takes for the package to arrive at its destination.The second is the distance that the package travels, which affects the price of the delivery (for example [4]).Another parameter is the amount of OCs that are involved in the delivery, since as this amount increases, so does the probability of the package getting damaged or lost.Each sender has different preferences, and the prioritization of these parameters varies accordingly.In this paper, we establish a personalized algorithm that finds the optimal route for each package according to the sender's prioritization and its strictness.In addition, we implement the algorithm into an optimal route crowd-shipping (OR-CS) system.To the best of our knowledge, this is the first system that considers each sender's desires individually.
To establish a proof of feasibility, we implemented a general simulator that can be run in any city.We focused on a real-world city, Ashdod, and chose a set of SPs according to a predefined set of attributes.A set of OCs was generated, each with a corresponding route and departure time.The routes and times were generated using a random model.The travel time of the different OCs was calculated while considering the expected time.The random model varied between the different simulations.Every simulation also consisted of a set of deliveries (i.e., origin and destination SP and time) that were generated using a random model.
Running several different simulations yielded promising results, indicating that the OR-CS is feasible and can be effectively used in real-world settings.The simulations have provided evidence that the system can be successfully utilized with positive results.These findings highlight the potential for practical implementation and suggest that the OR-CS can perform effectively, enhancing the sustainability of logistics by reducing the number of vehicles on the roads, and thus should become part of future transportation.
To summarize, the main contributions of this paper are (i) Creating a new crowdshipping system with a personalized algorithm that finds an optimal route for each package according to the sender's preference.(ii) Building a general simulator to check the system's performance.(iii) Running simulations on the city of Ashdod and analyzing the results.
The rest of the paper is built as follows: Section 2 reviews recent studies in this field.Section 3 describes the new algorithm and the OR-CS system.Section 4 describes the general simulator we built, and Section 5 shows the results of the simulation run on the city of Ashdod.Finally, Section 6 has a discussion and conclusions.

Literature Review
The remarkable triumph in the last decade of sharing platforms like Uber, Lyft, and Airbnb, which operate without actually possessing their assets; instead, they facilitate connections between owners and users.This has further fueled the desire to apply the sharing economy concept to delivery services [6].
Recent studies report on the willingness of consumers from developing countries [7] to use the pick-up point structures and the viability of implementing them.Case studies conducted in Greece [3] and Italy [8] demonstrate that crowd-shipping and public transport crowd-shipping can alleviate the challenges associated with last-mile deliveries, significantly enhancing the system's overall performance.Further, a literature review [9] that related the factors within mobile applications that encourage sustainable choices found that a well-designed approach incorporating financial incentives and environmental consciousness could boost public transport usage.Alternatively, the shipping mode may include electric bicycles [10,11] as a solution for urban last-mile deliveries.
The optimization aspects of crowd-shipping were studied from different perspectives.Ref. [12] focuses on the problem of matching crowd-shipping supply and demand, presenting a procedure that maximizes the number of matched shipments while considering the employees' minimum expected earnings per time unit, this problem was also considered in [13].In [14], the authors proposed mechanisms to achieve outcome prediction in crowdsourcing, while the authors of [15] suggest agile optimization to handle problems related to routing time and distance or to reducing energy consumption.In [16], they address energy optimization and constraints using linear programming.In [17], a closely related problem is considered, and the goal is to optimize total travel time and costs.
The ultimate crowd-shipping solution to deliver packages is based on OCs, as assumed in many studies [5,18,19].However, employing company couriers as a backup is also suggested, so there is a need to refer to reducing the costs of company messengers [20][21][22][23].In [3], the system assigns each package to one OC.The system in [5] assigns the packages to several OCs; however, the route is determined not according to the OC's routs.In [4], the system also assigns the packages to several OCs; it tries to maximize profit while fulfilling constraints using mixed integer programming.
Relating to the SPs, some studies [20,21] assume carriage directly between origin and destination, whereas others [5,18,23] suggest that different drivers would unload the package at an SP along the route, and there it would be stored until the next driver loads it.Alternatively, the drivers meet at intermediate destinations at synchronized times to pass the package from hand to hand [22,24].Choosing the locations of the SPs is close to choosing the locations of centers in different supply chains (for example [25]).
What sets our work apart is its unique approach, providing a flexible solution that caters to the preferences set by the package sender.Namely, depending on the prioritization of time distance and amount of OCs, the algorithm shown in this paper finds an optimal route for the package.Moreover, we showcase the feasibility of this solution by presenting a simulator capable of testing diverse scenarios using real-world data.

The OR-CS System Description
The OR-CS system's goal is to use OCs to transfer packages between SPs along the delivery routes.The system contains a set P = {p 1 , ..., p n } of n SPs that are chosen at the initialization from a predefined region.A location is considered an SP if it has an appropriate place to park, load, and unload OC vehicles safely.Places that fit these criteria include gas stations and parking lots.Obviously, the set P can change from time to time.
The OR-CS system has known time intervals; sometimes, an interval may extend to a day or even more.Each individual who wishes to be an OC can register in the OR-CS before the beginning of the time interval.During the registration process, the OC must declare the start time and route associated with the future journey (i.e., the OC registrant must identify, order, and sequence of SPs that will be included in the journey).Namely, the SPs that will be visited on the journey and their order.The OR-CS calculates the approximate time of arrival to each SP.Hence, for each time interval, the system also contains a set C = {c 1 , ..., c m } of m OCs, a set R = {r c 1 , ..., r c m } of m routes for each c i ∈ C, and a set T = {t c 1 , ..., t c m } of starting times for each OC.
The OR-CS also has a defined bound on the maximal time allowed for a package to be delivered, denoted by U t .A package sender allocates an origin SP and a destination SP for the package and the time the package will be placed in the origin SP, t o .Each sender must prioritize the following parameters concerning the package route from its origin SP to its destination SP: (i) Time: the amount of time it takes the package to travel the route.(ii) Distance: the length of the route.(iii) #OC: the total number of OCs that carried the package through the route.The motivation for taking the third parameter into account is the assumption that as the number of OCs that deliver a package increases, so does the probability of the package being damaged or lost.The sender also chooses how strict the prioritization should be.At the beginning of each time interval, the OR-CS creates a TIMEEXPANDEDGRAPH.For every new package during this time interval, the OR-CS defines different weights over the edges of the TIMEEXPANDEDGRAPH, according to the sender's preferences.Using the weighted TIMEEXPANDEDGRAPH, the OR-CS runs an algorithm that chooses the route the package will follow and the OCs that will deliver it.Following, we describe how we build the TIMEEXPANDEDGRAPH (Algorithm 1) and how the optimal route is found (Algorithm 2) for a given package.

The TIMEEXPANDEDGRAPH
A TIMEEXPANDEDGRAPH G = (V, E) is a directed graph of a type suggested in [26].Each vertex v ∈ V in the graph is a triplet v = (c, p, t) in which c ∈ C is an OC, p ∈ P is a specific SP, and t is a time.A triplet is a vertex in the graph iff OC c reaches SP p in time t.
The following definitions are used to describe the set of edges.The LOADINGTIME is the maximum time it takes to load or unload a package.For each OC, c, route(c) represents the entire series of vertices of the form, (c, p i , t i ), ordered by time.
The set of edges contains two types: (i) Station edges: these edges represent the fact that a certain package that was dropped off in an SP can be later picked up by some OC that reaches this SP.Formally, there exists a station edge from vertex (c, p, t) to vertex (c ′ , p ′ , t ′ ) iff p = p ′ and t ′ ≥ t + LOADINGTIME.(ii) Route edges: an edge between a vertex and its successor in the route.Notice that route edges connect only vertices associated with the same OC (see an example of the edges in Figure 1).

Algorithm 1: Build TIMEEXPANDEDGRAPH
Input: .., p k } where p j , ..., p k ∈ P and a set T = {t c 1 , ..., t c m } of starting times for each OC.
For each r c i ∈ R: (a) For each p ∈ r c i : For each station edge e = ((c, p, t), (c ′ , p, t ′ )) ∈ E:

The Optimal Route Algorithm
Given the TIMEEXPANDEDGRAPH, and a new package to deliver, the sender must choose what variables are most important regarding delivering the package: delivering time, overall distance traveled of the delivery, or number of OCs used to carry the package.The sender defines the prioritization order ⟨x, y, z⟩ (six possible permutations exist) and the strictness parameters α, β.
Recall that U t denotes the upper bound over time, as described above.Let U d denote the upper bound of a considerable distance for a delivery route of a package.Let U oc ≤ m denote an upper bound of the number of OCs involved in the delivery of a package.
To establish the weight function, the unit used to measure each parameter must be normalized with the units of the other parameters.Namely, δ(time) represents the weight that is added to the total weight by one unit of time, δ(distance) represents the weight that is added by one unit of distance, and δ(#OC) the weight added by one OC.
To preserve a prioritization, ⟨x, y, z⟩, the following equations must hold: where 0 ≤ α ≤ U y , 0 ≤ β ≤ U z are parameters that represent the strictness of the prioritization.In detail, if α and β equal 0, the prioritization is very strict; if these values are higher, prioritization is less strict.
Hence, any decrease in the time, even a small one, will be preferable even if it results in a considerable increase in the number of OCs.However, if we let α = 96 then Namely, a decrease in a time unit is preferable only if it increases no more than 4 OCs.The weight of a station edge from (c, p, t) to (c ′ , p, t ′ ) is The weight of a route edge from (c, where |p i+1 − p i | is the length of the shortest route between two SPs. To determine the best route of a package in the weighted TIMEEXPANDEDGRAPH, we first add two special nodes to the graph-an origin node, O, and a destination node,D-as follows: let p o be the origin SP of a package, p d its destination SP, and t the time the package arrived at the origin SP.The origin node will have an edge to every node of the form (_, p o , t ′ ), where t < t ′ < t + U t , and the weight of the edge is δ(time) • (t ′ − t).The destination node has edges going into it from every node of the form (_, p d , t ′ ) where t < t ′ < t + U t and the weight of the edge is 0.
After adding the two nodes, we adjust the weights to comply with the sender's priorities.Finally, we apply Dijkstra's algorithm [27] to the graph with the origin node as the source node.The route the algorithm outputs from the origin node to the destination node will be the route of the package (See an example in Figure 2).

Simulator
We implement the OR-CS system as a simulator to evaluate its feasibility (Our commitment to the open-source paradigm is exemplified by the availability of our codebase, accessible at [28], fostering collaborative knowledge sharing and community involvement).The simulator is a web app with an interface to feed a road map of the related region, chosen SPs within, and traffic load information for each route segment.The simulator allows tuning the number of drivers and parcels and displays the simulation results on a map at various speeds.In addition, the user should define the prioritization (time, driver, or distance) for each package (see Figure 3).
The simulations were conducted in the Israeli city of Ashdod.The simulator is fed with real traffic data gathered using Waze's API [29].The traffic data used can be found here [30].The population of Ashdod is approximately 225,000 with a density of 4791 people per km 2 .To select suitable SPs, we evaluated locations based on their ability to provide safe parking and facilitate loading and unloading.This criterion included locations such as gas stations and parking lots.The SPs were chosen using commonly employed Geographic Information System (GIS) tools, with additional SPs being manually selected.In total, 70 SPs were designated for this purpose, as illustrated in Figure 4.
There was a need to calculate both the distance between every pair of SPs and the time it takes to travel from one to another.The travel time varies depending on the traffic, which usually depends on the time of day.Hence, the day was divided into 15 intervals that share the same estimated traffic load (In the simulator, the intervals parameter is tuneable).The estimated travel time was calculated for each interval using Waze's API [29].This information was retrieved and stored before running the simulations.There was also a need to create random routes for the OCs.For simplicity, the origin and destination points were chosen randomly from the set of SPs (the distribution varied between the simulation as described in Section 5).The optimal route for this journey, which does not consider the SPs, was retrieved via the Mapbox directions API.The next stage was finding SPs close to the route.To do so, first, all SPs that have an aerial separation distance of less than 10 −3 -3 • 10 −4 from the route were marked.Using a traveling salesperson optimization algorithm, with the origin, destination, and marked SPs as input, a new route was chosen (see an example in Figure 5).

Results
The model's performance was assessed across various parameters through a series of experiments.In each set of experiments with fixed parameter values, a total of 50 random trials were conducted.
Initially, we evaluated the model's performance by generating random routes, origin, and destination SPs, all with a uniform probability distribution.Our criteria for success were delivering a package within 24 h.As illustrated in Figure 6, the model exhibited a low success rate when dealing with a thousand packages while employing 100 OCs.However, when utilizing 500 OCs, the success rate significantly improved, reaching 90%.This trend was consistent even with smaller quantities of packages.Interestingly, a reduction in the number of packages did not lead to a significant change in the required number of OCs to achieve a high success rate, as depicted in Figure 7. Furthermore, we explored the model's performance in scenarios where OC routes were not generated uniformly.Specifically, for certain OCs, we exclusively selected origin or destination stations (or both) from a subset of 14 northern SPs out of the total 100 SPs (refer to Figure 8).The results of this analysis, conducted with 300 OCs and 1000 packages, are presented in Figure 9.
The findings indicate that using a uniform distribution yields the best results.Nevertheless, it's intriguing to note that even when approximately 60% of both the origin and destination stations are exclusively chosen from the northern SPs, the success rate still surpasses the 50% mark.
This observation shows the model's capability to deliver satisfactory results even when faced with a non-uniform distribution of origins and destinations.
We also investigated whether there is a correlation between the delivery price and the number of packages.To answer this question, we conducted a simulation with 300 OCs, where the priority of each package was randomly assigned using a uniform distribution from a set of six possible priorities (all possible prioritization of time, distance, and amount of OCs).For each package amount (ranging between 100 to 1000 in intervals of 100), we conducted 50 simulations and calculated their average.The results in Figure 10 indicate that until the number of packages reaches a threshold of around 600 there is a decrease in the average cost as the number of packages increases, and from this threshold, the average cost stays the same.However, the maximum cost does not show a similar decrease.

Discussion and Conclusions
Wasted resources in the transit system have become a growing concern in today's world.The inefficient use of vehicles, leading to empty or underutilized vehicles, causes unnecessary fuel consumption, increased emissions, waste of resources, and financial burdens.Additionally, the lack of proper synchronization and coordination between different transit vehicles often leads to longer travel times, redundant routes, and overlapping services.This inefficiency wastes time and energy and contributes to congestion on roads.Moreover, the lack of technology integration prevents the optimization of routes and capacity management.
This work examines the possibility of addressing these issues by implementing a smart crowd transit solution that can reduce waste in the transit system by utilizing drivers who are already on the road as occasional carriers of goods.We believe such a system can improve resource utilization and be more sustainable.
In this study, we accomplished several significant tasks.Initially, we developed an optimal package routing algorithm.Within this algorithm, we introduced the concept of a preference function, recognizing that time alone is not the sole parameter to consider.We introduced two significant additional parameters: travel distance and the number of OCs.Importantly, our algorithm is designed to accommodate the inclusion of more parameters in the future.Furthermore, we implemented the algorithm into a fully working system, OR-CS, and ensured that each sender's preference function is individually customized.This means that every sender benefits from a personalized adjustment to their route selection method, enhancing the overall effectiveness of the routing process.
Later, we created a general simulator that can check the performance of the OR-CS system on every city with any number of OCs and packages.Lastly, we conducted multiple simulations to assess the feasibility of the system.These simulations demonstrated the system's validity and ability to achieve the desired goal successfully.Namely, the simulations revealed that the system proved effective once the number of participating OCs surpassed a minimal threshold.It is worth noting that the threshold required was only 500 OCs, which is a relatively small number considering the average traffic load in medium or larger cities.As a result, achieving such numbers in a real-world setting should not pose a significant challenge.These findings highlight the potential for widespread adoption and successful system implementation in practical scenarios.Another interesting result is that the average cost per package decreases as the number of packages in the system increases.From a threshold of around 600 the average cost is steady and relatively low.
Currently, most transport deliveries are conducted by human-driven vehicles.The future of transportation could mean a less human approach, such as that supported by electric, self-driving cars, or drones.Although the OR-CS uses conservative means of transportation, it can also be used when using autonomous vehicles.The same vehicle can be efficiently used for driving people and multiple deliveries.Hence, a system that enables the utilization of vehicles for efficient deliveries will be needed.
The simulator described in this paper was built in a generic way that can be applied to every city.It would be interesting to apply it to different cities and see how the OR-CS performs under different cities' topologies, sizes, and traffic congestion.
In future work, we aim to enhance the applicability of our research to real-world settings by addressing several important aspects that were simplified in our current study.Specifically, focuses on accommodating the limited space available in SPs and OCs' vehicles and developing robust mechanisms to handle situations where drivers may change their minds after committing to picking up a package or deviating from their designated routes.Additionally, it will be beneficial to examine the practical way to combine OR-CS with automated parcel machines.
The proposed OR-CS system has several risks to be considered in future work.These include concerns about the security and trustworthiness of occasional couriers, liability in case of accidents or losses, potential privacy issues, variations in service quality, user adoption resistance, scalability limitations, regulatory and compliance hurdles, uncertain environmental impact, and safety concerns related to untrained or unvetted occasional couriers.Successful implementation will require careful planning, legal compliance, insurance coverage, background checks, and user education to mitigate these risks and ensure the system's viability.These enhancements will enable the crowd-shipping system to operate seamlessly and effectively in noisy and dynamic real-world environments, offering practical solutions to the challenges faced in the field of logistics and transportation.

Figure 1 .
Figure 1.Example of a TIMEEXPANDEDGRAPH.The graph presents a scenario with five SPs {1, 2, 3, 4, 5} and three drivers c 1 (marked green), c 2 (marked blue) and c 3 (marked pink).c 1 has a route 3 ⇝ 4 ⇝ 5 ⇝ 1, which starts at 12:00 p.m. c 2 has a route 1 ⇝ 3 ⇝ 2 ⇝ 4, which starts at 5:20 p.m. c 3 has a route 4 ⇝ 1, which starts at 13:40 p.m.The distance matrix between the SP appears to the graph's right.The orange edges describe the Station edges while the black edges describe the Route edges.

Figure 2 .
Figure 2. TIMEEXPANDEDGRAPH for a given package.Given the TIMEEXPANDEDGRAPH presented in Figure 1, and a package arriving at the origin SP: p o = 4 at time t o = 12:10, with destination SP: p d = 1, and prioritization: ⟨distance, #OC, time⟩.The rectangular vertices indicate the origin (red) and the destination (gray), while the gray edges are their respective temporary edges.The resulting route (output by Algorithm 2) is marked with (*) over the relevant edges.

Figure 3 .
Figure 3.The interface of the simulator.

Figure 4 .
Figure 4.A map of Ashdod, the stars are the SPs chosen for the simulator.

Figure 5 .
An example of the route the simulator created for an OC, after choosing the origin and destination SP randomly.(a) The optimal route between the origin and destination SPs.(b) The route connecting the origin and destination SPs after adding possible intermediate SPs.

Figure 6 .
Figure 6.Success rates of delivering packages as a function of the number of OCs.

Figure 7 .
Figure 7. Success rates of delivering packages as a function of the number of OCs for different amounts of packages.

Figure 8 .
Figure 8.The 14 SPs located in the north are represented as green dots, while purple dots represent the remaining SPs.

Figure 9 .
Figure 9. Success rates of delivering packages as a function of the number of OCs for different amounts of packages.

Figure 10 .
Figure 10.The effect of the number of packages on the payment of each package.The graph presents the average and the standard deviation of the maximum and the actual costs.
with O as the source node.10.Return the route found for vertex D