# On Maximizing the Probability of Achieving Deadlines in Communication Networks
## 6 Simulation Implementation
### Network Layer (NET)  
When a packet becomes available at the NET for transmission, the deadline-aware routing table is looked up, and the packet is passed down to the DLL. Generating adequate routing tables in the simulator relies on three key processes at the NET: estimation of the link delay PDFs, the exchange of CDFs between neighbors, and a mechanism for avoiding the \"count to infinity problem\". Each process is described below.  
Estimation of link PDFs: Both proposed algorithms require knowledge of the probability distributions of the link delays seen at the NET between neighbors (see Equation (1)). Because, in practice, these PDFs are unknown a priori, they must be estimated and updated regularly. For this, link delays are measured (1) actively by means of probing packets and (2) passively by harvesting delay information from transmitted data packets. Probing packets are unicast by each node to all their neighbors every 120 s.  
Link delays observed by the DLL are stored as histograms at the NET. The histograms consist of 101 bins, where the first 100 bins are uniformly distributed for times from 0 to the initial TTD. Bin 101 counts the number of observed delays above that time, including the count of packets discarded at the DLL.  
The link delay PDFs are determined by dividing the number of measured delays in each bin by the total number of measured delays. This quotient is then multiplied by the packet delivery ratio of the respective link.  
Exchange of CDFs among neighbors: The two proposed algorithms require a regular exchange of DAP-CDFs between neighboring nodes. For this, the broadcasting of CDFs is performed at regular intervals of 5 s.  
Preventing the \"count to infinity problem\": We have observed for both algorithms that the DAP-CDFs are slow to incorporate evolving link statistics. As a consequence, the exchanged DAP-CDFs may provide an inaccurate snapshot of the network's actual link statistics. With the ADPAD, this simply delays its convergence. However, for the AMPAD, it may lead to routing loops in a similar fashion to the \"count to infinity problem\" of distance vector routing (Section 5.2.4 in [37]). In order to avoid this effect and avoid routing loops, we propose using a solution based on an aging sequence number, whereby every node starts with a sequence number with a value of zero and attaches it to every transmission of DAP-CDFs. The destination node increments its own sequence number every 120 s. This increment propagates through the network in a flooding fashion when the DAP-CDFs are exchanged. Each time a node receives a new DAP-CDF from a neighbor, it inspects the enclosed sequence number. If it is larger than its own sequence number, then the following processess are carried out:  
1. The node's own sequence number is updated to the newly received sequence number.
2. A new empty routing table (\"scratch table\") is allocated (but not yet used). This table will be updated several times by the steps explained below. It will become operational (i.e., used for forwarding decisions) the next time it receives a sequence number greater than its own (when these steps are applied the next time and a new scratch table is allocated).
3. All locally stored DAP-CDFs of the neighbors are erased.
4. All link PDFs are calculated from the current histograms.  
In the previous case, and in case the received sequence number is equal to the node's own number, the DAP-CDF is updated locally according to lines 12-14 and 16 of Algorithm 2. The scratch table is updated every time according to line 15.  
Finally, when the received sequence number is smaller than the node's own sequence number, then the received DAP-CDF is considered outdated and ignored.