Research and Innovation Action Flex5Gware Flexible and efficient hardware/software platforms for 5G network elements and devices H2020 Grant Agreement Number: 671563 WP5 – 5G SW modules and functions D5.1 - System level architecture specification Contractual Delivery Date: 31 December 2015 Actual Delivery Date: 24 December 2015 Responsible Beneficiary: WINGS ICT Contributing Beneficiaries: UC3M, CNIT, IMINDS, IMDEA, NEC, TELECOM ITALIA S.p.A, TST, UNIPI, WINGS ICT Dissemination Level: Public Version: 1.0 PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the Flex5Gware Consortium. This page is left blank intentionally PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the Flex5Gware Consortium. H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Document Information Document ID: Version Date: Total Number of Pages: Abstract: Keywords: WP5 / D5.1 24 December 2015 71 This document defines the Flex5Gware software architecture. For this purpose, it examines several use cases and corresponding key performance indicators, extracting the relevant software requirements that are translated into concepts and design principles. The architecture is split into three functional layers, i) “Modular and flexible node operation”, ii) “Multi-node coordination”, and iii) “Intelligent programs”. The first layer deals with the abstraction of hardware and the definition of hardware-agnostic interfaces, the second layer provides the required control and management plane that enables a multinode technology-agnostic software operation, while the third layer includes innovative software programs that support the dynamic and autonomous management of the available resources. The aim of the architecture is to support a flexible, programmable and re-configurable operation of 5G networks. 5G, Abstractions, Architecture, Concepts, Coordination, Flexibility, Programs, Reconfigurability, Requirements, Virtualization. Authors Full Name Beneficiary / Organisation e-mail Role Vassilis Foteinos Panagiotis Vlacheas Orestis Liakopoulos Vera Stavroulaki Evaggelia Tzifa Aikaterini Demesticha Dimitris Kelaidonis Pablo Serrano Carlos Donato Javier Valiño Arturo Medela Giuseppe Bianchi Domenico Garlisi [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] Overall Editor Antonio Virdis WINGS WINGS WINGS WINGS WINGS WINGS WINGS UC3M UC3M TST TST CNIT CNIT UniPisa Giovanni Stea UniPisa [email protected] Contributor Dissemination Level: Public Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Contributor Page 3 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Antonio Frangioni UniPisa [email protected] Contributor Domenico Giustiniano IMDEA [email protected] Contributor Vincenzo Mancuso IMDEA [email protected] Contributor Ingrid Moerman iMinds [email protected] Contributor Bart Jooris iMinds [email protected] Contributor Felipe Huici NEC [email protected] Contributor Francesco Mauro TI [email protected] Contributor Full Name Beneficiary / Organisation e-mail Date Pablo Serrano Antonio Virdis Vincent Berg Miquel Payaró Dario Sabella UC3M UniPisa CEA CTTC TI [email protected] [email protected] [email protected] [email protected] [email protected] 02 December 2015 02 December 2015 14 December 2015 15 December 2015 18 December 2015 Reviewers Version history Version 0.1 0.2 1 Date 30 November 2015 09 December 2015 24 December 2015 Dissemination Level: Public Comments First internal review PMT review Final version Page 4 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Executive Summary This document defines the Flex5Gware software architecture. For this purpose, it examines several use cases and corresponding key performance indicators, extracting the relevant software requirements that are translated into concepts and design principles. The architecture is split into three functional layers, i) “Modular and flexible node operation”, ii) “Multi-node coordination”, and iii) “Intelligent programs”. The first layer deals with the abstraction of hardware and the definition of hardware-agnostic interfaces, the second layer provides the required control and management plane that enables a multi-node technologyagnostic software operation, while the third layer includes innovative software programs that support the dynamic and autonomous management of the available resources. The aim of the architecture is to support a flexible, programmable and re-configurable operation of 5G networks. Dissemination Level: Public Page 5 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Table of Contents 1. Introduction ..................................................................................................... 12 1.1 1.2 1.3 1.4 Objectives related to 5G SW modules and functions ....................................... 12 Scope and boundaries of System level architecture specification ................. 12 Methodology ......................................................................................................... 13 Structure of the document ................................................................................... 13 2. Overview of Flex5Gware use cases and requirement targets and relevance to the SW architecture ........................................................................................... 15 3. Requirements on 5G SW modules and functions......................................... 20 3.1 3.2 3.3 Requirements on intra-node operation (modules and interfaces) ................... 21 Requirements on multi-node coordination ........................................................ 22 Requirements on intelligent programs ............................................................... 22 4. Specification of the concepts and design principles for 5G SW modules and functions .......................................................................................................... 24 4.1 Vision and framework definition of the SW architecture .................................. 24 4.1.1 Softwarising radio operation ............................................................................... 24 4.1.2 Approach ............................................................................................................ 25 4.1.3 Functional architecture ....................................................................................... 26 4.1.4 Modular and flexible node operation ................................................................... 26 4.1.5 Multi-node coordination ...................................................................................... 27 4.1.6 Intelligent Programs ............................................................................................ 28 4.2 Concepts and design principles for intra-node operation (modules and interfaces) ......................................................................................................................... 29 4.2.1 Sensor node firmware and communication API .................................................. 29 4.2.2 Sensor node abstraction and communication..................................................... 31 4.2.3 Device level abstraction ...................................................................................... 33 4.2.4 Extended API for energy-aware operation.......................................................... 38 4.2.5 API for dynamic radio-frequency bandwidth ....................................................... 41 4.2.6 VM Manager and Node Function Virtualization .................................................. 42 4.3 Concepts and design principles for multi-node coordination ......................... 44 4.3.1 Capacity estimation mechanisms ....................................................................... 44 4.3.2 Positioning Algorithms for Context-Aware Networks .......................................... 46 4.3.3 Dynamic Functional Re-composition .................................................................. 48 4.4 Concepts and design principles for intelligent programs ................................ 49 4.4.1 Feedback loop of optimisation schemes ............................................................. 50 4.4.2 Architectures and algorithms for content dissemination ..................................... 52 4.4.3 Resource allocation in dense deployments ........................................................ 56 4.4.4 Performance-aware resource management ....................................................... 58 4.4.5 Energy-aware operation ..................................................................................... 59 4.5 Anticipated impact ............................................................................................... 59 5. Conclusions ..................................................................................................... 62 6. Appendix .......................................................................................................... 63 6.1 6.2 Device level abstraction – Background and starting point .............................. 63 TSAPI preliminary considerations ...................................................................... 67 Dissemination Level: Public Page 6 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 7. References ....................................................................................................... 69 Dissemination Level: Public Page 7 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 List of Figures Figure 1-1: D5.1 relationship with other WPs ......................................................................... 13 Figure 2-1: Use-case families, use-cases, and PoC mapping .............................................. 18 Figure 3-1: Requirements description template ..................................................................... 20 Figure 4-1: Reference framework architecture for the activities developed within WP5 ........ 26 Figure 4-2: Framework for the modular and flexible node operation ...................................... 29 Figure 4-3: Flex5Gware sensor node software architecture .................................................. 30 Figure 4-4: Sensor abstraction ............................................................................................... 32 Figure 4-5: Simplified version of 802.11 implementation in Linux kernel ............................... 39 Figure 4-6: Definition of the energy-aware data structure and a function to assign it ............ 40 Figure 4-7: New operations for cfg80211_ops ....................................................................... 40 Figure 4-8: Sample ARM and x86 Single Board Computers .................................................. 42 Figure 4-10: Virtualized function architecture. The VM manager is in charge of instantiating the virtualized function VMs, and the redirection module takes care of sending the data samples to the corresponding VMs. ....................................................................................... 43 Figure 4-12: N-queue CPS in which the service rate of each queue depends on the activity of any other queue. .................................................................................................................... 46 Figure 4-13: N-queue feed-forward network derived from a CPS. Service rates are not affected by the real activity of queues in lower stages of the feed-forward chain. ................. 46 Figure 4-14: Simple D2D scenario with 3 D2D pairs interfering with each other. .................. 46 Figure 4-15: Capacity region for the D2D network of Figure 4-14, computed with CPS and other methods for the case in which the pair (TX1,RX1) demands 47.5 Mbps. ...................... 46 Figure 4-16: Dynamic functional placement and partitioning ................................................. 49 Figure 4-17: Framework for the intelligent programs ............................................................. 50 Figure 4-18: Feedback loop of a optimisation scheme ........................................................... 50 Figure 4-19: Comparison of cellular load (D) of HYPE versus the optimal (ideal) strategy and heuristics proposed in the literature using San Francisco real traces and 536 users. HYPE performs closely to the benchmark provided by the optimal strategy and substantially outperforms previous heuristics ............................................................................................. 53 Figure 4-20: HYPE signalling load as a function of the number of nodes N for the four baseline scenarios. HYPE outperforms the previous heuristics and scales very efficiently with the number of nodes. ............................................................................................................. 54 Figure 4-21: Schema of the cloud-based distribution system. The central component of the cloud is the Dissemination service. ........................................................................................ 54 Figure 4-22: Comparison of saved bandwidth for different strategies. ................................... 55 Figure 4-23: Example of dense deployment ........................................................................... 56 Figure 4-24: Performance-aware resource manager ............................................................. 59 Figure 6-1: Workflow describing the four steps for creating a MAC protocol using the TAISC framework............................................................................................................................... 64 Figure 6-2: Overview of the TAISC architecture. Left: RAM memory blocks. Middle: logical processing unit. Right: ROM memory. ................................................................................... 65 Figure 6-3: Overview of TAISC registers. Similar to the registers one can find in micro controllers these are volatile and are updated by the TAISC modules. ................................. 66 Figure 6-4: Overview of TAISC events. These events can be used for the implementation of conditional radio programs. .................................................................................................... 67 Figure 6-5: TAISC CSMA/CA code example: use of the back-off instruction ......................... 67 Figure 6-6: Application structure and API linking ................................................................... 67 Dissemination Level: Public Page 8 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 List of Tables Table 2-1: Key performance indicators .................................................................................. 15 Table 2-2: PoC relationship to WP1 and WP5 ....................................................................... 19 Table 3-1: Requirements on 5G SW platform ........................................................................ 20 Table 3-2: Requirements on intra-node operation.................................................................. 21 Table 3-3: Requirements on multi-node coordination ............................................................ 22 Table 3-4: Requirements on intelligent programs .................................................................. 23 Table 4-1: Sensor node firmware requirements mapping ...................................................... 29 Table 4-2: Targeted requirements of sensor node abstraction .............................................. 32 Table 4-3: Targeted requirements for the device level programming abstraction and architecture............................................................................................................................. 38 Table 4-4: Extended API for energy-aware operation requirements mapping ....................... 39 Table 4-5: API for dynamic radio-frequency bandwidth ......................................................... 41 Table 4-6: Capacity estimation mechanisms: requirements mapping .................................... 44 Table 4-7: Positioning Algorithms for Context-Aware Networks: requirements mapping ....... 47 Table 4-8: Targeted requirements of the Dynamic Functional Re-composition (DFR) .......... 48 Table 4-9: Requirements for feedback loop of optimisation schemes .................................... 51 Table 4-10: Architectures and algorithms for content dissemination ...................................... 55 Table 4-11: Requirements addressed by the intelligent programs for resource allocation in dense deployments ................................................................................................................ 57 Table 4-12: Targeted requirements of the Performance-aware Resource Manager .............. 58 Table 4-13: Mechanisms – Use cases – KPIs – Impact ......................................................... 60 Dissemination Level: Public Page 9 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Abbreviations Acronym AP APIs CoAP CoMP C-RAN CS CDN CPU CSMA D2D DAGs ETSI FPGA FSM FW GPRAM GPRS GPS HAL HW IDE IEEE IETF IoT IPC IREB KPIs LTE MAC MEC NICs OPEX OS PHY PoC QoE QoS RAM RATs SDN SDR SW TDMA ToF UART USRP V2X Dissemination Level: Public Description Access Point Application Programming Interfaces Constrained Application Protocol Coordinated Multipoint Cloud-RAN Coordinated Scheduling Content Delivery Network Central Processing Unit Carrier Sense Multiple Access Device-to-Device Direct Acyclic Graphs European Telecommunications Standards Institute Field-Programmable Gate Array Finite-State Machine FirmWare General Purpose RAM General Packet Radio Service Global Positioning System HW Abstraction Layer HardWare Integrated Development Environment Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet of Things Inter-Process Communication International Requirements Engineering Board Key Performance Indicators Long-Term Evolution Medium Access Control Mobile Edge Computing Network Interface Cards OPerational EXpenditure Operating System Physical layer Proof of Concept Quality of Experience Quality of Service Random-Access Memory Radio Access Technologies Software-Defined Networking Software-Defined Radio SoftWare Time Division Multiple Access Time-of-Flight Universal Asynchronous Receiver/Transmitter Universal Software Radio Peripheral Vehicle-to-X Page 10 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 VM vRAN WARP WLAN WMP WP WPAN Dissemination Level: Public Virtual Machine Virtualized Radio Access Network Wireless Open-Access Research Platform Wireless Local Area Network Wireless MAC Processor Work Package Wireless Personal Area Network Page 11 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 1.Introduction As implied by the project name, a primary objective of Flex5Gware is flexibility. This is accomplished by means of i) highly reconfigurable hardware (HW) platforms targeting both network elements and devices, suitably controlled by ii) HW-agnostic software (SW) platforms and interfaces. A strategic project’s goal is to increase capacity not only through technology enhancements but also via (eventually dynamic) adaptation of the radio behaviour and operation to mutating context and environmental conditions. At the same time, we target reduced energy footprint, as well as scalability and modularity, to enable a smooth transition from 4G mobile systems to 5G. In this context, the purpose of WP5 “5G SW modules and functions” is to specify the interfaces, modules, and services, to support the flexible and reconfigurable SW-driven operation for 5G. The present deliverable D5.1 “System level architecture specification”, as a first deliverable of WP5, specifies the Flex5Gware vision of the SW architecture. For this purpose, use cases and requirements defined in WP1 “5G Architecture requirements, specifications, and use cases” are examined, focusing on the software-related aspects, in order to specify the requirements on 5G SW modules and functions. Moreover, the concepts and design principles for intra-node operation, multi-node coordination and intelligent programs are defined, taking into account the work in WP4 “5G Digital front-ends and HW/SW function split”. Based on the aforementioned efforts, the SW framework is defined, including the main blocks, functionalities and interfaces. 1.1 Objectives related to 5G SW modules and functions As already stated, the objective of WP5 is to detail the specification of the interfaces, modules, and services, to support a flexible and reconfigurable SW-driven operation for 5G Radio Access Technologies (RATs). It builds on the functionality provided by WP4, which depends on the corresponding technology considered, and extends it by specifying HW abstractions and building blocks to enable the orchestration of services and the development of new ones, supporting, among others, real-time re-configuration of the PHY parameters of RATs, Medium Access Control (MAC) protocol extensions, and distributed optimization schemes. In this way, there are two major objectives: Specification of a generic, HW-agnostic and programmable architecture, comprising generic SW modules and interfaces, which includes both the intra-node and the internode functional blocks and Application Programming Interfaces (APIs). Design and implementation of mechanisms/schemes for enhanced performance, energy savings, larger throughput, lower latency, and protocol operation tailored to users’ preferences. For these purposes, WP5 consists of four tasks that will provide the requirements, concepts and design principles of the Flex5Gware SW architecture (T5.1 “Requirements, strategies, and concepts for 5G SW modules and functions”), will specify the intra-node modules and offered APIs (T5.2 “Modular and flexible node operation”), will design and implement the required control and management plane (T5.3 “Multi-node coordination”) and finally will design innovative SW programs (T5.4 “Intelligent programs”). The proposed design and enhancements will be validated through the implementation of the SW architecture and new functionality (both new services and enhancements mechanisms), and the performance gains will be assessed in representative scenarios through experimentation. 1.2 Scope and boundaries of System level architecture specification In general, the studies in WP5 are influenced by WP1 and WP4, while the outcome serves as input to WP6 “Proof of concept in Flex5Gware” (Figure 1-1). WP1 provides use cases, requirements and Key Performance Indicators (KPIs), WP4 contributes through research on digital HW architectures and implementations and WP6 demonstrates the developed Dissemination Level: Public Page 12 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 technologies and services, in terms of proof of concepts. In particular, this deliverable, considers the work in T1.1 “Use cases and scenarios for 5G systems” and T1.2 “5G system requirements break-down”, ensuring the compliance with D1.1 “5G system use cases, scenarios, and requirements break-down”. Furthermore, it studies the efforts in digital architectures, i.e. T4.2 “Digital HW architectures optimizing spectrum and energy efficiency” and T4.3 “Digital HW architectures optimizing flexibility”, in order to build on top of the corresponding implementations. Integration and demonstration activities in WP6 will exploit the SW architecture that is defined in this deliverable. Finally, results and research findings are disseminated and exploited according to the plan described in WP7 “Dissemination, Standardization, and Exploitation”. Figure 1-1: D5.1 relationship with other WPs 1.3 Methodology The work in this deliverable started with the exploitation of the use cases and requirements defined in WP1. An overview of use cases was first provided, highlighting their relevance to the SW architecture. SW requirements were listed and classified into the three main categories of WP5, i.e. intra-node operation, multi-node coordination and intelligent programs. A formal Internet Engineering Task Force (IETF) format was followed for the description of the requirements. Based on this work, the vision of the SW architecture was drafted. Modules/blocks were selected and the interfaces were specified. The operation of the whole framework as well as the individual behaviour of the components was also examined. After analyzing the concepts and design principles for the modules in more detail, taking into account the envisioned enhancements to improve performance of 5G networks, the architecture was revisited and the framework was finalized. 1.4 Structure of the document This document is organized as follows. Chapter 2 presents an overview of Flex5Gware use cases, requirements and KPIs, emphasizing the aspects related to the SW architecture. Chapter 3 details the requirements on 5G SW modules and functions. Chapter 4 presents the functional SW architecture and analyzes concepts and design principles for the intraDissemination Level: Public Page 13 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 node operation, multi-node coordination and the intelligent programs. Finally, Chapter 5 concludes the document, summarizing the key points addressed herein. Dissemination Level: Public Page 14 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 2. Overview of Flex5Gware use cases and requirement targets and relevance to the SW architecture Based on the entry point given by Flex5Gware PoC definition and their envisaged requirements, WP1 has drafted the list of use case families and use cases identified as interesting and relevant for the project. By using Next Generation Mobile Networks (NGMN) and Metis-II as references for both naming and 5G use case families, WP1 proposes the following list of categorized use cases to be considered on Flex5Gware: Use case family: Broadband access in dense areas Use case: Crowded venues Use case: Dynamic hotspots Use case family: Broadband access everywhere Use case: 50+ Mbps everywhere Use case: Mobile broadband in vehicles Use case family: Massive Internet of Things Use case: Smart cities Use case: Performance equipment Use case: V2X communications for enhanced driving Together with the use cases definition, WP1 has also outlined a basic subset of KPI to be used on the project. This selection of key performance indicators is presented on the following table (Table 2-1). Each selected KPI is presented including a description proposed at WP1 side, highlighting the WP5 related items. Table 2-1: Key performance indicators KPI Flexibility / versatility / re-configurability Cost Energy efficiency Dissemination Level: Public Acronym Description and related Flex5Gware approach FVR The definition of this KPI has a quite broad coverage, and is related to the 5G requirement of an increase of HW versatility and reconfigurability, including the ability to operate at millimetre wave (mmWave) bands. As WP5 deals with software programs, it takes advantage of the above features, but does not enable them. CST This KPI is more HW oriented. Flex5Gware contributions will have a significant impact on the cost reduction with respect of the state-of-the-art of 5G handheld devices and network elements (e.g., base stations) via cost reductions mostly based on their HW components. Within WP5, proving the ability to use of virtualization techniques for base-station operations may pave the way for the use of generic hardware, which would cheapen costs. NRG This KPI is related to the power consumption reduction or the improvement of any performance parameter while keeping the energy consumption at the same level. In this case, it relates to WP5 work when improving the Page 15 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 way energy is spent at SW level (thanks to energyaware SW APIs, and virtualization / reconfiguration control functionalities), and supporting the dynamic selection of a trade-off between energy consumption and performance. Resilience continuity and RES For those scenarios where there are multiple RATs and service continuity and resiliency are critical, WP5 should provide the required intelligence (in terms of SW programs) to select the most appropriate RAT among those available –in particular, supporting a rapid transitioning when radio conditions drop. Also, thanks to the multi-node coordination SW layer, the reliability will be improved from a network perspective rather than from a single link point of view. MDV This KPI, related to the throughput provided to the user (uplink and downlink), is relevant to WP5 as via softwarisation (programmability and reconfigurability) of the communication means, and thanks to the reconfigurability of the platform, the system should adapt to the varying dynamic conditions to provide in the most efficient manner the maximum throughput available. To this aim, the programs will exploit context and performance information and configure the network accordingly. NoU Software programs will support increasing the number of connected subscribers through efficient handling of dense scenarios (hotspots, vehicular scenarios), e.g., with a dynamic partitioning of the macro-cells into smallcells that can be implemented by HW or SW via VM instances. BW This KPI is not very related to the activities in WP5, as it consists on HW improvements. Still, WP5 software applications will maximize the use and the allocation of the bandwidth in an efficient way with, e.g., scheduling algorithms, protocol layer re-configuration. LAT This KPI can be related to the network latency (round trip time) and also to the link latency (via, e.g., constraints imposed by the HW). The dynamic HW/SW function split together with the Analogue/Digital signal processing trade-off considered in Flex5Gware will contribute to reducing latency via choosing configurations that trade energy consumption with latency. Also, depending on application requirements, SW programs should change their operation to fulfil these (via e.g. exchanging energy savings for performance). Mobile data volume • • Aggregated data rate Coverage / ubiquitous access Number of users / connected devices Bandwidth • • Instantaneous bandwidth Operation bandwidth Latency Dissemination Level: Public Page 16 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 User data rate Integration / size / footprint UDR Like in the case of MDV, in WP5 the software programs will support an efficient use of network resources, which would contribute to maximising throughput, thanks to the information collected from the devices and the new HW capabilities. ISF While this KPI is mostly related to the HW footprint related to its size/volume, for the case of WP5 it will impose some constrains on the design of SW programmes. Therefore, WP5 functionality should be efficient not only in terms of performance but also in terms of resources such as CPU, memory, etc. All these KPIs, and their translation into use cases, are impacting the work expected from WP5. Together with PoCs, they will shape WP5 requirements and lines of investigation. To summarize all use cases, PoC and KPIs trying to relate to the WP5 activities, Figure 2-1 presents the relationship between use case families, use cases and PoCs. In addition, Table 2-2 provides the matching between WP1, WP5 and WP6, showing those Flex5GWare PoCs on which WP5 contributions have influence. a) Broadband access in dense areas Dissemination Level: Public Page 17 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 b) Broadband access everywhere c) Massive Internet of Things Figure 2-1: Use-case families, use-cases, and PoC mapping Dissemination Level: Public Page 18 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Table 2-2: PoC relationship to WP1 and WP5 PoC 7 8 9 10 Use cases Dynamic Hotspots Mobile broadband in vehicles V2X communications for enhanced driving Dynamic Hotspots Smart Cities Mobile broadband in vehicles V2X communications for enhanced driving Dynamic Hotspots 50+ MBps everywhere Dynamic Hotspots 50+ MBps everywhere Dissemination Level: Public KPIs FVR NRG UDR LAT FVR NRG NoU RES Intra-node operation Medium High Low Low High High Low Medium FVR LAT UDR NRG FVR UDR High Medium High Low High High WP5 task impact Multi-node Intelligent coordination programs Medium Medium High High Low Low Low Low High High Low Medium Low Low Medium Medium High Medium Medium Low Low High High Medium Medium High High Low Page 19 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 3. Requirements on 5G SW modules and functions This section describes the requirements on the design, performance and enhancements of the 5G SW modules and functions, taking into account the relevant studies in WP1 “5G Architecture requirements, specifications, and use cases”. These requirements will be translated into the specification and implementation of the SW architecture. In particular, they will be translated into design principles for the intra-node operation (Section 4.2), the multinode coordination (Section 4.3) and the intelligent programs (Section 4.4). The requirements are expressed based on the sentence template depicted in Figure 3-1, as suggested by the International Requirements Engineering Board (IREB). The keywords for the different levels of requirements follow the IETF guidelines [1]. Table 3-1 provides the requirements on the overall 5G SW architecture. In the next subsections, requirements on intra-node operation, multi-node coordination and intelligent programs are also presented. Figure 3-1: Requirements description template Table 3-1: Requirements on 5G SW platform ID SW-1 Requirement The SW operation must be energyefficient SW-2 The SW platform must support large diversity of applications The SW platform must improve QoE SW-3 SW-4 SW-5 SW-6 The SW platform must guarantee QoS for those flows admitted under certain requirements The SW platform should be hardware agnostic The SW platform must be able to adapt to demanding and changing contexts Dissemination Level: Public Description The ability to reduce energy consumption while maintaining the required performance. Different users, different IoT devices have different applications requirements The application requirements (application data rate, application delay, jitter at application level, data loss...) need to be mapped to QoS requirements in the network (e.g. min. throughput, network latency, jitter, network reliability). Then QoE is improved by satisfying these requirements. The network must guarantee the network QoS requirements, or reject the flow A SW platform developer does not require deep knowledge on the hardware platform The SW platform requires monitoring capabilities to identify the network context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes Page 20 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 SW-7 Generic SW building blocks should be provided SW-8 The SW platform should facilitate the scheduling of optimisations in a conflictfree manner The device must be re-programmable from the remote network or intelligent programs SW-9 Fundamental mechanisms that operate on top of heterogeneous hardware modules and can be reused by diverse applications. Scheduling and conflict avoidance Over the air re-programmability; HW-agnostic APIs 3.1 Requirements on intra-node operation (modules and interfaces) The requirements on intra-node operation are presented in Table 3-2. Apart from the modules, specific attention is given to the offered interfaces. These requirements will guide the work in Task 5.2 “Modular and flexible node operation”. Table 3-2: Requirements on intra-node operation ID Requirement Description IO-1 The device must be able to provide hardware abstraction from underlying hardware resources The abstraction layer should facilitate the dynamic selection of communication technologies and protocols according to context and goals The abstraction layer should have a generic front-end to facilitate the interplay with the remote network or intelligent programs The abstraction layer should have a generic back-end for accessing the hardware functionalities Abstraction realized through HWagnostic APIs IO-2 IO-3 IO-4 IO-5 IO-6 IO-7 IO-8 The device hardware should support virtualization extensions and the abstraction layer should provide interfaces to instantiate virtualized functions on the device. The abstraction layer should provide generic/uniform interfaces towards remote network/intelligent programs and hardware resources The device should dispose monitoring and context awareness mechanisms and relevant events (e.g. change detection, triggers, etc.) The device may react to intentional interference, such as jammer, in the same spectrum Dissemination Level: Public Flexibility, reconfigurability and energyawareness will be supported Local Resource Controller; for data formatting and provisioning to high-level entities Virtualization of functions; for accessing the functionalities provided by devices and for direct interaction with interfaces Virtualization of functions Generic/ HW-agnostic/ uniform interfaces Monitoring agent; ability to collect and process measurements at multiple levels (channel, sensors, higher layers) Decisions in the Local Resource Controller Page 21 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 3.2 Requirements on multi-node coordination Table 3-3 summarizes the requirements on multi-node coordination. In general, the studies in this area should enable a multi-node technology-agnostic SW operation, as well as the coordination in real-time of the different SW modules that are available across multiple nodes. Table 3-3: Requirements on multi-node coordination ID MC-1 MC-2 MC-3 MC-4 MC-5 MC-6 MC-7 MC-8 MC-9 MC-10 MC-11 Requirement The control and management plane should remove the current repetition of functionality among multiple layers, technologies, and elements The SW platform must be flexible, reprogrammable and reconfigurable and support dynamic functional composition The SW platform must provide global acceptable solutions that prevent instabilities/conflicts/competitions The coordination among nodes must be supported from both the management/control plane and the node itself The device should offer models for: nodes/components, communications and (functional, reconfiguration) behaviour The SW platform must be able to enforce decisions and policies The SW platform should verify the effectiveness of its decisions and configurations The SW platform should allow the coordination of heterogeneous and multi-technology nodes The SW platform must be able to extract context in order to take optimal solutions The SW platform must reconfigure the wireless network card in less than the “default” operation timescale of the protocol (e.g., beacon interval time for 802.11) The SW platform should fix the information length exchanged between Local Resource Controller and Remote Network Controller Description Functional re-composition of generic and reusable building blocks Dynamicity, flexibility, over-the-air reprogrammability and reconfigurability Multi-node coordination Cooperative control Existence of models, critical for hardware abstraction Configuration, policy translation and enforcement Feedback mechanisms Coordination of heterogeneous and multi-technology nodes Context extraction and awareness; Monitoring service; Aggregation of context information from multiple (heterogeneous) nodes Timing constraint configuration/reconfiguration Information length exchanged between layers 3.3 Requirements on intelligent programs Table 3-4 presents the requirements on the intelligent programs. In Flex5Gware, innovative SW programs run on top of the developments in the intra-node operation and the multi-node Dissemination Level: Public Page 22 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 coordination, supporting the dynamic and autonomous management of the available resources. Table 3-4: Requirements on intelligent programs ID IP-1 Requirement The intelligent program must fulfil high level policies IP-2 The intelligent program must exploit lower level context information IP-3 The intelligent program must take adaptive decisions on dynamic and autonomous management and configuration of the available resources The intelligent program should be able to communicate with the device/node directly besides the intervention of the multi-node coordination layer The intelligent program must make decisions within a specified deadline The intelligent program should make the best possible decision, unless this process requires breaking the deadline IP-4 IP-5 IP-6 IP-7 The intelligent program may exploit historical information on the system IP-8 The intelligent program should be able to make decisions with incomplete inputs Dissemination Level: Public Description Performance-awareness in terms of application/user requirements, QoS, energy efficiency, scalability Context-awareness in terms of changing conditions, ranging and position of nodes in the network, traffic levels/variations, HW capabilities; Monitoring library Resource management exploiting the multi-node coordination and intra-node operation offerings Direct communication between intelligent programs and devices/nodes The decision are possibly required by other system elements to correctly work The optimal decision might require more than the available time to be computed: in this case an intermediate solution should be provided Historical information may refer to measurements performed on the system over time (e.g. average number of users, information on peak-hours) It could be possible that not all the info is available at the intelligent programs side, but an intermediate solution should be provided Page 23 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 4. Specification of the concepts and design principles for 5G SW modules and functions As of Today, the flexibility of commercial wireless Network Interface Cards (NICs) is limited. As discussed later on in more details, the substantial work done in terms of software implementation of radio functions is only rarely associated with an effort to expose such internal implementation flexibility to third parties, via adequate programming interfaces. Indeed, when commercial NICs expose some tuning knobs, they are usually restricted to somewhat limited facilities for customizing and/or adapting a few parameters or thresholds, or activating/deactivating some advanced algorithms (e.g. Automatic Gain Control, Rate Adaptation, etc.). The situation in the current generation of Base Stations is slightly better, and especially with the migration towards C-RANs, a trend has started in extending the ability for operators to optimize and configure the BSs to adapt them to their needs. Still, this trend is at the beginning and it is usually carried out in the frame of specific platforms or products, i.e. without much attention to devise programming models which are independent to the underlying technological platform. Hence, further work is needed to permit third parties outside the manufacturer’s domain, i.e. the actual users of such technologies, to devise and enforce radical changes or customizations of low-level channel access mechanisms, scheduling techniques, and in most generality radio behaviour, so as to adapt them to the (possibly very specific and personalized) context and service needs, and with the possibility to “port” such customizations across different vendors’ platforms. The aftermath is that, as of now, wireless networks suffer from an extremely slow pace of innovation, bound to the slow process of protocols’ standardization and the therein emerging restrictions. This situation can be perhaps considered paradoxical, since the wireless community has been extensively working for as much as two decades (i.e. since the pioneering inception of cognitive networking principles from Mitola, in the nineties) on dynamic, software-based, reconfiguration of wireless devices, so as to more fully exploit the radio spectrum and to deliver data both faster and more reliably. Indeed, many valuable programmable radio platforms have been developed in the course of the past years, including but not limiting to research platforms such as GNUradio [2], WARP [3], USRP and relevant SW frameworks (GNUradio, LabVIEW [4], MATLAB, Simulink, Iris [5]) , SORA, AirBlue, ZedBoard/GR-Easy [6] (Zinq-capable version of GNUradio), and commercial software reconfigurable baseband platforms from NXP, CEVA, etc. and many other products in the C_RAN arena. Such research effort on software radio has brought remarkable scientific and technological achievements (such as finding the right mix of programmable hardware to support high performance signal processing in radios), and has brought us to the point where performance, cost, and power consumption figures appear ready (or at least very close) to enable a viable real world transition from radios with behaviour fixed in hardware to radios with behaviour determined by software. In what follows, we will describe how WP5 addresses the challenge of improving the programmability and reconfigurability of the operation of wireless nodes, with specific attention to the identification of platform-agnostic programming interfaces. To this aim, we will first provide an overview of the complete functional architecture, including the identification of one of its cornerstones, namely, abstraction, and then we will describe with more detail (following a layered approach) the functionality that needs to be provided to enable this vision. 4.1 Vision and framework definition of the SW architecture 4.1.1 Softwarising radio operation As described before, hardware capabilities are readily available to support software-based operation of radio interfaces. However, what still appears largely under-explored is the identification of abstractions and relevant programming languages which formally describe a Dissemination Level: Public Page 24 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 desired wireless operation, and which can be deployed across multiple vendors' platforms, irrespective of their internal implementation (be it FPGA or DSP or a proprietary ASIC). Indeed, as sharply sketched in [7], in the course of this twenty-years-long work, the wireless community has mostly neglected a vital question: how to describe the radio behaviour in a platform-independent manner. Using Craig Partridge’s own words: “One might imagine a lot of practical and theoretical work has been done on how to tell a radio how to behave and how a radio can describe its own behaviour. However, rather stunningly, little work has targeted this problem''. The advantages of a fully (and third-party) re-programmable wireless stack, opposed to the standardization of a specific radio behaviour (such as a fixed set of PHY/MAC functionalities or full-fledged protocols) buried inside the NIC implementation, are many. A protocol stack might not require anymore to be designed once for all, but the most appropriate protocol fitting the possibly very specific context at hands could be automatically downloaded upon need. Protocols would be simpler (for instance, why bothering with hidden terminals in contexts where there is none?), the radio behaviour could be steered by, and adapted to, time-varying context conditions, and backward compatibility would not be an issue anymore (all the stations in a same radio coverage could download from a same base station or access point the same radio stack, and run it). 4.1.2 Approach Conceptually, the way towards platform-independent programmability of radio devices entails three complementary steps: 1) the need to identify suitable device-level abstractions to formally describe a PHY/MAC protocol independent on the underlying platform, and the relevant ability to transform such a description into a software formalization (e.g. language) which can be downloaded inside the terminal, 2) the identification of a novel device architecture capable of “executing” such software formalization of the desired radio behaviour; in practice (as explained later on), capable of controlling and orchestrating locally implemented hardware primitives (TX, RX, schedule, sensor data acquisition, etc.); and 3) the development of a control and context monitoring framework devised to gather context information, take intelligent high-level network reconfiguration decisions, and trigger the necessary reconfiguration in the remote devices, thus including also dynamic reloading of new software-coded PHY/MAC functionalities. With specific reference to (3) and in part (1), the a careful reader will note several similarities with the new networking models emerging in the wired networking community, most notably the impressive rise of Software-Defined Networking (SDN). The last 6 years of research in this SDN field have underlined the crucial role of i) vendor-independent behavioural abstractions for the data forwarding plane, pioneered by the 2008 OpenFlow proposal, and ii) the complementary role of a logically centralized control systems permitting operators to have a unitary and virtualized view of network states, and significantly simplify (and further abstract) network management and control. However, in the wireless domain, we need to take further steps. First, when facing with distributed protocols such as those employed in WLAN systems, programmability and control cannot be limited to the base station or the access point, but must go down to the end user device (e.g. for changing the distributed MAC function operation). Second, we envision end user devices not only as communication devices, but also as “environmental probes”, hence further capable of providing a monitoring and sensing service which permits our centralized controller to gather context information and trigger relevant adaptation decisions. Third, the relative simplicity of the forwarding decisions taken by wired switches or routers (and duly modelled via simple abstractions such as the OpenFlow’s match/action one) significantly Dissemination Level: Public Page 25 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 contrasts with the much greater complexity of a wireless protocol or a radio behaviour model, which require new abstractions further capable of describing complex, stateful, behaviour (think for instance about a MAC protocol such as CSMA with binary exponential backoff, and its necessary reliance of a stateful operation), and the relevant ability to evolve such behaviour in time, hence the need for a novel device architecture identified in the above item (2). For all these reasons, the three steps highlighted above pose new specific challenges, well beyond the “usual” SDN model. We next describe how this SDN-like model is mapped as a functional architecture, which enables a centralized control of the different functions of the wireless network, by identifying the envisioned functionality within nodes and their interactions. 4.1.3 Functional architecture Our softwarised operation of a network consists on the functional architecture illustrated in Figure 4-1, which serves as the reference framework architecture for the activities developed within WP5. In that figure, we identify the most relevant functionalities that will be specified, some of these modules constituting key building blocks of Flex5Gware proof of concepts such as PoC 7, 8, 9 and 10. As the figure illustrates, the framework is split in three functional layers: “Intelligent programs”, “Multi-node coordination” and “Modular and flexible node operation”. We next provide an overall description of each of these layers, and then detail, in the following sections, the specific functionality to be provided by the modules. Figure 4-1: Reference framework architecture for the activities developed within WP5 4.1.4 Modular and flexible node operation In this layer, we specify the operation of the intra-node modules and offered APIs, through the abstraction of HW and definition of HW-agnostic interfaces to facilitate the interplay between SW modules and HW elements. The design of SW architecture will comprise generic SW modules and interfaces, removing the functional repetition among layers and RATs. This task takes as input the requirements on the system architecture specified in T5.1, and translates these into the technology-specific API provided by WP4. Functionalities of this Dissemination Level: Public Page 26 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 layer are directly related to several PoCs. In particular, PoC7 targets energy-aware communications and therefore, it exploits interfaces and energy-related concepts provided in this layer. PoC8 monitors hardware elements (Monitoring Agent) and aims at reconfiguring the nodes. The Radio Engine Manager/Radio Programs are suitable for this purpose. Moreover, virtualization technologies (VM Manager) are essential for PoC9. As this task is devoted to intra-node specification we define a device API for HW-agnostic operation. For that purpose, we cover an analysis and extension of existing technologies with the design of APIs at different protocol layers (FPGA-based developments, Wireless MAC Processor (WMP)-based extensions, SnapMAC [8] / TAISC [9] - based extensions). 1. Radio Engine Manager This module is responsible to configure/reconfigure the Radio Programs and the HW platform during the initialization of the radio or during the radio activity. 2. Radio Program This is where the logic for driving the HW platforms is specified and where the lowerMAC protocols, modulation/demodulation schemes or other processing operation over the HW, for instance spectrum scanning schemes, interference estimation schemes and localization schemes, are implemented. 3. Monitoring Agent Gathers values of specified metrics from the device/node and makes them available to the Monitoring Service located at Remote Network Controller layer. 4. Local Scheduler Using the local information about the channel conditions, the Local Scheduler performs resource scheduling to allocate the resources for the UEs. It can receive a global scheduling from the Global Scheduler module which is used in order to maximize the resources that are being served since the Global Scheduler is aware of the global state of the whole network. 5. VM Manager Provides an API to manage the virtualized functions running on the device (if any). Operations include uploading VM images and starting/destroying VMs. 4.1.5 Multi-node coordination The goal of this layer is to design and implement the required control and management plane to enable a multi-node technology-agnostic SW operation, i.e., develop the tools required to coordinate in real-time the different SW modules available across multiple nodes. This coordination comprises both the case of a node managing the operation of another node, not necessarily the next hop node, (e.g., infrastructure nodes changing the behaviour of mobile clients), and the case of two nodes coordinating their activities. PoC8 is related to the studies in this layer. The Dynamic Functional Re-composition module will be exploited for the functional re-composition purposes, while the Monitoring Service will provide access to the collected data. In particular, the following modules can be found in this layer: 1. Dynamic Functional Re-composition (DFR) Manages the reconfiguration process and decides the suitable functional composition exploiting models for nodes/components, communications and functional/reconfiguration behaviour. It can also enforce decisions in execution parts, interfaces and reconfiguration ports and it verifies the effectiveness of its actions by means of feedback mechanisms. 2. Monitoring service Dissemination Level: Public Page 27 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 This service provides interfaces to the client-side Monitoring library. It gathers data from the local monitoring agents of the devices and pushes them to the upper layer. This data can be available either as, raw measurements or in a more meaningful way after being processed. The Monitoring service also includes the Device Positioning module to apply different positioning algorithms in order to locate devices that use multiple wireless technologies with heterogeneous sources of noise. 4.1.6 Intelligent Programs This layer consists on the autonomous generation and invocation of services, according to the various application requirements and estimated network conditions. These optimizations take into account the virtualization of the resources, namely, both the wireless medium and computation capabilities, and the analysis of the required gains for 5G systems. PoCs will demonstrate the efficiency of the intelligent programs. In particular, PoC8 targets enhanced performance and manages the scheduling of resources, exploiting context information. Also, PoC10 is based on flexible resource allocation. 1. Monitoring Library This library provides several functions to the upper modules. Its main goal is to make available the current metrics and historical collection from the devices/nodes and offering them to the Resource Manager. In this way, the Resource Manager can build the current context and performance of the device in order to compute optimizations to adapt the system to the changes of the environment. This module plays a very important role, since it must provide a common format of the information independently of the radio platform that is running in the device. 2. Global Scheduler It is in charge to collect the information provided by the Local Scheduler running on the device and performs a schedule of the resources, in an efficient way, with this information. Once the schedule has been computed, the Global Scheduler reports its results to the Local Schedulers. 3. Context-aware module The objective is to concurrently improve the performance in two dimensions: networking and positioning services. The context-aware module collects information about device status (e.g. device position, network status) through the Monitoring Library and interacts with Radio Engine Manager for a MAC and PHY level reconfiguration with schemes that can adaptively reconfigure node parameters to meet the network requirements to and achieve better timing information for positioning algorithms. 4. Performance-aware module For enhanced performance and energy aware consumption, this module takes high level policy information, e.g. application/user requirements, QoS constraints, energy efficiency, scalability, etc. It also collects lower level information from the devices such as traffic levels/variations and/or HW capabilities directly from the Monitoring Agents located at the devices. With all of this information, it is able to provide a new reconfiguration for individual resources and management and configuration of multiple resources through the control plane module, Dynamic Functional Recomposition (DFR). 5. Service Scheduler The module is responsible for the synchronization among of the different modules located at Resource Manager. It is in charge to exchange and format the information in order to make all the operations consistent. Dissemination Level: Public Page 28 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 4.2 Concepts and design principles for intra-node operation (modules and interfaces) We next detail the functionality that will extend the operation of current nodes by taking as reference the functional framework presented before. This functionality maps to the framework as illustrated in the figure below. Figure 4-2: Framework for the modular and flexible node operation 4.2.1 Sensor node firmware and communication API The software architecture envisaged for Flex5Gware connected sensor nodes must enable transparent and efficient communication modes between these devices and the common network devices in 5G networks. As IoT devices are usually hardware constrained and extremely low power oriented, it is key to define optimized software architecture and efficient and scalable firmware (FW) modules to cope with these challenges while assuring seamless connectivity between all elements. This way, the availability of sensor data at decision points on the overall architecture can be guaranteed. The sensor node SW architecture is key to both general Flex5Gware considerations and proposed PoCs inside the project. It enables the use of this kind of data, unused so far, to enhance the flexibility of the network. Thus, the sensor-node software architecture directly addresses some of the requirements described in section 3 (such as energy efficiency or node re-configuration) but also acts as enabler for achieving other requirements on network nodes, as this new ability of being able to gather sensor data enables the more efficient network decisions. Table 4-1 gives some details with respect to the requirements more in line with the proposal. ID SW-1 SW-2 SW-5 SW-9 MC-2 MC-9 Table 4-1: Sensor node firmware requirements mapping Requirement Description The SW operation must be energySW architecture for Flex5GWare sensor efficient nodes is proposed to by highly energy efficient as required by the nodes. The SW platform must support large The API to be designed will be oriented diversity of applications to multi-purpose applications. The SW platform should be hardware The SW architecture proposed relies on agnostic the interface/module HW heterogeneity proposed in WP4 The device must be re-programmable OTAP functionalities for end nodes from the remote network or intelligent should be covered by the proposed SW programs architecture The SW platform must be flexible, The API developed should cover reprogrammable and reconfigurable interface/module reprogramming and support dynamic functional functions composition The SW platform must be able to The proposed API will enable the sensor Dissemination Level: Public Page 29 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 IP-2 extract context in order to take optimal solutions The intelligent program must exploit lower level context information context data to be published and shared at network level. This contribution acts as enabler for all IP requirements and specially in this case, providing sensor data. The proposed software architecture is based on a layering approach that enables the easy development of user applications based on the hardware proposals made for sensor nodes on WP4. One key feature envisaged to be included so as to ease the integration of thirdparty modules at application level is the ability to use C programming language for integrating purposes. Figure 4-3 shows the software structure of Flex5Gware sensor nodes. APP TSAPI (High level functions) OS MICROPROCESSOR Figure 4-3: Flex5Gware sensor node software architecture The proposed software architecture relies on the definition of three main layers: 1. MICROPROCESSOR layer This layer contains the low level drivers of the microcontroller. Ideally, those drivers will be provided by the chip manufacturer. These drivers implement the basic functionality of the microcontroller and manage the core and the different peripherals of the microcontroller, such as the UART or the MCU core. 2. Operating System (OS) layer The idea here is using an open source, real-time, multitasking operating system for embedded software applications (i.e. FreeRTOS [10]). This layer has its own API to develop not only internal layers but also applications. 3. TST API (TSAPI) layer TST plans to implement a hardware abstraction layer to facilitate software development of user applications. This layer will be in charge of supporting many functions to simplify the management of the underlying hardware. This layer will rely on OS mechanisms, e.g. mutex, semaphores, queues and so on. Devices (i.e. virtualization of sensor node hardware) and communication buses will be integrated in a complete multitasking software environment, which simplifies user application programming. Using these layers, new application coding will be done by, first, programming the desired functionality and, then, linking it with TSAPI and OS layers. The idea behind this software proposal relies on having an underlying hardware able to handle different communication interfaces (Modbus, FTP, TCP/IP, ZigBee, Digimesh, 802.15.4, Wi-Fi, RS-485, USB), peripherals (UART, I2C, SPI, DIOs, AIs) and devices (GPRS, NFC, GPS, XBee). The resulting platform will be able to mix different technologies in the same application, giving a wide variety of possible applications. For example, for a given application one may use NFC, GPRS and FTP functionality to report access occurrences on a given location, while it would Dissemination Level: Public Page 30 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 be also possible to use the same hardware and software to take advantage of ZigBee and Modbus to report meteorological data. Finally, an extra added value of the proposed architecture will be the ability of third-party programmers to use it via open source software tools merged in a single integrated development environment (IDE). In this environment, users can manage all the processes to program, compile and load their applications to the selected target board. The IDE is composed of a well-known interface with the end user (for instance Eclipse or similar) customized for programming by adding debuggers (such as GDB) and linkers to hardware modules (i.e. OpenOCD). 4.2.2 Sensor node abstraction and communication A conservative prediction about the near future declares that there will be 50 billion devices connected to any kind of networks. Anything that can benefit from being connected will be connected and the main technological enablers for this evolution include the mass production of smart devices, the ubiquitous connectivity and the possibility of providing advanced services through the integration of different smart objects/things [11]. In addition, the research area of the machine-to-machine communication examines devices that are connected to the Internet and communicate with each other, as well as with the wider world through wired/wireless and any other possible technology. In a more optimistic estimate, the number of these connected devices could even reach the 500 billion [12]. Several sensors may be embedded in each of these devices, making them an integral part of future 5G wireless networks. It could be argued that currently there is an extremely wide and stochastic deployment of these sensors, belonging to different vendors/providers and using several protocols and technologies. Consequently, heterogeneity cannot be avoided. Moreover, the current developments have mainly focused on specific applications, leading to domain-centric silos that lack flexibility and interoperability. In this manner, the need for sensor abstractions and generic APIs is evident. The goal is to increase the level of integration of heterogeneous technologies and to enable interconnectivity and seamless interoperability of diverse sensors. To this end, two challenges should be addressed (Figure 4-4): • • Generic Front-End: for data formatting and provisioning to high-level entities, such as applications/services. Generic Back-End: for accessing the functionalities provided by sensing devices and for direct interaction with sensor interface. Dissemination Level: Public Page 31 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-4: Sensor abstraction The work in this area will contribute to the objectives of Flex5Gware and will in particular facilitate the interplay between SW modules and HW elements, paving the way for the expected reconfiguration processes. Table 4-2 summarizes the requirements of Section 3 that the generic Back/Front-end target to address. More specifically, the generic front-end will provide the means to access the sensors in a uniform way independent of the technologies, vendors or protocols. The generic back-end will be implemented as a HW-agnostic API that facilitates the interplay among sensor based applications and mobile sensing devices enabling dynamic selection of communication technologies and protocols according to context and goals. The targeted abstraction of hardware, the virtualization of functions, as well as the definition of generic and hardware agnostic interfaces will lead to increased flexibility, resilience, efficiency of resource usage, energy efficiency and OPEX reduction. ID SW-5 IO-1 IO-2 IO-3 Table 4-2: Targeted requirements of sensor node abstraction Requirement Description The SW platform should be The proposed generic back-end hardware agnostic hides the sensor details The device must be able to provide Abstraction is realized through HWhardware abstraction from agnostic APIs underlying hardware resources The abstraction layer should The proposed generic backfacilitate the dynamic selection of end/front-end guarantee flexibility communication technologies and and dynamicity protocols according to context and goals The abstraction layer should have a The proposed generic front-end generic front-end to facilitate the allows data formatting and interplay with the remote network or provisioning to high-level entities intelligent programs Dissemination Level: Public Page 32 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 IO-4 IO-6 The abstraction layer should have a generic back-end for accessing the hardware functionalities The abstraction layer should provide generic/uniform interfaces towards remote network/intelligent programs and hardware resources The proposed generic back-end can be exploited for accessing the functionalities provided by sensors Generic/ HW-agnostic/ uniform interfaces Furthermore, the work described in the previous section (Section 4.2.1) will be taken into account and possible synergies will be investigated. Therefore, additional studies will be conducted over the sensor node firmware and communication API. In this direction, two targets can be identified: 1) The definition of (high level) functions (TSAPI layer). 2) The development of applications. The TSAPI layer realizes the hardware abstraction of the sensor nodes and includes a set of functions that undertake the management of the underlying resources and hide the complexity from the upper layers. Applications will be developed on top of this layer, exploiting the available functions and providing advanced operations. The combination of appropriate functions and basic applications will realize the abstraction and efficient communication of the sensor nodes. 4.2.3 Device level abstraction In principle, programmability of a wireless device would be trivial if vendors were exposing all the internal details of the developed platform (not to mention if they were to agree on the same (!) platform) and were providing the ability to program the platform using very low- level software languages. In practice, this model can hardly become real: wireless device manufacturers may be hardly willing to open their implementations. Moreover, there are two technical reasons which suggest that “full openness” might not be the best solution. First, when dealing with lower MAC or PHY radio operations, subject to strict timing issues and real-time requirements, vendors may extensively leverage hardware acceleration for some functionalities, or even rely on full hardware implementation, thus ruling away even the possibility to software program the device. Second, openness may even be counterproductive: different platforms may show huge internal implementation differences so that code developed for a device may need a complete rewriting to be ported on another brand, and this multiplication of versions may turn into a deployment hurdle rather than an enabler. Our proposed approach thus takes the start from two remarks relating to the above discussion. First, a compelling programming model must be pragmatic, i.e. it must address the dichotomy between i) the idealistic goal of true flexibility and ability to support a broad range features via complete openness and control of the platform details, and ii) the pragmatic real world constrains of high performance, low cost and compliance with commodity hardware, and consistency with the vendors’ need for closed platforms. Second, and more technical, a close scrutiny of existing PHY and MAC wireless solutions or protocols reveals that different protocols (or protocol releases) share an interesting and not nearly narrow common set of primitives and functions. It readily follows that a viable programming model should attempt to clearly separate i) the set of primitives that are (pre-)implemented by the vendors (in SW, FW or HW) inside the wireless card, from ii) the behavioural logic which governs how these primitives should be composed in order to “program” a desired protocol or radio behaviour. A concrete proposal is presented in the following subsections. Dissemination Level: Public Page 33 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 4.2.3.1 Platform-agnostic abstraction We propose a platform-agnostic programming abstraction which relies on the clear separation between A set of basic radio primitives (or capabilities) pre-implemented in the radio device, and The way in which such primitives are combined to form a desired radio behaviour. For what concerns radio primitives, these are the elementary building blocks offered to the device programmer. They include traditional “data plane” PHY/MAC radio primitives, such as transmit a frame, apply a given modulation and coding scheme, forge an acknowledge, switch on a given frequency band, adapt the bandwidth, etc, as well as the relevant control signals (or “events” such as busy channel signals, power/interference thresholds, timers, etc) which permit the programmer to control and specify the relevant combined operation as discussed below. The detailed list of primitives deployed in the Flex5GWare devices will be addressed in the future WP4 and WP5 specification deliverables (but some initial discussion on recommended extensions to the set of instruction is anticipated in the next section 4.2.3.2): our goal here is rather to propose the architecture which can accommodate such separation, and in particular to promote, as major architectural principle, the separation of the specification of such primitives from the specification of how they shall be controlled and coordinated. Indeed, such separation permits us to design a programming interface which is agnostic to how such primitives are specifically implemented. Specifically, radio primitives can be modelled as a finite number of pre-implemented actions (or functions, or “instructions”), which can thus be invoked by the programmer using a specific “code” associated to each action. In addition, each action may receive some input (e.g. the frame to be delivered, or the signal vector that requires to be processed) and provides an output. The programmer can thus specify a memory address (and a relevant memory size) which points either to the device RAM for data to be transmitted/processed, or to device registers for control information, and which contains the data (or registry content) that shall be fetched and provided to the action for its execution. Note that the actual implementation of such operation somewhat resembles that of an ordinary CPU, with the crucial difference that in our case “instructions” are specific for the radio domain. We now address the second, and crucial, aspect that relates to device programmability: how the programmer can combine such primitives in order to achieve a desired radio behaviour, while remaining platform agnostic? In prior work, two different approaches have been proposed as “alternative” approaches: Direct Acyclic Graphs (DAGs)– this approach is frequently used in software-defined radio platforms and is particularly appropriate to describe PHY radio operation which typically rely on the concatenation of different signal processing blocks (equalization, coding, modulation, etc.) which implement a radio primitive as discussed above. The idea is to formally describe a composition of such blocks as a “workflow” which specifies the processing “path” along multiple concatenated blocks. DAGs thus emerge as a very natural abstraction to describe workflows which eventually go beyond the simple chaining of blocks, and which may rely on conditions based on which an output from, say, block B1 should be delivered to block B2 or B3. eXtended Finite State Machines - In the frame of MAC protocols, as duly summarized in the Appendix (Section 6), Flex5Gware project partners recognized that the above DAG abstraction was not appropriate for formalizing channel access operations typical of MAC protocols (and especially of distributed MAC protocols such as those employed in WLAN/WPAN technologies). As such they first proposed an alternative abstraction which relies on generalized forms of finite state machines. Dissemination Level: Public Page 34 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 The idea is that a given wireless access operation can be described in terms of states. In every state, different radio primitives may be invoked (for instance, transmit only in given states), and radio events (such as idle/busy channel signals) can in turn determine state transitions (e.g. decrease a backoff counter only if the medium is sensed idle). Instead of considering such approaches as “alternative”, our proposed architecture aims at integrating both abstractions into the same framework. The idea is conceptually very simple: associate a different DAG, describing how radio primitives are chained, to different (X)FSM states, and use control events to trigger state transitions. Note that such an abstraction unifies the two different programming models adopted for PHY and for MAC stacks. Indeed, by modelling the radio behaviour as “stateless” (i.e. comprising a single, static, “default” state) it rolls back to a classical static DAG, typical of PHY/SDR programming. Conversely, by using single actions per state, it permits to model more complex and stateful MAC protocols as described in the prior partners’ work reviewed in the Appendix (Section 6). Most interestingly, the combination of DAGs and XFSMs permits to model cross-layer radio operations where the specific composition of PHY-layer processing blocks can become now dependent on a given device state, and thus can be adapted whenever an event triggering a state change occurs. Note that a state machine may be as simple as a “switch” threshold. For a concrete and simple example, an elementary RSSIbased rate adaptation mechanism would be very naturally described by such combined DAG+FSM abstraction, where depending on the RSSI (whose levels could be summarized into a connection state), a given modulation and coding chain (i.e. the DAG part) is executed. What appears compelling in the proposed abstraction is rather that the state machine can become eventually complex (but still remaining abstract and agnostic to the specific platform executing it): going back to the rate adaptation algorithm’s example, one might model more complex states and state transitions which further include1 the history of the previous transmissions (e.g. a specific sequence of unacknowledged/errored frames). A second major asset in our proposed abstraction is the versatility in terms of definition of which events should trigger state transitions. In past works, events were always strictly related to the radio operation. However, we note that this is of course not necessary, as an event is by itself an “abstract” event which we do not have to necessarily associate to “just” radio conditions, but which we can trigger on the basis of exogenous conditions, such as sensor events or events triggered by a centralized network intelligence and delivered to the devices. It readily follows that our proposed abstraction is naturally capable to support generalization in terms of such events. This further opportunity will be addressed in the next specification deliverables, and with specific attention to the integration of the sensing technology and systems described in the previous section 4.2.1. Finally, even if this deliverable is related to the architecture and the relevant platformagnostic programming interfaces, and hence it is clearly in charge to propose a specific implementation over specific platforms (this will be addressed in WP4 D4.2), some comments are useful to understand which are the possible implementation issues to be faced, and how they could be addressed. On one side, state maintenance and state transitions, even when required on a per-connection basis (as it is appropriate inside a BS, unlike a terminal’s device) do not appear to bring about any significant concern in terms of implementation. Indeed, it suffices to deploy two tables: 1 Note that, with reference to 802.11 systems, existing rate adaptation algorithms so far coded inside the specific platforms/drivers could very easily formalized in terms of FSM-DAG abstractions, and hence could be very easily decoupled from the specific platform implementation using the proposed Flex5Gware platform-agnostic programming abstraction. Dissemination Level: Public Page 35 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 a state table, which can be queried using as key a flow/connection identifier, and which returns the current state associated to the flow (this can be trivially implemented using an O(1) hash table lookup); a DAG table, which is queried via the state, which checks whether the events specifically associated to the considered state are triggered, and which returns both i) the processing workflow to be enforced on the data frame or signal vector associated to the considered flow/connection, and ii) the next state if a state transition was triggered – this state is of course duly updated in the previous state table. Conversely, what might appear to be a challenge is the dynamic reconfiguration of the processing blocks at each state transition. However, it is worth to remark that at least a basic implementation, which would be appropriate in the case of few different possible DAGs (and states), appears feasible. It consists in pre-configuring all the possible block chains, and simply using the retrieved state as “selector” for the block chaining to be applied to the considered data. This implementation would indeed permit dynamic operation (the applied DAG would change based on the state) via a static configuration (all possible DAGs would be simultaneously deployed), although at the obvious expense of supplementary internal resource consumption. An interesting remaining challenge is how to accomplish a more flexible and dynamic DAG reconfiguration so as to optimize internal resources, but this issue will be dealt with in the frame of Flex5Gware’s WP4. 4.2.3.2 Improving the instruction set The programming model TAISC (Time-Annotated Instruction Set Computer) consists of a cross-platform MAC protocol compiler and execution engine. The TAISC framework offers a solution for hardware independent MAC protocol development and management. The solution allows describing MAC protocols in a platform independent language (consisting of a radio platform independent instruction set), followed by a straightforward compilation step, yielding dedicated binary code, optimized for specific radio chips. The cross-compilation approach allows developers to design MAC protocols once, and then compile them for reuse on different radio platforms. To enable time-critical operation, the TAISC compiler adds exact time annotations to every instruction of the optimized binary code. The execution engine running on the radio platform, will execute the instructions with accurate time control thanks to the time annotation. TAISC has been implemented for IEEE 802.15.4 MAC protocols, both on an embedded sensor platform and on a ZedBoard SDR platform. For TAISC, a basic instruction set is available, which supports basic monitoring functions (such as RSSI measurements) and basic MAC control functions (such as activating/deactivating a MAC program). The management function, load new MAC (over the air), is currently being implemented and will be available soon. Current MAC programs in TAISC are rather static and expose no parameters in the General Purpose RAM (GPRAM) (see Figure 6-2). In order to cope with more flexible medium access and according flexible scheduling schemes, MAC parameters should be exposed via the control plane interface, such as: for CSMA/CA MAC schemes: minimum/maximum contention window maximum number of retries for TDMA schemes: slot size, superframe size, guard time, ACK policy, blacklisting of channels (for example to avoid interference with co-located IEEE 802.11 traffic), etc. Channel hopping schemes: list of channels that can be used, channel hopping algorithms Dissemination Level: Public Page 36 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 The instruction set further needs to be extended to support advanced synchronisation functions for time synchronisation between multiple nodes, in particular when heterogeneous wireless technologies are involved. The basic TAISC instruction set was in the first place targeted for implementations on embedded sensor platforms. Currently, the same instruction set is also employed in an implementation on SDR, but the instruction set could be further enriched with more advanced PHY functionalities, such as: channel width (smaller or larger channels could be selected depending on traffic requirements) dynamic forward error correction schemes based on link quality number of simultaneous channels (a SDR platform could run multiple instances of an IEEE 802.15.4 on different channels) 4.2.3.3 Integrating sensor data The TAISC framework developed by iMinds uses CoAP [13] as a generic/uniform interface towards the remote network controller and/or resource manager. CoAP is an IETF protocol enabling development of IoT applications on top of constrained sensor devices (in the same way as http is used for developing web services). The same CoAP interface used for monitoring can hence also be used for integrating sensor data. CoAP can be used for exchanging radio/network monitoring data as well as sensor data information by using its “observe” functionality. CoAP clients, used by the remote network controller and/or resource manager, can register for parameter updates to retrieve monitoring or sensor information. The CoAP servers, implemented on the monitoring agent of the local resource controller, will notify the network controller and/or resource manager each time a parameter (monitoring information, sensor data) is updated. Another possibility is to use “periodic CoAP resources” to receive periodic updates of monitoring information or sensor data. This is especially useful to allow the aggregation of monitoring information on the local monitoring engine, thereby reducing the monitoring data that needs to be transferred over the wireless medium. 4.2.3.4 Summary and targeted requirements We conclude this section on device level abstractions by summarizing how the above described initial architectural ideas are expected to contribute in bringing a greater degree of flexibility in the node configuration and programmability. We first recall that our promoted approach does not require “low-level” programmability, but permits to combine in a flexible and expressive manner (via a suitable combination of finite state machine and direct acyclic graph abstractions) radio processing blocks or functions pre-implemented in the devices. This approach therefore appears to reasonably compromise between two contrasting needs: the need for vendors to retain control over the radio primitives (frequently implemented in HW and via proprietary designs), and the need for operators to “select” the most appropriate radio primitives, based on the monitored context, and combine them in a “smart” manner to implement a specific operation (for instance a rate adaptation scheme). Moreover, this approach candidates to permit platform independence, as the network manager or operator does not need to know the internal implementation details of the radio primitives used, nor whether they implemented via dedicate HW or via software of firmware means, but only requires to be provided with a uniform naming interface for invoking such primitives. Second, the “event” abstraction is not necessarily restricted to events related to the radio channel (e.g. busy signals, interference, etc.) or to the radio frames (e.g. inqueued frames, acknowledgements, etc.), but can be trivially extended to support “exogenous” events gathered via either device-level sensors or notified by a network controller. This makes our approach particularly compelling in terms of extensibility and possibility to integrate sensor Dissemination Level: Public Page 37 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 data, and hence permit reconfiguration upon more complex and variegate context conditions, possibly including environmental changes sensed by the sensing technology. The following table (Table 4-3) summarizes the requirements of Section 3 that the device level abstraction and the relevant architecture targets to address. Table 4-3: Targeted requirements for the device level programming abstraction and architecture ID Requirement Description The SW platform must support large Different users, different IoT devices SW-2 diversity of applications have different applications requirements The SW platform should be hardware A SW platform developer does not SW-5 agnostic require deep knowledge on the hardware platform The SW platform must be able to adapt The SW platform requires monitoring SW-6 to demanding and changing contexts capabilities to identify the network context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes The device must be re-programmable Over the air re-programmability; SW-9 from the remote network or intelligent HW-agnostic APIs programs The device must be able to provide Abstraction realized through HWIO-1 hardware abstraction from underlying agnostic APIs hardware resources The abstraction layer should facilitate Flexibility, reconfigurability and energyIO-2 the dynamic selection of awareness will be supported communication technologies and protocols according to context and goals The abstraction layer should provide Generic/ IO-6 generic/uniform interfaces towards HW-agnostic/ remote network/intelligent programs uniform interfaces and hardware resources The device should dispose monitoring Monitoring agent; IO-7 and context awareness mechanisms ability to collect and process and relevant events (e.g. change measurements at multiple levels detection, triggers, etc.) (channel, sensors, higher layers) The SW platform must be flexible, Dynamicity, flexibility, over-the-air reMC-2 reprogrammable and reconfigurable programmability and reconfigurability and support dynamic functional composition The SW platform must reconfigure the Timing constraint MC-10 wireless network card in less than the configuration/reconfiguration “default” operation timescale of the protocol (e.g., beacon interval time for 802.11) 4.2.4 Extended API for energy-aware operation In this section, we describe the API definition to include relevant energy-related parameters to the applications located at the Intelligent Program layer. This API allows gathering energyrelated information about the device and performing network optimization with this new information. Thus, the objective is to design an energy-aware API to support efficient protocols in order to receive the energy footprint, so upper layers are aware of the Dissemination Level: Public Page 38 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 energy/performance trade-offs and can choose or devise the best scheme. In the following subsections we describe the 802.11 stack implementation in the Linux kernel and the required changes to be done in order to add the proposed features. Table 4-4 gives some details with respect to the requirements more in line with the proposal. ID SW-7 IO-1 IO-2 Table 4-4: Extended API for energy-aware operation requirements mapping Requirement Description Generic SW building blocks should be This extension provides a generic provided energy characterization of the device, thus this API can be reused for different HW The device must be able to provide The primitives must provide an agnostic hardware abstraction from underlying layer to access to HW energy hardware resources parameters The abstraction layer should facilitate API is prepared to provide flexibility, the dynamic selection of reconfigurability and energy-awareness communication technologies and to the intelligent programs layer protocols according to context and goals To understand the API presented in this section and what changes are required among the different layers of the 802.11 protocol implementation, we introduce a brief and simplified version of the 802.11 implementation in the Linux kernel which is shown in Figure 4-5. We can differentiate 3 big layers: User space, Kernel space and Hardware. User space is where all the tools that interact with the 802.11 stack are developed; tools such as iw, hostapd or wpa_supplicant run at this level and the communication with the lower levels are performed through the libnl library. This library provides a generic Inter-Process Communication (IPC) interface between both User space and Kernel space. Figure 4-5: Simplified version of 802.11 implementation in Linux kernel Dissemination Level: Public Page 39 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 The real implementation of 802.11 protocol can be found in Kernel space. It is separated in two blocks: cf80211 and mac80211. The first block cfg80211 provides a set of functions to perform low level operations such as scanning, configuring the device as Access Point (AP) or connecting to an AP to the User Space. This block is connected to upper layers through nl80211 library that opens a direct access to libnl library. It is important to distinguish a structure of data that contains the configuration of the wireless device and it is the backend of cfg80211, cfg80211_ops. This structure offers information about the transmission power, the current state of the wireless card (transmitting, sleeping or listening) and to set complex operations as schedule a scanning, suspending the interface, adding or removing virtual interfaces, changing the transmission rate, etc. Going through the 802.11 stack, we find mac80211 module. This block implements the MAC protocol and provides an API for interfacing with the low level device drivers which is executed in ieee80211_ops data structure. This structure offers all the callbacks from mac80211 to the driver. Next layer that we find is the driver. As the driver depends of the HW, the implementation offers two services to access to network interface card: DMA and a proprietary messaging framework. Finally, we reach the bottom of the stack: the hardware. As we mentioned before, the design of the network card affects directly the driver design since it can provide access to the DMA controller or it can offer a HW abstraction layer (HAL) to set card operations. 4.2.4.1 API definition for energy-aware operation In this subsection, the changes required among the different levels of the 802.11 implementation are described. At User space level, we define a data structure that contains the relevant information about the energy characterization that we have denominated rho and the crossfactor. These values are employed to characterize the energy consumption since a packet is generated by the application until it arrives to the NIC. Figure 4-6: Definition of the energy-aware data structure and a function to assign it These values must be measured a priori and hardcoded into the code because there is no way to quantify these values directly from the system and it depends of the device. The next required change is at Kernel Space, in the cfg80211_ops structure. As we explained before, this structure handles the information that is exchanged between User space and Kernel Space. For this reason, we have added new operations to assign and to get these values to the 802.11 stack. Figure 4-7: New operations for cfg80211_ops First operation returns all the energy-related information including rho and the crossfactor plus the energy-related parameters obtained from the driver. In this way, we provide a complete characterization of the device to the application. Second operation assigns the values obtained in User space to the 802.11 subsystem. This operation assigns these values Dissemination Level: Public Page 40 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 to ieee80211_hw structure that previously has been modified to add these two new variables. 4.2.5 API for dynamic radio-frequency bandwidth We design an API between the hardware and the radio engine manager in the local resource controller that provides a dynamic, flexible and fast re-configuration of the radio-frequency bandwidth. This concept can be advantageous in presence of intentional interference generated in the same spectrum. The bandwidth will be controlled varying the pulse shape of the transmitted signal and varied at the necessary rate. For instance, symbol level variation of the radio frequency bandwidth can be foreseen if the intentional interference in range requires highly-dynamic decisions. An example of application scenario can be the one of intentional jammer that can swiftly react to the decisions of the signal transmitter. The local radio engine manager at the transmitter is here responsible to make decisions of the selected radio-frequency bandwidth according to a pseudo-random pattern. In order to make the process robust to the intentional interference, the radio program at the receiver subsequently selects the most appropriate configuration to filter the remaining interference noise based on real time estimation of the interfering signal. The pattern to select the most appropriate RF bandwidth over time will have an impact on the signal-to-noise ratio gain with respect to conventional spread spectrum techniques and for a given packet loss ratio. The mapping to the requirements is given in Table 4-5. ID SW-3 SW-6 MC-9 MC-10 IO-2 IO-8 Table 4-5: API for dynamic radio-frequency bandwidth Requirement Description The SW platform must improve QoE The application requirements (application data rate, application delay, jitter at application level, data loss...) need to be mapped to QoS requirements in the network (e.g. min. throughput, network latency, jitter, network reliability). Then QoE is improved by satisfying these requirements. The SW platform must be able to The SW platform requires monitoring adapt to demanding and changing capabilities to identify the network contexts context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes The SW platform must be able to Context extraction and awareness; extract context in order to take Monitoring service; optimal solutions Aggregation of context information from multiple (heterogeneous) nodes The SW platform must reconfigure Timing constraint the wireless network card in less configuration/reconfiguration than the “default” operation timescale of the protocol (e.g., beacon interval time for 802.11) The abstraction layer should facilitate Flexibility, reconfigurability and the dynamic selection of energy-awareness will be supported communication technologies and protocols according to context and goals The device may react to intentional Decisions in the Local Resource interference, such as jammer, in the Controller Dissemination Level: Public Page 41 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 4.2.6 same spectrum VM Manager and Node Function Virtualization In recent years, the network edge (e.g., RAN) has gained increased prominence, with a large number of industrial players seeking to deploy functionality as close to end users as possible. An example of this trend is a recent ETSI white paper on Mobile Edge Computing (MEC) that argues for placing servers in aggregation and radio access networks next to base stations and radio network controllers [14]. Other big players such as Intel are also jumping in, calling for the deploying of servers in so-called “smart cells” [15]. The idea is to allow third parties to deploy functionality, and for the platform (e.g., a base station or a server connected to it) to be able to run these concurrently while providing isolation via virtualization technologies (e.g., Xen, KVM or containers). The applications and type of processing that could benefit from running at this particular location of the network are multiple and varied. For example, we could run a minimum-delay cloud storage service that allows users to quickly upload content to the edge device, and have the edge device back the data to a data center at a later point in time. Further, a number of services could be offloaded from the mobile device, where they consume battery, to edge devices (e.g., firewalls, anti-virus software, ad-blockers). CDN caches could also benefit from the low delay that an edge deployment would offer, not to mention contextaware services such as augmented reality (e.g., Google glass), edge-based video analytics (e.g., for surveillance purposes) and application-aware optimizers. Along these lines, in Flex5Gware we aim to enable not only deployment of functionality near or at the base station/node, but to provide the ability to do so in an isolated manner in order to support third-party deployments and multi-tenancy; in other words, building a platform for efficiently deploying network functions in edge networks, near or next to base stations. To do so, we are targeting the use of tried-and-tested virtualization technologies such as Xen or KVM. The avid reader might ask whether it is wise to use these on devices with potentially limited memory and/or CPU resources. While containers are in principle lighter-weight alternatives, we rule them out because they tend to have weaker isolation guarantees. Instead, where needed, we aim to leverage recent research into so-called unikernels, virtual machines based on minimalistic OSes and running a single, tailor-built application (e.g., a single application to determine mobile users’ location based on raw sampling data). Figure 4-8: Sample ARM and x86 Single Board Computers Regarding the actual hardware, there are a number of possibilities (note that this list is certainly not exhaustive). For instance, software radios such as the USRP N210 from Ettus Research allow us to run a software-based base station (either GRPS with software such as GNU radio or LTE with OpenAirInterface) on a server attached to the device over an Ethernet cable. Another example is to use a single-board computer (SBC, see Figure 4-8) to run both the base station software and the virtualized functions. Single-board computers are small form factor computers based on ARM or x86 processors and are typically inexpensive Dissemination Level: Public Page 42 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 (between 30 - 200 $), consume little power and are able to run virtualization technologies. The canonical example of an SBC is the Raspberry Pi, but there are now a large number of other offerings such as s the Intel NUC, Gizmo 2 and Minnowboard (x86); and the Cubietruck, ODroid and Wandboard (ARM32). Figure 4-9 shows the specifications for a number of different SBCs. Figure 4-9: Specifications for a few single-board computers In terms of management, the virtual machine manager (VM manager) runs on the platform and is in charge of providing an API to control the deployment and use of virtualized functions on the device (see Figure 4-10). While the full API is yet to be defined, it could contain the following operations: VM image upload VM image deletion VM instantiation along with configuration parameters (e.g., memory) VM destruction VM monitoring VM checkpointing Figure 4-10: Virtualized function architecture. The VM manager is in charge of instantiating the virtualized function VMs, and the redirection module takes care of sending the data samples to the corresponding VMs. Dissemination Level: Public Page 43 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Finally, it is worth mentioning that the platform might need an additional component to redirect the samples/packets to the necessary VMs (see block labeled “redirection” in Figure 4-10). We will refine this requirement in further deliverables as the project develops. 4.3 Concepts and design principles for multi-node coordination The second functional layer in the Flex5Gware reference framework is the Remote Network Controller (see Figure 4-11). This layer provides the control and management plane to enable a multi-node technology-agnostic SW operation and will offer the tools required to coordinate in real-time the different SW modules available across multiple nodes. This coordination requires both the case of a node managing the operation of another node (e.g., infrastructure nodes changing the behaviour of mobile clients), and the case of two nodes coordinating their activities. Next sections detail the functionality that is mapped to this functional layer. Figure 4-11: Framework for the multi-node coordination 4.3.1 Capacity estimation mechanisms Capacity allocation of wireless links is strongly affected by the time-variant interaction between links. Thereby, we propose the study of the network as a queuing system with coupled processors (CPS), in which the service rate at each queue varies over time in function of the set of active queues in the system. A trivial (but inefficient) way to analyse CPS systems is to assume a static scenario, in which service rates are those of a system in saturation, with all queues serving data packets. This leads to heavily pessimistic results, often of little practical interest. Research has focused therefore on modelling the effects of system dynamics on performance of small, toy scenarios with few queues [18] - [20]. For larger settings, very conservative assumptions are needed, which results in limited interest, e.g., a specific inter-cell interference limited cellular networks scenario as described in [21]. Results that apply to more general settings and to a generic number of queues are based on a large number of computationally heavy simulations [22], [23]. ID SW-5 SW-7 MC-3 MC-8 IP-1 Table 4-6: Capacity estimation mechanisms: requirements mapping Requirement Description The SW platform should be Resources are abstracted hardware agnostic Generic SW building blocks should The method proposed is a building be provided block for resource estimation The SW platform must provide The goal of the proposed method is global acceptable solutions that to avoid waste of resources and prevent instabilities instabilities/conflicts/competitions The SW platform should allow the Cellular and D2D are both accounted coordination of heterogeneous and for in the study multi-technology nodes The intelligent program must fulfil High level resource allocation high level policies policies are addressed Dissemination Level: Public Page 44 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 IP-3 The intelligent program must take adaptive decisions on dynamic and autonomous management and configuration of the available resources The mechanism can be used to make online decisions In contrast, we design a fully analytical approach for performance analysis of a generic CPS, which applies to a large class of input traffic. We use our method to study a D2D resource allocation and scheduling problems. In a CPS, correlations between service rates are mutual. Indeed, the service rate of queue i in the CPS is Ri(q1,q2, …, qN), where q1,q2, …, qN are binary variables indicating whether the queues have backlog to serve. To make the problem tractable, we propose a method to break circular dependencies in the analysis. Specifically, we suggest to order the queues in the CPS and to model the service rate impairment caused by each queue on the queues following in the ordered list, starting from the top of the list (position 1). With this, we model inter-queue dependencies in one direction (top-down in the list). To model the dependencies in the other direction (bottom-up in the list) without incurring in complex calculations, we consider that a queue in position j in the list is considered as always active by all the queues listed in position k < j. As a result, in a network derived from the original CPS, the service rate of the queue in position j is Ri(q1, …, qj ,1,1, …, 1), i.e., it does not depend on the real activity of queues j+1, …, N. This is clearly a worst-case approach, which will lead to the identification of performance bounds. Moreover, each possible “ordering” of the CPS queues results in a feed-forward network of queues, as shown in Figure 4-12 and Figure 4-13. All possible orderings need to be considered. Indeed, as we prove in [24], the capacity region and the bounds on backlogs and delays can be achieved by merging the results on stability and bound obtained for all possible feed-forward networks. However, a good approximation can be achieved by studying a small subset of all possible feed-forward networks. The study can be performed with Markov Chains or by means of Network Calculus, depending of the target. For instance, a stochastic approach using Markov Chains characterizes the system in distribution or in terms of averages, while using Network Calculus yields less tight yet guaranteed bounds. For example, for the simple D2D network shown in Figure 4-14, the capacity region estimated with our method and with state-of-the art methods is shown in Figure 4-15. In the figure, the curve indicated as “Deterministic Stability” is computed using Network Calculus, while “Stochastic Stability” refers to average values of the capacity region computed by means of Markov Chains. Of course, the former is a conservative estimate of the latter. As it is shown in the figure, not only our Markov Chain-based CPS analysis matches simulations, but also the CPS-based approach is much more precise than other approaches when the traffic is not balanced between D2D pairs. With the results of the CPS analysis of a wireless system, it is possible to define and solve an optimization problem on the resource allocation and on the MAC configuration (given a set of possible MAC configurations). In particular, we plan to apply our CPS analysis to the case of D2D communications in cellular networks, in which resource allocation and D2D mode selection are managed by the operator and are key to achieve efficient utilization of resources in the cellular network. Dissemination Level: Public Page 45 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-12: N-queue CPS in which the service rate of each queue depends on the activity of any other queue. Figure 4-13: N-queue feed-forward network derived from a CPS. Service rates are not affected by the real activity of queues in lower stages of the feed-forward chain. TX 1 RX 1 RX 3 TX 3 RX 2 TX 2 Figure 4-14: Simple D2D scenario with 3 D2D pairs interfering with each other. Figure 4-15: Capacity region for the D2D network of Figure 4-14, computed with CPS and other methods for the case in which the pair (TX1,RX1) demands 47.5 Mbps. The CPS analysis provides the basic blocks to develop a control application for multi-node operation. Specifically, with respect to the framework defined in WP5, and reported in Figure 4-1 and Figure 4-11, the modules that need to be taken into consideration when implementing such control application are the Global Scheduler program (which makes rate adaptation and D2D mode selection decisions based on an optimization function defined by the operator), the Dynamic Functional Recomposition (DFR) block in the Network Controller (because the DFR is in charge of enforcing decisions, e.g., D2D decisions) plus the Monitoring blocks in the Network Controller and in the wireless node (because monitoring is needed to “learn” inter-link dependencies to estimate service rates under various conditions). In addition, the Radio Engine Manager of the wireless node has to be able to switch among available D2D operational modes (inband, outband, underlay, overlay, etc.). A mapping onto requirements is also shown in Table 4-6. 4.3.2 Positioning Algorithms for Context-Aware Networks As part of the monitoring service depicted in Figure 4-1, positioning algorithms are required to allocate resources with context-awareness. A challenge in this direction is that pervasive localization systems are still unavailable nowadays. For localization, Time-of-Flight (ToF)based positioning algorithms are among the most important localization and tracking Dissemination Level: Public Page 46 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 technologies with the aid of the infrastructure network (the corresponding ToF ranging technique is studied in WP4). Current approaches attempt to use one among the set of available localization technologies. Instead, our vision is of a wireless mobile device that can pervasively position itself by integrating any ToF-based wireless technology at a very-fine grain. We especially target areas such as the gray zone, where single technologies tend to fail or have limited accuracy. As an example, let us suppose we can receive signals from two GPS satellites and from two WiFi Access Points. Multi-lateration cannot be computed with only two independent signals from one technology. In contrast, it could be computed with four independent signals from the two technologies (GPS and WiFi). As a result, the mobile could now position itself. However, current devices do not allow such integration since the different technologies work as monolithic blocks. In this direction, the fusion of timing signals of satellite navigation with opportunistic timing signals inherent in WiFi and other radio communications could be achieved with novel algorithms and methodologies, and taking into account the heterogeneous sources of noise of each technology. The availability of seamless positioning can allow investigating contextaware schemes running in the resource manager (see Figure 4-1). These schemes can adaptively reconfigure the node parameters (such as radio channel of operation) according to the dynamicity of both the services' demand and location ecosystem. The new reconfiguration can then, for instance, achieve better timing information for ToF positioning, and operate in conditions less sensitive to channel propagation impairments. The mapping to the requirements is presented in the Table 4-7. Table 4-7: Positioning Algorithms for Context-Aware Networks: requirements mapping ID SW-6 Requirement The SW platform must be able to adapt to demanding and changing contexts SW-9 The device must be reprogrammable from the remote network or intelligent programs The SW platform must be able to extract context in order to take optimal solutions MC-9 MC-10 IO-2 IO-7 IP-2 The SW platform must reconfigure the wireless network card in less than the “default” operation timescale of the protocol (e.g., beacon interval time for 802.11) The abstraction layer should facilitate the dynamic selection of communication technologies and protocols according to context and goals The device should dispose monitoring and context awareness mechanisms and relevant events (e.g. change detection, triggers, etc.) The intelligent program must exploit Dissemination Level: Public Description The SW platform requires monitoring capabilities to identify the network context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes Over the air re-programmability; HW-agnostic APIs Context extraction and awareness; Monitoring service; Aggregation of context information from multiple (heterogeneous) nodes Timing constraint configuration/reconfiguration Flexibility, reconfigurability and energyawareness will be supported Monitoring agent; ability to collect and process measurements at multiple levels (channel, sensors, higher layers) Context-awareness in terms of Page 47 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 lower level context information 4.3.3 changing conditions, ranging and position of nodes in the network, traffic levels/variations, HW capabilities; Monitoring library Dynamic Functional Re-composition Frequently changing environments are foreseen for the fifth generation of mobile wireless systems. Consequently, nodes/devices are expected to experience an extreme contextdependent behaviour. A change in context will result in possible reconfiguration(s) that may risk overall performance. Therefore, global acceptable solutions should be pursued to support these reconfigurations and maximize the desired benefits. However, the 5G ecosystem consists of diverse and heterogeneous devices in terms of purpose, scope, technologies and vendors/manufacturers. Unavoidably, critical situations will occur, e.g. instabilities, conflicts and competitions. To this respect, Flex5Gware software platform is suitable for coordinating the devices and alleviating the risks. In this context, WINGS designs and implements a HW agnostic control module for Dynamic Functional Re-composition (DFR). This module will be responsible for the underlying heterogeneous HW infrastructure’s reconfiguration and in particular for stitching together SW and HW components at runtime (Figure 4-16). It aims at removing the current repetition of functionality among multiple layers, technologies, elements and offers a flexible, reprogrammable and reconfigurable functional composition. Table 4-8 summarizes the requirements of Section 3 that DFR targets to address. Table 4-8: Targeted requirements of the Dynamic Functional Re-composition (DFR) ID Requirement Description The control and management plane One of the main objectives of DFR MC-1 should remove the current repetition of functionality among multiple layers, technologies, and elements The SW platform must be flexible, DFR will realize the dynamic MC-2 reprogrammable and reconfigurable functional re-composition and support dynamic functional composition The SW platform must provide DFR proposes conflict-free solutions MC-3 global acceptable solutions that prevent instabilities/conflicts/competitions The SW platform should allow the DFR targets not only single elements MC-8 coordination of heterogeneous and but also coordination of multiple multi-technology nodes heterogeneous nodes Dissemination Level: Public Page 48 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-16: Dynamic functional placement and partitioning DFR will manage the reconfiguration process, deciding the optimal functional composition. It will be triggered either by context events (e.g. sudden degradation of performance due to rain, a dynamic hotspot) or by explicit requests from other mechanisms (e.g. intelligent programs). The goal is the synthesis of SW and HW segments and the definition of the most suitable workflow. For this purpose, DFR will exploit models for nodes/components, communications and (functional, reconfiguration) behaviour. The execution part of the DFR’s operation includes the enforcement of the decisions to the nodes. Appropriate commands will be sent through the defined interfaces to the responsible mechanisms. In addition, DFR will monitor the effectiveness of its actions, verifying the positive outcome of its intervention. To this end, feedback mechanisms will be exploited. A list of KPIs that will be analysed and targeted for improvements includes: i) flexibility, ii) resilience, iii) latency, iv) energy efficiency, and v) cost (OPEX reduction). In addition efficiency of resource usage and availability of scalable management will also be important features to be analysed and improved. In Flex5Gware, DFR is the module that will enable the smooth multi-node and technology-agnostic SW operation. 4.4 Concepts and design principles for intelligent programs As previously described, abstraction of HW and definition of HW-agnostic interfaces are critical for a modular and flexible node operation, while dedicated mechanisms are critical for multi-node coordination and technology-agnostic SW operation. On top of these, intelligent SW programs (Figure 4-17 - upper layer in framework) could provide advanced functionalities. Based on context extraction and awareness, as well as the platform’s reconfiguration capabilities, these programs support the dynamic and autonomous management of the available resources, taking into account application requirements. Concepts and design principles for the main programs of this layer are presented in this section. In particular, this section details the definition of intelligent programs, with a particular focus on how they interact with the rest of the architecture. We start by analysing how measurements gathered from the system can be managed in the process of optimizing Dissemination Level: Public Page 49 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 the system itself. Then we study the problem of content dissemination in the context of mobile users. Finally, we describe how resource allocation can take place at a global scale. Figure 4-17: Framework for the intelligent programs 4.4.1 Feedback loop of optimisation schemes The challenges when optimising the communication parameters of a static scenario are multiplied with dealing with scenarios that introduce variability, which is typically the case in cellular networks: either due to the intrinsic characteristics of the wireless medium or because of devices’ mobility (including not only the actual movement of the participating devices, but also the appearance and departure of new devices), the scenario changes over time and therefore any optimised configuration has an implicit “expiration date” or, to put it in a different way, is valid only as long as conditions do not change significantly (which is rarely the case). In addition, the added variability of traffic generation over time contributes to this expiration date of the computed configuration. Because of the above, one very common approach to optimise performance (see e.g [16] and references within for the case of 802.11 WLANs) is to design, either implicitly or explicitly a closed loop that upon changes in the conditions of the scenario triggers a new configuration (this being understood as any change in the operation parameters of the wireless setting, e.g., transmission power, scheduling scheme, contention parameters). This closed loop is illustrated in the following figure. Figure 4-18: Feedback loop of a optimisation scheme As the figure illustrates, the usual operation of an optimisation scheme can be summarised as follows: there is a system that performs according to a set of parameters; the performance of the system is estimated through sampling by a monitoring module, which then might process this information before delivering it to an optimiser, that computes the optimal configuration and distributes it to the system, which activates it. Note that this operation could be periodic (or with a variable period, depending on previous results) or aperiodic, if it’s triggered by a given condition (e.g., a new user arrives). Also, all the above procedures could introduce a non-negligible delay, which might impact the performance of the resulting solution. For instance, in [17] it is showed that depending on the time to activate a new configuration, the optimality of a resource-on-demand policy might change drastically. Dissemination Level: Public Page 50 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 To analyse the performance of optimisation techniques based on feedback loop, on the one hand there are the following entities: System: this is the (wireless) scenario to be optimised. Its behaviour is based on a set of tuneable parameters, and results in a given performance. Monitoring: is the entity that samples the above performance of the system, either periodically or aperiodically, might process the resulting information (to decide e.g. if a change is significant enough to trigger a new configuration), and delivers it to the optimiser. Optimiser: entity responsible for computing the optimal configuration, based on a set of estimated conditions for the scenario. The resulting configuration has to be distributed to the system, which will activate them. Note that the above framework is specified in terms of logical entities, that might be placed in different nodes in the network or in the same node, e.g., an access point might implement the monitoring and optimiser entity in a single software module, a scheme to optimise the modulation and coding scheme does not need to distribute the optimal configuration, as all entities are within the same actual device. On the other hand, the feedback loop also serves to identify the different delays that might appear in the optimisation technique: The optimiser might incur into a non-negligible delay to compute the novel configuration, i.e., a computation delay. The novel configuration has to be delivered to the system that could be one or more hops away, and might consist on a number of nodes, which the intrinsic challenges of the wireless medium. This is the distribution delay. The activation time, i.e., the time it takes between a configuration is properly distributed and it’s actually committed might also affect the closed loop performance, as some systems might suffer from e.g. slow reaction to changes. The sampling can have an associated, intrinsic delay, i.e., the time between the novel configuration is committed and the time samples from the novel performance are obtained. Finally, the monitoring can perform some processing of the sampled information, which could require some time before the actual delivery of this information to the optimiser (which, again, might introduce some delay). Of course, there are a huge variety of optimisation schemes that could be analysed under this framework, which could serve to fulfil many of the requirements identified in Section 3. In Table 4-9, we limit ourselves to those requirements that apply to most of the optimisation that we envision, and therefore are related to re-configurability and abstraction aspects. Table 4-9: Requirements for feedback loop of optimisation schemes ID SW-6 Requirement The SW platform must be able to adapt to demanding and changing contexts SW-8 The SW platform should facilitate the scheduling of optimisations in a conflictfree manner Dissemination Level: Public Description The SW platform requires monitoring capabilities to identify the network context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes Scheduling and conflict avoidance Page 51 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 IO-2 IO-3 IO-7 MC-2 MC-3 MC-9 The abstraction layer should facilitate the dynamic selection of communication technologies and protocols according to context and goals The abstraction layer should have a generic front-end to facilitate the interplay with the remote network or intelligent programs The device should dispose monitoring and context awareness mechanisms and relevant events (e.g. change detection, triggers, etc.) The SW platform must be flexible, reprogrammable and reconfigurable and support dynamic functional composition The SW platform must provide global acceptable solutions that prevent instabilities/conflicts/competitions The SW platform must be able to extract context in order to take optimal solutions Flexibility, reconfigurability and energyawareness will be supported Local Resource Controller; for data formatting and provisioning to high-level entities Monitoring agent; ability to collect and process measurements at multiple levels (channel, sensors, higher layers) Dynamicity, flexibility, over-the-air reprogrammability and reconfigurability Multi-node coordination Context extraction and awareness; Monitoring service; Aggregation of context information from multiple (heterogeneous) nodes Timing constraint configuration/reconfiguration The SW platform must reconfigure the wireless network card in less than the “default” operation timescale of the protocol (e.g., beacon interval time for 802.11) The intelligent program must take Resource management exploiting the IP-3 adaptive decisions on dynamic and multi-node coordination and intra-node autonomous management and operation offerings configuration of the available resources The intelligent program must make The decision are possibly required by IP-5 decisions within a specified deadline other system elements to correctly work 4.4.2 Architectures and algorithms for content dissemination MC-10 Due to this exponential growth of mobile data traffic and bandwidth-hungry applications, there is a demand for new architectures and algorithms to access content. It has been shown that the distribution of popular content can benefit from solutions that dynamically distribute copies of the content from the backend to a subset of subscribed mobile users, and let these users spread the content with opportunistic communication. This approach is of particular relevance to disseminate popular content to devices having two radio interfaces (such as cellular and D2D transceivers). A flexible architecture is required to infer how many copies of the content can be disseminated through the cellular interface and how many via D2D communication, with the objective of minimizing the load of the cellular interfaces for applications having a given delay constraint. We envision that the inherent scalability properties of the cloud can allow to deploy multiple instances of the media recording service for a large number of requested media streams and adapt the allocated network resources in a flexible manner according to the number of subscribed users and the dynamics of D2D communication. Details of our methods and concepts can be found in our publications for this project [25], [26]. Dissemination Level: Public Page 52 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 We study this problem both by means of analytical and experimental study. Our architecture can be seen as a realization of the framework presented in Figure 4-1, and in particular: we design an architecture (Figure 4-21) for content delivery, and we show that part of the global scheduler of the framework presented in Figure 4-1 could be implemented in the cloud we investigate the optimal content injection strategy running in the global scheduler. Our solution requires low signalling load from the monitoring agent operating in each modulator node. In order to investigate the most suitable algorithms running in the global scheduler, we first address this challenge from an optimization analysis perspective, in contrast to the existing heuristic solutions. Our solution is called HYPE. We model the dissemination of content (injected through the cellular interface) in an opportunistic network with heterogeneous node mobility. Then, based on this model, we derive the optimal content injection strategy that should run in the global scheduler, which minimizes the load of the cellular network while meeting the applications' constraints. We propose an adaptive algorithm based on control theory that implements this optimal strategy without requiring any data on the mobility patterns or the mobile nodes' contact rates requested to the monitoring agent in the mobile node. Figure 4-19: Comparison of cellular load (D) of HYPE versus the optimal (ideal) strategy and heuristics proposed in the literature using San Francisco real traces and 536 users. HYPE performs closely to the benchmark provided by the optimal strategy and substantially outperforms previous heuristics The proposed approach is extensively evaluated with both a heterogeneous mobility model as well as real-world contact traces, showing that it substantially outperforms previous approaches (heuristics) proposed in the literature. Two examples of evaluation scenarios are shown in Figure 4-19 and Figure 4-20. Dissemination Level: Public Page 53 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-20: HYPE signalling load as a function of the number of nodes N for the four baseline scenarios. HYPE outperforms the previous heuristics and scales very efficiently with the number of nodes. Following the analytical analysis, we design an architecture (Figure 4-21) for content delivery where scheduling mechanisms in the global scheduler are implemented in the cloud and we investigate with an experimental analysis how cloud computing could help disseminate the popular content for the above scenario. We investigate strategies for delivering the content with the cloud logic and we implement our system using Microsoft Azure cloud service and building a video application running on commodity smartphone. While we focus on the design and implementation of solutions that address the problem of video content delivery in practice - by far the most challenging in terms of network resources among the set of use cases above, our ideas and concepts can be applied or reformulated for other use cases as well. By exploiting the similarity of interests among multiple mobile users, multiple contents can be also delivered using an extension of our architecture. Figure 4-21: Schema of the cloud-based distribution system. The central component of the cloud is the Dissemination service. The first specific question we address is how cloud computing could tackle the overloading of the cellular networks and how it could help the network operators to alleviate the load of the network. Second, users may be at one position or may move, and available bandwidth of device-to-device (D2D) communication (and thus the offload opportunities) can greatly change over time. We experimentally compare different strategies and show that implementing the global scheduler in the cloud is more efficient in terms of traffic offload than approaches without cloud logic, and that practical challenges are solved by our approach that were not considered in former analytical works. The results in Figure 4-22 show that an initial spreading strategy based on multi-armed bandit problem provides high offloading opportunities (details can be found in our paper [26]). Dissemination Level: Public Page 54 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-22: Comparison of saved bandwidth for different strategies. ID SW-3 SW-6 SW-7 IO-2 IO-7 MC-7 IP-2 Table 4-10: Architectures and algorithms for content dissemination Requirement Description The SW platform must improve QoE The application requirements (application data rate, application delay, jitter at application level, data loss...) need to be mapped to QoS requirements in the network (e.g. min. throughput, network latency, jitter, network reliability). Then QoE is improved by satisfying these requirements. The SW platform must be able to The SW platform requires monitoring adapt to demanding and changing capabilities to identify the network contexts context and reconfiguration capabilities to adapt network and radio setting to guarantee QoS also when the network context changes Generic SW building blocks should Fundamental mechanisms that be provided operate on top of heterogeneous hardware modules and can be reused by diverse applications. The abstraction layer should Flexibility, reconfigurability and facilitate the dynamic selection of energy-awareness will be supported communication technologies and protocols according to context and goals The device should dispose Monitoring agent; monitoring and context awareness ability to collect and process mechanisms and relevant events measurements at multiple levels (e.g. change detection, triggers, etc.) (channel, sensors, higher layers) The SW platform should verify the Feedback mechanisms effectiveness of its decisions and configurations The intelligent program must exploit Context-awareness in terms of lower level context information changing conditions, ranging and Dissemination Level: Public Page 55 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 IP-7 4.4.3 The intelligent program may exploit historical information on the system position of nodes in the network, traffic levels/variations, HW capabilities; Monitoring library Historical information may refer to measurements performed on the system over time (e.g. average number of users, information on peakhours) Resource allocation in dense deployments Especially during peak hours, dense deployments are characterized by a high degree of interference that can take a toll on system performance. These can affect both the throughput of the user applications and the power consumed by each node. Moreover, as the system deployment is tailored to cope with peak hour conditions, the number of nodes that are actually deployed is generally overdimensioned for off-peak hour operations. Figure 4-23: Example of dense deployment From the point of view of resource allocation, the above two problems are commonly solved, on one hand by using Coordinated Multipoint (CoMP) techniques such as Coordinated Scheduling (CS), on the other by dynamically switching on and off certain nodes depending on the load of the network. Both solutions are generally realised using a centralized approach, which in turn requires knowledge on the status of the network over time in order to make effective decisions. The amount of information that needs to be shared in this case can be non-negligible and increases with the number of coordinated/managed nodes. Moreover, a high number of coordinated/managed nodes leads to a greater complexity, thus requires higher computational resources. All the above elements have been a great limitation in the actual deployment of coordination/management solution for Distributed RAN systems, limiting the number of nodes and forcing operators to adopt multi-level solutions to extend the scale of the considered system [27]. The new definition of 5G systems is leading to Centralized- and/or Virtualized-RAN (CRAN/V-RAN) solutions, which are seen as potential enabler to alleviate the above problems. Being centralized, these new architectures will allow greater information sharing among Dissemination Level: Public Page 56 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 nodes, without requiring any additional communication mechanism or medium. Moreover, the usage of virtualized system will also enable the sharing of computational resources, thus allowing for more complex (hence more effective) algorithms to be run. It is possible to leverage a C-RAN/V-RAN architecture to implement more effective and dynamic CoMP-CS and node activation/deactivation algorithms. In more details, two intelligent programs can be derived. A Flexible CoMP-Coordinated Scheduler (FC2S) will be focused on minimizing the interference in dense areas. The algorithm will collect as input the amount of resources requested by each node to cope with the user needs, and information regarding their interference conditions. It will then compute and distribute a global schedule, specifying to each node which resources can be used for transmission and on which one to expect interference. The FC2S algorithm will be based on optimization algorithms. A second intelligent program will deal with Flexible Activation/Deactivation (FAD) of nodes. It will take as an input information on the load of each node (e.g., number of connected users, requested resources) and the spatial position of both nodes and users. It may also leverage historical information regarding the status of the system (e.g., as average per-hour data rate) and high-level context information (e.g., a football match is about to start) which can enrich the view of system. These two solutions will be designed taking into consideration the requirements defined in Section 3, with a particular focus on the ones listed in Table 4-11. Table 4-11: Requirements addressed by the intelligent programs for resource allocation in dense deployments ID Requirement Description The SW operation must be energyIt will be ensured by reducing SW-1 efficient interference and activating/deactivating nodes The SW platform must improve QoE Performance in terms of application data SW-3 rate and possibly delay will be improved by coordinating transmissions of nodes The intelligent program must make Decisions will be made keeping time IP-5 decisions within a specified deadline constraints into account The intelligent program should make The designed programs will be designed IP-6 the best possible decision, unless this so as to produce also intermediate process requires breaking the deadline solutions The intelligent program may exploit Historical information may be used to IP-7 historical information on the system foresee the behaviour of the system and make decisions proactively The intelligent program should be able The designed programs will tolerate IP-8 to make decisions with incomplete missing inputs e.g. by replacing them inputs based on the previous ones Both these intelligent programs will work in a system-wide and centralized fashion, obtaining from the nodes information regarding the system, and forwarding their decisions to them. The two intelligent programs will work at different timescales. CoMP-CS algorithms are expected to follow the traffic dynamics as closely as possible. For these, an algorithm that makes decisions with a period ranging from hundreds of milliseconds to seconds appears to be an achievable goal (and in line with the dynamics of the traffic). It goes without saying that the FC2S algorithm will need to trade optimality and/or scale for time. A simulation evaluation is therefore required to assess how the algorithm scales with the number of coordinated nodes, users, resources, and how the minimum decision period depends on the scale. Dissemination Level: Public Page 57 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 On the other hand, the FAD algorithm will make decisions at a much coarser timescale (e.g. hundreds of seconds to tens of minutes). In fact, the network topology should not be altered too frequently, since frequent on/off switch of nodes might in fact lead to unexpected ripples in the configuration of the network (e.g. massive handovers) which are highly likely to hamper system performance. The FAD algorithm too will be based on optimization techniques. Much like with the FC2S algorithm, the FAD will be simulated to assess the optimal trade-off point between optimality and scale, on one side, and required period, on the other. 4.4.4 Performance-aware resource management Multi-node coordination implies the necessary procedures for the efficient coexistence of diverse and heterogeneous devices. Apart from the smooth operation of the devices, high performance is also a targeted value. To this end, this section describes an intelligent program for performance-aware resource management (Figure 4-24). The mechanism exploits the studies in intra-node operation and multi-node coordination, in order to achieve an overall superior operation that satisfies high-level requirements. Table 4-12 summarizes the requirements of Section 3 that the mechanism targets to address. Table 4-12: Targeted requirements of the Performance-aware Resource Manager ID Requirement Description The mechanism improves QoE SW-3 The SW platform must improve QoE through the satisfaction of the QoS requirements The intelligent program must fulfil The mechanism takes as input high IP-1 high level policies level policies and finds suitable configurations The intelligent program must exploit The mechanism takes as input lower IP-2 lower level context information level context information The intelligent program must take This is the main responsibility of the IP-3 adaptive decisions on dynamic and performance-aware resource autonomous management and manager configuration of the available resources Dissemination Level: Public Page 58 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 4-24: Performance-aware resource manager The mechanism provides an integrated solution for enhanced performance and energy reduction. It takes as input both high-level policy information (application/user requirements, QoS, energy efficiency, scalability) and lower level context information (traffic levels/variations, HW capabilities). Context awareness is derived from the elaboration of the measurements of the devices (monitoring agents). The outcome of its operation (decision) results in either the direct reconfiguration (parameterization) of individual resources or the management and configuration of multiple resources (through the Dynamic Functional ReComposition module). For taking the optimal decision, the mechanism is based on a multiobjective optimization algorithm. Through the dynamic and autonomous management and configuration of the available resources (e.g. spectrum, battery power, transmission power, transmission time, time slots, the number/bandwidth of radio channels, overall capacity, access points), it allows greater flexibility and resilience, as well as increased energy efficiency and OPEX savings. 4.4.5 Energy-aware operation Following the API described in Section 4.2.4, we expect to provide a full energy characterization of the device to be reported to the application. Taking into account this model, the system can optimize the energy consumption and the system performance changing rate adaptation. Using a higher MCS implies a better throughput but also an increase of the energy consumption and sometimes it is not the best policy to follow since a higher MCS also increases the retransmission rate but not the throughput due to the network conditions. Thus, we expect to improve the system performance but not only in terms of throughput but in terms of energy, including the new information provided by this API and maximizing the total system performance. 4.5 Anticipated impact The previous sections described the framework of the SW architecture that is proposed in Flex5Gware for realizing the vision of flexible, reconfigurable and re-programmable 5G Dissemination Level: Public Page 59 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 operation. The framework consists of three layers having different scope and objectives, while for each of the layers several mechanisms/solutions were presented. Table 4-13 summarizes these studies, highlighting for each of them the corresponding use cases, the targeted KPIs and the anticipated impact. Table 4-13: Mechanisms – Use cases – KPIs – Impact Mechanism / Algorithm / Scheme Sensor node abstraction and communication Use cases Targeted KPIs Impact Dynamic hotspots Smart cities Mobile broadband in vehicles Dynamic hotspots Smart cities Mobile broadband in vehicles Flexibility, versatility, reconfigurability Sensor HW abstraction Functions virtualization Flexibility, versatility, reconfigurability Energy efficiency Dynamic reconfiguration Improved performance (optimal functional composition) Energy savings Performance-aware Resource Management Dynamic hotspots Smart cities Mobile broadband in vehicles Improved performance Energy savings OPEX savings Flexible Coordinated Scheduler CoMP- Dynamic hotspots 50+ Mbps everywhere Flexible Activation/Deactivation Dynamic hotspots 50+ Mbps everywhere Energy efficiency Number of connected devices Resilience, continuity Flexibility, versatility, reconfigurability User Data Rate Flexibility, versatility, reconfigurability Energy Efficiency Content dissemination techniques Dynamic hotspots Mobile broadband in vehicles 50+ Mbps everywhere Dynamic hotspots Smart cities 50+ Mbps everywhere Flexibility, versatility, reconfigurability Number of connected devices Improved usage network resources Flexibility, versatility, reconfigurability Number of connected Enabler of context aware allocation of resources Dynamic Functional Re-composition Positioning Algorithms for Context-Aware Networks Dissemination Level: Public Dynamic and context aware allocation of resources Improved performance (data rate) Quick reaction to traffic distribution changes Energy saving and optimal node activation of Page 60 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Capacity estimation mechanisms Dissemination Level: Public Dynamic hotspots 50+ Mbps everywhere devices Flexibility, versatility, reconfigurability Number of connected devices Energy Efficiency Dynamic and contextaware resource allocation Improved performance (reduction of wasted resources) D2D enabler Page 61 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 5. Conclusions The purpose of WP5 is to specify the interfaces, modules, and services, to support the flexible and reconfigurable SW-driven operation for 5G. In this context, this deliverable drafted the vision of the corresponding SW architecture. To this end, the work started with the exploitation of the use cases and requirements defined in WP1. The SW requirements were collected and classified according to the three main categories of WP5. Furthermore, they were translated into the specification of the SW architecture. In particular, they were translated into design principles for the intra-node operation, multi-node coordination and intelligent programs. Based on these studies, this deliverable defined the Flex5Gware SW architecture, by specifying the main blocks and related interfaces, and analysing concepts and design principles for the modules. The defined SW architecture enables a flexible, reconfigurable and re-programmable 5G operation. In general, the advantages of platform-independent and fully re-programmable radio devices are many. In this case, a protocol stack wouldn’t require to be designed once for all, but the most appropriate protocol could be automatically downloaded upon need. Protocols would be much simpler, while the radio behaviour could be steered by, and adapted to, time-varying context conditions. In addition, backward compatibility wouldn’t be an issue anymore. Towards this direction, three aspects were particularly examined, i) device-level abstractions, ii) device architecture, and iii) control and context monitoring framework. Although, several similarities with the SDN concept can be identified, there are factors that pose new specific challenges, well beyond the “usual” SDN model. Considering the above, the framework splits into three functional layers, i) “Modular and flexible node operation”, ii) “Multi-node coordination”, and iii) “Intelligent programs”. The first layer deals with the specification of the intra-node modules and offered API, through the abstraction of HW and definition of HW-agnostic interfaces. For this purpose, specific proposals for device level abstractions and programmability of devices were provided in this document, with special attention paid to sensor nodes. Interfaces, which are crucial for the efficiency of the abstractions, were also studied. Furthermore, it is worth mentioning that virtualization technologies could also be exploited in this layer. The second layer provides the required control and management plane that enables a multi-node technology-agnostic SW operation. Several mechanisms were designed for the purposes of this layer. Finally, innovative SW programs (third layer) run on top of the developments of the aforementioned layers and support the dynamic and autonomous management of the available resources. The implementation of the defined SW architecture is the next step. Blocks, mechanisms and interfaces will be developed and evaluated. The objective is to fulfil the vision of a flexible and reconfigurable SW-driven operation for 5G networks. The final description and the performance evaluation of the SW architecture based on quantified metrics will be provided in the next deliverable D5.2 “Performance evaluation” of this WP. Dissemination Level: Public Page 62 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 6.Appendix 6.1 Device level abstraction – Background and starting point In the Flex5Gware project, we (also) take the start from findings obtained in a former EU project (FP7-FLAVIA), where such programming model was successfully applied to the very specific subset case of wireless MAC protocols. The work carried out in FLAVIA showed how to decouple the Medium Access Control protocol logic (described in an abstract form via eXtended Finite State Machines – XFSM) from the wireless device design, implementing the radio primitives as well as an XFSM execution engine called “Wireless MAC processor”. The approach promoted by FLAVIA appears to identify a viable compromise between the ability to program a broad range of wireless MAC protocols, and the consistency with the vendors' need for closed platforms. We now briefly review the basic Wireless MAC Processor (WMP) concept and the relevant MAC programming abstraction, to the extent needed for understanding how a similar (but more general) approach can be also used as a possible base for Flex5Gware. In designing a viable abstraction for platform independent wireless MAC protocols specification, the technical hurdle to face is how to formally model the MAC protocol behaviour using an high level language, and meanwhile support operations which may require a precision in the order of microseconds (e.g. schedule a frame transmission), and which cannot hence be outsourced to software programs running outside the NIC (e.g. in the driver). FLAVIA’s proposed abstraction is based on the following decoupling compromise: NIC cards do support an hard-coded (not modifiable by the MAC protocol programmer) instruction set, namely an Application Programming Interface (API) comprising of actions, events, and internal parameters upon which conditions can be evaluated [28]; Third-party MAC programmers formally describe how actions are coordinated and triggered (by events and conditions) via eXtensible Finite State Machines (XFSM); in essence, the programmer can specify in a formal (executable) model, custom protocol states, state transitions and relevant triggering events and conditions, and actions invoked when state transitions occur and/or when a state is reached. To execute injected XFSM (suitably compiled into a byte-code-like language), the NIC further implements a generic XFSM processing engine, conceptually analogous to a Central Processing Unit (CPU) in ordinary computing systems, but technically differing in its operation, as its role is to fetch states, parse events, trigger state transitions, and invoke associated actions. The above abstraction clearly decouples the role of the NIC manufacturer from that of the MAC programmer. Vendors remain in charge of providing HW signals and in bringing about innovation in the radio primitives (faster transmission technologies, advances in modulation and coding schemes, etc.); MAC programmers are free to define the protocol states and relevant transitions which orchestrate such primitives according to their desired MAC protocol logic. And dynamic MAC protocol reconfiguration becomes as easy as switching from a state machine to another. Such an approach was demonstrated by means of an implementation based on a commercial ultra-cheap commodity wireless card, and reconfiguration of the whole protocol stack was attained in the sub-microsecond time scale. Similar findings have been recently obtained by iMinds in a parallel national project. The programming model is called TAISC (Time-Annotated Instruction Set Computer) and consists of a cross-platform MAC protocol compiler and execution engine. MAC protocols significantly impact wireless performance metrics such as throughput, energy consumption and reliability. Although the choice of the optimal MAC protocol depends on time-varying criteria such as the current application requirements and the current environmental Dissemination Level: Public Page 63 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 conditions, today’s MAC protocols cannot be upgraded after deployment since their implementations are typically written in low level, hardware specific code that is hard to reuse on other hardware platforms (different radio chips and/or technologies). The TAISC framework offers a solution for hardware independent MAC protocol development and management. The solution allows to describe MAC protocols in a platform independent language (consisting of a radio platform independent instruction set), followed by a straightforward compilation step, yielding dedicated binary code, optimized for specific radio chips. The cross-compilation approach allows developers to design MAC protocols once, and then compile them for reuse on different radio platforms. To enable time-critical operation, the TAISC compiler adds exact time annotations to every instruction of the optimized binary code. The execution engine running on the radio platform, will execute the instructions with accurate time control thanks to the time annotation. The overall TAISC workflow to develop and execute a MAC protocol is illustrated in Figure 6-1: Step 1: device-agnostic MAC protocol creation. First, the MAC protocol designer creates a high-level, platform independent radio program to describe the MAC logic using predefined commands (instructions) in a C-like language, either using highlevel C syntax or using a more intuitive drag- and-drop interface. This human readable code consists of a sequence of commands that describe the generic behaviour of the MAC protocol and is largely independent of hardware specifics of the final hardware platform. Step 2: device specific compilation. Next, this human-readable sequence is compiled by the TAISC compiler into efficient, device-specific binary bytecode that can be executed by the TAISC execution engine running on the radio platform. Step 3: protocol dissemination. Afterwards, the bytecode is wirelessly transmitted to the target hardware platform and added to the MAC application repository on the local TAISC execution engine. Step 4: MAC protocol execution. Finally, the TAISC kernel executes the bytecode. Figure 6-1: Workflow describing the four steps for creating a MAC protocol using the TAISC framework. This approach has been successfully implemented for IEEE 802.15.4 MAC protocols, both on an embedded sensor platform and on a ZedBoard SDR platform. The full TAISC architecture is presented in Figure 6-2: Dissemination Level: Public Page 64 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 6-2: Overview of the TAISC architecture. Left: RAM memory blocks. Middle: logical Figure 5: Overview of theTAISC architecture. Left: RAM memory blocks. Middle: logical processing unit. Right: ROM memory. processing unit . Right : ROM memory. The TAISC RAM unit (Figure 6-2, left side) contains dynamic information, including program management (chain in Figure 6-2, corresponding radioradio module (imple menting chip spemanagement cific radio imple mentations ). Finally,to “Radio Engine Manger” in Figure 4-1), keeps all the radio programs consistent TAISC provides three upper layer interfaces (Figure 5, upper left): (i) the regarding their ROM and RAM boundaries and stores which radio program is data plane inte rface interacts with incoming / received packets from higher currently active layers,General (ii) the control inte rface provide s higheto r laye rsScheduler” access tointhe radio Purpose RAM (GPRAM, corresponding “Local Figure 4-1) program specific variable s from thevariables GPRAM and (iii) the management plane for storing dynamic radio program interfaceprovide to transmission upload and/ or activatene w compile d MAC access to thesfunctionality receive / transmit queue (corresponding to “blue arrow protocols. between Radio Engine and Radio Hardware” in Figure 4-1), 5. TAISC registers that contain radio specific status information, such as the current radio frequency (corresponding Per for m ance evaluat ion to “blue arrow between Radio Engine and Radio Timestamps” in Figure 4-1). The TAISC unite(Figure 6-2, rightpe side, corresponding to “Radio Program” Figureand 4-1) This sROM ection valuate s the rformance of the TAISC architeincture stores static information, including one or more compiled radio programs as well as their several implemented MAC prot ocols. static information such as lookup tables (for example to retrieve the radio frequency to use in each time slot for a hopping based MAC protocol). 5.1. TAI SC architecture performance The TAISC logic unit (Figure 6-2, middle, corresponding to “Radio Engine” in Figure 4-1) cutetimeannotate MAC s, theTAIS C is archite ctureneeengine dsto formsToe the xe core of the architecture.dIts mostbinarie important component the execution that implements a scheduler which manages the execution times of the instructions, be installed on the processor controlling the radio chip. The architecture has dispatches the instruction to the correct module, processes incoming events and schedules been implemented on top of a MSP430F5437 micro-controller and theCC2520 which instruction or radio program to fetch next. Instructions are executed by the core IEEE802.15.4 int egrat edprogram on t he counter RM090forembedded formor[14]. module (that a.o.radio manipulates the reacting toplat triggers conditional events), the arithmetic module (supporting operations such as copy, add, subtract, etc.), the data plane module (that a.o. manages access to and from the data plane and manages conflicts between different modules) and the radio module (implementing chip specific radio implementations). 15 Dissemination Level: Public Page 65 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Finally, TAISC provides three upper layer interfaces (Figure 6-2, upper left): (i) the data plane interface interacts with incoming / received packets from higher layers, (ii) the control interface provides higher layers access to the radio program specific variables from the GPRAM and (iii) the management plane interface provides functionality to upload and/or activate new compiled MAC protocols. As step 1 of the TAISC (Radio platform independent MAC protocol creation) seems to be very critical for the Flex5Gware project, some more details are given. TAISC is designed to ease the process of developing and reprogramming MAC protocols. During this step, the programmer can focus on writing human-readable radio programs that are easy and intuitive to create. To this end, MAC protocol design in TAISC requires no knowledge about specific radio chip behaviour such as the transition timings (for example the time to switch to a new channel) or radio dependencies (for example the prerequisite conditions before a packet can be transmitted). The high-level logic of a MAC protocol is described in a radio program that consists of a sequence of instructions for the radio platform. Radio programs are created using a simple C-like language to describe the desired radio behaviour. The syntax of such a description is C-compatible, but uses the following TAISC specific components: Instructions. An instruction describes a single action of the TAISC engine. Instructions are implemented in TAISC as function calls and are declared in the taisc.h header. Registers. Developers can define their own variables, but a number of often used variables are offered by default to MAC protocol developers. A list of these registers is shown in Figure 6-3. Events. A MAC protocol can react to external impulses by making use of events. Events describe impulses that can be triggered by both hardware (such as the radio) as software (such as the network stack). A radio program can wait for one of these triggers before continuing execution or skip several instructions by using if statements. An example of the available events on the RM090 embedded sensor node platform used by iMinds is shown in Figure 6-4. Radio programs can include variables that will be allocated in the TAISC memory space and conditional execution is supported by using ‘if’ statements as well as event triggers. As an example, Figure 6-5 shows a short code fragment for the back-off calculation from a CSMA/CA MAC protocol. Figure 6-3: Overview of TAISC registers. Similar to the registers one can find in micro controllers these are volatile and are updated by the TAISC modules. Dissemination Level: Public Page 66 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 Figure 6-4: Overview of TAISC events. These events can be used for the implementation of conditional radio programs. Figure 6-5: TAISC CSMA/CA code example: use of the back-off instruction 6.2 TSAPI preliminary considerations The envisaged way to link the new application programming on nodes through the newly proposed API is described at Figure 6-6. Figure 6-6: Application structure and API linking Dissemination Level: Public Page 67 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 An application is linked to the proposed architecture using the provided API. An application is made up of three parts: 1- Headers: As the envisaged code language preliminary selected is ANSI C, they will be .h files. These files will include the declaration of the functions that programmers will use in their programs. This header includes everything needed to work with the architecture, e.g. drivers, boards, devices and standard libraries. 2- Initialization function. This function is called during the initialization process. This process is an automatic initialization of the microcontroller, and simply requires a small configuration of the peripherals that will be used by the microcontroller. 3- Application task. Each task created in the initialization function is developed in this part. Tasks contain the functionality of the application, for example sending a SMS to a specific mobile phone number or reading a NFC card to process the NFC data. The API envisaged to be developed in the Flex5GWare project will offer functions to program the hardware platform, simplifying the management of the underlying hardware. The following and preliminary rules are presented as guidelines to be used when defining the API. Coding rules A name system will be defined so as to be shared among all functions in the TSAPI. Every function in this API will be composed of 3 parts; it will begins with the generic name (as for instance Flex5GWare) followed by the device name (hardware module) and a short description to explain the functionality offered by the function, e.g. Flex5GWare_GPRS_SendSms () is a function to send a SMS using the GPRS modem. All data types in TSAPI follow the same coding rule; they begin with the generic name followed by the device and a short explanation about its use, e.g. Flex5GWare_gprs_config_t is a type to configure the GPRS modem. The idea is having a software handler for each module (or at least the majority) to link it to the hardware module and to store relevant information like task handlers or queue handlers. This function handler should not be modified by the programmer, but sometimes it is interesting to check or read it to look for error codes. Return codes It is very common to have the same return codes in API functions; Flex5GWare_PASS or Flex5GWare_FAIL. There might be functions that can return a special fault code. These codes will have specific meaning to help programmers to debug their applications. Initialization and configuration functions The init function will be defined so as to initialize all hardware and software resources needed to manage the devices (GPRS, NFC, GPS, etc…) or peripherals (UART, I2C, SPI, DIO, AI…). The init functions will have 2 main parameters: device’s handler and configuration structure. This structure holds relevant parameters for the device as, for example, the baud rate. Other functions The API documentation will also include predefined example functions that programmers may use as references for developing their own solutions. They should cover all communication possibilities. Dissemination Level: Public Page 68 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 7.References [1] IETF, “Key words for use in RFCs to Indicate Requirement Levels”, RFC2119 [2] GNU Radio. The GNU Software Radio, http://www.gnu.org/software/gnuradio/ [3] WARP Project. Wireless Open-Access Research Platform, Rice University, http://warp.rice.edu/ [4] National Instruments. “LabVIEW,” http://www.ni.com/labview/ [5] D. Sutton, J. Lotze, H. Lahlou, S.A. Fahmy, K.E. Nolan, B. Ozgul, T.W. Rondeau, J. Noguera, and L.E. Doyle. “Iris: an architecture for cognitive radio networking testbeds” Communications Magazine, IEEE, 2010 [6] “GR-Easy”, http://www.ccm.ece.vt.edu/?q=greasy [7] Craig Partridge, "Realizing the future of Communications of the ACM 54.9 (2011): 62-68 wireless data communications", [8] Pieter De Mil, Bart Jooris, Lieven Tytgat, Jeroen Hoebeke, Ingrid Moerman and Piet Demeester “snapMac: a generic MAC/PHY architecture enabling flexible MAC design”, AD HOC NETWORKS. 17. p.37-59, 2014 [9] Bart Jooris, Eli De Poorter, Peter Ruckebusch, Peter De Valck, Christophe, Van Praet and Ingrid Moerman, "TAISC: a cross-platform MAC protocol compiler and execution engine”, Elsevier Computer Networks, paper under review. [10] FreeRTOS operating system. http://www.freertos.org/ [11] “Internet of Things propels the Networked Society”, Ericsson Labs Blog by Ericsson Research, Available: https://labs.ericsson.com/developer-community/blog/internet-ofthings-propels-the-networked-society [12] OECD (2012), “Machine-to-Machine Communications: Connecting Billions of Devices”, OECD Digital Economy Papers, No. 192, OECD Publishing. http://dx.doi.org/10.1787/5k9gsh2gp043-en [13] The Constrained Application Protocol (CoAP), IETF RFC Request for Comments: 7252, https://tools.ietf.org/html/rfc7252 [14] “Mobile Edge Computing – Introductory Technical White Paper”. https://portal.etsi.org/Portals/0/TBpages/MEC/Docs/Mobile-edge_Computing__Introductory_Technical_White_Paper_V1%2018-09-14.pdf [15] Smart Cells Revolutionize Service Delivery, Intel white paper. http://www.intel.co.uk/content/dam/www/public/us/en/documents/white-papers/smartcells-revolutionize- service-delivery.pdf [16] P. Serrano, P. Patras, A. Mannocci, V. Mancuso, A. Banchs, “Control Theoretic Optimization of 802.11 WLANs: Implementation and Experimental Evaluation”, Elsevier Computer Networks, vol. 57, no. 1, January 2013. [17] J. Ortín, P. Serrano, C. Donato, “Modeling the Impact of Start-Up Times on the Performance of Resource-on-Demand Schemes in 802.11 WLANs”, The 4th IFIP Conference on Sustainable Internet and ICT for Sustainability (SustainIT), Madrid, Spain, April 2015 [18] G. Fayolle and R. Iasnogorodski, “Solutions of functional equations arising in the analysis of two server queueing models,” in Performance, pp. 289–303, 1979. Dissemination Level: Public Page 69 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 [19] F. Guillemin and D. Pinchon, “Analysis of the weighted fair queuing system with two classes of customers with exponential service times,” in Journal of Applied Probability, 2004. [20] S. C. Borst, O. J. Boxma, and P. R. Jelenkovic, “Coupled processors with regularly varying service times,” in INFOCOM, pp. 157–164, 2000. [21] multi-cell scenarios,” in SIGMETRICS, pp. 378–380, 2004. [22] , “Stability of parallel queueing systems with coupled service rates,” Discrete Event Dynamic Systems, vol. 18, no. 4, pp. 447–472, 2008. [23] M. Jonckheere and S. C. Borst, “Stability of multi-class queueing systems with state-dependent service rates,” in VALUETOOLS, p. 15, 2006. [24] C. Vitale, G. Rizzo, B. Rengarajan, V. Mancuso, “An Analytical Approach to Performance Analysis of Coupled Processor Systems”, in proceedings of ITC27, Ghent, Belgium, September 2015. [25] Vincenzo Sciancalepore, Domenico Giustiniano, Albert Banchs, Andreea Hossmann-Picu, “Offloading Cellular Traffic through Opportunistic Communications: Analysis and Optimization” (Accepted for publication) IEEE Journal on Selected Areas in Communications, PP (99). pp. 1-16. ISSN 0733-8716 [26] Jiri Danihelka, Domenico Giustiniano, Bernhard Plattner, “On a Cloud-Controlled Architecture for Device-to-Device Content Distribution” In: The 10th ACM MobiCom Workshop on Challenged Networks (ACM Chants 2015), in conjunction with the 21st Annual International Conference on Mobile Computing and Networking (ACM MobiCom 2015), 11 September 2015, Paris, France [27] G. Nardini, G. Stea, A. Virdis, D. Sabella, M. Caretti, "Practical large-scale coordinated scheduling in LTE-Advanced networks", Springer Wireless Networks, to appear (Accepted 27/3/2015), DOI: 10.1007/s11276-015-0948-6 [28] I. Tinnirello, G. Bianchi, P. Gallo, D. Garlisi, F. Giuliano, and F. Gringoli. Wireless MAC processors: Programming MAC protocols on commodity hardware. In Proc. IEEE INFOCOM, pages 1269–1277, 2012 Dissemination Level: Public Page 70 H2020 Grant Agreement Number: 671563 Document ID: WP5 / D5.1 ________________________________________________________________________ http://www.flex5gware.eu ________________________________________________________________________ Dissemination Level: Public Page 71
© Copyright 2026 Paperzz