3 COMPUTATIONAL
EXPERIMENTS
In this section, we describe the CETSP instances
and the computational evaluation of the proposed ap-
proach. Our algorithm is coded in C/C++ using Cplex
12.1 with Callable Library and was run on a 2.4 GHz
CPU with 2GB RAM. The running time for each in-
stance was limited to 2 hours. We have tested differ-
ent values of M (5000, 10,000 and 20,000) and ob-
served that its impact on the performance of the algo-
rithm is negligible. We decided to predetermine M at
a value of 10,000 in the implementation.
3.1 Data Instances
To build the CETSP instances, we randomly generate
graphs that imitate real street networks by the follow-
ing procedure:
• The coordinates of n vertices are randomly gener-
ated in a unitary square. Then a heuristic is used to
find the shortest tour passing through all the nodes
exactly once. This tour is a Hamiltonian cycle
and is used as a framework to construct the full
graph. The resulting graph is therefore strongly
connected.
• In order to imitate real networks, random arcs are
added to the current tour to reach a total number of
arcs m = nd, where n denotes the number of ver-
tices and d the ratio between the number of arcs
and the number of nodes, in such a way that: (i)
the arcs are not too long, and (ii) there is no inter-
section between any two arcs.
In our tests, we use the graphs with the num-
ber of vertices n ∈ {300, 400, 500} and the ratio be-
tween the number of arcs and the number of nodes
d ∈ {1.5, 2, 2.5, 3}. For each couple of n and d, we
have generated 10 different graphs. Arc costs are de-
fined as c
ij
kilometres, where c
ij
is the Euclidean dis-
tance between v
i
and v
j
multiplied by 5 to obtain an
average length of arcs close to reality (from about 0.2
to 0.4 kilometres).
Once the graphs are created, the CETSP instances
are generated by randomly positioning q = mt cus-
tomer nodes on the square containing the graph,
where m denotes the number of arcs and t the ratio
between the number of customers and the number of
arcs, t ∈ {0.5, 1, 5, 10}. Thus, for each graph, four
CETSP instances are created. The effective RFID ra-
dius r is set at a value of 150 meters. In order to en-
sure the existence of a solution, we delete all the cus-
tomers that can not be covered by any arc. We also
examine the impact of increasing the radius parame-
ter from 150 meters to 200 meters. To do this, we still
use the graph created with r = 150 meters but change
the read range to 200 meters. In other words, the arcs
and coordinates of the customers and vertices are kept
constant while r is increased.
For each value of r, we thus generate 480 CETSP
instances named ce-n-k-t, where n is the number of
nodes, k indicates the number of arcs and t is the ra-
tio between the number of customers and the number
of arcs. For example, ce-300-450-10 stands for an in-
stance with 300 nodes, 450 arcs, and t =10.
In order to analyse further the impact of customer
number on our algorithm, we use a customer reduc-
tion procedure. Given w
l
∈ W, let Z(w
l
) be the set
of arcs that can cover w
l
. Consider each pair of cus-
tomers w
i
and w
j
, if Z(w
i
) ⊆ Z(w
j
) then customer w
j
can be eliminated. This is because when we service
w
i
, w
j
is covered at the same time. Note that, the
number of remaining customers is also the maximum
number of arcs that have to be activated for covering
purpose.
3.2 Computational Results
Tables 1 and 2 present the characteristics of the in-
stances and the computational results obtained for
two different values of r (radius of AMR). They in-
clude the name of the instance and the average num-
ber of remaining customers after the reduction pro-
cedure (in columns 1 and 2). #ofOpt indicates the
number of optimal solutions obtained for each set and
OptVal the average optimal value (in km) for these
solutions. #ofIPIter presents the average, minimum
and maximum number of integer programming itera-
tions. Time shows the average, minimum and maxi-
mum running time (in seconds).
The results presented on Table 1 and 2 indicate
that the ratio between the number of remaining cus-
tomers and the number of arcs in graph is often be-
tween 0.2 and 0.5. Therefore, the number of arcs that
must be activated for covering purpose is smaller than
the total number of arcs and our instances are thus far
from a CPP.
As can be observed in Table 1, for t = {5,10} our
algorithm was able to solve all butone of the instances
with 1250 arcs. It was also capable of solving some
instances with up to 1500 arcs. But when t is smaller,
the instances become more difficult. This counterin-
tuitive behaviour can be explained as follows. When
the number of customers decreases, the number of
arcs that must be activated for covering purpose also
decreases. Thus, there are more potential combina-
tions to connect these ”covering” arcs. More MIP it-
AN EXACT ALGORITHM FOR THE CLOSE ENOUGH TRAVELING SALESMAN PROBLEM WITH ARC
COVERING CONSTRAINTS
235