Simulation-Based Assessment of Hyperconnected Megacity Parcel Logistics

Abstract

Background: The concept of Hyperconnected Megacity Parcel Logistics (HMPL) was introduced in 2018 and aims to enhance the efficiency, responsiveness, resilience, and sustainability of parcel movements in megacities. However, evaluating such fundamental solutions presents challenges and requires a comprehensive understanding of all stakeholders and decisions involved. Methods: This study introduces a discrete-event agent-based simulation platform that encompasses critical stakeholders and addresses various levels of decision-making. This platform provides an opportunity to evaluate key decisions within an HMPL structure. Results: To demonstrate the capability of the simulator, we assess the impact of package routing and consolidation strategies facilitated by HMPL compared to traditional practices. Preliminary findings suggest that increased interconnection among nodes in HMPL reduces transit times, thereby enabling tighter customer delivery services. However, examining different consolidation heuristics reveals potential trade-offs between handling and shipping costs under fixed shipment schedules, prompting further investigation into dynamic shipment services. Conclusions: The findings of this study suggest that the benefits of innovative approaches in a complex environment, such as parcel logistics, cannot be evaluated in isolation from other decisions. Accurate assessment of the ultimate outcomes and underlying trade-offs requires multi-faceted models that incorporate all key variables.

1. Introduction

More than half of the world’s 8-billion population currently lives in cities, and this proportion is expected to climb above two-thirds by 2050. Already, 14% of the urban population lives in the 34 megacities with at least 10 million citizens [1,2]. City Logistics (CL) manages and performs the activities necessary to satisfactorily fulfill the demand for physical objects (goods, food, etc.) in urban environments, notably encompassing the urban first and last miles of the growing e-commerce sector. It is complex and costly, currently with low efficiency and sustainability.

Megacity Logistics (ML) is the largest scale and most complex in the overall spectrum of city logistics. It is generally characterized by the highest demand volume and density, the most convenience-demanding and time-sensitive customers, the most complex transportation infrastructure, the largest set of logistics and transportation service providers, and the heaviest traffic. Parcel Logistics (PL), on the other hand, involves satisfying the pickup, fulfillment, and delivery of orders consisting of smaller and lighter objects weighing less than 100 pounds and encapsulated in easy-to-handle containers (e.g., boxes, bags). PL is of the highest importance in urban environments, especially in megacities, where myriad small orders from/to myriad locations must be swiftly handled every day.

This paper focuses on Megacity Parcel Logistics (MPL), which faces the most complex city logistics challenges in the contemporary landscape, driven by urbanization, e-commerce growth, and evolving consumer expectations. One primary challenge is the surge in last-mile delivery and return demands, exacerbated by the rapid expansion of online shopping platforms. This leads to increased traffic congestion, pollution, and delivery inefficiencies in urban areas [3,4,5]. Additionally, the unpredictable nature of consumer behavior, such as varying delivery preferences and demand patterns, imposes significant logistical hurdles for parcel carriers [6,7]. Moreover, the rise of same-day and instant delivery services has heightened pressure on logistics providers to streamline operations while maintaining cost-effectiveness and environmental sustainability [8,9]. Addressing these challenges requires innovative solutions that integrate technology, strategic planning, and more efficient urban flow movements to optimize parcel logistics networks and meet evolving consumer needs.

The Hyperconnected City Logistics (HCL) conceptual framework, combining the City Logistics and Physical Internet frameworks, has been introduced as an alternative solution to the existing inefficient and expensive urban flow movements and to address the sustainability and resiliency challenges faced by logistics in cities [10,11]. Within the HCL framework, Hyperconnected Megacity Parcel Logistics (HMPL) focuses on parcel flow into, through, and out of megacities [12]. HMPL relies on an urban logistics web composed of multi-tier meshed logistic-hub networks mapped to geographically multi-tiered space clusters. Shipping a parcel from its pickup point to its delivery point in HMPL involves three fundamental processes: acquisition, transfer, and delivery. These three tasks, however, require the involvement of several entities, such as hubs and drivers, and necessitate a wide variety of operators to make decisions cooperatively and interactively.

Due to the inherent complexity of HMPL systems and the interconnected nature of various multi-stakeholder strategic, tactical, and operational decisions, providing a holistic assessment of the feasibility and added value of this new concept is challenging and has not been accomplished to date. To illustrate the complexity in assessing the feasibility and value of the proposed HMPL scenario, Figure 1 schematizes sample interactions between several decision domains in shipping a parcel, highlighting the intricate web of decisions and interactions necessary for effective HMPL operations.

The main contributions of this paper are (1) introducing a novel simulator-based methodological solution for holistic feasibility and value assessment of Hyperconnected Megacity Parcel Logistics (HMPL), demonstrating its capability to tackle the most challenging megacities while focusing on the highly significant parcel logistics spectrum; and (2) providing empirical results and insights from experiments investigating HMPL design and implementation in one of the world’s largest megacities, using the proposed simulator-based methodology to test various scenarios across strategic, tactical, and operational decisions.

The rest of this paper is structured as follow. Section 2 presents an overview of the relevant literature. Section 3 explains the general architecture of hyperconnected megacity parcel logistics illustrating the mutual connection between the key players through the domain model. It also introduces the proposed simulator framework, in a conceptual model, as a means for modeling the integrated city parcel logistics design and operations. Using the proposed simulator framework, two sets of experiments are conducted in Section 4 for assessing the hyperconnected network behavior. Both experiments rely on real data from a Chinese package delivery company. The first set of experiments compare the service level and time in the system for a traditional hub and spoke routing structure versus the introduced hyperconnected routing structure. The second set of experiments compare the handling costs and shipment efficiencies in a hyperconnected network structure for a number of different consolidation approaches. Finally, Section 5 presents the conclusion and avenues for future research.

2. Literature Review

Traditional package delivery systems are commonly designed based on a hub-and-spoke configuration, which was pioneered by Delta Airlines in 1955 [13] and quickly expanded to other industries across the world including parcel logistics [14,15,16]. The traditional hub-and-spoke configuration, however, has several drawbacks. Since every spoke is served by only one hub, the network is not resilient against hub failure. Moreover, enforcing all the spoke-to-spoke flows pass through the hubs, makes the capacity management at the hubs critical and increases the overall shipment time.

To tackle the resilience issue in traditional hub-and-spoke configuration, some studies have proposed a multiple-hub allocation structure [17,18,19] in which every spoke can be assigned to more than one hub in the network. Many of these studies, however, approach such structure as a backup plan in case of disruptions [13,20] and fail to assess how the presence of such links could impact the overall network flexibility and performance. Moreover, several studies have assessed the impact of inter-nodal shipments in a hub-and-spoke configuration and its benefit to saving total flow shipment costs [21,22].

Stepping beyond the traditional hub-and-spoke configuration, there are a variety of studies in the literature that assess the optimal design of a logistic network to better save in terms of transportation time and costs [23,24]. Crainic et al. were among the first to assess the shift from a single-tier to a two-tier delivery system [25]. They also modeled the demand uncertainty [26] and studied synchronized multi-trip multi-traffic pickup and delivery [27] under a 2-tier structure. When it comes to large and mega-cities, the use of multi-tier (more than two-tier) logistic networks can be justified [3]. Several studies have expanded the two-tier network to multi-tier [10,28,29] or have included other variations such as collection-and-delivery points [30]. In 2018, Montreuil et al. presented the first formal representation of the Multi-tier Urban Parcel Logistic Web which promises the capability for efficient and sustainable offering of faster delivery services across megacities [12] and has received attention from many scholars in the last years [11,31,32].

The innovative nature of the Multi-tier Urban Parcel Logistic Web has inspired further research and exploration of novel delivery network configurations. As it relates to network design, studies by Zhang et al. proposed a two-tier urban logistics network for e-commerce delivery, optimizing the location of urban consolidation centers and considering different vehicle types for the delivery process [33]. Kulkarni et al. investigated the resilience of hyperconnected network structures when faced with disruptions. Their research indicates a noteworthy improvement in the ability of these designed networks to withstand disruptions, compared to traditional logistics networks, with only a minor impact on performance [34]. In terms of hub design, Schwerdfeger and Boysen presented optimization-based design approaches for locating locker banks within the realm of omnichannel business-to-consumer hyperconnected logistics [35] and Buckly proposed a robotic gateway hub design well-suited to deal with the large flow and fast pace of parcels in a hyperconnected logistic web [36]. Due to the higher level of interconnectivity in the hyperconnected logistic networks, optimizing operational decisions tends to be even more challenging. Shang et al. investigated a new vehicle routing problem for citywide deliveries, integrating multi-distribution centers and various last-mile delivery options, aiming to minimize the total delivery cost and enhance the overall efficiency of the delivery network [37]. Orenstein and Raviv presented a simulation tool to design and operate the routing and scheduling of the vehicles within the hyperconnected service network [38].

An extensive body of research has investigated the potential for more efficient solutions in different domains of strategic, tactical, and operational design of urban parcel logistics [3]. However, despite the mutual impact of these domains on one another, only a few studies in the literature provide insights and analysis on the aggregate evolution of a logistic system over multiple involved decisions [39,40]. Even these studies are mostly small in scope and scale and/or only concerned with the interaction between a few core decision-makers, as such underplaying the inherent complexities and missing the critical insights on evolved dynamics in the mutual interaction between all involved parties.

Furthermore, the traditional optimization models fail to capture the scope and scale of the package delivery networks as a system, given their agent-based nature and the complex interaction between different decision-makers. Considering the large scale, high complexity, and fast dynamics of logistics operations in megacities, simulation tools play a more effective role in building such integrated platforms for assessing performance and enhancing operations in parcel delivery systems. Simulation also allows for evaluating a wide set of interrelated key performance indicators [41]. Several settings are introduced in [42] in which simulation modeling provides more benefits as compared to the optimization: in particular, (and as pertinent to the context of our study), where “the new concept does not exist and experimentation with a real-world model is too expensive or time-consuming”, and “when the problem is too complex that the outcomes are not simple and one sided”.

The majority of the agent-based simulation studies in the supply chain and logistics literature, however, are network-centric, failing to represent order processes at parcel granularity level and capture agents’ behavior [39]. This paper provides a multi-formalistic simulation model for urban parcel logistic operations combining different simulation approaches (flow, network, and behavioral). Furthermore, this study is the first of its kind to model urban parcel logistics as a multi-tier network, and as such, enables holistic assessment of the novel concepts of Hyperconnected Megacity Parcel Logistics and its Multi-tier Web introduced by Montreuil et al. [12], specifically as it relates to their capability for offering faster deliveries across megacities [10]. Designing a multi-formalistic simulator that embeds all different core decisions in last-mile logistics and can model network flow at parcel’s granularity, while being scalable enough to model real-world instances including thousands of hubs and millions of packages a day is not straightforward. Therefore, the main contribution of this study is to propose a scalable simulator platform that incorporates all critical decisions in last-mile delivery at a granular level and offers the flexibility to test various scenarios across strategic, tactical, and operational decisions.

3. Model Development

Following the structure presented in [43], we introduce the proposed simulation model through three stages: (1) explaining the Logistic Network and Resources, which represents the logistic system under study, its main components, and their behavior; (2) explaining the Decision Architecture, which provides a formulated and process-based representation of how core decisions are made in the simulated system and (3) the Simulation model, which details the modeling platform, coding language, and simulation dependencies.

3.1. Logistic Network & Resources

In the Multi-tier Urban Parcel Logistic Web (Figure 2), a city is geographically divided into Unit Zones, which depending on the demand density, may refer to an industrial park, an urban block or campus, a suburban community, or a high-rise in a dense business district. Within an urban territory, a Local Cell refers to a set of neighboring unit zones, and local cells themselves are further grouped to shape Areas. As shown in Figure 2, at the higher tiers of the network, urban areas are further grouped into Regions and Blocks which ultimately shape the World. In this study, our focus is on last-mile delivery, consequently bounding the geographical scope to urban areas. Unit zones, local cells and urban areas are each served by a set of hubs. At the lowest tier, Access Hubs are used as temporary storage for transitioning packages that are picked up or are going to be delivered at the unit zones; Local Hubs connect and serve local cells and finally, Gateway Hubs connect and serve urban areas.

In a standard parcel logistics system, a person/entity (called “Customer” hereafter) initiates package shipping requests through phone, online platforms, or in-person interactions with the delivery company. A package is a closed box which can contain one or several items. Each package has a predefined pickup and delivery point, dimensions (length, width, height) and weight, and is assigned a path when registered to the system. Packages are assigned unique identification numbers by which they can be tracked along their journey through the system. We consider two types of packages including Parcels and Containers:

• Parcel: a parcel is a unique item that is requested by a unique customer for shipment. As mentioned earlier, we consider three types of parcels: intracity, inbound intercity and outbound intercity.
• Container: a container is a package that may contain one or several packages(s). Each container has specific dimensions and a corresponding volume capacity that limits the number of packages that can fit into it. In line with HCL and Physical Internet, there is generally a limited set of modular container sizes [11].

In this network, we consider a dynamic service offering approach. When a customer submits information on the package he wants to send and the desired pickup window, the system generates a range of viable offers based on the pickup time and anticipated congestion in the network. From these feasible offers, the customer can select an option aligned with their preference, or decline and exit the system. Upon choosing a preferred delivery service, the package is logged into the logistics system, initiating its journey. An initial route is also assigned to the package, which might involve multiple hubs within the network as it travels from the pickup to the delivery point.

Depending on the size of an urban territory, serving pickup-delivery requests may require different sizes of hubs with different operational capabilities throughout the network. In general, less flow density close to the points of service (pickup/delivery) may require smaller hubs where the flow can seamlessly become aggregated; while at the higher tiers of the network where larger flows are being shipped, we may need larger and more equipped facilities to enable efficient flow de-consolidation and consolidation at large-scale [12].

Due to the relatively low volume of shipments in the first and last-mile logistics, economies of scale are a critical factor for saving costs. As such, we assume most of the hubs have a buffer as well which enables short-term dwelling of packages for aggregation toward subsequent common destinations; This is called freight or truck consolidation. Despite freight consolidation, parcels can be aggregated at a more precise level into containers that travel through several subsequent hubs altogether. Such grouping is called containerized consolidation.

Upon arrival of the packages at the hub (after being unloaded from a truck or dropped by a customer) the package is added to the hub buffer. The buffer is a general term representing a temporary storage space at the unloading docks or loading docks, a dedicated temporary storage space inside the hub, or a temporary space provided for package containerization/de-containerization. Next, if parcels within an inbound container are all heading toward the same subsequent destination, the container is moved to a buffer (which might be at the loading/unloading stage) to wait for a proper outbound truck; On the other hand, if the parcels within the inbound container are heading toward different subsequent destinations, the container is moved to a buffer (this could include shipment from inbound docks buffer stage to the temporary storage), and is opened at a proper time (de-containerized). The individual parcels may dwell for some time at the hub buffer until enough load toward their subsequent destination is aggregated or their target departure time is reached (whichever happens first) to be consolidated and containerized. The new containers will be then waiting in a buffer (which could be the hub’s outbound docks) to be loaded onto a proper truck.

Depending on parcel pickup and delivery locations, we also consider three types of parcels in the system including:

• Intracity Parcels: these are picked up from one unit zone in the city and transported to either the same unit zone or a different one within the city.
• Outbound Intercity Parcels: these are picked up from a unit zone within the city and, in the scope of our simulation, need to be delivered to one of the gateway hubs so they can be subsequently shipped to a different city.
• Inbound Intercity Parcels: in the scope of our simulation they are picked up from one of the gateway hubs and need to be delivered to one of the unit zones within the city.

Once the package route is established, it awaits collection by a driver for shipment to the access hub. Within the access hub, the parcel might be combined with other parcels bound for a shared subsequent destination, all fitting within standardized containers. Another driver then retrieves the container, transferring it to the next hub along the parcel’s journey. Upon the container’s arrival at the subsequent hub, if contained parcels have varied subsequent destinations, the container is opened and its contents are unloaded. These parcels are temporarily stored until consolidation with another batch. Alternatively, if all parcels share the same subsequent destination, the container bypasses the hub (without being opened), proceeding to the loading docks, and awaiting the next stage of transport.

We consider three types of drivers, including (1) couriers, who transfer packages between customers and access hubs, (2) riders, who transfer packages between access and local hubs, and finally (3) shuttlers, who transfer packages between local and gateway hubs. Figure 3 shows the different types of drivers operating at different tiers of the parcel delivery network.

Each driver uses a vehicle for moving packages throughout the network. Vehicles can be owned by the service provider, acquired under contracts through specific time windows, or requested on-demand whenever extra capacity is required. A combination of these cases is also possible and commonly applicable. At any point of time, a vehicle might be assigned to a specific driver and a task in the system, or stay idle (parked at the last visited hub) until a new request pops up. Only owned and contracted vehicles may remain in the system in an idle state; on-demand vehicles are released as soon as they finish their current task. We consider a heterogeneous fleet of vehicles with different weight and volume capacities and speed parameters. Vehicles’ speed varies depending on the distance to be traveled; with a higher speed considered for longer distances. This is a simple assumption to reflect the fact that traveling longer distances is usually made through highways/freeways in which case the average speed is usually higher compared to local trips which are mostly made through compact neighborhoods.

Upon a parcel’s arrival at its destination access hub, the container is unsealed, and the parcel awaits the delivery courier for transportation to the final delivery location. In instances where a parcel’s destination hub is a Gateway hub (applicable to intercity parcels departing the city), the container is unsealed, and the parcel is transferred to the sorting zone for intercity sorting. As the scope of this study does not encompass the intercity network, the parcel is exited from the system at this point, and relevant key performance indicators (KPIs) are gathered.

This complex system comprises various stakeholders, each needing to make well-informed decisions that align with the network as a whole. These decisions encompass aspects like logistic network design, service offerings, package routing, driver routing, and parcel consolidation, among others. In the subsequent section, we outline the logical structure, components, and processes that facilitate the implementation of the aforementioned simulation.

3.2. Decisions Architecture

As mentioned earlier, one of the main advantages of the proposed simulation model is its flexibility in modeling different network structures and decision mechanisms by separating the physical movements from the decision-making processes. The physical movements are modeled using discrete-event modeling where changes in an object attribute are modeled through discrete time steps often triggered by another discrete event. On the other hand, to be able to model the individual and local decision-making processes and their interactions, an agent-based modeling approach is used.

The hubs and vehicles are essential assets to the urban parcel logistics for handling and moving the packages. In order to plan and operate hubs and vehicles, a variety of reactive and proactive components are needed to take over actions and critical decisions, respectively. Reactive components are those who do not need intelligent decision-making capability but act according to the instructions they receive (for example drivers and couriers); while proactive components are tasked with making key decisions using a variety of methodologies and policies. Figure 4 provides an overview of the general framework of our target urban logistic system, different proactive and reactive components, objects, as well as the most important interactions between these components at an aggregate level.

As shown in Figure 4, the reactive and proactive components may interact based on different types of dependencies, including (1) pooled interdependence: where two activities are conducted in relative independence, but their combined output contributes to an overall joint goal, such as drivers, (2) sequential interdependence: where the output of one activity is the input to another activity, such as demand generators and demand managers, and (3) reciprocal interdependence: where the results of two activities serve as the mutual inputs for each other, such as demand managers, package routers, and vehicle routers. In the remainder of this section, we provide more details on the attributes and functionalities of each of these components.

3.2.1. Reactive Agents

The reactive components in the target urban parcel logistics system correspond to the general class of drivers. Drivers are the human resources who use vehicles to ship packages from one location to another in the logistic network. Similar to the vehicles, we consider three types of drivers including owned, contracted, and on-demand. To mimic real-life conditions, drivers are considered as separate entities from the vehicles, and therefore, a driver may operate different vehicles at different times and a vehicle might be used by different drivers at different times.

We consider different types of drivers for different tiers of the logistic web. Couriers use small-size vehicles (like two-wheel vehicles) and operate within unit zones, dealing directly with the customers; while Riders and Shuttlers use larger vehicles (trucks/vans) and move packages between access-local hubs and local-gateway hubs, respectively. One main operational difference in planning couriers versus riders and shuttlers routes is that although each courier is assigned to serve within a specific unit zone, the exact service locations (customers’ pickup/delivery point) are not known in advance. As such, courier routes cannot be optimized ahead of time. For the shuttlers and riders, however, since the service locations (i.e., hubs) are known and fixed, depending on demand uncertainty, a wide range of decision-making methodologies could be used to provide operational instructions; from the more sophisticated but less responsive offline optimization models to more data-driven and online decision protocols.

Except for the very short-distance pickup-delivery trips (where the package could be directly shipped from its pickup to its delivery point), a package is commonly shipped through a series of transfers between the hubs and the drivers. Along its journey from the pickup to the delivery point, the package is successively loaded to a driver, travels a distance with the driver and is unloaded at a subsequent hub, until it reaches its final destination. The package, therefore, may pass through several hubs and be handled by different drivers before it reaches its final destination.

Figure 5 illustrates the driver processes within the hubs. When a driver arrives at a hub/node, it is first scanned to find if there are any packages in his vehicle to unload; if yes, those packages are removed one by one from the vehicle. If there are no packages to unload, or all such packages are removed from the vehicle, the system checks if the driver’s shift is over; if so, it is then checked if the driver’s vehicle is empty, in which case, the driver is released from its task. If the driver’s vehicle is not empty, the system forces the driver to unload all packages on board even if they were not supposed to be unloaded at the current hub. These packages will be picked up by another driver later to continue their path to their next destination.

If the driver’s shift is not over, the driver receives instructions regarding their next destination. Besides the next destination, the driver also receives information on the packages to load and the route to take toward their next destination. If there are packages to load, those are put into the vehicle one by one. When the loading process is over or in case there are no packages to load to the drivers, they will travel toward their next destination. This whole process is repeated until the driver’s shift is over. A driver might be instructed to spend at least a fixed amount of time at each hub for planning purposes. Also, to fairly distribute several drivers serving the same tour (sequence of hubs) along their service area, extended dwell times may be imposed on a driver at a specific hub.

3.2.2. Proactive Agents

As explained earlier, reactive agents act based on the instructions they receive either as a fixed plan, a rule-based protocol, or a data-driven online command. All such mandates are provided by proactive agents. A proactive agent represents an intelligent decision-making system, like a computer, human, or combination of both that is responsible for making related decisions. One proactive agent may represent several underlying systems all working interconnected to provide an instruction.

To better handle the complexity of modeling the wide variety of involved decisions and their interactions in an urban parcel logistic system, we develop a decentralized decision-making framework, in which decisions are geographically decentralized but mutually informed and interconnected. In the network shown on the left side of Figure 6, the dark blue areas refer to unit zones; a cluster of nearby unit zones can form a local cell (indicated by red areas) and a set of local cells can form an urban area (shown in green). Relying on the concept of a multi-tier logistic web, we call each unit zone, local cell and urban area, a logistic element. Therefore, each logistic element may include several other logistic elements at its lower tier (if any) and might be contained in several other logistic elements in its higher tier (if any). Each arrow in Figure 6 indicates a path segment and a sequence of arrows identify an origin-destination path. The right side of Figure 6 shows how a path may transition between different tiers of the logistic network. This vertical containment includes both topological and operational features, and therefore, serves as an ideal basis for decentralizing the decisions and building the fundamentals for information sharing.

Based on this modeling approach, each logistic element corresponds to a set of decision-makers, including parcel and vehicle routers. Each logistic element decision maker is only responsible for the decisions in his own territory; however, to ensure decisions are efficient network-wide, the local decision-makers must be smartly interconnected through dynamically exchanging information. In Section 3.2.3 we provide more detailed explanations of the information integration framework over the logistic web.

In what follows, different types of proactive agents that are considered in the proposed urban parcel logistic model as well as their functionalities are introduced. Some of these agents are global and some are local entities given the decentralized network topology.

Customers

We assume each package is requested to be shipped by a unique customer, and therefore, batch shipments are not considered. This is a simplifying assumption, and in practice may not always hold; a customer may place several shipment requests simultaneously, or return to a system in the future to place another shipment request. When a shipment request for an intracity parcel is submitted, the corresponding customer receives a set of viable delivery offers based on the shipment specifications including its pickup and delivery point, its projected path, and the expected delivery speed of the systems at the time of request. From the set of offers received, the customer may select one based on his preferences, or deny placing an order and leave the system if none of the offers are desired. Customer behavior, price sensitivity, and desire for different delivery services can be defined using different rule-based, utility-based, or statistical models. When an offer is selected, the parcel is registered into the system and its delivery path and time are determined.

Unlike intracity parcels, for the intercity inbound and intercity outbound parcels, a pre-determined time-based fixed delivery window is considered. We rely on this assumption since in practice the major part of the journey for intercity parcels (more specifically the intercity portion) is planned by other stakeholders and is out of scope for urban parcel delivery.

To capture the size of a megacity demand for parcel delivery, we generate on the order of one million shipment requests per day on average. Parcels are generated based on a Poisson distribution with a rate $D_w\times {\lambda }_{i,j,d,h}$ where i and j represent the origin and destination zone/hub/city, respectively, d denotes the day of the week and h represents an hour of the day. $D_w$ is the total weekly demand which itself is computed based on yearly, monthly, and weekly seasonality factors retrieved from historical data.

Demand Managers

Demand managers are responsible for receiving new shipment requests and determining the shipment specifications if it was successfully registered into the system. We consider two types of demand managers including Intercity and Intracity demand managers. The Intercity Demand Manager is responsible for determining the delivery time at the customer location for intercity inbound parcels and at the outbound gateway hubs (within the city territory) for intercity outbound parcels. These delivery times are determined based on some rule-based time-dependent policies.

The intracity demand manager, however, has a more extensive set of responsibilities. It is responsible for receiving shipment requests from the customers (for intracity packages) or from the intercity demand manager (for intercity packages). After receiving the requests, it then determines the shipment path, schedule, and delivery time. For the intercity packages, the delivery window is pre-determined by the intercity demand manager. For the intracity parcels, however, this is conducted through a sequence of steps: (1) the intracity demand manager receives a shipment request from the customers or the intercity demand manager, (2) it collaborates with package routers to obtain a real-time estimate on the parcel’s projected path through the system and a worst-case delivery time estimate (based on a given robustness factor) given the capacity of the system at the pickup time, (3) the feasible set of offers are then provided to the customer to receive his preferences, (4) if the customer desires one of the delivery services received, their choice is sent to the demand managers who will finalize the parcels initial path and inform the customer about expected delivery time; if the customer rejects all the offers, their request is removed from the system.

Package Routers

As mentioned in the previous section, after the intracity demand manager receives a shipment request, it sends a query to the package routers to find a set of potential paths from the parcel pickup point to the parcel delivery point. An initial path will be assigned to every parcel registered into the system. Moreover, at any point along the package journey, its remaining path will be updated in case it falls out of the planned route or schedule. The green arrow in Figure 6 illustrates a typical path for a container shipped through different tiers of the network.

For routing packages through the network, we use a complete enumeration method. This methodology, however, has one downside: as the set of nodes in the network expands and/or nodes become more interconnected, enumerating all possible paths between an origin-destination pair could become heavily resource-expensive and practically infeasible for dynamic planning. To deal with this issue, we leverage the multi-tier structure of the logistic web to decentralize the route planning through the system. This novel approach helps to significantly reduce the computational burden of the dynamic route computation in two ways: (1) instead of assuming a complete network, it limits the inter-nodal links to the nearby nodes (within a zone/cell/area), and (2) allows to systematically decentralize the routing decision with the access to the global information, which reduces the size of the feasible space. To be more specific, for finding a set of paths for a package in the multi-tier meshed network, the following steps are made:

• First, a set of feasible sequences of logistic elements is determined (which is called a logistic path) for shipping the package from its current location to its delivery point. Figure 7 shows examples of logistic paths for intracity, intercity inbound and intercity outbound packages. For instance, for an intracity package, a logistic path might look like: (unit zone 1 → local cell 1 → urban area → local cell 2 → unit zone 2).
• Consecutive segments along a package’s logistic path are linked by hubs. These hubs are called pivot hubs as they connect two different logistic elements, enabling the package to move from one tier to its lower or upper tier in the logistic web. Figure 8 shows an example of a logistic path ($a\to b\to c$) for an intercity inbound package and illustrates the pivot hubs connecting different tiers. A package enters the first logistic element along its path through its pickup point and exits the last logistic element at its delivery point. The remaining transitions between consecutive logistic elements happen through the pivot hubs.
• Next, inside each logistic element along the logistic path, the shortest-time (or fastest) path is computed between every enter-exit hub pair. The enter hub is the one through which the package enters the current logistic element and the existing hub is the one through which the package exists from the current logistic element. Depending on the operating drivers’ cycles and expected travel times on each link, the fastest path between the same pair could be different at different times throughout the day.
• Finally, the origin-destination paths are built by attaching all possible combinations of the separate path segments from the package’s current location to its delivery point. The solid arrows in Figure 8 show two alternative paths for shipping the package from the Gateway hub to the customer location inside the unit zone.

The main advantage of the proposed routing approach is its scalability in terms of network dimensions and connectivity. After a path is built, an expected trajectory for package arrival at every vertex along the path is computed. This is conducted based on a series of time-based statistical distributions for the travel times (between every hub pair) and processing times (at every hub in the system) that are dynamically learned and updated through time (the information integration and sharing features are explained in more details in Section 3.2.3).

To determine time trajectories for a given route, consider parcel p as it moves through a series of vertices $\{v_0,v_1,\dots ,v_n\}$, starting from its origin at vertex $v_0$ and concluding at its destination at vertex $v_n$. These vertices may correspond to hubs or specific geographical coordinates associated with customer residences or workplaces. Let $t_{p,0}$ denote the time when parcel p is prepared for pickup at vertex $v_0$. Furthermore, we denote ${\mu }_{i,t}$ and ${\sigma }_{i,t}$ as the mean and standard deviation of shipping times between vertex $v_{i-1}$ and $v_i$ when the vehicle departs from $v_{i-1}$ at time t. Correspondingly, ${\mu }_{i,t}^{\prime }$ and ${\sigma }_{i,t}^{\prime }$ represent the mean and standard deviation of processing times at vertex $v_i$ for parcels arriving at that vertex at time t. These data are presumed to undergo continuous monitoring, learning, and logging as they evolve with the system’s performance during different daily hours. By assuming a normal distribution for both processing and shipping times and introducing $\rho$ as a parameter for robustness, we can compute the Expected Time of Arrival ($ETA$) and Target Time of Arrival ($TTA$) for parcel p at vertex $v_i$ with the help of the following equations:

$$\begin{array}{c}ET{A}_{p,i}=ET{D}_{p,i-1}^E+{\mu }_{i,ET{D}_{p,i-1}^E}\end{array}$$

(1)

$$\begin{array}{c}TT{A}_{p,i}=ET{D}_{p,i-1}^T+{\mu }_{i,ET{D}_{p,i-1}^T}+\rho {\sigma }_{i,ET{D}_{p,i-1}^T}\end{array}$$

(2)

where $ET{D}_{p,i-1}^E$ and $ET{D}_{p,i-1}^T$ represent the Expected Time of Departure for parcel p from vertex $v_{i-1}$ when not accounting for the standard deviation in hub processing time and when considering it, respectively. These values are computed as follows:

$$\begin{array}{c}ET{D}_{p,i-1}^E=ET{A}_{p,i-1}+{\mu }_{i-1,ET{A}_{p,i-1}}^{\prime }\end{array}$$

(3)

$$\begin{array}{c}ET{D}_{p,i-1}^T=TT{A}_{p,i-1}+{\mu }_{i-1,TT{A}_{p,i-1}}^{\prime }+\rho {\sigma }_{i,TT{A}_{p,i-1}}^{\prime }\end{array}$$

(4)

To achieve a specific service level, each parcel p is only offered services with delivery times exceeding $TT{A}_{p,n}$, the fastest estimated arrival time for parcel p on its origin-destination route. Let $D_p$ represent the promised delivery time for parcel p at its destination. The slack time $S_p$ is then calculated as $S_p=D_p-TT{A}_{p,n}$. We define $TT{D}_{p,i}$ as the target departure time from vertex i for parcel p to ensure timely arrival at its final destination. To utilize the slack time in determining parcels’ $TTD$ at each vertex $v_i$ along their route, we proportionally distribute this extra time among different segments of the parcel’s path using the following formulation:

$$\begin{array}{c}\hfill TT{D}_{p,i}=ET{D}_{p,i}+S_p\times \frac{TT{A}_{p,i}}{TT{A}_{p,n}}.\end{array}$$

(5)

Although the $TTD$ is a very helpful measure for avoiding parcel delay, in some cases it is too conservative. The system needs to have a more clear estimate of how late a parcel is versus its planned schedule to command proper preventive actions. Thus the Latest Time of Departure ($LTD$) is computed for the parcels as follows (which informs the latest time a parcel should depart from a hub after which with a high chance it is going to be late at its final destination):

$$\begin{array}{c}\hfill LT{D}_{p,i}=ET{D}_{p,i}+S_p.\end{array}$$

(6)

Vehicle Routers

Each logistic element has a vehicle router as well. A vehicle router decides on the route that each vehicle takes, manages the acquisition and release of required drivers and vehicles (in communication with the resource manager), tracks the working shifts for drivers, and assigns specific pickup∖delivery packages or re-positioning hubs to the drivers. Depending on if the logistic element is a unit zone, local cell, or urban area, a vehicle router may deal with couriers, riders, or shuttlers, respectively.

For this study, shuttle cycles are optimized offline, given the average flow through the network, and using the methodology introduced in [44]. To account for demand seasonality and flow pattern throughout the day, the shuttle’s activity throughout a day is divided into three regimes: (1) morning regime from 5 am to 11 am, (2) midday regime from 9 am to 6 pm, and (3) afternoon regime from 12 am to 12 pm. To design shuttle cycles, a path is first generated for each commodity in each regime using an IP-based formulation aimed at minimizing (variable) cost of the arcs while maximizing the consolidation opportunity in the network. Given the initial set of commodities routes obtained at phase 1, an IP model is used to generate cycles that provide the required minimum truck coverage for the arcs used by commodities paths while incurring the minimum cost. Next, commodities paths are restructured to find the shortest time-feasible path for each commodity on the cycle network built on each regime. Finally, a proper transition between cycles in consecutive overlapping regimes is determined [44].

Similar to shuttlers, rider routes are designed in multiple regimes (8 am–4 pm and 4 pm–11 pm) to adapt to the demand seasonality. Riders provide shipping capacity to move packages between access hubs and local hubs. Each route starts at a depot (in this case, a local hub), serves several pickup/delivery locations, and ends at the depot. Rider cycles are designed offline, considering the average flow, and using a two-stage optimization model introduced in [45] which is aimed at minimizing the number of riders and the average parcel transfer time.

Courier’s operations involve more dynamics compared to the riders and shuttlers. Couriers serve unit zones by picking up and delivering packages at customer locations. Since the pickup and delivery locations and the time packages arrive in the system are not known preliminary, couriers must be routed dynamically to be utilized at their best capacity. In this study, we use a simple first-come-first-served policy for serving packages. Furthermore, every time a package is registered to a unit zone for pickup/delivery, it is assigned to a courier with the least load-to-serve to ensure fairness.

The designed rider and shuttle cycles, also include information on the number of drivers and the type of vehicles operating on each cycle. Based on this information, each logistic element sends requests (to the Resource Manager) for the proper number and type of drivers to be assigned to the cycles in each regime.

Resource Managers

All drivers and vehicles, when added to the system, are registered in a directory that will be managed by the resource manager. The resource manager keeps a record of every driver and vehicle specification and has access to their current status (working/idle), current location, and upcoming tasks. The resource manager receives requests from the vehicle routers for seizing specific numbers and types of drivers and responds to the requests based on the availability of resources and the specific resource allocation protocols (for example allowance of using on-demand resources and any limit associated with that).

In order to find and assign a driver (and a vehicle) to a task, the resource manager first searches for idle vehicles (of proper size) near the point of request (based on an input neighborhood distance threshold). If no vehicles of proper size exist in the vicinity to the point of request, depending on the system preferences, an on-demand vehicle might be acquired or the request is denied. When the vehicle is determined, the resource pool manager searches (this time at a predefined distance to the vehicle) to find any free driver with the target specification (courier/rider/shuttler). If one is found, the vehicle will be assigned to the driver. The driver picks up the vehicle and then moves toward the point of request. Similar to vehicles, if no driver with the target specifications exists in the vicinity of the vehicle, one might be requested on demand. We also assume that the time for the driver to reach the vehicle is negligible.

Hub Managers

Each hub has a manager that performs several fundamental tasks. One of the main responsibilities of the hub managers is monitoring packages that pass through the hub, which includes (1) checking packages arriving at the hub to ensure they are on the right path and schedule, (2) continuously tracking packages sitting at the hubs to guarantee their timeliness, and (3) taking corrective actions if a package falls out of its planned route or schedule. In the proposed simulator, we assume misrouted (or lost) packages are re-routed and delayed packages are put in priority for being loaded to the first arriving truck that heads toward the package’s next destination.

The hub managers also play a crucial role in consolidating and containerizing packages. This involves prioritizing parcels for loading based on their scheduled departure times from the hub, grouping parcels with similar service requirements and shared destinations, and placing these groups into appropriately sized modular containers. Containerized consolidation enables parcels to skip the sorting process at multiple intermediate hubs and offers substantial advantages in terms of reducing handling and transit costs [46].

3.2.3. Information Sharing and Integration

Many of the policies and methodologies, introduced in the previous sections, for making critical decisions within the urban parcel logistics system heavily rely on live network data availability. Key parameters, including hub processing times at various hours of the day and travel times along routes, are initially established or computed and then dynamically updated during the simulation process. As packages traverse through hubs or drivers travel along routes, pertinent data are collected and stored for updating parameter distributions. Consequently, decisions are continuously informed by the latest data, reflecting the system’s recent performance whenever they need to be made.

To make the storage and access to this large pool of data feasible, we leverage the web structure of the network and the agent-based modeling features, to track the information in a distributed manner and save it locally while providing access globally and in real-time. Figure 9 shows the difference between a centralized and decentralized network in terms of data storage and access, responsiveness, and decision-making scale and complexity.

Such real-time information can bring many advantages to the system specifically when making real-time decisions. Most of the decisions made in the system are distributed between local agents, and therefore, each individual agent does not need to have access to all the information across the system. Access to such large pools of data not only is not necessary but also makes it time-expensive to find relevant information and almost impossible to make dynamic decisions. Instead, we collect data inside each logistic element and also inside each logistic hub. Due to the vertical containment of the logistic elements, the data are accessible between overlapping logistic elements and thus throughout the network by simply knowing the correct path to the data storage location (very similar to the package routing protocol). This structure is not only efficient in terms of live data tracking and storage, but also fast for data retrieval upon receiving a query.

In previous sections, we introduced time metrics such as ETA, TTA, TTD, and LTD, and described how they are computed for each hub along a package’s route after the journey commences. As the package begins its transit and progresses through the system, these data are continuously updated at each intermediate hub. Additionally, package arrival notifications are dispatched in advance to hubs along the package’s route and are dynamically adjusted in response to any changes. Similarly, for each vehicle traversing the system, real-time updates are dispatched ahead of time to inform hubs along the route about expected arrival times, vehicle and driver details, and the parcels on board. As previously mentioned, hub managers utilize this information when strategizing parcel consolidation and containerization.

3.3. Simulation Model

To model the urban parcel logistic system introduced in Section 3.2, we use the architecture presented in [47] and propose a simulator framework that relies on the general system’s definition and is independent of any specific urban parcel logistic configuration (see Figure 10). Such an architecture allows for a highly flexible framework that can simulate various scenarios with different strategic, tactical, and operational configurations. The knowledge base in Figure 10 refers to all the scenario-specific information corresponding to a user-defined configuration (Inputs). Through a conversion process, these data are translated into a language understandable by the simulator framework, creating the simulation environment. The output of a run on a simulation environment is a set of predefined key performance indicators represented through logged data files and dashboard visuals.

The simulator’s general framework is designed based on several key components (illustrated in Figure 11). Following the previous section, these components are categorized into three main groups, proactive agents, reactive agents, and objects. The main proactive agents in the designed framework correspond to the Customers, Demand Managers, Hub Managers, and Logistic Element Managers. The reactive agents refer to the general class of drivers that are used for transferring packages between hubs/customers. Finally, objects include Hubs, Vehicles, and Packages.

Each main component of the system extends into several other components of different types which in the coding language are called sub-classes. Figure 11 shows different sub-classes under each component of the framework which are explained earlier in this section.

The model is constructed using AnyLogic simulation software, version 8.8.1. AnyLogic was selected due to its proficiency in combining various simulation libraries, encompassing discrete-event, agent-based, and system-dynamics methodologies. AnyLogic employs Java as its foundational language, which allows for the smooth integration of optimization models through the Cplex library. An additional significant advantage of AnyLogic is its capacity to interact with a wide array of software programs, facilitating seamless input and output data exchange.

4. Experimental Study

In this section, we use the proposed simulator framework to explore the innovative concept of a hyperconnected logistic web and evaluate its performance across a variety of routing and containerized consolidation strategies. The modular design of the proposed logistic web enables the presentation of a traditional case study in each experiment to contrast against more sophisticated solutions relying on the novel concept of the logistic web.

4.1. Assessing Different Package Routing Strategies

In this section, we assess the operational performance of two parcel logistic scenarios that correspond to different degrees of network hyperconnectivity in terms of package routing. In the first scenario, which represents the conventional practice commonly used in today’s last-mile delivery, all the parcels have to travel to the highest tier of the network to be consolidated with other packages and then sent back to the lower tiers of the network for last-mile delivery. Although this approach creates significant potential for flow consolidation and transportation cost savings, it falls short of meeting tight delivery services by imposing unnecessary travel to the higher tiers of the network. On the contrary, the second scenario allows for short-cutting parcel paths by horizontally shipping between nearby hubs without sending parcels to higher tiers of the logistic network.

Using the proposed simulation technology in Section 3, in this set of experiments we assess the two different routing strategies mentioned above, with respect to the average pickup to delivery time as well as the logistic system’s capability in offering tighter services to the customers.

4.1.1. Scenario Design

Figure 12 presents schematic and geographical representations of the two network configurations used in our experimental studies. These networks are constructed based on real data from a prominent parcel delivery company’s first and last-mile operations in a major Chinese megacity. Both networks follow the multi-tier meshed network concept integrated into our framework, encompassing unit zones, local cells, and urban areas which are served by access, local, and gateway hubs, respectively. For the sake of comparison, we maintain identical unit zone territories, including the same number and placement of access, local, and gateway hubs in both scenarios. The primary distinction between these scenarios lies in the organization of zones into local cells and the allocation of access hubs to zones and local hubs to local cells. As illustrated in Figure 12, unlike scenario 1, scenario 2 involves multiple access hubs serving each unit zone and multiple connections between access hubs and local hubs. Furthermore, scenario 2 allows the lateral shipment of packages between nearby hubs across all network tiers. In terms of vehicle routes, scenario 1 implements a meshed network only at the highest tier, while scenario 2 extends this meshed network concept to all network tiers. The package routes in scenario 1 represent the traditional Hub and Spoke structure, while scenario 2, offers a hyperconnected routing strategy enabled by the multi-tier network topology.

We generate one million packages on average on a daily basis to mimic the scale of megacities. Moreover, we consider eight different delivery service offers including (1) 2-h, (2) 4-h, (3) 6-h, (4) same-day by 6 pm, (5) same-day by 8 pm, (6) next-day (by next day noon), (7) standard (by next day 8 pm), and (8) economy (by 3’d day noon). To better demonstrate the various configurations’ effectiveness in providing and fulfilling tight delivery services, this study assumes that customers consistently select the fastest available offer.

In terms of scale and scope of the model, both scenarios include 1296 access hubs, 49 local hubs, and three gateway hubs. The geographic region under study is divided into 3469 unit zones, which are further grouped into 49 and 90 local cells for scenarios 1 and 2, respectively. Furthermore, for both scenarios, all the local cells are grouped into one urban area. Based on working shifts, there might be a different number of drivers operating at any specific time of the day, with a maximum of 11,137 courier agents, 1406 rider agents, and 586 shuttler agents working simultaneously. To be fair on the comparison, we consider the same number of drivers of each type in each working shift for both scenarios and do not include third-party and on-call drivers. Figure 13 shows a screenshot of the simulated network with yellow, green and blue hubs corresponding to gateway, local, and access hubs, large trucks showing the shuttlers, small trucks showing the riders and the human icons indicating couriers.

Given the average hourly flow between origin-destination nodes, the shuttler routes are generated using the algorithm introduced in [44], and rider routes are generated based on the optimization model in [45]. Due to the uncertainty in pickup and delivery locations within the unit zones, courier routes cannot be planned in advance; instead, as explained in Section 3, a simple first-come-first-served policy is used to assign couriers to the emerging pickup and delivery requests.

Given the information on the package path and considering the signals a hub receives from arriving trucks, we use a greedy heuristic for the dynamic consolidation and containerization of parcels which tends to group parcels based on their service features and a furthest common destination with enough volume to justify the use of containers.

We run both scenarios for eight consecutive days, leaving the first day for the simulator warm-up period. In what follows, we summarize the key performance indicators.

4.1.2. Simulation Results

In what follows, we explain two key performance indicators (KPI), with the first KPI directly reflected in the network’s revenue and the second KPI affecting the network’s cost. Figure 14 shows the first KPI which is the share of offered services to the customers for scenarios 1 and 2. To gain better insights into each system’s shipping capability, this measure is presented separately for parcels with different relative pickup and delivery locations (withinZone, withinCell, and withinArea). As the results suggest, the network in scenario 2 is capable of offering tighter services in all of these three categories, which is explained by the possibility of lateral shipment between nearby hubs at the lower tiers of the logistic web.

The second KPI measures the duration of time parcels spend in the system, which translates into the respective shipping, handling, and storage costs. Figure 15 shows the average time in the system for parcels with different delivery service categories in scenarios 1 and 2. Besides considering the pickup and delivery location category, this KPI is presented separately for different service categories, including sameDay (2-h, 4-h, 6-h, same-day by 18 and same-day by 20) and nextDays (next-day, standard, and economy services). As we see in Figure 15, in scenario 1, the average time in the system for all service categories with delivery within nextDays is significantly higher than in scenario 2, as the system is loaded beyond its capacity. Moreover, the simulated network in scenario 2 reaches a steady state in less than two days, indicating the superior capability of this network in handling the same demand volume. As the figure shows, no sameDay delivery service was offered for withinZone parcels in scenario 1.

4.2. Assessing Different Package Consolidation Strategies

Using the developed simulator explained in Section 3, in this section, we examine the operational cost of the hyperconnected network under different consolidation strategies. We consider the same logistic network presented in Section 4.1 with around 1 million shipment requests per day. Furthermore, the parcel’s weight, length, width, and height are generated from a multivariate normal distribution based on the real data from the company under study.

As outlined in Section 3, the simulator facilitates seamless communication between trucks and the hubs along their routes, enabling the real-time exchange of anticipated arrival times at each stop. Additionally, each parcel follows a predefined route within the network and possesses a Target Time of Departure ($TTD$) from each hub along its journey to ensure on-time deliveries.

Within the hubs, individual parcels await their turn for the sorting process, which is orchestrated by the hub Operating System (OS) at the appropriate moment. The hub OS factors in information about arriving trucks and the specific service attributes of parcels, including their $TTD$, to dynamically prioritize them for containerized consolidation. This dynamic prioritization ensures that parcels with the highest importance are selected for sorting. Once the list of parcels, each with its own priority, set to travel on the next incoming truck is finalized, it is passed on to the consolidation and containerization modules. The consolidation module determines the next destination for parcel consolidation, while the containerization module groups parcels into containers that may vary in size (see Figure 16). During each decision cycle, all high-priority parcels must be assigned to a container for transportation on the next truck, while lower-priority parcels can be flexibly utilized to maximize the fill rates of priority containers, whenever feasible.

Figure 17 provides a straightforward example illustrating the hub’s Operating System (OS) operation. Let us assume that at time $T_0$, the hub’s IS receives a notification that truck $m_1$ is en route to the hub and is scheduled to depart from the current hub at ${\tau }_{m_1}$. The OS already possesses estimates for the arrival and departure times of other trucks. Further, suppose that truck $m_2$ is also on its way to the same next destination, denoted as d, with an estimated departure time of ${\tau }_{m_2}$. We have three parcels, $p_1$, $p_2$, and $p_3$, located at the hub, each having a Target Time of Departure ($TTD$)—$TT{D}_{p_1}$, $TT{D}_{p_2}$, and $TT{D}_{p_3}$, respectively, all heading toward destination d as their immediate next stop.

In this example, the OS determines that parcels $p_1$ and $p_2$ should be prioritized for shipment with truck $m_1$ since their $TTD$ is earlier than the expected departure time of the second truck. Parcel $p_3$ on the other hand is of lower priority for sorting at this time and can wait for truck $m_2$. It is worth noting that although not on the priority list, parcel $p_3$ might still be shipped using the same fleet (to enhance container fill rates) if the container(s) containing parcels $p_1$ and $p_2$ have available space.

4.2.1. Scenario Design

In current practice, packages oftentimes are either grouped based on their immediate next destination or, in more sophisticated cases, based on some common destinations decided either based on the historical flow of parcels throughout the system or an expert’s judgment. In this section, we first introduce two simple protocols for grouping and containerizing parcels, lying at the two extremes of all-sorting and no-sorting at intermediate hubs. Next, a top-destination policy is introduced which leverages network flow direction for deciding on parcel consolidation destination. These will be used as baselines for comparing against the savings achieved by the more sophisticated FFBG policy. We embed this heuristic together with the FFBG methodology into the proposed agent-based discrete-event megacity logistics simulator to assess the benefits of containerized consolidation under the dynamics of a typical parcel delivery system operating on a hyperconnected logistic network.

Policy 1 and 2: Next and Final Destination Consolidation

The initial policy, known as the Next Destination (ND) policy, focuses on consolidating each parcel towards its next immediate destination. Under this policy, parcels are shipped in containers and undergo sorting at each hub they pass through. In contrast, the Final Consolidation (FD) policy designates the last hub on a parcel’s journey as its consolidation destination. After parcels are grouped according to their consolidation destinations, the consolidation algorithm (Algorithm A1) is utilized to optimize the efficient packing of each parcel group into containers. In the literature, this problem is commonly known as the Variable Size Bin Packing Problem (VSBPP). It is important to note that VSBPP can be transformed into the classical bin packing problem, a problem known to be NP-hard in the literature [48,49], when only one bin size is permitted. Consequently, the VSBPP is also recognized as NP-hard.

The first step in Algorithm A1 is to pick a proper set of container sizes to assign to the parcels heading toward each consolidation destination. This is conducted by calling Algorithm A2. After the parcels are grouped into containers, Algorithm A1 searches to find the non-priority parcels that can fit into each container to increase its fill rate. The fill rate is measured in volume as we found parcel volume is a more dominant constraint in our data.

There are several well-known bin-packing heuristics in the literature including First-Fit (FF), Best-Fit (BF), First-Fit-Decreasing (FFD) and Best-Fit-Decreasing (BFD). Johnson et. al. have shown that FFD and BFD have superior performance compared to the FF and BF policies [49]. Furthermore, in the context of our problem, and in a simulation-based study conducted by Sarraj et. al. on interconnected logistic networks, they show that FFD and BFD have a very similar performance; FFD requires a significantly less computational power [50]. Therefore, in this study, we use a variation of the first-fit decreasing bin-packing model for dynamic containerization of parcels into containers of modular sizes. The algorithm is modified to adapt to multiple container sizes. The First-Fit Decreasing (FFD) heuristic is a widely recognized algorithm utilized in solving the one-dimensional bin packing problem. This approach adheres to a straightforward principle: it arranges items in ascending order of their sizes. Subsequently, starting from the largest item, it sequentially examines the bins from the first bin that was opened to the last one. If the item can be accommodated within a specific bin, it is assigned to that bin. Conversely, if the item cannot fit, a new bin is created and the item is placed in the newly created bin [51].

To solve the modular size bin packing concerned in this study, we need to modify the original FFD algorithm to take into account variable bin sizes. Furthermore, we define a minimum utilization threshold to encourage using smaller bins for smaller loads and avoid creating bins with unnecessary empty space. As mentioned before, in this study, we deal with volume-based packing, and therefore, a maximum utilization threshold is also defined to account for item dimension compatibility.

The modified heuristic starts by sorting the container sizes as well as parcels from the largest to the smallest volume. Then, we start with the container with the largest volume capacity, and as long as the total volume of remaining parcels is more than the minimum allowable utilization of the specific size container, we check the unpacked parcels (in descending order of their volume) and see if they fit into the opened container. If the remaining volume of parcels does not meet the container minimum utilization threshold, we still allow for using that specific container size if either of the following conditions holds: (1) if the current container is the smallest container we can use, (2) if at least one of the remaining parcels does not fit into a smaller container, and (3) if it is still cheaper to pack remaining parcels into this larger size container compared to the set of smaller size containers. If none of these conditions hold, we remove the current size of the container and move on to the immediate next (smaller) container size. The pseudo-code in Algorithm A2 represents the logic of this heuristic.

Both the ND and FD policies come with their drawbacks. The ND policy does not allow parcels to skip the sorting process, while the FD policy is likely to result in smaller and underutilized containers due to the frequent shipment of small volumes of goods between numerous origin-destination pairs.

In the following subsection, we introduce another benchmark consolidation strategy called the Top Destination consolidation heuristic. This approach aims to group parcels based on a shared next destination that is anticipated to receive substantial flows from the current hub.

Policy 3: Top Destination Consolidation

In the Top Destination (TD) consolidation policy, each hub h within the network is associated with a select group of destination hubs that experience the highest shipment volumes passing through hub h. These data are meticulously logged on an hourly basis and remain dynamic, continuously adapting through ongoing monitoring of parcel flows within the network.

In the dynamic parcel consolidation process at hub h, a parcel’s consolidation destination is ascertained as the farthest hub along the parcel’s route which qualifies as a top destination for hub h. In cases where none of the hubs along the parcel’s path corresponds to hub h’s top destinations, the parcel is consolidated toward its immediate next destination. After determining the consolidation destinations for all parcels, the grouping of each batch into appropriately sized containers is executed using Algorithm A1.

Despite its apparent simplicity, a TD policy has its own set of limitations. Firstly, it places considerable demands on computational resources to calculate and potentially update the top destinations for hubs on an hourly basis. Secondly, determining the optimal number of top destinations is somewhat subjective and relies on expert system knowledge. The actual value can vary significantly for each hub, making it a challenging parameter to establish. Lastly, this policy has the potential to exacerbate congestion within the network by channeling the flow predominantly toward popular hubs. Nevertheless, since parcel routes are reevaluated at each stop to ensure the fastest path and hub processing times are dynamically adjusted based on the flow, it is assumed that parcels will naturally divert away from heavily congested hubs. Consequently, the impact of the third limitation is anticipated to be mitigated.

Policy 4: Backward Greedy Containerized Consolidation

In this algorithm, parcels are first grouped based on their final destination. Next, all parcels destined for the same consolidation destination will be packed into containers of standard modular sizes (in terms of volume capacity). After parcels are containerized toward their final destination, we compute the cost of packing for each container, given the container size, parcels loaded to that container, and container path, using the logic shown in Figure 18. The container cost includes the parcel sorting, container filling, and container loading costs at the origin hub, container unloading, cross-docking, and loading costs at intermediate hubs, and container unloading and emptying costs at the destination hub. It also includes a penalty cost associated with container empty space. As mentioned before, the penalty cost is charged proportional to the number of hubs along the container path such that the longer the container path, the larger the penalty charged, respectively.

The next step is to check if cost savings can be achieved by backtracking and merging parcels into containers destined for a closer destination along the parcel path. To do so, we first group containers based on their parent hub. Next, we sort all the containers destined for the same parent hub in descending order of their cost per unit loaded volume. Then, starting with the container with the largest cost per unit volume, we temporarily make all its content destined for the parent hub and recompute the containerization cost toward the parent hub (which now sorts more parcels and crossdocks fewer containers) and the impacted child hub (which now sorts fewer parcels). We store the container index as well as associated savings (if any) compared to the original solution and move on to the next container on the list. For the second container, we add its content to the content of the first container and all the parcels that are already destined to the target parent hub and recompute the containerization. When the savings associated with all the container indices are computed and stored, we pick the index with the largest savings and update the containerization and consolidation decisions accordingly. If no positive savings were identified, we add a copy of the remaining containers to the parent hub so that they can be considered for backward merger toward the parent of the current parent hub as well.

At every step, we store the minimum cost destination for each container so that when a backward merger is being assessed, we can compare the cost before and after the change. The backward merger continues until no backward merger is possible (which is when we arrive at the parcel’s immediate next destination). Besides looking at costs, we also consider hub sorting and crossdocking capacity when assessing savings for a specific backward merger. In other words, we only consider a backward merger of a set of containers if the parent hub has enough sorting capacity to handle the contained parcels. Also, we may impose a backward merger, with zero or negative savings, if that helps resolve violations in the xdocking capacity limit at the parent hub or sorting capacity limit at the child hub. The pseudo-code in Algorithm A3 summarized the greedy heuristic algorithm that was explained above.

In the upcoming section, we evaluate the effectiveness of the FFBG heuristic in comparison to other benchmark approaches including Next and Final Destination as well as the Top Destination policy. The simulator incorporates each heuristic policy, and the results are documented for an 11-day simulation run, reserving one day for the initial warm-up period. It is assumed that all other logistical and operational aspects, such as network configuration, driver count, routes, capacity, and demand volume and distribution, remain consistent across all scenarios.

4.2.2. Simulation Results

Figure 19 displays the total daily handling costs for various consolidation and containerization scenarios, such as ND, FD, FFBG, and TD, considering both 25 and 50 top destinations per hub. We conducted an 11-day simulation for each scenario (with the first day as a warm-up), and the reported values are the daily averages for the subsequent 10 consecutive days.

The bottom part of Figure 19 details the assumptions related to container types, dimensions, and their respective expenses. These figures represent the average costs incurred at the local hubs. For access and gateway hubs, these costs are multiplied by a factor of 1.3 and 0.7, respectively, to account for variations in handling efficiency at larger hubs.

The findings indicate that the ND policy results in higher handling costs when compared to other consolidation policies. In contrast, the FD and FFBG policies exhibit the lowest total handling costs because they allow more parcels to bypass the sorting process. Furthermore, the pairwise T-test results (see

Table 1. p-value for scenarios’ pairwise t-test (given 10 samples for each scenario).

Scenario pair	ND, TD_25	TD_25, TD_50	TD_50, FD	FD, FFBG
p-value	$4.39\times {10}^{-16}$	$9.56\times {10}^{-5}$	$6.61\times {10}^{-5}$	$1.01\times {10}^{-10}$

) demonstrate that the performance of the FFBG policy significantly outperforms the FD and other policies (p-Value $<0.05$). Additionally, the performance differences between each pair of consecutive scenarios are statistically significant.

In Figure 20, the dark gray line illustrates the proportion of parcels that circumvent the sorting process at each hub within the various scenarios. The findings point to a delicate balance between opting for larger containers and the percentage of parcels that necessitate sorting. Smaller containers come at a higher per-item cost but enable a greater volume of crossdocking, resulting in more substantial savings in handling expenses.

Furthermore, the cost savings in unloading, loading, and crossdocking associated with the adoption of larger containers in the FFBG policy outweigh the additional sorting expenses when compared to the FD policy. As a result, the FFBG scenario emerges as the most cost-effective option overall, as depicted in Figure 19.

The TD policies, which encompass both total handling costs and the container types used, fall between the ND and FD policies. When there are fewer top destinations per hub, the model’s behavior tends to resemble that of the ND policy, whereas an increase in the number of top destinations tilts the results in favor of the FD policy.

While employing smaller containers can yield handling cost benefits, it can also impact the overall truck space needed for parcel shipments. Let $v_{m,a,t}^C$ represent the total container volume and $v_{m,a,t}^P$ denote the total parcel volume transported by driver m which initiates its journey along arc a at time t Additionally, let $d_a$ denote the distance along arc a To calculate the ratio of excess transport capacity required in each consolidation scenario, we sum up the product of container volume and distance ($v_{m,a,t}^C\times d_a$) over all drivers, arcs, and times, and divide it by the sum of parcel volume multiplied by distance ($v_{m,a,t}^P\times d_a$) over the same parameters. The formulation is shown below:

$$\begin{array}{c}\hfill \mathrm{Ratio}\mathrm{of}\mathrm{Excess}\mathrm{Transport}\mathrm{Capacity}=\sum _{m,a,t}(v_{m,a,t}^C\times d_a)/\sum _{m,a,t}(v_{m,a,t}^P\times d_a)\end{array}$$

(7)

For each scenario,

Table 2. Ratio of container volume per kilometer to parcel volume per kilometer in Different Scenarios (for ${10}^6$ parcel Volume per kilometer shipped).

	FD	FFBG	TD_50	TD_25	ND
Container × km	1,274,864	1,257,213	1,212,106	1,200,425	1,135,384
Ratio	1.27	1.26	1.21	1.20	1.14

presents findings regarding the space needed to transport a volume of ${10}^6$ parcels per kilometer, along with the ratio of total container space to the total parcel volume shipped throughout the network. The outcomes indicate that the FD policy exhibits the most substantial space requirement, primarily because it involves the use of smaller containers that are, on the whole, less efficiently utilized. Conversely, the ND policy, which employs larger and more efficiently utilized containers, demonstrates the least surplus capacity. That said, this result does not necessarily imply that one should impose more transportation costs to save on handling costs.

Studies show that about 20% of all the trucks driving in Europe are completely empty, and the rest are only half-full, on average [52]. Therefore, specifically in the LTL industry (which is more common in last-mile delivery), significant potential exists for saving handling costs by smartly using the available space in the trucks. Additionally, the shipping cost comprises various components beyond just container space, including handling, transportation, labor, and efficiency-related expenses. Smaller containers might provide the option for using smaller trucks but more frequent delivery routes. This could enable offering faster delivery services and offset any additional costs. The use of smaller containers enables a more efficient handling process, potentially reducing the labor cost. It also offers more flexibility in loading the trucks, possibly leading to fewer trips and more efficient use of shipping resources. As such, more in-depth studies on joint parcel and vehicle routing and containerization problems are needed to understand the true trade-off at stake, which leads to an interesting avenue for future research.

All experiments conducted in Section 4.1 and Section 4.2 were carried out using a dual AMD EPYC processor (2.50 GHz each), with 80 GB of allocated RAM, and on a Windows Server 2012 R2 Standard operating system, 64-bit, running on an x64-based processor.

5. Concluding Remarks

In this section, we provide a summary of this study, highlight and discuss its limitations, and propose several avenues for future research.

5.1. Summary

In this study, we introduced a holistic discrete-event agent-based simulator framework to enable assessment of the multi-tier mesh web introduced by Montreuil et al. [12] as a revolutionary transition toward more resilient and responsive urban parcel logistics systems. Given this framework, we tested two operational decisions in deterrent scenarios. In the first set of experiments, we tested two multi-tier parcel logistic webs with different degrees of hyperconnectivity in terms of vehicles and parcel routes. Simulation results suggested the superior performance of a fully hyperconnected structure (scenario 2) concerning feasible delivery services and packages’ average time in the system. In the second set of experiments, we leveraged the multi-tier mesh web to study the performance of various containerized consolidation methodologies. The findings revealed a distinct trade-off between the reduction in handling costs achieved through containerized consolidation and the needed transport capacity. Both experiments were conducted using real data from a high-profile delivery company in China.

These results notably underscore the significance of multi-faceted simulator systems in facilitating a more insightful examination of the consequences resulting from changes (whether in system or policy) within specific network segments and understanding the trade-offs between intervening decisions. Those intervening decisions include the trade-off between shipping cost and handling cost, between facility cost and transit cost, between commodity routing and vehicle routing, and between commodity routing and containerized consolidation, to name a few.

5.2. Limitations and Future Research Avenues

The works in this paper have their own limitations which opens a rich potential for future research to build upon it. First, despite all the benefits it offers, managing such complex simulation models presents its own set of challenges. The computational demands hinder the execution of a large number of scenarios, and even smaller runs require substantial time. To fully harness the capabilities of these comprehensive platforms, future progress is essential to facilitate multi-core and distributed simulations. For instance, each hub could operate independently on a dedicated core, all interconnected through a central platform incorporating feedback loops among the agents.

Aside from the technical hurdles, although the findings presented in Section 4.1.2 showcase the resulting time savings from the transition to a more hyperconnected routing strategy, it is crucial to study and compare the corresponding logistics cost, efficiency, resiliency, responsiveness, and sustainability under such scenarios. Delving deeper into this aspect will shed light on the broader implications of adopting a hyperconnected routing strategy, allowing for a more holistic understanding of its impact on overall logistics performance and cost-effectiveness.

Moreover, the simulation results in Section 4.2.2 suggest that achieving more handling cost savings has a bi-product of less container space utilization and potentially more transportation costs. However, it is important to note that given the extensive interconnectivity woven throughout different tiers of the hyperconnected logistic web, the strategic and tactical allocation of resources could become prohibitively costly and, in numerous instances, sub-optimal. To overcome these challenges, future studies should delve into the realm of more dynamic resource assignment, relocation, and planning strategies, which can adapt swiftly to changing demands and resource availability, and therefore, result in transportation cost savings.

Additionally, this study assumes given container sizes; while in reality, not one size fits all. The variety of container types available and the selection of appropriate sizes are contingent upon the characteristics of the particular parcel logistics system, warranting independent research. This can become more complicated when multiple players collaborate on parcel delivery, each with distinct networks and preferences. Subsequent studies could evaluate how varying container sizes influence cost savings in both single-player and multi-player settings.

The proposed simulation framework can be well leveraged for several niche research areas. Notably, we have introduced a protocol enabling real-time tracking and access to critical data across the entire logistic network. Given the rapid advancements in technology and computing power, coupled with the escalating industry interest in seamless data tracking, logging, processing, and access, this area stands as a compelling avenue for future research. The exploration of advanced techniques to enhance the protocol’s efficiency, security, and compatibility with emerging technologies would undoubtedly contribute to more informed, accurate, and timely decision-making processes within the logistics network.

In addition, the data collection and sharing framework presented in this study enables the incorporation and evaluation of diverse artificial intelligence tools and techniques to assess their impact on operational efficiency and effectiveness in urban parcel logistics. One such example involves utilizing AI to forecast demand patterns and understand customer behaviors, facilitating the targeted delivery of specific offers to distinct customer segments. Moreover, AI possesses the capacity to streamline and improve various aspects of service delivery, encompassing functions like scheduling, routing, dispatching, and tracking. For instance, AI can analyze data from various sources, including traffic conditions, weather forecasts, customer preferences, and service histories to optimize resource allocation and routing for each service request.

Furthermore, the hub-based network structure combined with the utilization of secure, modular containers presents a fertile ground for the exploration of resource pooling and collaborative efforts among diverse stakeholders. This calls for more comprehensive and expansive research efforts to uncover the full potential of such resource-sharing models, which could yield substantial benefits in terms of cost efficiency, operational agility, and sustainability.

This framework could be also well leveraged in future research to compare the collective outcome of embedding different tools and techniques for involved decisions, to investigate the impact of batch shipment in last-mile operations efficiency and sustainability, to assess the impact of new autonomous delivery technologies, and to analyze new alternative overall system architectures.

In summary, the nascent concepts of Hyperconnected City Logistics, Hyperconnected Megacity parcel Logistics, and Hyperconnected Logistic Web holds significant promise, and its potential is ripe for exploration across multiple dimensions. As we navigate the challenges of efficient resource allocation, collaboration among stakeholders, and the advancement of real-time data protocols, future research endeavors have the potential to revolutionize the landscape of logistics, ushering in an era of heightened efficiency, sustainability, and interconnectedness.