## 5 Results and Discussion
### Implications of the Choice of the HAN Communication Scenario  
All three relevant HAN communication scenarios have been implemented and tested according to the introduced methodology, given the SMGW was compatible with the HKS. The HKS3, HKS4, and HKS5 have been implemented for the PPC SMGW and the HKS4 and HKS5 for the Devolo/Kiwigrid SMGW. For each HKS exemplary configuration profiles can be found in the Supplementary Materials. However, the implementation of the scenarios for each manufacturer showed that interoperability, a core objective of the TR-03109, is not guaranteed on the implementation level. In the course of the development of our prototype, the interaction and interfaces between GWA, SMGW and DSMgr/aEMP have been a main cause for implementation difficulties. In cooperation with the respective parties, the individual systems had to be extended. Discrepancies between the systems are based on the fact that interoperability is mainly addressed on a conceptual level and only to a limited degree on the implementation level. Furthermore, although the syntax of the communication profiles among the different SMGWs is the same, the semantics differ. An example is the specification of the destination address in the communication profile, where some SMGWs require a protocol specification (such as \"https\" in addition to an IP address and a port), and others do not. To put it in the wording of RFC 3986, sometimes a _scheme_ is required in addition to _authority_, sometimes not. This results in a different behavior of different SMGWs regarding the acceptance or rejection of profiles. The main insights for each of HKS3-5 are illustrated in the following:  
**HKS3 (CLS initiates connection):**: HKS3 is special in that it uses the SOCKSv5 protocol. This brings additional complexity, because a draft version of protocol \"SSL for SOCKSv5\" is used for authentication. Our implementation showed that the SMGWs not necessarily act according to the protocol. If the protocol requirements are strictly implemented, these problems should no longer occur in the certified SMGWs. The advantage of the HKS3 is its independence from the GWA. The necessary configuration profiles must be uploaded to the SMGW once, after which the transparent data tunnel can be initiated from the HAN whenever and as often as necessary. Only in cases of structural changes to the communication setup are new configurations necessary. Especially in consideration of the aspect that the aEMP needs the GWA as a service provider, the greatest possible independence is desired. Considering profitability, higher dependence will probably also have an impact on the service fees paid to the GWA. Furthermore, assuming the CLS is developed by the DSMgr, the DSMgr can define when and how often the transparent data tunnel is initiated by the CLS without relying on a third-party company as in HKS4 and with a higher degree of freedom opposed to HSK5. Considering that for many applications a continuously open communication channel is desired, two scenarios have to be distinguished. Firstly, a planned, scheduled re-establishment of the transparent data tunnel can be realized by predefined rules configured in the CLS, or can be actively triggered by the DSMgr via already established communication. Secondly, an unplanned re-establishment, e.g., in case of interruptions of the communication, can follow predefined rules configured in the CLS. This way, in HKS3, the CLS instance (and thus the DSMgr), can implement and control the re-establishment of the data tunnel according to their individual needs. In the cases of HKS4 and HKS5 this is different and a potential issue, as discussed in the respective sections below. Another relevant aspect is that each connection may be open for a maximum of two days before it is closed by the SMGW. This means that the transparent data tunnel must be re-initiated after a maximum of two days. Taking the system design into consideration, the traffic in the WAN is minimized as the connection is initiated in the HAN.