## 1 Introduction
We focus on smart meter readings received; the parameters to be altered are the number of smart meters and the sampling period with which the readings are requested. Smart meter readings are necessary for several use cases, which can be divided into 5 categories, namely the awareness, the market, the scheduling and control, the network services and the diagnostics category, as indicated in [12]. Each use case has different requirements for the smart meter readings. For example, the market category use cases, such as dynamic pricing forecasts, pre-paid contracts and multi-contract customer use case, that require smart meter data every 15 min. The same goes for the awareness use cases, such as the dashboard for consumption and production awareness, the consumption awareness and cost estimation use case, as well as for the scheduling and control use case, namely the monitoring for elderly people use case. On the other hand, there are many use cases that require frequent smart meter data reception. Such examples are: the real-time power curve visualization (awareness category), which requires data every second; the PV self-consumption with appliances and storage systems (scheduling and control category--requiring data every second); the peak shaving with appliances and storage systems (scheduling and control category--requiring data every second); the scheduling for appliances (scheduling and control category--requiring data every 5 s). To complete the picture, there are many use cases that require smart meter data with a frequency of 30 s up to 3 min, such as the warning for exceeding available power thresholds, load shifting with storage systems, load shifting with appliances, active demand for network issues, tertiary and secondary reserves, and the supply service anomalies monitoring [12]. It should be mentioned at this point, that smart metering applications entail many challenges apart from the communication perspective and the frequency with which data is acquired from them. Such challenges are cybersecurity [16] and big data volume [17] that need to be taken care of. In this paper, such issues are out of the scope of our research. With this work, we give an example of an interoperability use case on which the design of experiments is applied. Laboratory tests are also provided to give insight on how different parameters can affect system performance. In this example, the effect on smart meter message exchange by altering crucial parameters, such as the number of smart meters and the frequency with which the messages are requested, is examined. For this reason, lab experiments are run, and the limitations of a small-scale AMI system are examined. Interoperability is maintained in case the system works in the same way even if the parameters defining the message exchange are altered. By testing the limitations of the AMI system, interoperability is examined. The rest of the paper is organized as follows: Section 2 gives the use case description and the description of the interoperability testing methodology, while Section 3 gives the statistical design of experiments description. Section 4 presents the experiments executed, and Section 5 concludes the paper.