## 4 Scenarios
### Targeted Application and Security Protocols  
The promise of the Internet of Things to connect physical objects to the Internet has not been entirely fulfilled so far, with parts of the Internet protocol stack being rather unsuitable for constrained networks and devices. However, IPv6 would be an important enabler for the IoT. IPv6 allows IoT devices to be uniquely addressable without having to work around all of the NAT issues. In addition, if the IP was supported by constrained networks and devices, there would be no need to develop tailor-made solutions for each new application and radio technology, allowing the deployment of IoT solutions to be eased and accelerated. Interoperability comes at a cost as these features add a certain overhead to the raw data. In addition to using the IP, application layer protocols can provide an additional level of interoperability by enabling devices to communicate and work together seamlessly. An example of a well-known protocol that is used in metering is DLMS/COSEM [39]. DLMS (Device Language Message Specification) defines the semantics and the syntax of a language used to provide an interoperable environment for exchanging metering data. DLMS supports applications such as remote meter reading, remote control and value-added services for various measurements, such as electricity, water or gas. The COSEM data model provides a view of the functionalities available on the meter via the communication interfaces. Due to its popularity in metering, we consider DLMS/COSEM at the application layer of the protocol stack. The UDP is selected at the transport layer due to its low overhead. The combination of DLMS application models and the IP over NB-IoT transport, leveraging SCHC, delivers an interoperable and scalable solution for data exchange with utility meters and other IoT devices. Note that the commercial implementation of SCHC by Acklio [41] is used in this work. Due to the sensitivity of information sent by smart meters, security is of high importance. DLMS can work on top of the UDP, and UDP exchanges can be secured using DTLS, the TLS-based protocol for secure datagram transport [42]. For the sake of implementation, two DTLS configurations have been used in the measurements, depending whether SCHC is used or not. The one used in non-SCHC measurements is the default one that comes with the Python bindings of the MbedTLS library. It consists of DTLS 1.2 with various signature algorithms and with the following extensions: encrypt-then-mac, extended master secret and session ticket. In the case of SCHC, Acklio's custom configuration of MbedTLS is used. It uses the connection ID, encrypt-then-mac and extended master secret extensions. The connection ID extension is required to be able to connect to Acklio's platform (the SCHC server, called IPCore). Note that this feature will not have any impact on the results presented later since we do not consider session resumption but only full handshakes. Furthermore, an optimization has been added to Acklio's MbedTLS configuration that disables the usage of the Hello Cookie messages during the DTLS handshake. This is possible due to the SCHC environment, which provides a new IP address even when messages are sent over IP networks. In the case of the non-IP, i.e., NIDD, the IP address is not related to the cellular network but to the device and the server. In the case of the IP, a new IPv6 address is created over the existing IP. This optimization saves one uplink and one downlink and thus will lead to fewer transmissions and less energy consumption by the device. In the case of non-SCHC measurements, the DTLS encryption is carried out at the application level, i.e., only the DLMS message is encrypted. In the case of SCHC measurements, the DTLS encryption is carried out at the transport level. The application listening on the TUN interface first compresses an IPv6/UDP/DLMS packet into a SCHC-compressed packet that is then encrypted.