The core element of the optimization method is the OSRNaware lightpath allocation (OSNRLA) algorithm, which solves the problem of allocation of lightpaths satisfying given SNR requirements for an ordered set of traffic demands (denoted as
$\tilde{\mathcal{D}}$), which are processed one by one. The algorithm makes use of candidate routing paths
$\mathcal{P}\left(d\right)$ that are available for each demand
d. In OSNRLA, the verification of SNR is performed both for each candidate lightpath and for all already allocated and possibly affected lightpaths based on the actual allocation status of spectral–spatial resources in network links, which is maintained in a network state matrix
A. In particular, the allocation status of frequency slices in cores of particular network links is represented using the maximal freeoccupied block (MFOB) approach proposed in [
30] that utilizes a threedimensional matrix
${A}^{\left\mathcal{E}\right\times \left\mathcal{C}\right\times \left\mathcal{S}\right}$. Element
$A(e,c,s)$ corresponds to slice
s in core
c of link
e, and it represents the allocation status of slice
s (free or busy) as well as contains the information about how many consecutive slices (beginning from
s) have the same status as slice
s. By reading element
$A(e,c,s)$, the algorithm is able to determine either whether the requested number of consecutive slices is available for allocation of a lightpath or which slice is worth checking next. As shown in [
30], the application of MFOB speeds up considerably the searching for free spectrum resources.
A pseudocode of the OSNRLA algorithm is shown in Algorithm 1. In lines 2 and 3, spectral–spatial resource allocation state matrix (
A), the set of allocated lightpaths (
$\overline{\mathcal{L}}$), and the required number of slices (
z) are initialized. In line 3, a loop iterating over consecutive demands from the ordered set of demands (
$\tilde{\mathcal{D}}$) begins. In line 4, the best lightpath (
$\overline{l}$) selected for demand
d is initialized. In lines 5 and 6, respectively, loops iterating over candidate paths (
$\mathcal{P}\left(d\right)$) for demand
d and available MCF cores (
$\mathcal{C}$) are started. The beginning frequency slice (
${s}_{beg}$) of a candidate lightpath is initialized in line 7, and a “while” loop iterating over consecutive candidate slices starts in line 8. In line 9, frequency slot
f beginning from slice
${s}_{beg}$ and occupying
$N(d,p,c)$ consecutive slices is initialized. Here,
$N(d,p,c)$ represents the number of slices required to serve the bit rate of demand
d on path
p and core
c, assuming that the best modulation format that can be used on path
p is selected. In line 10, candidate lightpath
l is initialized with path
p, core
c, and frequency slot
f. In line 11, it is checked using the allocation state matrix (
A) whether spectral resources are available for lightpath
l in core
c in each link of path
p. If the resources are available, then subset
$\tilde{\mathcal{L}}$ of the already selected lightpaths (
$\tilde{\mathcal{L}}\subseteq \overline{\mathcal{L}}$) that might be affected by lightpath
l is determined in line 12. In line 13, it is checked whether lightpath
l and all possibly affected lightpaths (
$\tilde{\mathcal{L}}$) satisfy the QoT requirement by calculating their inverse SNR values, using Model (
3), and comparing them with allowable limits, as discussed in
Section 3.2. If the QoT of lightpaths is acceptable, then it is checked (in line 14) whether candidate lightpath
l has a lower beginning slice index than the best lightpath (
$\overline{l}$) found so far for demand
d. If so, lightpath
$\overline{l}$ is substituted with lightpath
l (in line 15) and the “while” loop is terminated (in line 16). Otherwise, if either spectral resources are not available or the QoT of some lightpath is not satisfied, then beginning slice
${s}_{beg}$ is updated to the next available slice (in line 18), and the candidate lightpath verification procedure (starting in line 9) is repeated. After all candidate path–core pairs have been processed, the best lightpath (
$\overline{l}$) found for demand
d is included into the set of allocated lightpaths (
$\overline{\mathcal{L}}$) and network state (
A) is updated in line 19. In addition, in line 19, the required number of frequency slices (
z) is updated if the ending slice (
${s}_{end}$) of lightpath
$\overline{l}$ exceeds
z. The algorithm terminates after all demands have been processed.
Algorithm 1 OSNRAware Lightpath Allocation (OSNRLA) 
Require: ordered demands $\tilde{\mathcal{D}}$, candidate paths $\mathcal{P}$ 
1:  Initialize resource allocation state matrix A 
2:  Allocated lightpaths $\overline{\mathcal{L}}\leftarrow \varnothing $, required number of slices $z\leftarrow 0$ 
3:  for all demand $d\in \tilde{\mathcal{D}}$ do 
4:  best lightpath $\overline{l}\leftarrow \varnothing $ 
5:  for all path $p\in \mathcal{P}\left(d\right)$ do 
6:  for all core $c\in \mathcal{C}$ do 
7:  frequency slice ${s}_{beg}\leftarrow 1$ 
8:  while $({s}_{beg}\le \mathcal{S}\left\right)$ do 
9:  frequency slot $f\leftarrow ({s}_{beg},{s}_{beg}+N(d,p,c)1)$ 
10:  lightpath $l\leftarrow (p,c,f)$ 
11:  if spectral resources are available in A for lightpath l then 
12:  $\tilde{\mathcal{L}}\leftarrow $ the lightpaths from $\overline{\mathcal{L}}$ that have a common link and a common slice and are carried on a neighbor core to l 
13:  if QoT estimated using Equation (3) is acceptable for all lightpaths in $\left\{l\right\}\cup \tilde{\mathcal{L}}$ then 
14:  if $\overline{l}=\xd8\vee {s}_{beg}\left(\overline{l}\right)>{s}_{beg}$ then 
15:  $\overline{l}\leftarrow l$ 
16:  break 
17:  else 
18:  ${s}_{beg}\leftarrow $ next available slice obtained from A 
19:  Include lightpath $\overline{l}$ into $\overline{\mathcal{L}}$, update network state in A, and update $z\leftarrow \mathrm{max}\{z,{s}_{end}\left(\overline{l}\right)\}$ 
Ensure: lightpaths $\overline{\mathcal{L}}$ satisfying QoT for demands in $\mathcal{D}$, the number of required slices (z)

Algorithm 1 returns a feasible allocation of lightpaths after processing the demands according to given order ($\tilde{\mathcal{D}}$). Since the lightpaths selected and spatial–spectral resources allocated may differ for different sequences of processed demands, the value of objective function (z), which represents the number of frequency slices required in the network, may differ as well. Therefore, as the value of z is subject to minimization, we execute Algorithm 1 a number of times, each time assuming a different order od demands $\tilde{\mathcal{D}}$, and we consider the solution with the lowest value of z as the best one and returned by the optimization method.
To drive the algorithm in its search toward the best order of demands, we apply a simulated annealing (SA) method [
31]. Namely, at each SA iteration, two randomly selected demands in
$\tilde{\mathcal{D}}$ are swapped, and Algorithm 1 is executed for the resulting order of demands. If the obtained value of
z is improved, it is considered as the best one and order
$\tilde{\mathcal{D}}$ is accepted as the current one; otherwise, order
$\tilde{\mathcal{D}}$ is accepted with certain probability, which decreases after each SA iteration. To control the performance of SA, two parameters are used: temperature
$\mathcal{T}>0$ determining the probability of accepting nonimproving solutions and cooling rate
$\rho $ representing the speed of decreasing the temperature in consecutive iterations, where
$0<\rho <1$. We consider that
$\mathcal{T}$ is initialized with the product of the value of
z obtained in the first algorithm iteration and a temperature coefficient (denoted as
$\tau $). After each SA iteration,
$\mathcal{T}$ is updated and takes the value
$\mathcal{T}\times \rho $. The probability of accepting nonimproving solutions is calculated as
${e}^{(z\overline{z})/\mathcal{T}}$, where
z and
$\overline{z}$ are objective function values corresponding, respectively, to the new and current solution. In
Section 6.2, we perform algorithm tuning to select the values of
$\tau $ and
$\rho $ that offer the best performance.
Eventually, to speed up the algorithm, we make use of multicore CPU capabilities and run a number of parallel threads (one per a logical CPU core), where each thread executes an instance of the SA method described above. For algorithm parallelization, we apply the cooperative with solution exchange (CSE) approach proposed in [
30]. In CSE, the best global solution (namely, best order
$\tilde{\mathcal{D}}$ and best value of
z) is shared between the threads. Whenever improved, this best global solution is updated and distributed among the parallel instances of SA that consider
$\tilde{\mathcal{D}}$ as the current order of demands. As shown in [
30], a parallel simulated annealing (PSA) algorithm allows significantly decreasing computation times.
In the next section, we analyze the performance of the above presented OSNRaware lightpath planning method—referred to as OSNRLAPSA—by means of numerical experiments run in various network scenarios.