Information Technology Reference
In-Depth Information
R
p,a
i
=
R
p,d
i
R
p,n
. Then, the sets of all active, due, and non-due requests of
the entire coalition can be defined as
R
p,a
=
i
=1
R
p,a
∪
,
R
p,d
=
i
=1
R
p,d
,and
R
p,n
=
i
=1
R
p,
i
, respectively.
Based on the differentiation of requests according to their due time, two plan-
ning strategies concerning the information about future requests are defined.
Carriers may plan in either a myopic or a forward-looking way by considering
only requests in
R
p,
i
,(
H
= 1), or all requests known in
R
p,
i
,(
H>
1), respec-
tively. In a
myopic planning
(MY), only due requests are considered in each
planning. In case of
forward-looking planning
(FL), all requests known at the
planning time are taken into account in the planning. Considering the fact that
the plan for the non-due requests will be actualized in the next planning periods
and thus these requests are not equally important at that moment of planning
as the due requests, the importance of these two types of requests must be ac-
cordingly differentiated. This can be done by multiplying the outsourcing prices
for the requests with different weights according to their degrees of urgency. It is
worth mentioning that by setting the weight of requests that need to be served
after the next
H
planning periods to zero, the term
R
p,
i
can still be used for
the rolling horizon planning framework with a constant
H
. Thus, we also use
R
p,
i
to denote all known requests in the next planning horizon at planning time
t
p−
1
=(
p
i
i
1)
τ
. In the collaborative planning scenario, these two strategies can
be formulated by using the corresponding notations
R
p,d
and
R
p,a
.
−
4.2 Identification of Requests for Exchange
The first issue in applying the rolling horizon planning framework is to determine
the set of requests to be considered in each static planning and the set of requests
to be exchanged. This question can be easily answered in case of MY that deals
only with those requests in
R
p,d
. All requests in
R
p,d
are considered in the
planning and all of them are to be fixed assigned among the coalition members
through request exchange. For the FL however, all known requests
R
p,a
in the
next
H
planning periods are considered in constructing the plan. However, only
the most urgent requests, i.e., the requests in
R
p,d
, for which the plan must be
fixed, will be exchanged. Actually, MY can be realized by setting the weight for
all requests in
R
p,n
to zero and thus be regarded as a special case of FL in a
broad sense.
It is important to differentiate the requests to be considered and those to
be exchanged in case of FL. The reason is that each reallocation of requests is
associated with transfer payments among the members which are determined
based on 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
request information in advance should be considered in planning, the plan for
requests that are not urgent should not be fixed as soon as the plan is made [29].
Obviously, at planning time
t
=
pτ
, all requests that must be picked up in
the next planning period
p
+1, i.e., the service at their pickup locations must be
