## 4 Positioning the LDAF in Fog Architectures  
There are several options for deployment of LDAF server in current and future communication networks. These options differ in their level of network integration. They can range from  
1. Function reachable through the network and implemented at (external) application servers, which are only connected, but not really integrated in the network infrastructure, and
2. Function provided by the network, where LDAF is a functional component of, e.g., the 4G/5G network. Applying LDAF as an additional application server reachable through the network is a straightforward approach. It is independent from the underlying network infrastructure. The network is merely providing internet connectivity from end devices to the LDAF proxy. In LoRaWAN the application servers are already foreseen in the architecture. We tested this approach with a LoRaWAN TTN platform. In a similar manner the current 4G and emerging 5G networks provide channels to external internet servers and applications. This approach however, cannot fully exploit the possibilities that would appeared if LDAF were integrated into the network infrastructure. The benefits of integrating LDAF in the network infrastructure--and thus the gateway being a function provided by the network--may include the following. 1. Proximity of computational and storage resources to reduce latency and backend traffic. 2. Collaborative sensing where LDAF would implement initial data preprocessing and aggregation of messages or streams from several end devices. 3. Switch to non-IP data delivery for the end device for further traffic optimization. Figure 3: Message type definition for the Ethereum—based smart grid switch and counter service. * Information about the status of the radio-access network (RAN) for dynamic LDAF services or near-real-time application-aware performance optimization of the LDAF services. * Context awareness of the services, where context can reach beyond traditional cookie or location--based adaptations. LoRaWAN network architecture is typically laid out in a star-of-stars topology, in which the gateway is a transparent bridge relaying messages between end devices and a central network server in the backend. Gateways are connected to the network server (NS) via standard IP connections, while end devices use single-hop wireless communication to one or many gateways. The network's server hosts all the intelligence; it manages packets from different gateways and sends them to the specific application server. In LoRaWAN, LDAF could become a part of the network server. A similar approach was taken in [43], where the NS blockchain management of end devices was built into LoRaWAN architecture. LDAF services in NS could rely on the network and device status provided by the NS and thus adapt service operation. The LDAF could, e.g., pass on the time-insensitive information only when the end device wakes from sleep mode for other communications, without additionally awakening it. In mobile edge computing (MEC) [44], Evolved NodeB (eNB) and Next-generation NodeB (gNB) not only provide radio access, but can host the fog nodes that execute a part of the application's functionality at the edge of the network. A new feature of LTE and 5G networks, as compared to 3G, is the exchange of data flows directly among the neighboring NBs. These would enable new use cases and applications like computation offloading, distributed content delivery, web performance enhancements, and application-awareness and optimization for IoT [45]. The LDAF server placed at the NBs could, e.g., aggregate and exchange data from various end devices, including those connected to different radio nodes. Besides, the network slicing mechanism [46] completely separates the network service provision from the actual physical infrastructure. The network, storage, and computational resources can be dynamically allocated in a network slice.