## 7 Traffic Traces Analysis  
### Basis of the Traffic Analysis Tool PRIME Analytics  
PRIME Analytics [40] is a cutting-edge software tool, developed within the scope of the OSIRIS project, which aims to assist DSO to remotely diagnose communications problems in their operative NBPLC PRIME networks by analyzing reports and logs provided by the deployed data concentrators. Figure 45 shows an overview of how PRIME Analytics works. Notably, it takes as input the standard topology report S11, a log with topology events and a log with traffic traces, and provides as output a set of graphs and processed data. Based on such processed data, network forensics analysis are made to determine whether a scenario is problematic from communications perspective or not, and to answer typical forensics questions in case it is problematic, such as why, where, and who.  
Figure 44: (**a**) Spectral signal without PRIME communications in test PVI1 (without filter); (**b**) Spectral signal without PRIME communications in test PVI2 (with filter).  
In this study, two parameters, obtained from the output of PRIME Analytics, are considered as figures of merit to evaluate the impact of the noise sources in PRIME communications and the effectiveness of the filter to mitigate such an impact:  
* Ratio between ALV_B and ALV_S (ALV_B/S): As Figure 45 shows, PRIME Analytics provides statistics of packet types based on the traffic traces log. The analysis performed in this study focuses on two types of packets in particular: ALV_B and ALV_S. ALV_B refers to the keep-alive messages that the data concentrator (the Base node in PRIME terminology) sends to the smart meters. The ALV_S refers to the answers of the smart meters (the Service nodes in PRIME terminology) to the keep-alive messages from the concentrator. The concentrator has independent counters to keep track of the number of ALV_B and ALV_S messages sent to and received from each smart meter. These counters are used to obtain statistics on the quality of the communications with each smart meter, as well as to proceed to unregister a smart meter from the network when the difference between them exceeds a given threshold. In addition, the concentrator configures a specific keep-alive timeout at each smart meter and, whenever any smart meter does not receive any ALV_B message during such a timeout, it proceeds to unregister from the network. Furthermore, if the smart meter is connected with the concentrator through one or more switches, the switch(es) would process the unregistration message, proceeding to remove that smart meter from their forwarding table. Therefore, the higher the difference between the ALV_B and ALV_S, the worse the conditions of the communications network, since this indicates that either the ALV_B messages or the ALV_S got lost. In the ideal situation, where no messages get lost, each ALV_B sent by the concentrator would be answered with the corresponding ALV_S sent by the appropriate smart meter, so the ratio between these two types of messages would be 1.
* Number of unregistered nodes: whenever a smart meter is unregistered from the network (no matter if the procedure is triggered by the concentrator or by the smart meter), the concentrator make a note of such an event in the topology event log. Therefore, by processing such a topology event log, PRIME Analytics calculates the overall number of unregistered nodes. This parameter is used in this study since it reflects the performance of the network: the higher the number of unregistered nodes, the worse the performance of the network. It should be noted that if the same smart meter unregisters from the network, registers to the network and unregisters again during the same test, both unregistrations count, since this provides indeed an idea of how harsh the communications are.  
Figure 45: PRIME Analytics simplified schema.