Rolling horizon planning for a dynamic collaborative routing problem with full-truckload pickup and delivery requests

Abstract

In order to improve their operational efficiency, small and mid-sized freight forwarders can establish horizontal coalitions in order to exchange customer requests. Decentralized operational transportation planning processes enabling request exchange among forwarders in spite of information asymmetry and distributed decision-making competences is referred to as collaborative transportation planning (CTP). CTP can help forwarders take advantage of economies of scale and reduce their costs of fulfilling customer requests compared to the case of isolated planning without request exchange. In order to exploit the potential of cost-savings embedded in CTP, appropriate request exchange mechanisms have to be developed. In this paper, the dynamic CTP problem of a coalition of freight forwarders serving full-truckload transport requests is studied. Two rolling horizon planning approaches are proposed to solve the dynamic routing problems. It is analyzed how the planning results, in particular the cost reduction realized by CTP, are influenced by different planning settings. Computational experiments show that the planning results of CTP are considerably superior to those obtained by isolated planning, and the realized cost-savings in percentage remain relatively constant, independently of the test settings.

1 Introduction

A key element of a successful operation of freight forwarders in road haulage is to keep a high operational efficiency of the fulfillment of their customer transportation requests. Due to the relatively limited business size, it is much more difficult for small and mid-sized forwarders to reach the level of operational efficiency that large forwarding companies on average can achieve, since the latter ones can consolidate requests to a higher extent. Building horizontal coalitions and seeking for cooperation with fellow forwarders may be considered as a promising remedy.

Through request exchange within horizontal coalitions, complimentary requests of different freight forwarders can be consolidated and more efficient vehicle routes can be constructed. A reduction of the total operational costs of up to 30 % can be realized by applying centralized planning for request exchange (Cruijssen and Salomon 2004; Cruijssen et al. 2007a; Krajewska et al. 2008). Centralized planning means that all information with respect to requests, costs and the availability of transportation resources as well as all decision-making competences are transferred to a central planning authority of the coalition. If coalition members want to preserve their private information and autonomy of decision-making, decentralized planning approaches have to be developed. Wang and Kopfer (2014) refer to such decentralized planning processes with respect to vehicle routing and scheduling as collaborative transportation planning (CTP).

CTP is characterized by the fact that the forwarders in the coalitions generate plans on their own and only for themselves and these individual plans are harmonized within the coalition by applying appropriate decentralized request exchange mechanisms. The specific goal of CTP is to reallocate the requests among all member forwarders so that the total fulfillment costs are reduced as far as possible compared to the sum of the forwarders’ individual costs without cooperation. The obtained cost-savings present the joint benefits of the coalition that cannot be achieved individually. Forwarders’ profitability can then be improved by acquiring their shares of the joint benefits.

CTP has been investigated by many researchers in the last decade. However, the majority of existing research focuses on static CTP scenarios, in which all information is available a priori. On the contrary, little attention has been paid to dynamic CTP problems. In this paper, a dynamic CTP problem which is referred to as the dynamic collaborative full-truckload pickup and delivery problem with forwarding (DCFPDPF) is introduced. The dynamic CTP extends the static CTP over a long time horizon with gradually revealed request information. Two rolling horizon planning (RHP) approaches that solve the static problems periodically based on the updated current information are used to solve the DCFPDPF. The first one is introduced in Wang and Kopfer (2013) and solves a new static problem when a predefined time interval is reached. In the second approach, the static CTP is triggered whenever a new request becomes urgent and must be irrevocably planned at that time. In order to solve the static CTP problems, the route-based request exchange mechanism proposed in Wang and Kopfer (2014) and Wang et al. (2014) is adapted and used in both RHP approaches.

The purpose of the study in this paper is to analyze the influence of different planning strategies on the planning results. Especially, the main contributions of our paper are: (1) the comparison of the cost-savings that can be achieved by advanced individual planning techniques and by performing CTP with coalition members, (2) a systematical analysis of the influence of different planning settings on the achievable cost-savings through CTP in a dynamic environment, and (3) practical recommendations for freight forwarders derived from the discussion on our computational results.

This paper is organized as follows. Literature of related topics is briefly reviewed in Sect. 2. In Sect. 3, the DCFPDPF is formally described. Two RHP approaches are proposed in Sect. 4. Computational studies and comprehensive discussions on the results are shown in Sect. 5. Section 6 concludes this paper.

2 Literature review

On the one hand, research questions on dynamic CTP are closely related to dynamic and deterministic vehicle routing and on the other hand to collaboration within operational transportation scenarios.

2.1 Dynamic and deterministic routing

In contrast to static routing problems where all input data of the problems are known a priori when the routes are constructed, some input data are revealed or updated during the period of time in which operations take place in a dynamic routing problem (Berbeglia et al. 2010). Moreover, a routing problem can be either deterministic or stochastic according to the information quality which reflects possible uncertainty on the available data (Pillac et al. 2013). The reader is referred to Pillac et al. (2013) for a recent review on dynamic routing problems. Specifically, Berbeglia et al. (2010) review the literature on dynamic pickup and delivery problems (PDP). In this section, we focus on some major contributions to dynamic and deterministic routing problems.

Pillac et al. (2013) classify the solution approaches for dynamic routing problems into two categories. The first category comprehends periodic re-optimization approaches. After having constructed a set of initial routes, these approaches periodically solve static problems corresponding to the current states triggered by specific incidences. The first type of such triggers is an update of input data, which practically can be the release of a new customer request. This strategy is used in Psaraftis (1980), Yang et al. (1998), and Yang et al. (2004). Psaraftis (1980) proposes a dynamic programming approach for the dynamic dial-a-ride problem. RHP approaches are used to solve the real-time full-truckload (FTL) PDP with time windows (PDPTW) in Yang et al. (1998) and its extension by considering the possibility of rejecting requests and soft time windows in Yang et al. (2004). Instead of being triggered by specific incidences, a re-optimization can be started whenever a predefined interval is reached. Savelsbergh and Sol (1998) apply a branch-and-price algorithm to solve the static PDPTW for each single re-optimization. Similarly, Chen and Xu (2006) use the column generation scheme in a dynamic approach and solve each time the vehicle routing problem with time windows (VRPTW). An ant colony system is developed by Montemanni et al. (2005) for a dynamic vehicle routing problem in which encrypted information about characteristics of good solutions are conserved in a pheromone matrix and passed on to the next static problem after a predefined duration.

The second category is referred to as continuous re-optimization. The general idea is to run the optimization routines and maintain information on good solutions in an adaptive memory. Whenever an event occurs, e.g., a new request is known or a vehicle has finished its current job, a decision procedure stops the optimization routine and updates the routes. After that, the optimization routine is restarted with the new generated solutions. Different from periodic re-optimization approaches, a driver doesn’t know the next customer to serve until he has finished his current job. Diverse optimization routines are used in these approaches. Gendreau et al. (1999) apply a parallel tabu search proposed in Taillard et al. (1997). Another tabu search heuristic that uses the concept of ejection chains (Glover 1996) to construct a powerful neighborhood structure is proposed in Gendreau et al. (2006).

In addition to work on developing efficient solution approaches for dynamic routing problems, the influence of waiting strategies on the quality of solutions to dynamic routing problems is studied by Mitrović-Minić and Laporte (2004). Tjokroamidjojo et al. (2006) and Zolfagharinia and Haughton (2014) analyze how valuable it is for forwarders to have the advanced request information.

2.2 Collaborative transportation planning

For small and mid-sized forwarders, their relatively limited business size restricts the potential for taking advantage of economies of scale with respect to vehicle routing. In order to overcome this drawback, forwarders can seek for partnerships within horizontal collaboration. Some general opportunities and impediments of horizontal cooperation in logistics are revealed in Cruijssen et al. (2007b). A literature review can be found in Cruijssen et al. (2007c).

Appropriate request exchange mechanisms must be developed to exploit the cost-saving potential embedded in CTP. Such mechanisms have to be (1) simple and implementable, (2) effective in terms of generating high joint benefits (Özener et al. 2011), and (3) able to deal with distributed information and decision-making competences (Wang and Kopfer 2014).

Some mechanisms are proposed to tackle the task of exchanging requests in static CTP. Schönberger (2005) proposes an approach based on combinatorial auctions (CA) for a static CTP scenario where each member of the coalition has only one vehicle with unlimited capacity. Since time window constraints are considered, the coalition has not enough capacity to fulfill all the acquired requests and must subcontract some requests to external common carriers. Krajewska and Kopfer (2006) also use a CA to solve a simplified case of static CTP while making the assumption that the fulfillment costs for any bundle of requests can be exactly evaluated. An incentive compatible approach using cryptographic techniques for swapping pickup and delivery requests among independent forwarders is proposed by Clifton et al. (2008). They develop a protocol that is secure against a centralized model referred to as the “trusted broker” model, where all parties give their input to the broker and the broker computes and returns the result. Schwind et al. (2009) use both a one-round auction and an iterative auction to exchange requests among profit centers (warehouses) of a single company serving its customers with single commodity goods. The proposed mechanisms try to identify profitable request exchanges between adjacent profit centers while each of them independently solves its own VRPTW. Berger and Bierwirth (2010) propose both a Vickrey auction (Vickrey 1961) and a CA for another static CTP scenario. Since vehicle capacity is not considered, the underlying routing problem of each coalition member is the traveling salesman problem with pickup and delivery. Özener et al. (2011) study the lane exchange problem of collaborating FTL forwarders and propose bilateral exchange mechanisms. In order to solve the problem of exchanging less-than-truckload (LTL) requests with time windows while taking the capacity limit of vehicle fleets into account, a route-based request exchange mechanism is proposed by Wang and Kopfer (2014) and is extended to solve static CTP problems with heterogeneous fleet in Wang et al. (2014).

In contrast to static CTP, little research has been conducted on its dynamic counterpart. Song and Regan (2003) study a variant of dynamic CTP of a coalition of forwarders fulfilling FTL pickup and delivery requests. Whenever a member forwarder acquires a customer request, he launches an auction for the assignment of this request and acts as an auctioneer. Other coalition members acting as bidders calculate the marginal costs of inserting this request into their existing routes. The request will be transferred to the bidder with the lowest bid price if this price is lower than the auctioneer’s own marginal costs. Wang and Kopfer (2013) propose an RHP approach with a predefined time interval between two successive static CTP procedures. Computational study shows that CTP is especially preferable in a highly dynamic environment. The authors further recommend using advanced request information and planning in a forward-looking way for better solution quality. However, it is not analyzed how the cost-reduction realized by CTP is affected by changes of parameter settings of the used CTP approach.

3 Problem definition

The DCFPDPF deals with a horizontal coalition of $m$ independent freight forwarding companies who offer FTL transportation services. Each forwarder in the coalition $i,\, i=1,\ldots ,m$, has an own homogeneous fleet $K_i$ with $\varrho _i$ vehicles. At the beginning time $t_0=0$ of the entire time horizon $[0,\infty )$, these vehicles are located at different locations. No specific end depots are assigned for them in the dynamic situation. Let $K=\cup _{i=1}^mK_i$ denote the entire fleet of the coalition. We assume that all vehicles in $K$ are equally equipped so that every request can be fulfilled by any vehicle in $K$. However, all forwarders may use their own scheme to calculate route costs for their own fleet, i.e., the vehicles may have different variable cost rates $\beta _k$.

Each forwarder $i$ in the coalition acquires requests from his customers during the entire time horizon. The set of requests of forwarder $i$ over the entire time horizon is denoted as $R_i$. Let $R=\cup _{i=1}^mR_i$ denote the set of all requests. A request $r\in R$ must be transported from its pickup location to the corresponding delivery location. At each location $u$, the operation (pickup or delivery) must be started in a customer defined time window $[a_u, b_u]$. The service time at $u$ is given by $s_u$. In a static PDP, all request information is available at the time of planning. In a dynamic PDP, however, requests may be released while the routes are executed. The time when a request $r$ is released to a forwarder is called the release time and is denoted as $t_r^{rls}$.

In dynamic environments it is important to define the corresponding request sets associated with a point in time $t$. At any $t$, only a subset of requests $R_i^t\subset R_i$ is known to forwarder $i$. $R_i^t$ is the set of $i$’s requests released no later than $t$, i.e., $R_i^t=\{r\in R_i|t_r^{rls}\le t\}$. $R_i^t$ can be further divided into two parts. The first part consists of all requests that have not been planned yet and is denoted as $R_i^{t,a}$, where the index $a$ means that these requests are still “active” for the planning. The complement $R_i^t\setminus R_i^{t,a}$ is the set of requests that have already been irrevocably planned and thus are no more relevant for the planning at $t$. These requests cannot be reassigned either because their services have already been started or even finished or because their services must be started soon after $t$.

Three fulfillment modes can optionally be used by a forwarder to fulfill one of his customer requests: The first one is self-fulfillment, i.e., to assign this request to a forwarder’s own vehicle. The second one is to subcontract it to a common carrier and pay a certain freight charge $\gamma _r$. The third one is to transfer it to another coalition member through request exchange. The DCFPDPF aims at minimizing the overall costs of the entire coalition to fulfill all requests in $R$.

4 Solution approaches

In this section, two RHP approaches are presented for the DCFPDPF. The two basic frameworks for these approaches are illustrated in Fig. 1 and described in more detail subsequently. Some important issues related to the DCFPDPF are then discussed.

Fig. 1

Frameworks of rolling horizon planning. a RHP with fixed interval. b Request triggered RHP

4.1 Rolling horizon planning with fixed interval

The first approach is based on an RHP framework with a fixed interval. This approach, which is also used in Wang and Kopfer (2013), is illustrated in Fig. 1a and is denoted as RHP-INT. The entire time horizon is divided into a series of planning periods (PP). All PPs have the same length $\tau$. We use identifier $p$ to denote a PP, $p=1,2,\ldots ,\infty$. At $t_0=0$, an initial plan $\varPi _1$ for the first planning horizon (PH) including $\zeta$ following PPs, i.e., $p=1,2,\ldots ,\zeta$, is constructed. The length of a PH is then given by $L_{PH}=\zeta \tau$. The plan for the first PP is irrevocable. The plan for the next PPs, i.e., $p=2,\ldots ,\zeta$, however, will be actualized in the forthcoming plans as a result of the dynamically released new requests during the execution of planned routes. After that, at the end of each PP $p$, i.e., at the planning time $t_p=p\tau ,\, p=1,2,\ldots ,\infty$, a new plan $\varPi _{p+1}$ for the next PH ranging from $p+1$ to $p+\zeta$ will be made based on the updated status. Again, the partial plan constructed for PP $p+1$ will be irrevocable while the remaining part of the current PH will be kept changeable. Figure 1a shows the case when $\zeta$ is set to 3.

At each planning time $t_p,\, p=1,2,\ldots ,\infty$, a vehicle can be assigned new requests after it has finished fulfilling all the requests that have been planned irrevocably in its route previously. If a vehicle has already finished serving all assigned requests, it waits at the location of the last customer for new requests.

4.2 Request triggered rolling horizon planning

Another possibility of doing RHP is to adjust the plan after each actualization of the status of the request portfolio. This variant is referred to as RHP-RT and illustrated in Fig. 1b. At $t_0=0$, an initial plan $\varPi _1$ for the first PH with a predefined length $L_{PH}$ is constructed. At $t_1$, the status of the requests is changed and a new plan is made. The part from $t_0$ to $t_1$ of the first plan $\varPi _1$ has already been executed and it is the irrevocable part of $\varPi _1$. The remaining part, i.e., from $t_1$ to $t_0+L_{PH}$ will be actualized due to the new plan. At $t_2$, the status of the request portfolio changes again, and the process repeats. As a result, the irrevocable part of a plan in RHP-RT is dynamically determined.

Different triggers can be used within this framework. Song and Regan (2003) use the release of a new request as the trigger. As soon as a new request is known to a coalition member, a single-item auction is initiated, through which this request will be unalterably assigned. Another option that will be used here is to initiate an exchange process at the time when a request $r$ becomes urgent and must be irrevocably planned immediately, which is referred to as the due time $t_r^{due}$ of $r$. For a request $r$, its due time can be calculated as $t_r^{due}=e_{r^+}-t^{ld}$, where $e_{r^+}$ is the latest time when the service of this request must begin, i.e., the end of the time window of the related pickup operation, and $t^{ld}$ is a predefined lead time. The lead time is an important parameter of RHP that must be set before the planning starts. Without loss of generality, $t^{ld}$ is identical for all requests in this paper. The lead time should not only include the time for planning but also the time a vehicle needs to get from its current location to the pickup location of the request.

4.3 Determination of due requests

In a dynamic environment, requests are released as time goes on. Some of them may be released shortly before the latest time when the service must begin and need a quick response of the forwarders. Others may be known quite a long time before their time windows open and leave the forwarders much more time to seek for the best plans. Thus, it is necessary in RHP to differentiate requests according to their urgency.

The set $R_i^{t,a}$ of all active requests of forwarder $i$ at the planning time $t$ can be further differentiated into three subsets according to their urgency: (1) the due requests $R_i^{t,d}$ that must be irrevocably planned at $t$, (2) the non-due requests $R_i^{t,n}$ comprising the remaining part of requests to be considered in the current PH, and (3) the requests whose due time lies beyond the PH and thus will be excluded from the planning $R_i^{t,e}$. Then we have $R_i^{t,a}=R_i^{t,d}\cup R_i^{t,n}\cup R_i^{t,e}$. The sets of all active, due, non-due and excluded requests of the entire coalition at $t$ can be defined as $R^{t,a}=\cup _{i=1}^mR_i^{t,a}$, $R^{t,d}=\cup _{i=1}^mR_i^{t,d}$, $R^{t,n}=\cup _{i=1}^mR_i^{t,n}$, and $R^{t,e}=\cup _{i=1}^mR_i^{t,e}$, respectively.

Due requests are differently defined for the two different RHP frameworks. In case of RHP-RT, a new planning will be launched when one or more requests become due requests. Here, a request $r$ is defined as a due request at time $t$ if $t_r^{due}\le t$ holds. More precisely, $r$ triggers a new planning process when $t_r^{due}=t$. In RHP-INT, the definition of due requests is not based on the due time of requests but on the appendant PP. Obviously, at the planning time $t=p\tau$ which is the beginning time of the $(p+1)$th PP, all those requests that must be picked up within the $(p+1)$th PP are due requests. I.e., $R^{t,d}$ consists of the requests whose service must be started before the end of the $(p+1)$th PP at their pickup locations. Additionally, in order to improve the continuity of the plan, requests whose pickups must be served soon after the end of the $(p+1)$th PP are also considered as due requests in RHP-INT.

4.4 Planning strategies using advanced request information

In a dynamic environment, forwarders can improve the quality of their planning if they are offered the request information in advance. However, the value of the advanced request information is not always the same according to how much in advance the information is released (Tjokroamidjojo et al. 2006). For a given request, the shorter the time is from the current time to the latest time allowed to begin the service, i.e., the more urgent the request is, the more valuable the information about this request is. On the contrary, the longer the time is and the less urgent the request is, the less valuable the related request information is for the planning at the current time. Thus, it is also important in RHP to specify planning strategies that differentiate the importance of the known requests to the current planning according to their urgency.

There are two factors influencing the planning strategies. The first one is $L_{PH}$. The longer the PH is, the more forward-looking the planning is. Specifically for RHP-INT, the minimum value of $L_{PH}$ equals to the length $\tau$ of a PP, which means that the planning focuses only on the most urgent requests. Thus, for RHP-INT, any strategy with $L_{PH}=\tau$ is referred to as myopic planning (MYP), and any strategy with $L_{PH}=\zeta \tau$, $\zeta >1$, is denoted as forward-looking planning (FLP). For RHP-RT, MYP means that requests are considered singly in static planning, i.e., only the costs of moving a vehicle from its current position to the pickup location of this request and bringing the goods then to the corresponding delivery location are considered. In this case, $L_{PH}$ is practically determined as the time span between the due times of two requests to be planned consecutively and it is no more a constant.

The second factor is a weight function that assigns each considered request a weight reflecting its urgency. The weight can also be interpreted as a valuation of the advanced information of requests associated with a specific point in time. The weight function has a simple form in any MYP: since only due requests are considered and all due requests have the same importance at the planning time, we can assign them the same weight of 1 and other requests the weight of 0. In FLP, the situation is more complicated since a weight between 0 and 1 has to be assigned to the non-due requests additionally.

4.5 Identification of requests for exchange

A strategy for the usage of advanced request information specifies the requests to be considered in each static planning and the evaluation of their urgency. For CTP, however, we must additionally determine the candidate requests for exchange. In case of RHP-RT, all requests that have triggered the new planning at the same time are candidates for exchange, since a CTP will be launched when some requests become due and must be irrevocably planned at that moment. For RHP-INT, two situations have to be differentiated: MYP and FLP. As MYP only deals with requests in $R^{t,d}$, all requests in $R^{t,d}$ are candidates for exchange; i.e., they are considered in the planning and have to be irrevocably assigned to the forwarders through request exchange. For the FLP, however, all requests in $R^{t,d}\cup R^{t,n}$, i.e., all active requests which are currently known for the next $\zeta$ PPs are included for constructing the plan. Nonetheless, only the most urgent requests, i.e., the requests in $R^{t,d}$ that must be irrevocably planned, will be candidates for exchange. Actually, MYP can be realized by assigning all non-due requests in $R^{t,n}$ the weight of zero and thus be regarded as a special case of FLP in a broader sense.

It is important to differentiate the requests to be considered and those being candidates for exchange. Each reallocation of requests will result in transfer payments among the members and the amounts of the payments are determined on the basis of the costs of routes. These costs are supposed to be as accurate as possible. In a dynamic environment, these costs can only be precisely determined for the partial routes serving the most urgent requests since they will not be changed during their execution. Another important reason is that although advanced request information should be considered in planning, the plan for requests that are not urgent should not be fixed as soon as the plan is made (Tjokroamidjojo et al. 2006).

4.6 Extended route-based request exchange mechanism

The static CTP problems are solved periodically within the RHP frameworks using an extended version of the route-based request exchange mechanism of Wang et al. (2014). The readers are referred to Wang and Kopfer (2014) and Wang et al. (2014) for a comprehensive description of the static approach. The most important extension is to integrate the weight factor described in Sect. 4.4 into the routing problems. Figure 2 gives an overview of the adapted mechanism.

Fig. 2

Overview of the adapted route-based request exchange mechanism

Each time a new planning is initiated at time $t$, all partners first propose all their active requests relevant to the current planning, i.e., $R_i^{t,d}$ in case of MYP and $R_i^{t,n}$ additionally in case of FLP into the common request pool, which is denoted as $R^{t,p}$. All due requests in $R^{t,d}\subseteq R^{t,p}$ will be irrevocably assigned through CTP.

Next, each forwarder $i$ performs an isolated planning (IP) by solving a routing problem for himself using his own fleet and common carriers to fulfill only his own requests in $R_i^{t,p}$. In this routing problem, a request can either be planned in a vehicle route or be outsourced to a common carrier. By introducing a weight $w_r^t$ for each request $r\in R_i^{t,p}$, we can formulate the objective function of this routing problem as follows:

$$\begin{aligned} \min \sum _{k\in K_i^t}\sum _{(u,v)\in A_i^t}\beta _kd_{uv}x_{uvk}+\sum _{r\in R_i^{t,p}}\gamma _rw_r^tz_r \end{aligned}$$

(1)

where $K_i^t\subseteq K_i$ is the set of available vehicles in the current planning, $A_i^t$ is the set of arcs defined by forwarder $i$’s own requests and vehicle locations, and $d_{uv}$ is the travel distance given by arc $(u,v)$. The decision variable $x_{uvk}\in \{0,1\}$ indicates if an arc $(u,v)$ is used in vehicle $k$’s route and the other binary variable $z_r$ indicates if a request is outsourced to a common carrier. The weighted freight charge $\gamma _rw_r^t$ of $r$ can be seen as a penalty cost for not including it in any route. Requests with $w_r^t=0$ will thus be practically excluded from the planning. In case of MYP, all requests in $R_i^{t,n}$ have $w_r^t=0$ and all due requests have a weight of one. In case of FLP, all due requests also have the weight of one while other requests have a weight less than one. After having solved this routing problem, each forwarder $i$ declares the costs of fulfilling his own requests in $R_i^{t,d}$ without request exchange as the transfer price, which is the maximum amount he would pay if these requests are fulfilled by someone else. In case of FLP, a route may have both due and non-due requests. Only the first part containing the due requests is considered for the determination of the transfer price, i.e., the partial route costs until the delivery location of the last due request in a route are used. Denote this transfer price as $C_i^{t,d}$. The sum of all transfer prices $TC_{IP}^{t,d}=\sum _{i=1}^mC_i^{t,d}$ represents the total costs for due requests at $t$ without cooperation. This information is used for the acceptance of CTP solutions, which will only be accepted when they are better than the solutions of IP, i.e., $TC_{CTP}^{t,d}<TC_{IP}^{t,d}$.

The next step is initial route generation. Each forwarder $i$ solves a routing problem for his own available vehicles $K_i^t$ and generates a set of routes fulfilling the requests selected from the request pool $R^{t,p}$. The objective function is the same as (1) except that $A_i^t$ and $R_i^{t,p}$ are replaced by $A^t$ and $R^{t,p}$, respectively.

$$\begin{aligned} \sum _{k\in K_i^t}\sum _{(u,v)\in A^t}\beta _kd_{uv}x_{uvk}+\sum _{r\in R^{t,p}}\gamma _rw_r^tz_r \end{aligned}$$

(2)

Through solving this problem in a heuristic manner, a set of different solutions can be obtained. The first part of the routes in these solutions containing only the due requests is reported as candidate routes to the agent. The costs of the partial routes will be declared as the costs of these candidate routes.

After the set of candidate routes has been initialized, the iterative process starts. In each iteration, the agent solves the winner determination problem (WDP) in form of a linear relaxed set partitioning problem (SPP) to minimize the total fulfillment costs of all due requests. In the SPP, each due request $r\in R^{t,d}$ is either assigned to a winning candidate route or to some common carrier for the price $\gamma _r$, which is the same for all coalition members.

Suppose that $|R^{t,d}|=n^t$ and $b_i$ candidate routes have been proposed by forwarder $i$ in the initial route generation step. For each request $r\in R^{t,d}$, a fictive route representing the common carrier option with the route cost of $\gamma _r$ is also added into the set of candidate routes. Thus, $b=\sum _{i=1}^mb_i+n^t$ candidate routes are there in total. Let $a_{rj}=1$ indicate that request $r$ is in route $j$ and $a_{rj}=0$ otherwise, $j=1,2,\ldots ,b$. We use $f_{kj}=1$ to indicate that route $j$ is proposed for vehicle $k$, $k\in K^t$. The cost of a candidate route is denoted by $c_j$. The WDP can be formulated as follows by introducing the binary variable $y_j$, $j=1,2,\ldots ,b$ to indicate whether a route is chosen as a winning route.

$$\begin{aligned} \min TC_{CTP}^{t,d}=\sum _{j=1}^bc_jy_j \end{aligned}$$

(3)

subject to:

$$\begin{aligned}&\sum _{j=1}^ba_{rj}y_j=1\quad \forall r\in R^{t,d} \end{aligned}$$

(4)

$$\begin{aligned}&\sum _{j=1}^bf_{kj}y_j\le 1\quad \forall k\in K^t \end{aligned}$$

(5)

Constraints (4) ensure that each request is assigned to exactly one winning route and constraints (5) ensure that each vehicle is assigned no more than one route. The agent solves the linear relaxation of this model and gets the dual values related to (4) for requests $\pi _r$. They are sent back to the forwarders for the next iteration of route generation.

Using this feedback information, forwarders can generate and submit new candidate routes in the iterative route generation step by solving another routing problem with the following objective function:

$$\begin{aligned} \min \sum _{k\in K_i^t}\sum _{(u,v)\in A^p}\beta _kd_{uv}x_{uvk}+\sum _{r\in R^{t,d}}\pi _rz_r+\sum _{r\in R^{t,p}}\gamma _rw_r^tz_r \end{aligned}$$

(6)

Again, only the first part of each route in the obtained solutions is proposed as a candidate route. The adaptive large neighborhood search (ALNS) heuristic presented in Wang et al. (2014) is used to generate candidate routes in both the initial and iterative route generation steps.

Iterative route generation ends when predefined criteria are satisfied. The agent solves then in the Step final winner determination the WDP which is formulated as a set covering problem by replacing (4) with

$$\begin{aligned} \sum _{j=1}^ba_{rj}y_j\ge 1\quad \forall r\in R^{t,d} \end{aligned}$$

(7)

If some requests belong to several winning routes in the WDP solution, the agent calls a simple repair routine to obtain a feasible solution for the CTP problem. The result of the WDP will only be accepted if $TC_{CTP}^{t,d}<TC_{IP}^{t,d}$. In this case, the partners pay the transfer prices $C_i^{t,d}$ to the coalition and get the route costs back from the coalition for each of their winning routes. The difference $TC_{IP}^{t,d}-TC_{CTP}^{t,d}$ is the mutual benefits of the collaboration that will be shared within the coalition.

5 Computational experiments

To obtain some insights into dynamic CTP, a comprehensive simulation study is conducted. A lot of scenarios are simulated to analyze the influence of several factors on three aspects: the total costs related to the planning results, the potential cost-savings that are theoretically achievable by request exchange, as well as the efficiency of the proposed CTP approach in realizing this potential.

5.1 Test case generation

For our simulations 30 theoretical instances are generated in the similar way as in Wang and Kopfer (2013). The instances can be found at www.logistik.uni-bremen.de. Customer locations are randomly distributed in a rectangle of size $200\times 150$. Pickup operations are distributed in the time horizon [0, 4,500] which is 50 % longer than that of the instances tested in Wang and Kopfer (2013), so that we can simulate with large $L_{PH}$-values. To make sure that all requests can be fulfilled, the entire time horizon is extended to $[0,4800]$. Vehicles are located at randomly generated start locations with empty load at $t_0=0$. Without loss of generality, the variable cost rate per distance unit is set to one for all vehicles $k\in K$ and the fixed costs of vehicles are supposed to be the same for all forwarders so that they can be ignored in our study. The velocity of all vehicles is assumed to be one distance unit per time unit so that the driving time between two nodes directly corresponds to the distance.

The outsourcing cost $\gamma _r$ for a request $r$ is calculated as $\gamma _r=\varphi d_r\theta ^{d_r}$, where $\varphi =2$ is a constant cost rate and $d_r=\max \{5, d_{r^+r^-}\}$ is the adjusted distance between pickup and delivery locations $d_{r^+r^-}$. The motivation to use the adjusted distance is that common carriers charge a fixed minimum fee if the distance to travel lies below a specific level. The parameter $\theta$ is set to 0.9986 so that $\theta ^{d_r}$ can be seen as a distance-dependent discount on the cost rate, which captures the fact in practice that freight rates reduce with increasing distance.

Let $t_r^{ts}=b_{r^+}-t_r^{rls}$ denote the time span between the release time $t_r^{rls}$ of request $r$ and the beginning of the time window of its pickup operation $b_{r^+}$. The test cases are generated in such a way that 5 % of all requests have $t_r^{ts}=450$, 10 % have $t_r^{ts}=400$, another 10 % have $t_r^{ts}=350$, 15 % have $t_r^{ts}=300$, 30 % have $t_r^{ts}=250$, 20 % have $t_r^{ts}=200$, and the remaining portion of 10 % have $t_r^{ts}=150$.

5.2 Performance of RHP-INT

In the first part of our simulation study the performance of RHP-INT is analyzed. Several scenarios are simulated using the generated 30 test cases. The results are statistically analyzed to draw some conclusions.

5.2.1 Simulation scenarios

Three factors are considered in this study: (1) the strategy using advanced request information, (2) the length of the planning horizon, and (3) the type of planning with respect to collaboration.

If forwarders can acquire request information in advance, they can use it to improve their planning quality. Zolfagharinia and Haughton (2014) report a cost reduction of 22 % by using request information for the next PP as well as a 6 % reduction for the PP after that. Similar results are also reported in Tjokroamidjojo et al. (2006). It is also reported in both studies that the request information for the remaining PPs has no significantly sufficient influence on the solution quality. We thus formulated three strategies: MYP totally ignores the not urgent requests and the advanced request information; FLP-I considers all know requests and FLP-II includes only future requests to a limited extent which is specified as the next 2.5 PPs. The degree of urgency of requests can be expressed by proper weight values. By changing the weight values the advanced request information can be considered in RHP in different manners. Specifically, the three strategies are defined as follows: MYP can be realized by assigning due requests that must be served in $(p+1.25)\tau$ the weight of 1 and non-due requests the weight of 0. For FLP-I, the weight of due requests is 1. Non-due requests with $(p+1.25)\tau <e_{r^+}\le (p+2)\tau$ have a weight of 0.75 and all other non-due requests have a weight of $0.75^2\approx 0.56$. FLP-II differs from FLP-I as non-due requests with $e_{r^+}>(p+2.5)\tau$ are ignored and assigned a weight of 0 instead of 0.56.

The second factor studied here is the length $\tau$ of the PP. Instead of being studied as a variable parameter of the RHP, it is often considered as a given value in literature reflecting for instance a day in the real world (Mitrović-Minić and Laporte 2004; Tjokroamidjojo et al. 2006; Zolfagharinia and Haughton 2014). In our simulation, we consider this parameter as a variable and six different values: 25, 50, 75, 100, 125 and 150 are tested. The purpose is to find out if it makes sense to change the frequency of the RHP.

The last factor concerns the information transparency of the planning in the coalition. Three situations are introduced: without information exchange and request exchange (IP), collaborative request exchange based on limited information exchange (CTP), and centralized planning (CP) with full information transparency. In CP, all coalition members share their private information with respect to requests, fleet capacity, and cost structure. Moreover, they give up their decision-making competences and let a central authority plan for the entire coalition. This is the way with the best results achievable for the single static planning within a predefined RHP framework.

In total, 54 scenarios can be defined by combining the possibilities of the three factors. The same 30 test cases are calculated for all 54 scenarios. The results are shown and analyzed in detail in the next part of this section.

5.2.2 Value of advanced request information

The benefit of planning with advanced request information can be recognized from Table 1. $\varDelta _I$ and $\varDelta _{II}$ give the average cost reduction of the 30 simulations in each scenario achieved by using FLP-I and FLP-II against MYP. As FLP-II considers less information than FLP-I, this strategy also needs less computational efforts compared to FLP-I. $\varDelta _t$ in the last column refers to the average computational time reduction. Although the value of advanced request information in our tests lies below 1 %, results of the t-test $(\alpha =0.05)$ strongly suggest its statistical significance except for the scenario $\{\hbox {CTP}, \,\tau =150\}$. Thus, it can be concluded that FLP is generally better than MYP.

Table 1 Value of planning with advanced request information

A further comparison of the performance of FLP-I and FLP-II shows that although less information is considered in FLP-II, it works statistically equally well except for the scenarios $\{\hbox {IP}, \tau =25\}$ and $\{\hbox {CP},\, \tau =50, 75, 100\}$. Even for the four exceptions the t-values exceed only slightly the critical values of the two-tailed t-test $(\alpha =0.05)$ used for the comparison of the two variants of FLP. However, as indicated in the last column $\varDelta _t$, up to 85.91 % computational time can be reduced by using FLP-II. A direct conclusion for forwarders is that advanced request information is valuable and has to be considered. However, ignoring requests to be fulfilled in the far future can significantly reduce the computational efforts without necessarily worsening the overall results.

Nonetheless, the performance of FLP is strongly influenced by the value of $\tau$, since larger $\tau$-values indicate less information known in advance and this logically leads to a convergence of the performance of MYP and FLP.

5.2.3 Cost reduction through request exchange

Two other important topics to discuss are the cost reduction achievable by request exchange and the efficiency of CTP. The results of our simulation are shown in Table 2. The costs given are the average total costs of the 30 test cases in each scenario. The results of CP are used to approximate the minimal costs achievable through request exchange in all scenarios. $\varDelta _1=100\cdot (TC_{IP}-TC_{CP})/TC_{IP}\%$ shows the relative cost-savings if all members would totally give up their autonomy in the planning. $\varDelta _2=100\cdot (TC_{IP}-TC_{CTP})/TC_{IP}\%$ shows the cost reduction using the proposed CTP approach. $\eta =100\cdot (\varDelta _1-\varDelta _2)/\varDelta _1\%$ indicates the efficiency of the collaborative approach in realizing the potential cost-savings. The results in Table 2 indicate a very high efficiency of the CTP approach for the DCFPDPF. It must be mentioned that although CP leads to superior solutions in the static planning of each PP, the overall results can be even slightly worse than the CTP solutions in dynamic environments as in the scenarios {FLP-I, $\tau =25$} and $\{\hbox {MYP},\, \tau =50\}$.

Table 2 Cost reduction through centralized and collaborative planning

If we consider the scenarios {MYP, IP}, i.e., all scenarios with myopic isolated planning, and compare the cost-savings realized by FLP ({FLP, IP}) with those by CTP ({MYP, CTP}), it can be concluded that introducing collaboration has more positive impact than establishing FLP: even the worst solution of CTP is much better than the best solution of IP. It is worth mentioning that this comparison does not indicate a conquer between CTP and FLP. In fact, the best results are achieved by conjointly applying both of them. For forwarders, it is thus recommendable seek for cooperation with proper partners besides planning in a forward-looking way.

5.2.4 Influence of the length of planning periods

As indicated previously, the length of the PP/PH is considered as a given parameter in the majority of the research in literature. However, our simulations show that $\tau$ and the frequency of planning significantly influence the overall total costs. The best results in all three constellations IP, CP and CTP are obtained using FLP-I with $\tau =125$, 100 and 100, respectively. The benefits of adjusting $\tau$ amount to 0.94–1.77 %. These results suggest that forwarders can improve their forward-looking strategy by choosing a proper $\tau$-value instead of regarding it as a given parameter in RHP if applicable in practice.

The influence of $\tau$ on the potential cost-savings $\varDelta _1$ and $\varDelta _2$ by request exchange remain relatively insignificant. The cost-savings with large $\tau$-values are slightly less than those with small values. It can be explained by the fact that in planning with short PHs, forwarders can hardly construct efficient routes in the IP scenarios. In the CP/CTP scenarios, however, the coalition has a larger request pool and a larger fleet so that request exchange among the members can considerably improve the results. On the contrary, a long PH means at the same time a large number of requests to be planned in each PP and forwarders can better bundle their requests in the IP scenario, too. As a result, the potential of further improvement of the routes by CTP decreases a little. It means for forwarders that they can always achieve a further noticeable improvement besides FLP through collaboration, especially in highly dynamic environments that require quick responses of forwarders and thus short PPs.

In order to better understand how the routing results are influenced by $\tau$, it is helpful to take a glance at the cost composition of these results. Table 3 reports the total costs $TC$ and the two components: total route costs $RC$ and total outsourcing costs $OC$. Since the results of CP and CTP are almost the same, we only give the detailed information for CP.

Table 3 Cost composition of planning results using FLP-II

It is not surprising that a too small or a too large value of $\tau$ leads to solutions inferior to those based on well-chosen moderate $\tau$-values. The shorter the PP is, the less requests are considered in the planning. As a result, there exist few opportunities to bundle requests for efficient routes, and the repositioning costs caused by sending vehicles from one request to another also tend to be higher than in case of longer PPs. The average insertion cost, which is defined as the cost increment caused by inserting $r$ into routes at the best position overall, also increases with decreasing number of requests to be planned each time. On the contrary, a longer PP allows more requests to be inserted into routes and thus increases the possibility that the considered requests will be well bundled, i.e., better routes can be found. The distance from a delivery location to the pickup location of the next request also tends to be shorter. The higher efficiency of the own vehicle routes lead to better solutions in general. But if $\tau$ is set too large, the planning process tries to fix the plan for too many requests and it becomes unresponsive to dynamics.

Last but not least, request exchange enables in all scenarios a stable improvement of the route efficiency beyond the increment of the degree of usage of the own fleet. The efficiency of the vehicle routes can be measured by the parameter $\eta _K$, which is defined as the ratio of total driven distances with loads to the total route lengths of all vehicles in $K$, where $K$ is the entire vehicle set of the coalition. The absolute improvement of route efficiency $\varDelta _{\eta _K}$ through request exchange by CTP and the number of additional requests fulfilled with own vehicles $\varDelta _{\xi }$ are given in Table 4. The saved $OC$ at the same time overcompensate the increment of $RC$ and result in better plans.

Table 4 Route efficiency: comparison between IP and CP

5.3 Performance of RHP-RT

The performance of the second framework variant RHP-RT is analyzed and compared with that of RHP-INT. Since FLP-II performs equally well as FLP-I but requires significantly less computational efforts, only FLP-II is used in the following simulations. In order to enable a fair performance comparison between RHP-RT and RHP-INT, the same lengths $L_{PH}$ of PH as those tested previously in the performance study of RHP-INT in Sect. 5.2 are used here, too. We can introduce a fictive PP with the duration of $L_{PH}/2.5$ and use the same weight function as introduced for FLP-II.

Different to RHP-INT, the number of plannings of RHP-RT does not depend on $L_{PH}$ but on the number of requests and the average number of requests of the 30 test cases is 1,767.4. As some requests have the same due time and several requests are planned at once at $t=0$, the number of actually performed plannings in the entire time horizon is somehow less than the number of requests and accounts to 1,442.13 on average.

Table 5 shows the results of the simulations. It can be observed that the results of RHP-RT are worse than those obtained by RHP-INT (FLP-II) shown in Table 2. The total costs in scenarios IP and CP are on average 1.20 and 1.23 % higher whereas the relative cost-savings defined by CP remain on the same level as those of RHP-INT. The high frequency of planning strongly degrades the performance of CTP and results in an increment of total costs of 3.83 % and a loss of efficiency of the CTP of about 38 % on average. The best results in each of these scenarios are achieved with the largest simulated value of $L_{HP}=325$, which is equivalent to $\tau =150$. The length $L_{PH}$ of the PH is no more irrelevant to the solution quality achieved in scenarios IP, CP, and CTP: while the performance of CTP remains the same with all tested $L_{PH}$-values, a cost reduction of 1.39 and 0.65 % can be expected by changing $L_{PH}$ in the IP and CP scenarios, respectively.

Table 5 Results of FHP-RT

As RHP-INT performs better than RHP-RT with respect of the solution quality, RHP-INT is used in the following simulations for further analysis.

5.4 Planning with high subcontracting costs

Subcontracting cost is an important factor in the DCFPDPF which influences the results a lot. An increment of this cost will boost the pressure on forwarders to exploit their own fleet more intensively. We simulate the situation when freight charges for subcontracting requests are increased by 50 %, i.e., the value of $\varphi$ used for generating the test cases is increased from 2 to 3. In this case, subcontracting becomes so expensive that for a given request $r$ with the travel distance $d_{r^+r^-}$ the freight charges for outsourcing can cover almost the vehicle cost for traveling a distance that is three times as long as $d_{r^+r^-}$. Such extremely subcontracting costs force the planning to avoid any outsourcing whenever the capacity of the fleet is not exhausted.

Table 6 Results of simulation with high subcontracting cost

The results are given in Table 6. Compared to the results in Table 3, the total costs $TC$ increase on average by 22.34 and 18.64 % in IP and CP, respectively. That means request exchange can mitigate the effects of high subcontracting costs. The fact that significant smaller $\tau$-values 75, 50 and 50 are now the ones that result in the smallest $TC$ in IP, CP and CTP recommends a higher frequency of planning.

Comparing the composition of costs in Table 6 with Table 3, it can be observed that due to higher subcontracting costs the increment of the total route costs $RC$ is stronger for IP than for CP and conversely the increment of the outsourcing costs $OC$ is stronger for CP than for IP. It can be explained by the fact that the higher degree of vehicle utilization reached for CP limits the potential to shift requests from subcontracting to the own fleet. The higher total costs also lead to higher cost-saving potential $(\varDelta _1)$. However, the efficiency of the collaborative approach $(\eta )$ becomes slightly lower due to the increased difficulty of the planning.

The extent of transportation service realized by engaging subcontractors can be quantified by the total amount of freight charges paid for the subcontracted requests. Although the freight rate is increased by 50 %, the total amount of freight charges paid to subcontractors is only increasing by 33.07 % for IP and 40.66 % for CP, and not by 50 % which would have been expected if the share in total transport volume realized by subcontracting would remain unchanged. This means that the subcontracted transportation volume (measured in freight charge with a fixed freight rate as uniform reference value) decreases if the price for subcontracting is raised. The number of subcontracted requests also reduces significantly by 8.41 % on average for IP and 3.13 % for CP. Interestingly, in case of CTP and for small $\tau$-values from 25 to 75, raising the freight rate has the effect that the number of outsourced requests is increased while the total freight charges are reduced. On average 3.80 % more requests are outsourced to common carriers. The reason for this is that the CTP approach compares the freight charges with the potential route costs only for due requests. Due to small $\tau$-values and short PP the potential of bundling these due requests is strongly limited so that in most cases the costs of fulfilling only one or two requests using own vehicles are compared with the freight charges. In case of high subcontracting rates, the CTP approach predominantly subcontracts transportation requests with short distances and uses primarily own vehicles to fulfill those with longer distances, because the longer the transportation distance of a request is, the more freight charges can be saved by serving it by self-fulfillment.

5.5 Planning with increased capacity

The capacity of the own fleet is another important factor that influences the planning. We simulate the situation when the number of available own vehicles is increased by 50 %. Table 7 shows the detailed results. The additional vehicles create more potential of bundling requests in routes which can be better exploited by request exchange. Compared to the results in Table 3, the total costs $TC$ can be reduced on average by 5.92 and 7.71 % in IP and CP, respectively. The increment of $TC$ is over compensated by the reduction of $OC$. The expansion of the fleet does not significantly influence the choice of the $\tau$-value.

Table 7 Results of simulation with high fleet capacity

The potential cost-savings $(\varDelta _1)$ show that the cost reduction can be increased by expanding the own fleet. An interesting observation is that the CTP efficiency $(\eta )$ in some cases even exceeds 100 %. In this case, the collaborative approach for dynamic scenarios can be considered as an alternative solution methodology for the ALNS heuristic used for CP. However, the time consumption of the CTP approach accounts to about twice as much as that needed by the ALNS.

5.6 Influence of distribution of request length

The last factor analyzed in our simulation study is the distribution of the request length $d_{r^+r^-}$. The distribution of requests simulated so far can be regarded as a Bernoulli distribution shown in Fig. 3a, which is depicted using all requests of the 30 test cases. To analyze the influence of the distribution, we generated 30 new test cases with the request length uniformly distributed from 0 to 200. Figure 3b shows the distribution of these new test cases. The means of the 53477 requests of all 30 new test cases of the uniform distribution is 94.57 and slightly higher than the average length of the 53022 requests of the Bernoulli distribution which accounts to 92.30.

Fig. 3

Distribution of request length $d_{r^+r^-}$. a Bernoulli distribution. b Uniform distribution

Table 8 Results of simulation with uniformly distributed request length

The results of this simulation are given in Table 8. Compared to the results in Table 3, the total costs $TC$ are higher due to the larger number of requests but unchanged fleet capacity. The trends of the costs are quite similar to that of the results in Table 3, and the best results are obtained with exactly the same $\tau$-values. This indicates only an insignificant influence of the distribution of request length on the choice of the best $\tau$ setting. The subcontracting costs $OC$ increase more than the route costs $RC$ with small $\tau$ in IP. With larger $\tau$-values, the routes can be generally more efficiently planned and the $RC$ also increase considerably and account for up to over 60 % of the increment of $TC$. Both the potential cost-savings $\varDelta _1$ and the efficiency $\eta$ here are slightly lower than those in Table 2, but a statistical difference cannot be concluded.

6 Conclusions

Forwarders can improve their operational efficiency by integrating external transportation resources into their planning processes. Besides outsourcing requests to common carriers, they can also set up horizontal coalitions with fellow companies and perform CTP. The static CTP has been studied for different situations in the last decade. However, little research has been conducted to study CTP in a dynamic environment, which is a more challenging task in the research on transportation logistics. In order to fill this gap, the DCFPDPF is introduced and solved using two RHP approaches in this paper. For the approach RHP-INT, a new planning is triggered by a fixed interval between two consecutive planning processes. The approach RHP-RT uses another trigger for new planning which is the actualization of request status.

A comprehensive computational study on the DCFPDPF has been conducted to evaluate the proposed approaches and to derive some practical suggestions for forwarders: First, CTP outperforms IP by far in all simulations and the coalition can always expect the similar amount of cost-savings by CTP in almost all cases independent of the applied approach and the parameter settings. Second, if forwarders can get the request information in advance, they can improve their plans. However, they can ignore the requests that are to be fulfilled in the far future without worsening the solution quality. Third, the choice of the proper approach and configurations significantly affects the results. RHP-INT outperforms RHP-RT in terms of solution quality. Fourth, stable percentage cost-savings through CTP indicate that CTP has no disturbing effect on the tuning of the planning techniques by choosing promising configurations for the planning techniques. Altogether, forwarders can improve their efficiency on three ways: CTP, forward-looking planning, and choosing adequate configurations. Comparison of these ways shows that CTP has the strongest effect on improving efficiency. Individual planning settings that have proved to be successful can be used for deriving proper configurations of the CTP in coalitions by simulation studies.

Through the analysis of the influence on the planning results of specific factors, more information can be obtained. If the costs of applying common carriers increase to an extremely high level, short intervals should be chosen for the RHP. In this case, CTP can better compensate the increasing freight charges of common carriers. Increasing the capacity of the own fleet can reduce the total costs and increase the potential of cost-savings through CTP. Finally, the tested distributions of request length in our simulation study affect little the results in all respects and need not be considered separately in searching for the proper configurations of the CTP.

The dynamic CTP approach using the adapted route-based request exchange mechanism of Wang et al. (2014) is proven efficient in realizing the cost-saving potential embedded in collaborative planning and is better compatible with the planning framework RHP-INT.

Our study on the DCFPDPF can help better understand the CTP of forwarder coalitions in dynamic environments and appeal to more intensive studies in this area. A limitation of the proposed approaches is that they focus only on the latest possible time to start the services. The earliest time that is the beginning of the time window is ignored. In the future research, the possibility of assigning requests with wide time windows that can be fulfilled before they become urgent has to be considered. Another challenging work is to consider LTL requests in dynamic CTP.