# Dynamic Packet Duplication for Industrial URLLC
## 3 Proposal
### Implementation Considerations  
While the measurements in this paper were performed on simulations, it is important to discuss the issues that arise when this implementation is ported to the real world, in a real MN and stock UEs. Specifically, in this subsection, the aspects on data collection requirements, the need for retraining and the hardware and software requirements both on the MN and the UE are discussed. Regarding the data, the ML algorithm requires data on KPIs and S-KPIs. KPIs are easily collected by the Network Monitoring System (NMS), which is part of the maintenance systems of the MN. The S-KPIs are harder to obtain, since they require the collection of data in the UEs. Therefore, to obtain real values, a measurement campaign must be done, including UEs with the appropriate software for capturing and transmitting the S-KPIs. Another important aspect is the need for retraining the model to adapt it to changes in the environment. The validity of the model depends on variations in the behavior of the features that are used in it, which determine the relation between the independent and dependent variables. Second-order effects, such as contextual factors that are not included in the model (e.g., geometry of the buildings, weather conditions, power supply variations etc.). These effects are out of the scope of the tests in this paper; however, on real tests, the required frequency of retraining would be an important parameter to study. To implement the proposed functionality in reality, some hardware and software requirements are posed over both the MN elements and the UEs. Specifically, in the MN, the software for data collection (KPIs and S-KPIs), as well as the ML algorithm and the estimator (described in Figure 2) must be implemented in some element of the network. An important aspect to take into account is the latency of the decision. There are two possible implementations:  
* Implement the data collection and ML stages in the network core. The main advantage is the availability of large datasets that add diversity to the final model. Another advantage of this method is that cloud computing resources can be used better. This is even more important when looking ahead to future 6G networks, where network elements in the core network for ML and AI are envisioned. * Implement everything in the network edge. In this case, to gain diversity, a Federated Learning (FL) mechanism can be used to share model parameters between different agents. FL is the collaborative learning, which trains and updates the model through the joint effort of multiple servers that are deployed in a decentralized manner within the network. In both of these cases, the estimator will run in the network edge to minimize latency in the decision, the KPI collection will be done in the network edge due to the nature of the task, and the S-KPI collection will be done in the terminals. All these software elements must be supported by the appropriate hardware equipment. While ML is hardware intensive, the estimator has a low demand in resources. Regarding the UE, the hardware and software requirements are quite low. Specifically, the devices must implement a functionality for capturing S-KPI information and sending it to the MN (to wherever the data collection function is implemented; either in the edge or the core). While the requirement is quite low in terms of hardware and software, it has some complications in the form of privacy and confidentiality issues. Therefore, it is expected that the use of UEs with the appropriate software is limited to a reduced set of devices acting over a predefined period of time. Ownership of the network will also play a central role for this aspect; if the user (in the case of industry, the owner of the factory) is also the owner of the network equipment where the data is collected (edge or core), then it is likely that the rate of penetration of the S-KPI probes is higher in the installed base of UEs and more stable in time.