charisma - d2.2 - v1€¦ · v0.1 11/10/2016 uessex table of contents v0.2 15/11/2016 hhi, icom,...

CHARISMA – D2.2 of 66

Converged Heterogeneous Advanced 5G Cloud-‐RAN Architecture for Intelligent and Secure Media Access

Project no. 671704

Research and Innovation Action

Co-‐funded by the Horizon 2020 Framework Programme of the European Union

Call identifier: H2020-‐ICT-‐2014-‐1

Topic: ICT-‐14-‐2014 -‐ Advanced 5G Network Infrastructure for the Future Internet

Start date of project: July 1st, 2015

Deliverable D2.2

CHARISMA PHY design and interfacing

Due date: 31/12/2016

Submission date: 31/12/2016

Deliverable leader: Michael Parker (UEssex)

Dissemination Level PU: Public PP: Restricted to other programme participants (including the Commission Services) RE: Restricted to a group specified by the consortium (including the Commission Services) CO: Confidential, only for members of the consortium (including the Commission Services)


List of Contributors

Participant Short Name Contributor

Fraunhofer HHI HHI Kai Habel, Volker Jungnickel

Ericsson ERICSSON Carolina Canales

Fundació i2CAT I2CAT Shuaib Siddiqui, Eduard Escalona

Demokritos NCSRD NCSRD Eleni Trouva

Innoroute INNO Andreas Foglar, Marian Ulbricht

JCP-Connect JCP-C Yaning Liu

University of Essex UESSEX Mike Parker, Geza Koczian, Terry Quinlan, Stuart Walker

Intracom ICOM Dinos Katsaros, Dimitrios Kritharidis

Ethernity ETH Eugene Zetserov

Change history

Version Date Partners Description/Comments

v0.1 11/10/2016 UESSEX Table of Contents

v0.2 15/11/2016 HHI, ICOM, JCP-C

UESSEX, ETH,

INNOROUTE

Initial contributions from partners

v0.3 9/12/2016 ICOM, UESSEX, ERICSSON, COSMOTE, HHI, I2CAT

Final round of contributions

v0.4 19/12/2016 COSMOTE, HHI Internal Review

v0.5 22/12/2016 COSMOTE, HHI Final Internal Review

v1.0 23/12/2016 UESSEX FINAL


Table of Contents 1. Introduction ........................................................................................................................ 6

2. Overview of Architecture & Management Interfacing ......................................................... 7 2.1. CHARISMA Architecture Overview ..................................................................................................... 7 2.2. CHARISMA Physical Network Resource Management Interfaces ....................................................... 7

2.2.1. TrustNode .................................................................................................................................... 7 6Tree fast routing ...................................................................................................................................... 9 2.2.2. MoBcache Node ........................................................................................................................... 9 2.2.3. 100G OFDM-‐PON ....................................................................................................................... 13 2.2.4. Point-‐to-‐Point wireless backhaul ............................................................................................... 14 2.2.5. Ericsson HDS 8000 based data centre infrastructure ................................................................ 18 2.2.6. P2P Wireless Link ....................................................................................................................... 19

3. High Capacity PHY links ..................................................................................................... 21 3.1. 100G OFDM-‐PON .............................................................................................................................. 21

3.1.1. OLT design .................................................................................................................................. 21 3.1.2. Generic FFT core ........................................................................................................................ 21 3.1.3. ONU design and measurements ................................................................................................ 25

3.2. 10G Wireless Links ............................................................................................................................ 27 3.2.1. Omnidirectional 13dBi Gain Bi-‐ Conical Horn Antenna for IEEE802.11ad Applications ............. 27 3.2.2. Antenna Design Philosophy ....................................................................................................... 27 3.2.3. Discussion and Further Work ..................................................................................................... 31

4. Virtualised CPE .................................................................................................................. 34 4.1. VNF Modeling for vCPE ..................................................................................................................... 34

4.1.1. VNF Components ....................................................................................................................... 34 4.2. Specifications & test set-‐up .............................................................................................................. 37

4.2.1. vCPE Deployments and Specifications ....................................................................................... 37 4.2.2. vCPE Challenges and Implementation ....................................................................................... 38 4.2.3. Test set-‐up ................................................................................................................................. 38

5. CHARISMA Security Features ............................................................................................ 41 5.1. Distributed e2e security .................................................................................................................... 41 5.2. Physical layer security ....................................................................................................................... 46

5.2.1. 4D Tesseract-‐key (T-‐Key) Concept ............................................................................................. 46 5.3. TrustNode multi-‐user & router platform environment .................................................................... 55

6. Conclusions ....................................................................................................................... 56

References ............................................................................................................................ 57

Acronyms .............................................................................................................................. 60


List of Figures Figure 2-‐1: Trustnode OpenFlow integration .................................................................................................... 8 Figure 2-‐2: Trustnode userblock modes ............................................................................................................ 9 Figure 2-‐3 MoBcache Prototype Overview ..................................................................................................... 10 Figure 2-‐4 Management interface for Cache Node in CHARISMA .................................................................. 10 Figure 2-‐5: 100G OFDM-‐PON control and data flow ....................................................................................... 13 Figure 2-‐6: Software integration ..................................................................................................................... 13 Figure 2-‐7: Control packet format ................................................................................................................... 13 Figure 2-‐8: Backhaul System View .................................................................................................................. 15 Figure 2-‐9: SDN adaptation on backhaul equipment ...................................................................................... 15 Figure 2-‐10: Network Processor adaptation for the transition to SDN ........................................................... 17 Figure 3-‐1: OLT-‐Tx architecture of 100G OFDM-‐PON ..................................................................................... 21 Figure 3-‐2: Parallel architecture for 8-‐point FFT with radix 2 butterfly .......................................................... 22 Figure 3-‐3: 16-‐point FFT using radix 4 butterflies ........................................................................................... 22 Figure 3-‐4: 16-‐point FFT using split radix (radix 2 and 4) butterflies ............................................................... 22 Figure 3-‐5: Parallel FFT input and output. ....................................................................................................... 23 Figure 3-‐6: Building blocks of parallel FFT ....................................................................................................... 24 Figure 3-‐7: ONU-‐Rx architecture of 100G OFDM-‐PON .................................................................................... 25 Figure 3-‐8: Experimental setups to evaluate ONU DSP for 100G OFDM-‐PON ................................................ 25 Figure 3-‐9: Initial estimation of CFO and SFO for ONU DSP ............................................................................ 26 Figure 3-‐10: Results for tracking of CFO and SFO at ONU ............................................................................... 26 Figure 3-‐11: Model graphic of the complete antenna structure ..................................................................... 28 Figure 3-‐12: S11 plot of 75 mm antenna over IEEE802.11ad band ................................................................. 29 Figure 3-‐13: VSWR plot of 75 mm antenna over IEEE802.11ad band ............................................................. 29 Figure 3-‐14: Impedance plot of 75 mm antenna over IEEE802.11ad band ..................................................... 30 Figure 3-‐15: Surface current propagation on monopole and horn surface .................................................... 30 Figure 3-‐16: Predicted radiation patterns and gain performance .................................................................. 31 Figure 3-‐17: Rain fade effects at mmW frequencies ....................................................................................... 32 Figure 3-‐18: mm-‐wave bands highlighting absorption peaks and troughs ..................................................... 33 Figure 4-‐1 VNF high-‐level architecture model ................................................................................................ 35 Figure 4-‐2 VNF example with two VNFC ......................................................................................................... 35 Figure 4-‐3 Service graph example with 3 VNFs ............................................................................................... 36 Figure 4-‐4: vCPE environment ......................................................................................................................... 38 Figure 4-‐5: vCPE testing environment ............................................................................................................. 39 Figure 5-‐1: Principal LTE network architecture ............................................................................................... 42 Figure 5-‐2: Fingerprint [9] ............................................................................................................................... 42 Figure 5-‐3: End points for e2e security in mobile network ............................................................................. 43 Figure 5-‐4: Left: The centralized security architecture in 4G LTE leads to increases latency, because secure traffic has to be routed via the EPC. Right: Latency could be significantly reduced, if the X2 traffic could be routed at the nearest common aggregation point, e.g. the lowest CAL node. ............................................... 44 Figure 5-‐5: Architecture view on 4G (centralised) and 5G (decentralised) ..................................................... 45 Figure 5-‐6: Schematic construction of a 4D tessaract. .................................................................................... 47


Executive Summary

This deliverable D2.2 provides an update on the physical layer design and interfacing towards the overall implementation of the CHARISMA architecture. We provide updates on the technical performances and requirements of the following devices, with regard to their interfacing for network resource management.

TrustNode 6Tree router: The configuration of the low-‐latency IPv6 router is changed using the hardware interface, and is also part of the TrustNode security concept. Integrity and authentication is achieved via a unique configuration parameter determined by a device’s logical position in the network. The path of a packet through the network is predefined by the value of the IPv6 address bits inside the protection area of MACSec. By applying a plausibility check for the source address on incoming packets, network devices are therefore not vulnerable to address spoofing attacks.

MoBcache: This is managed and configured based on the Network Configuration Protocol (NETCONF), the NETCONF protocol operations being realized as remote procedure calls (RPCs). In the management system, a Netconf client is used to communicate with a Netopeer server running on the cache node.

100G OFDM-‐PON: The OLT of the 100G OFDM-‐PON is implemented on a Virtex7-‐based FPGA platform, with the interface to the CMO being handled via a Python script, which listens on a predefined port (15015) for a specific UDP packet. A new FFT IP core has been developed in order to choose the FFT size depending on the different requirements of OLT and ONU. Because of the high throughput of OLT and ONU only a parallel FFT architecture has been considered.

Millimetre-‐wave wireless backhaul system: This interfaces with an access base station (e.g. eNodeB) and transmits traffic through a processing chain consisting of a Network Processor performing upper MAC layer, a baseband processor executing the PHY layer processing, DAC/ADC, RF transceiver and an antenna.

60-‐GHz omnidirectional antenna: A new design based on a horn antenna architecture is described, with the design exhibiting a gain of 13dBi over 360 degrees, with a predicted S11 return loss better than -‐ 15dB across the required range with an associated VSWR being lower than 1.4.

Ericsson Hyperscale Datacentre System 8000 configures and manages the compute resources, storage capacity, and network connectivity, as well as the power systems, firmware, and related functions.

Virtualised CPE: CHARISMA uses the TeNOR NFVO for its MANO chores, the modelling of a vCPE being done within the TeNOR NF framework. The use of metadata for VNF description permits the service chaining and the service insertion, and building e2e services by composition.

For the CHARISMA security features, in order to provide e2e security the user data is encrypted, with messenger applications (e.g. Signal and Threema) providing e2e security for messages and voice data. Methods and protocols used in these applications can be adapted and implemented into the 5G protocol stack in order to provide native e2e security. Three levels of e2e security are indicated: at application level (e.g. Signal), on user devices (5G protocol stack), and at the digital units (DUs). We describe a SW-‐based approach to security and encryption offering potential low-‐cost, ease of use and real-‐time operation, the technique being based on a symmetric block cipher technique with a large 384-‐bit key-‐space. Encryption key generation is based around the concept of a 4D tesseract, such that 4-‐rounds and different sub-‐rounds are using to shift the tesseract and create a part of the encryption key randomly.


1. Introduction

This deliverable D2.2 provides an update on the physical layer design and interfacing towards the overall implementation of the CHARISMA architecture. This builds upon the work first reported in D2.1 and D3.1, and gives the latest details on the physical layout design, virtualisation technologies, and link technologies security features, being developed within the work package WP2. In particular we describe the management interfaces for the CHARISMA hardware devices so that they can be controlled by the control management and orchestration (CMO) system being developed in work package WP3.

The technologies described in this deliverable have been developed in the context of the hierarchical network architecture that has been developed in CHARISMA, based around the Converged Aggregation Level (CAL) notes, as reported earlier (e.g. D1.1, D3.1, and D1.2). The hierarchical CALs have been adopted in order to facilitate the low latency, open access (multi-‐tenancy), and virtualised security objectives of the CHARISMA project. Many of the technologies described in this deliverable are intrinsic to the intelligent management units (IMUs) associated with each CAL, and where the distributed CHARISMA network intelligence resides. In addition, the high capacity PHY link technologies described here provide the physical connectivity between the various hierarchical CAL nodes of the CHARISMA architecture. Together, these technologies comprise the underlying performance innovations required to support the CHARISMA 5G capabilities and objectives.

The deliverable is organised as follows. Following the introductory remarks, chapter 2 provides an overview and update of the architecture management interfaces for the following CHARISMA technologies: TrustNode with 6Tree routing (for low end-‐to-‐end latency); MoBcache node, for low latency access times; 100 OFDM-‐PON and point-‐to-‐point millimetre-‐wave (mmW) wireless links for high-‐capacity data transport (to avoid bottlenecking delays); the Ericsson HDS 8000 datacentre (DC) infrastructure for hosting the CMO. Chapter 3 describes the high-‐capacity physical PHY layer technologies being developed for CHARISMA, based upon the 100 OFDM-‐PON for the backhaul section, between CAL3 and CAL2, and the 10G mmW wireless links between CAL1 and CAL0. Chapter 4 provides the modelling and specifications (with test set-‐up) for the virtualised CPE. The CHARISMA security features are described in Chapter 5, with a discussion of a distributed end-‐to-‐end security architecture suitable for 5G networking, as well as a PHY layer security approach that has been developed within CHARISMA, and the security approach for the TrustNode routing platform based upon the 6Tree hierarchical routing concept. Finally, some conclusions are provided in Chapter 6.


2. Overview of Architecture & Management Interfacing

2.1. CHARISMA Architecture Overview In this chapter, we provide an overview of the technical developments in the physical layer innovations that have occurred since the earlier deliverable D3.2 was written 6 months previously (M12 of the project.) In particular, in section 3.2.4.3 “CHARISMA Physical Network Resource Management Interfaces” of D3.2 the following physical devices and systems were described:

• 10GPON system

• TrustNode router

• Smart NIC card

• EPC and eNB

• MoBcache node

• 100G OFDM-‐PON

• mmW wireless backhaul

• 60-‐GHz wireless edge-‐haul

In the following section, we provide updates on the technical performances and requirements of these devices, with particular regard to their interfacing for network resource management. In particular, we consider the updates for the TrustNode router, MoBcache, 100G OFDM-‐PON, mmW wireless backhaul, and the additional Ericsson HDS 8000 based data centre infrastructure equipment. These technical update are described in the next section 2.2. There are no specific updates or technical improvements to be reported for the 10GPON, 60-‐GHz wireless edge-‐haul, smart NIC, EPC and eNB technologies.

2.2. CHARISMA Physical Network Resource Management Interfaces This section details the different management interfaces of the different physical devices under consideration for the CHARISMA network.

2.2.1. TrustNode

The TrustNode router is a CPU-‐FPGA hybrid device, where the main part of the traffic is processed in hardware, with the CPU acting as support for advanced routing decisions and as the configuration interface. The CPU is accessed using well-‐known software interfaces like ssh and openflow. The FlowEngine, which is a part of the TrustNode hardware, is used to accelerate the selected flows.


Configuration can either be done via a command line interface (CLI) or is automatically fed with flows from the OpenvSwitch core.

The configuration of the high-‐speed IPv6 routing (6Tree) can be changed manually using the hardware interface on the TrustNode device, and can be considered to be part of the TrustNode security concept to provide a secure and stable IPv6 network as a base for software defined network technologies.

Open Flow Support

TrustNode allows a straightforward implementation of an OpenFlow switch (Figure 2-‐1, below). The Control Processor implements the OpenFlow Channel, while the FlowEngine implements the extension to the OpenFlow data path. For the configuration interface, all features of the current OpenSwitch version 2.5.0 are supported. For further documentation see: http://openvswitch.org/support/

Figure 2-‐1: Trustnode OpenFlow integration

TrustNode as OpenFlow Switch

Hardware reconfiguration

The TrustNode allows modification and extension of the HW and SW parts, i.e. the FlowEngine in the FPGA and the ATOM Control Processor. For HW modifications/ extensions relevant parts of the design are provided as VHDL source code.

Basic modules such as Ethernet framing interfaces, serial-‐to-‐parallel conversion, packet multiplexing, and queuing mechanism are hardwired, so that basic operation is always assured. Ethernet switching with MAC learning and forwarding and the 6Tree algorithm are hardwired as well. For implementation of new forwarding mechanisms, modifications and/or new functions can be implemented in the ingress data path, in the scheduler and in the egress data path. In the data path two types of forwarding modules exist, pipelining block and storage block (see Figure 2-‐2, below). The former needs a definite number of cycles to execute a task. No pause is allowed. The backpressure signal TREADY is disabled or – as indicated with the dotted line – is directly bypassed to the preceding block. The storage block contains a FIFO buffer in order to buffer the data stream during pauses, which occur, for example, during VLAN tag insertion. For both block types, templates are provided.


Figure 2-‐2: Trustnode userblock modes

To implement HW modifications/ extensions the VHDL HW description language is used. A high-‐level entry tool to replace VHDL by a high level language (C, Python, etc.) is under investigation. For the reconfiguration of the FPGA during run time, an embedded USB-‐JTAG is used, which will be available in the hardware revision. The configuration can be initiated from the Atom CPU via the Vivado HW_server .

6Tree fast routing

The 6Tree algorithm, as described in other papers, e.g. [1], uses the benefit of a tree structured IP address plan to speed-‐up the routing process. Traditional routing uses longest prefix match to determine the output port on each packet. The time needed for the lookup depends on the number of entries in the lookup table. A 6Tree device uses a preconfigured number of bits in the destination IP address as a value representing the output port. No search is needed for this process any more, which therefore significantly speeds up the packet delivery. Initial measurements show a processing delay of only 2.5µs.

2.2.2. MoBcache Node

The CHARISMA content caching system is designed to provide an open access, highly configurable, efficient and transparent in-‐network caching service to improve the efficient exploitation of network resources, by distributing content using the different CHARISMA converged aggregation levels (CALs) in the network, as already defined in D1.1. One of the main difficulties is to provide continuous service with low latency in a mobile scenario, where user equipment switches from different wireless/mobile networks. For example, in the automotive – bus use case presented in Section 4.2.3 of D1.1 and D1.2, some intelligent caching, switching and routing closer to end users has been defined in order to assist in reducing network latency. However, providing intelligence in a wireless / mobile scenario requires a sophisticated design for the hardware device.

The MoBcache (MB) shown in Figure 2-‐3 is a dedicated mobile router-‐server prototype enabling content caching and prefetching functionalities with autonomous battery and auto-‐configuration. MoBcache is specially designed for mobile scenarios in the CHARISMA system to keep the service continuity, while a user moves and handovers between networks are performed. It has a 1-‐Gb Ethernet Port, a Wifi 5-‐GHz interface, a Wifi 2.4-‐GHz interface, and an optional LTE interface.


Figure 2-‐3 MoBcache Prototype Overview

The MoBcache is designed to be managed and configured using the Network Configuration Protocol (NETCONF). NETCONF provides mechanisms to install, update, and delete the configuration of network devices, such as routers, switches, and firewalls. It uses Extensible Markup Language (XML)-‐based or JavaScript Object Notation (JSON) data encoding for the configuration data and as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs).

Figure 2-‐4 shows the interface design between cache nodes and management system. In the management system, the Netconf client (for example, netopeer-‐cli or OpenDayLite (ODL) netconf client) is used to communicate with the Netopeer server running on the cache node.

Figure 2-‐4 Management interface for Cache Node in CHARISMA


The Netopeer server runs on the MoBcache, and is a set of NETCONF tools built on the libnetconf library. The goal of a Netopeer server is to provide a generic NETCONF framework that will allow network device developers to apply configuration changes to their devices without any knowledge of the NETCONF protocol. In CHARISMA, each MoBcache (MB) or a cache node runs a NETCONF server, running in the background as a system demon and allows multiple accesses from clients using the standard SSH transport protocol. The main implementation on cache nodes is provided by the TransAPI module for caching and prefetching functionalities. The TransAPIs provide the interface through which the NETCONF server changes the setting of various devices (e.g., network interfaces), the system (e.g., time zone) and the configuration of software programs (e.g. squid proxy) on the machine. It allows the cache controller or CMO to read the current configuration of cache nodes, change the configuration, or send a remote command to the cache nodes. We have implemented four modules: squid-‐config, squid-‐list, prefetch-‐config and prefetch-‐list. The module squid-‐config allows the cache controller or CMO to configure the squid configuration file “squid.conf” via the NETCONF TransAPI. The module squid-‐list reads the cached content, and the current and past user requests, and sends this information to the CMO. The module prefetch-‐config allows the CMO to configure the prefetcher, while the module prefetch-‐list is used to perform a prefetch command sent by CMO.

Each module has a datastore file that gives a high level description of TransAPI module parameters. For example, the datastore.xml of jcp-‐squid-‐config is:

<datastores xmlns="urn:cesnet:tmc:datastores:file"> <running lock=""> <squidconf xmlns="urn:jcp:com:squidconf"> <httpPort>3128</httpPort> <cacheMem>256 MB</cacheMem> <memoryReplacementPolicy>lru</memoryReplacementPolicy> <cacheReplacementPolicy>lru</cacheReplacementPolicy> <maxOpenDiskFds>0</maxOpenDiskFds> <minimumObjectSize>0 KB</minimumObjectSize> <maximumObjectSize>4096 KB</maximumObjectSize> <cacheSwapLow>90</cacheSwapLow> <cacheSwapHigh>95</cacheSwapHigh> </squidconf> </running> <startup lock=""> <squidconf xmlns="urn:jcp:com:squidconf"> <httpPort>3128</httpPort> <cacheMem>256 MB</cacheMem> <memoryReplacementPolicy>lru</memoryReplacementPolicy> <cacheReplacementPolicy>lru</cacheReplacementPolicy> <maxOpenDiskFds>0</maxOpenDiskFds> <minimumObjectSize>0 KB</minimumObjectSize> <maximumObjectSize>4096 KB</maximumObjectSize> <cacheSwapLow>90</cacheSwapLow> <cacheSwapHigh>95</cacheSwapHigh> </squidconf> </startup> <candidate lock="" modified="true"/> </datastores>

In cache controller or CMO, we use the OpenDayLite (ODL) SDN controller working as a NETCONF client to manage the configuration of cache nodes remotely. It provides a northbound interface (NBI), namely the Restconf API, towards the CMO, to receive their configuration requirements. It needs also the southbound


interfaces (SBI) for the cache nodes (including caching and prefetching functionalities) to pre-‐verify the commands given by the NBI and to communicate with the NETCONF server. In order to enable communication between the MoBcache and ODL controller, the client-‐side API with Yang model, e.g. [2], on ODL controller is developed, and the connection between NETCONF client and NETCONF server is set up.

The client-‐side API allows the ODL controller to recognize the configurations of the different modules (such as the squid-‐config module, the prefetch-‐config, etc.) running on a MoBcache. The Yang project needs to be created to generate JAVA APIs from Yang model files (for example, squid-‐config.yang for the module squid-‐config). Then the JAR build package (for example, model-‐squid-‐config-‐1.1-‐SNAPSHOT.jar) is created.

Furthermore, an ODL NETCONF client should be configured with the address and login credentials for each target NETCONF Sever running on MoBcache or any cache node. The target Server configuration includes the target server's IP address, port, connection type (TCP or SSH), and username/password. The ODL NETCONF client configuration also includes a reference to MD-‐SAL, and the configuration of NETCONF client's thread group for opening and maintaining sockets, and its event executor for sourcing events into MD-‐SAL. Defaults values for global configuration, defined in this document, should be sufficient for most cases. In the case of building from source, a file to hold the NETCONF client configuration in the directory is created as follows:

“controller/opendaylight/distribution/opendaylight/target/distribution.opendaylight-‐osgipackage/opendaylight/configuration/initial/”.

This file holds the NETCONF server configuration that the client will attempt to connect to.

Once the ODL NETCONF client and the NETCONF server on the MoBcache have been connected, we can use the RESTCONF interface provided by the ODL SDN controller to remotely configure the CP and PFP. RESTCONF is a REST like protocol running over HTTP for accessing data defined in YANG using data stores defined in NETCONF. It is an IETF draft that describes how to map a YANG specification to a RESTful interface. The RESTCONF API is not intended to replace NETCONF, but rather provide an additional simplified interface that follows REST-‐like principles, and is compatible with a resource-‐oriented device abstraction. Since the RESTCONF interface is listening on port 8080, we can issue the following command to change the data store of different modules on the NCS.

$ curl -d @prefetch-config.xml -H 'Content-Type: application/xml' 'http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/libnetconf/yang-ext:mount/'

Where the file “prefetch-‐config.xml” contains the configuration of the prefetch module. For example, if we want to add the following entry in the prefetch module Datastore to let it prefetch immediately the video “big_buck_bunny.mp4” from “video.js-‐zencoder.com”, we should put the following content in the file.

<prefetcher xmlns="urn:bcom:com:prefetcher">

<content>

<id>11</id>

<time>0</time>

<hostName>video-js.zencoder.com</hostName>

<path>/big_buck_bunny.mp4</path>


</content>

</prefetcher>

2.2.3. 100G OFDM-‐PON

The OLT of the 100G OFDM-‐PON is being implemented on a Virtex7-‐based FPGA platform. A block diagram of the key elements is depicted below in Figure 2-‐5. The control flow is handled by a PowerPC chip placed on the development board, while the controller has a Gigabit Ethernet interface (RJ45), which is used to interface with the CMO. The internal interface with the FPGA is realized by GPIO lines.

Figure 2-‐5: 100G OFDM-‐PON control and data flow

The interface to the CMO is handled via a Python script (see Figure 2-‐6, below), which is listening on a predefined port (15015) for a specific UDP packet.

Figure 2-‐6: Software integration

The generic packet structure to exchange information between CMO and OFDM-‐PON has been defined and is given in Figure 2-‐7.

Figure 2-‐7: Control packet format

The packet contains five different fields, namely the CMO_id, Type, Data_length, CMD, and Data. Table 2-‐1 gives their allowed values, their length, and describes the respective fields.

Dev. board

Virtex 7XC7VX690T

Power PC

GPIO

MicramDAC II

24GTH OLT output

GbE

10GE(SFP+)

control flow

data flow

Power PCLinuxPythonAppsocket

CMO

UDP header CMO Id Type Data Length CMD Data


Table 2-‐1: Control packet values

Field values length (bytes) Comment

CMO_id 0x00…0xFF 2 Id of CMO

Type 0x01 query request, 0x02 set request, 0x03 reply

2

Data_length 0x0000…0xFFFF 4 Length field

CMD 0x00…0xFF 2 Command

Data 0…1024 actual data

The following combinations of type and command are currently defined:

• Bitloading query: 0x10 • Power control query: 0x11 • ONU mapping query: 0x20

2.2.4. Point-‐to-‐Point wireless backhaul

Current backhaul architecture

A typical architecture for a wireless backhaul system is shown below in Figure 2-‐8. It interfaces with an access base station (e.g. eNodeB) and transmits traffic through a processing chain consisting of a network processor performing the upper MAC layer, a baseband processor executing the PHY layer processing, DAC/ADC, RF transceiver, and finally an antenna. For the networking part there is typically a network processor, which consists of a packet and a control processor. The former handles packets at line rates, whereas the latter is responsible for initializing the hardware, e.g. setup filters to handle specific packets from traffic flow, setup VLANs, QoS, and microwave attributes. It handles control protocols such as Spanning Tree Protocol (STP) and management requests for configuration and monitoring.

The network processor has three 1 GigE interfaces for data traffic and one 100 Mbit/s Ethernet for out-‐of-‐band management. The management can be performed, either in-‐band or out-‐of-‐band, using CLI, SNMP or an HTTP/HTTPS web application.


Figure 2-‐8: Backhaul System View

SDN backhaul architecture

In the context of SDN, OpenFlow and NETCONF are currently the two prevailing protocols for control and management respectively. In this deliverable, we focus on the control plane and flow-‐related topics in order to support multi-‐tenancy. As previously described in the CHARISMA deliverable D3.2, backhaul equipment has to conform to specific requirements of the MEF CE 2.0 (Carrier Ethernet) specifications. In order to achieve this, there is a need for two components: an SDN controller with a specific application that will provide the MEF functionality; and an OpenFlow-‐enabled backhaul with the capability to interpret the rules sent by the SDN controller. The first step of the development is based on OpenFlow-‐enabled virtual switches, which are open source and already support all the OpenFlow specifications that are needed in order to “understand” OpenFlow rules. The next step is the implementation of the necessary adaptations to the physical equipment, so that it becomes SDN-‐ready.

Our architectural decision for enabling OpenFlow on the switching component of the backhaul hardware, is to use an adaptation layer (Data Path Abstraction) on top of the Network Processor and an OpenFlow agent, such as Indigo [3]. The adaptation layer is a device-‐specific module, while the Indigo agent is device-‐independent. The architecture is shown in Figure 2-‐9.

Figure 2-‐9: SDN adaptation on backhaul equipment

OpenFlow agent


The device-‐independent Indigo agent enables support for OpenFlow, e.g. establishes connections and handles OpenFlow messaging on physical and hypervisor switches [4]. Its most important sub-‐modules are:

• The OpenFlow Socket Manager: Provides the functionality for managing sockets. It provides a generic socket registration process as well as timer event processing to allow these functions to be integrated in single-‐threaded environments.

• The OpenFlow Connection Manager: Provides the functionality for managing OpenFlow connections such as addition and removal of connection instances, tracking the connection state (handshakes, keep-‐alives) and applying rate limiting policy for asynchronous messages.

• The OpenFlow State Manager: Provides the functionality for representing the OpenFlow state of the switch in a device-‐independent way. This allows the decoupling of database-‐like queries on the OpenFlow flow table from the manipulation of the forwarding state, which is device specific.

Adaptation Layer

The adaptation layer abstracts the device specific functionality by conveying the OpenFlow rules in a proprietary language, which will be understood by the packet processor.

The device-‐specific modules (Data Path Abstraction layer) are:

• Forwarding Engine: This module exposes the interfaces that allow the manipulation of the device’s forwarding engine as represented by the OpenFlow protocol;

• Port manager: This module exposes the interfaces that allow the retrieval and manipulation of the device’s data plane entries.

Evolution towards a full SDN architecture, means that the OpenFlow agent and the data path abstraction will eventually reside in the control processor. The evolution of the SW architecture for the transition to SDN is depicted in Figure 2-‐10.


Figure 2-‐10: Network Processor adaptation for the transition to SDN

OpenFlow Interfaces

Concerning the interface between the OpenFlow-‐enabled backhaul and the SDN controller, there are two interconnection options: in-‐band, in which control and data traffic use the same physical medium; and out-‐of-‐band, in which there are separate physical mediums for the data and control planes.

In-‐band control is more suitable for wireless equipment as it results in less cabling, whereas out-‐of-‐band is the norm in environments like data centres for control between the SDN controller and the physical or virtual switches. In-‐band control with OpenFlow is more demanding, as the OpenFlow-‐enabled equipment, deprived of its forwarding logic, needs an adequate preinstalled configuration in order to be able to setup the connection to the SDN controller by itself. This involves resolving all the networking issues, such as handling ARP requests and replies that may occur in the process. One possible solution for its configuration is the infrastructure manager to install “hidden flows” that are not related to and not visible to OpenFlow, that have a higher priority than any OpenFlow rules, and therefore do not interfere with them.

On the other hand, given that OpenFlow support provides a readily available out-‐of-‐band control capability to the equipment, the envisaged architecture is based on out-‐of-‐band control, as this will allow us to concentrate our resources on the SDN aspects of the wireless backhaul.


2.2.5. Ericsson HDS 8000 based data centre infrastructure

Ericsson HDS 8000 is a new generation of hyperscale datacentre systems that uses Intel® Rack Scale Architecture for a disaggregated hardware approach to dramatically improve efficiency, utilization, automation and total cost of ownership.

HDS 8000 uses optical interconnects. Combining a disaggregated hardware architecture with optical interconnects removes the traditional distance and capacity limitations of electrical connections. This enables a more efficient pooling of resources, which has a positive impact on utilization and energy consumption.

Ericsson Secure Cloud Storage is a pre-‐integrated portfolio of data services complementing the policy-‐driven hybrid Platform-‐as-‐a-‐Service (PaaS) layer, streamlining web scale development and deployment of new data rich applications. The data services portfolio adds leading cloud software databases that span traditional relational databases to web scale, big data NoSQL type databases. Ericsson is partnering with Cleversafe in this area, a leading provider of hyperscale object storage. Ericsson’s first announced product is secure object storage capable of controlling access with policy and guaranteeing confidentiality and integrity of data.

2.2.5.1. Managing Ericsson HDS 8000 The primary platform for managing Ericsson Hyperscale Datacentre System 8000 is Ericsson Command Centre. It configures and manages compute resources, storage capacity, and network connectivity of both Ericsson Hyperscale Datacentre System 8000 and systems from other vendors. It also manages the power systems, firmware, and related functions of Ericsson Hyperscale Datacentre System 8000.

Datacentre operators can also use Ericsson Command Centre to partition the infrastructure of their datacentre into vPODs.

A vPOD (virtual Performance Optimized Datacentre) is a virtual aggregation of compute, storage, and network resources that provide a complete and isolated Infrastructure as a Service (IaaS) platform to datacentre customers. Each vPOD customer can focus on using the capabilities of the IaaS platform while leaving the details of managing the hardware to the datacentre operator.

The capabilities of Ericsson Command Centre include:

• Ability to be deployed on a single Compute Sled Unit for non-‐redundant operation or on two or more compute sleds for redundancy and to make available additional hardware resources

• One configurable dashboard that provides a one-‐stop view of the current state of the datacentre

• Authentication and authorization based on a central user database, such as Microsoft Active Directory, ensuring that only authorized users can access information about systems in the datacentre

• Resource and asset information from across the entire datacentre

• Status information and statistics about all systems in the datacentre

• Active alarm state with alarm notifications and subscription capabilities

• SNMP-‐based notifications

• Deployment support, including PXE boot management, firmware management, and so on


• Hardware monitoring and health management.

2.2.5.2. Managing Ericsson HDS system via API Other management platforms can use the RESTful API in the Ericsson Command Centre to manage the Ericsson Hyperscale Datacentre System 8000. The API enables other management platforms to:

• Configure and operate certain aspects of the Ericsson Hyperscale Datacentre System 8000

• Read information that the Ericsson Command Centre has collected about other systems in the datacentre.

2.2.5.3. Managing datacentre hardware The Ericsson Command Centre manages hardware by working with information about:

• Hardware inventory

• System status

• Power

• System configuration

• Search

2.2.5.3.1. Hardware inventory The Ericsson Command Centre gathers inventory data about systems in the datacentre and their individual components, such as interface cards, memory modules, and more. It can gather inventory data about Ericsson hyperscale systems or systems from other vendors. The type of inventory data depends on the method used to gather it.

2.2.5.3.2. System status Status information can be about hardware components—such as storage devices and memory—or about software attributes such as the operating system version and system load.

2.2.5.3.3. Power Using the Ericsson Command Centre one can power on, force a power-‐off, and force the restart of the Ericsson Hyperscale Datacentre System 8000. One can apply those power functions individually or to a group of hyperscale systems.

2.2.5.4. Sources • http://www.ericsson.com/mwc2015/launches/hyperscale-‐datacentre-‐system-‐ericsson-‐hds-‐8000

• http://www.ericsson.com/hyperscale/cloud-‐infrastructure/hyperscale-‐datacentre-‐system/managing-‐hyperscale-‐system/management-‐interface

• http://www.ericsson.com/hyperscale/cloud-‐infrastructure/hyperscale-‐datacentre-‐system/managing-‐hyperscale-‐system/hardware-‐management

2.2.6. P2P Wireless Link

For the P2P Wireless link system installed in the final field trial we propose to use the ubnt P2P airMAX device, which supports the 802.11 standard. In particular, it features data rates up to 1 Gb/s in the 5-‐GHz


band with a range up to 10km. The system management is fully controlled via software using the following interfaces:

• 1 x 10/100/1000Mbps WAN Port

• airMax link

The link management can be done using the WAN port, in-‐band management, using or SNMP or CLI (Command Line Interface), and the HTTP-‐based configuration web is also available. The P2P wireless link supports the following management features:

• Local management by CLI and HTTP or HTTPS web browser

• Remote management using Telnet or SSH and SNMPv2

• In-‐band management

• Local and external alarm storage and Syslog

• Automated backup, restore, and rollback.


3. High Capacity PHY links

3.1. 100G OFDM-‐PON

3.1.1. OLT design

For the OLT architecture there have been no major changes since the release of the earlier deliverable D2.1 “CHARISMA Initial Architecture Design and Interfaces”. Nevertheless, the architecture is repeated here (Figure 3-‐1) and briefly described in order to give the context for further discussion.

Figure 3-‐1: OLT-‐Tx architecture of 100G OFDM-‐PON

The OLT node is split into an OFDMA MAC and PHY entity as shown above in Figure 3-‐1 and described as follows. Incoming Ethernet frames are first processed by the Ethernet sublayer functions PCS/PMA and MAC, while invalid frames are dropped afterwards. Since the OLT has knowledge about the subcarriers assigned to each ONU at each point in time, it analyses the destination MAC address and passes the frame to the respective ONU, i.e. subcarrier line (FEC encoder & Buffer). All subcarriers are multiplexed and passed together with bit-‐loading information into the PHY entity. The bit-‐loading is performed by mapping data symbols with variable numbers of bits, according to the assigned modulation format, onto each subcarrier. Training symbols are added and the power for each subcarrier is set. After passing all subcarrier signals into an inverse fast Fourier transform (IFFT), the cyclic prefix (CP) is added. The OFDMA signal is now passed to the DDS output stage.

3.1.2. Generic FFT core

A new FFT IP core has been developed in order to choose the FFT size depending on the different requirements of OLT and ONU. Because of the high throughput of OLT and ONU, only a parallel FFT architecture has been considered. A sample rate of ~16 GSa/s at 6 bit is expected for the OLT. Since modern FPGAs allow clock frequencies of the order 250 MHz, for a non-‐trivial design (i.e. as appropriate for the 100G OFDM-‐PON) a degree of parallelisation of at least 64 is required. This means that 64 samples (6 bit) have to be processed in parallel to deliver such large throughputs.

Output (DDS)OFDM-‐MAC (OLT-‐Tx) OFDM-‐PHY (OLT-‐Tx)

OFDM-‐MAC

Interface

MapperM-‐QAM

TSinsert

Powerloading IFFT CP

insert

Bitloadingextraction TS

PCS/PMA MAC ETH

checkCarrierswitch

FEC

FEC

FEC

Buffer

Bit-‐loading

Carrierscheduler

Buffer

Buffer100G ETH

I/Qmixer

LO

DAC

a) b)


The parallel architecture can be derived directly from the method described by Cooley and Tukey [5]. This algorithm describes a fast method to calculate the discrete Fourier transform (DFT) for point sizes 2N, hence the name Fast Fourier Transform (FFT). A block diagram of a simple 8-‐point FFT is depicted in Figure 3-‐2.

Figure 3-‐2: Parallel architecture for 8-‐point FFT with radix 2 butterfly

Every symbol represents a unit cell, the so-‐called radix 2 butterfly. Each cell performs a complex multiplication and two complex additions, where each complex multiplication consists of three real-‐valued multiplications and five real-‐valued additions. The parallel architecture for a 2N-‐point FFT consists of N stages and 2N/2 cells per stage, which results in 3N⋅2N/2 real multiplications and 9N⋅2N/2 real additions overall.

Elementary cells with a larger radix can be chosen in order to save some resources. While a FFT using radix 2 cells can create FFT-‐sizes of 2N (e.g. …32, 64, 128, 256, …), a radix 4 elementary cell reduces the possible FFT sizes to 4N (e.g. 16, 64, 256, 1024, …). Another option is to use the so-‐called split-‐radix, a combination of elementary cells with different radixes. Both architectural options are depicted in Figure 3-‐3 and Figure 3-‐4 respectively.

Figure 3-‐3: 16-‐point FFT using radix 4 butterflies

Figure 3-‐4: 16-‐point FFT using split radix (radix 2 and 4) butterflies

A comparison of the three architectural options discussed for a parallel is compiled in Table 3-‐1.

Table 3-‐1: Number of operations for different FFT radix and size

FFT-‐Size Real multiplications Real additions 2N Radix-‐2 Radix-‐4 Split-‐Radix Radix-‐2 Radix-‐4 Split-‐Radix

16 24 20 20 288 248 148


32 88 -‐ 68 720 -‐ 388

64 264 208 196 1,728 1,488 964

256 1,800 1,392 1,284 5,896 5,488 5,380

1024 10,248 7,856 7,172 30,728 28,336 27,652

As a general observation, it can be seen that radix-‐2 requires most resources – as expected. The radix-‐4 implementation requires fewer resources for FFT sizes of 4N as compared to radix 2. However, the best performance is achieved using the split radix algorithm, but which has an increased complexity, due to the fact that radixes of different size are mixed together [6].

Therefore our goal was to start with a parallel FFT implementation using radix 2 elementary cells, because it allows FFT sizes of 2N and uses the simplest elementary cells. The architecture allows arbitrary degree of parallelization M, and arbitrary size N. The number of input and output ports for a parallel FFT is given by the degree of parallelization M, and is depicted in Figure 3-‐5. The FFT core is required to process M input samples at every clock cycle.

Figure 3-‐5: Parallel FFT input and output.

For the OLT we have planned to use a 1024-‐point FFT and a throughput of 16 GSa/s, which requires 64 inputs and outputs for a targeted clock rate of 250 MHz. The planned FFT size is smaller for the ONU, here a 64-‐points and a throughput of 1 GSa/s is foreseen. This requires a degree of parallelization of four. The design is vendor independent, although it will be tested and implemented on Xilinx platforms only.

The building blocks for the FFT IP core, which has been designed for CHARISMA is depicted in Figure 3-‐6. It contains of two main blocks, namely: the permutation block and the butterfly block. The VHDL descriptions of both blocks are auto-‐generated, and its inner structure is determined by M, N, and the respective stage.

FFTN-‐

points

M samplesclock

12

M

M samplesclock

M ≤ N


Figure 3-‐6: Building blocks of parallel FFT

There exist two implementations for the parallel FFT, based on radix 2 and radix 4 respectively. It must be noted that the degree of parallelization must be a power of two or four, depending on the radix being employed, e.g. the radix 4 implementation limits the degree of parallelization to 4, 16, 64, etc.

For an example configuration (OLT FFT) the actual resources are compiled in Table 3-‐2, with the following parameters considered:

• 1024 point FFT • 64 complex inputs (parallelisation) • 9-‐bit input width • 19-‐bit output width • 11-‐bit twiddle factor width

Table 3-‐2: Required resources for radix 2 and radix 4 implementation of a 1024-‐point FFT with 64 parallelization

FPGA resources

Radix-‐2 Radix-‐4 Competitor

Registers 83,294 42,381 94,462

LUT 48,217 32,418 55,073

Block RAM 0 60 286

DSP 648 496 624

Latency (cycles)

n.a. 89 134

P-‐Block B-‐Block

P…permutationB…butterfly

12

M MP-‐Block B-‐Block

MM

1. stage 2. stage

P-‐Block B-‐BlockM

Log2(N). stage

7

01234567

0123456

P-‐block

AutogeneratedInner structuredepends onsize and stage

7

01234567

0123456

B-‐block+-‐

+-‐

+-‐

+-‐

AutogeneratedTwiddle factorsprecalculated


Clock (MHz)

>2501) 2701), 3702)

2501)

1) Virtex 6 (xcvhx565t-‐2), 2) Virtex 7

It can be observed the current radix 4 requires least resources, while providing a lower latency compared to a competitor commercial FFT solution.

3.1.3. ONU design and measurements

The ONU entity as shown in Figure 3-‐7 expects the down-‐converted I and Q components of the respective parts of the OFDM spectrum as input.

Figure 3-‐7: ONU-‐Rx architecture of 100G OFDM-‐PON

After frame synchronization and CP removal, the received signal is transformed back into the frequency domain using an FFT with a smaller point size as compared to the OLT. The DSP blocks for channel estimation and correction, I/Q imbalance and fine correction are passed next. All processed subcarriers are forwarded to the MAC entity, where the FEC decoder corrects errors within its capability. The frames from all subcarriers destined for this ONU are multiplexed, checked and then passed to the Ethernet processing blocks MAC, PCS/PMA and forwarded to the 10G Ethernet interface.

Figure 3-‐8: Experimental setups to evaluate ONU DSP for 100G OFDM-‐PON

The setup shown in Figure 3-‐8 was used to evaluate the self-‐interference tolerance of the frequency offset estimation. The transmitter applies 512 subcarriers accompanied by 32 CP samples to the shown band. Carrier Frequency Offset (CFO) and Sampling Clock Frequency Offset (SFO) estimation evaluates phase differences between OFDM symbols.

OFDM-‐PHY (ONU-‐Rx) OFDM-‐MAC (ONU-‐Rx)

PCS/PMA

ETHMAC

ETHcheckFEC MUX

queue

M subcarrier

FrameSYNC

CPremoval

FFTChannelest. +corr.

I/Qest. + corr.

Fine corr.

I

Q 10G ETHa) b)

OLT ONU

AWG LP12GHz I/Q

Osc.(CFO)

Scope

OLTDSP

Freq.control

ONUDSP

LP

LP250MHz 1GSa/s24GSa/s

Ref. Ref. Osc.(SFO)

6….11.5GHz

10MHz±1kHz

Ref. In

OFD

M data

OFD

M data

3.75 11.75 (GHz)


Figure 3-‐9: Initial estimation of CFO and SFO for ONU DSP

Figure 3-‐9 (a, d) shows typical results on initial estimation working on a repeated, known OFDM symbol. By repeating the same symbol, ISI and ICI nearly remain constant. Differences between successive symbols cancel most self-‐interferences, and averaging reduces noise dependence. In this way, CFO is generally estimated with a precision of less than 0.02 ppm when evaluating a 500 MHz sub-‐band using 640 training symbols. This corresponds to a CFO of 190 Hz in all sub-‐bands. SFO is estimated with a precision of about 1 ppm. Simulations have shown that both residual values independently allow mean SNRs of about 26 dB. A continuous process allows fine correction and tracking. 16 optimized training symbols precede the payload for estimate I/Q-‐imbalance and channel response. Since the set of symbols remains the same, differential frame-‐to-‐frame evaluation cancels self-‐interferences. Channel response should be constant during the frame time for a time-‐invariant optical fibre channel. Different values are assumed to be a result of error in the last CFO and SFO estimation values. Since every minor change in channel response is seen as a result of frequency offset change, a damping factor k is applied to the detected errors, minimizing error variance.

Figure 3-‐10: Results for tracking of CFO and SFO at ONU

a)a)d)

b)

c)

e)f)


Figure 3-‐10 shows examples for CFO (b, c) and SFO (e, f) estimation corrections (k = 0.2). Residual CFO values of about 0.05 ppm (47.5 Hz) and SFO values of about 0.2 ppm are achieved.

3.2. 10G Wireless Links

3.2.1. Omnidirectional 13dBi Gain Bi-‐ Conical Horn Antenna for IEEE802.11ad Applications

Small-‐cell mesh wireless systems capable of high data rates seem likely to play a key role in the new proposed IEEE802.11ad based 5G networks, with CHARISMA seeking to exploit mmW technologies both for fronthaul and edge-‐hauling, as well as for device-‐to-‐device (D2D) connectivities. Key to these architectures will be antennas that can both support very wide bandwidths and at the same time deliver high gain performance whilst maintaining omnidirectional characteristics. Such attributes are often considered to be mutually exclusive or require steerable array techniques to accomplish. The design described here satisfies these requirements in a single device gain with 13dBi gain over a frequency range between 57GHz and 64GHz.

With outline planning of the next generation 5G wireless networks now well underway it seems likely that small-‐cell use based on the mmW IEEE802.11ad standard will feature heavily in proposed system architectures. The necessity to accommodate rapidly increasing demands for high data rate communications requires the use of sophisticated software management techniques and very high bandwidth wireless V band (approximately 40…75 GHz) deployments. Such architectures feature intelligent remote antenna node structures for backhaul implementations and shorter range meshed cells to provide the high throughput D2D and device-‐to-‐infrastructure (D2I) coverage that is predicted to be necessary. This places extreme demands on antenna structures with system designers asking for antennas that are capable of supporting wide bandwidths whilst possessing high gain and multidirectional properties. Currently, these demands are being addressed by the use of large-‐scale MIMO arrays and beam steerable, phased array type antenna arrangements. Whilst these methods are very effective they require the use of complicated electronics and chip level fabrication techniques that can support the control algorithms necessary to ensure optimal system performance. With these requirements in mind, our aim has been to develop an inherently multidirectional antenna with adequate gain and bandwidth characteristics such that beam steering techniques are no longer necessary. Drawing on experience developed with stacked slot antenna arrays, such a configuration was shown to be possible by shaping the radiation pattern of the antenna into a disk like format. A difficulty existed here in that due to the frequency variable phase relationship between each of the fixed array elements, a dispersive effect became apparent with wide bandwidth signals. This manifested itself in a frequency dependent “squint” that caused some difficulty in antenna alignment when accommodating signals that require the use of the complete 7-‐GHz spectral bandwidth allocation of 802.11ad. To address this issue a design that incorporates the best attributes associated with bi-‐conical and horn antenna types has been investigated. These designs are individually well known for possessing high bandwidth, omnidirectional properties (bi-‐conical antenna) and high gain (horn antenna) respectively. Using a circular geometry, a monopole feed into a waveguide and a flared E-‐plane horn launch section, a device that incorporates the desirable features of both designs has resulted.

3.2.2. Antenna Design Philosophy

Unlike conventional bi-‐conical antenna designs where stimulation occurs by exciting two conical surfaces in a dipole-‐like configuration, this design is based on a horn antenna architecture. Here, the structure consists


of two conductive cone-‐like structures mounted in a reciprocal configuration, as shown in Figure 3-‐11. At the centre of each cone is a flat section that forms a half-‐wavelength waveguide section, enabling a quarter-‐wavelength launch in all directions. Positioned centrally in the lower of these flat sections is a quarter-‐wavelength monopole constructed around a section of Huber and Suhner SR 86 semi-‐rigid coaxial cable. A 1.25-‐mm section of the 0.51-‐mm diameter central conductor was exposed to form the monopole radiator. With an outer screen diameter of 2.18 mm this conveniently lends itself to incorporation into a quarterwavelength waveguide launch structure utilising the opposite face of the top conical structure to complete the assembly. In this way, a horn-‐like structure is achieved with a circular geometry. The Huber and Suhner SR 86 semi rigid coaxial cable was interfaced with an MMPX connector to provide a low cost reliable mmW pluggable connection. Tuning of the S11 related VSWR was accomplished with the addition of two basic aperture-‐matching rings added to the outer edges of the conical sections. Whilst not an ideal smooth transition this approximation also conveniently forms appropriate anchor points for the Perspex upper and lower section separation support pillars situated on the antenna periphery.

Figure 3-‐11: Model graphic of the complete antenna structure

Modelling devices that operate at mm wavelengths always requires attention to detail, so an emphasis was placed on producing a practical realisable structure from the outset. To this end the model was made as complete as possible with all mounting and support structures in place. As the S11 return loss of the MMPX connector assembly is quoted at -‐16dB at the frequencies of interest this was not included in the model. Initial structure dimensions were based on standard WR 15 waveguide fed rectangular horn dimensions of 100 mm in length, with a flare angle of 12.7°, with a feed cavity height of 1.88 mm, and a “mouth” dimension of 21.94 mm. The model was then used to produce a trade-‐off between device size and performance. It was found that the structure behaved similarly to a standard horn with horn length and flare affecting the gain, return loss and associated VSWR of the antenna. Final dimensions were arrived at empirically, as being: cone outer radius of 75 mm, with a 1.25-‐mm radius flat centre section, and a flare between upper and lower elements of 15.5°. This gave a final dimension of 21.88 mm at the “mouth” of the bi-‐conical horn antenna. Consistent performance across the band is essential if signal quality integrity is to be maintained, this behaviour being particularly important if high bandwidth, and high data rate signals are to be accommodated. Amplitude variations here can lead to incongruities in signal-‐to-‐noise ratio and filtering effects that can impact on received signal error rates.

As can be seen in Figure 3-‐12 the return loss of the shorter device varies by less than 0.3 dB across the range, indicating that received signal quality would be maintained across the IEEE802.11ad band.


Figure 3-‐12: S11 plot of 75 mm antenna over IEEE802.11ad band

Figure 3-‐13 below confirms this, and illustrates that the antenna possesses a variation in the VSWR of less than 0.2 across the required frequency range. The gain of the finalised 75mm device exhibits an improvement of between 0.4 dB to 2.2 dB over that of the 100-‐mm radius antenna.

Figure 3-‐13: VSWR plot of 75 mm antenna over IEEE802.11ad band

As mentioned earlier it was found that the addition of a 5-‐mm x 10-‐mm aperture matching ring of conductive material to the outside, planar face, of the conical structures improves S11 and VSWR, which results in improved antenna gain. In Figure 3-‐14, it can be seen that, as would be expected from the results already seen, t the predicted antenna impedance is centred uniformly around the 50Ω point of the Smith chart model graphic. Details of the impedance values at the four frequency points chosen are also given, indicating acceptable impedance values of between 38.1Ω at the highest frequency to 51.7Ω at the lowest frequency.


Figure 3-‐14: Impedance plot of 75 mm antenna over IEEE802.11ad band

Attention is now turned to the antenna feed. As mentioned previously, this device differs from the conventional bi-‐conical antenna configuration, in that it is treated as a horn-‐type radiator. As such, the feed mechanism is that of a monopole operating within a quarter-‐wavelength section of waveguide. In this case, as the monopole radiates in all directions, it is located at the centre of a 2.5-‐mm flat section, this permitting the 1.25-‐mm quarter-‐wavelength requirement in all directions. So as to illustrate the efficacy of this approach, surface current plots showing both propagation along the monopole and the coupled surface current activity along the surfaces of the horn structure have been taken.

Figure 3-‐15: Surface current propagation on monopole and horn surface

Figure 3-‐15 shows such a surface current plot, indicating launch from the monopole feed and propagation from the waveguide section along the horn. Shown here is the top face in the top section for clarity. This behaviour is also reciprocated on the bottom face of the horn structure.

With these parameters established, the predicted radiation characteristics and device gain were then examined as shown in Figure 3-‐16.


Figure 3-‐16: Predicted radiation patterns and gain performance

As this antenna is intended for deployment in a small cell wideband mesh wireless environment with no adaptive control element, it was desirable that as far as possible the radiation characteristics are stable across the IEEE802.11.ad frequency range. For this purpose, as can be seen above, the predicted radiation pattern and gain plots are shown on two planes and at the four selected frequencies. As can be seen in the 57-‐GHz plot, the 5-‐mm thick support pillars are beginning to cause “shadowing” in the radiation pattern that result in serrations and areas of low gain. This shadowing predictably worsens, the closer the support pillars are to the centre of radiation, and so defines the structure minimum dimension to that of a 75-‐mm radius. Below this radius the radiation patterns become unacceptably serrated at all frequencies, although at a radius of 50 mm the predicted gain rises to 14.8 dBi at 61 GHz as a result. Further modelling using several different materials including PTFE (Ɛr = 2.1) and Delrin (Ɛr = 3.7) for these support pillars reveals that Perspex (Ɛr = 3.4) is the least disruptive material. Intuitively, reducing the thickness of these pillars to 3

mm, all but eliminates the serrations in the radiation patterns, but is thought to be impractical. In Figure 3-‐16 it can be seen that at the frequencies above 57 GHz an acceptably even discoidal radiation pattern results for the 75-‐mm configuration. As shown in the coloured scales alongside each plot, the corresponding antenna gains vary from 12.8 dBi to 13.8 dBi in all directions across the frequency range. Importantly it can also be seen that at no time is a frequency dependent squint evident, and that the radiation is pattern is stable in the horizontal axis across the required frequency range. Predicted horizontal 3-‐dB beam angles vary slightly with a beam divergence angle variation of 1.7°.

Unsurprisingly the antenna predictions suggest strong linear polarisation properties. Polarisation isolation predictions of 37.8 dB at 64 GHz rising to 40 dB at 57 GHz have been attained. Such attributes give rise to the possibility of frequency reuse or full duplex / simultaneous transmission deployment.

3.2.3. Discussion and Further Work

With the inevitable rise in demand for high capacity 5G wireless data transmission, mesh cell architectures seem likely to dominate future network planning. Often featuring intelligent antenna deployments to direct traffic, these meshed networks will place very high demands on associated antenna designs. These requirements include a high bandwidth capability, an ability to operate in an omnidirectional mode and possess a high gain. To accommodate this, current antenna systems rely heavily on MIMO and phased-‐array techniques. The device proposed here uses an alternative approach with elements draw from bi-‐


conical and horn antenna designs that inherently address these issues without the need for complex electronics and algorithms. This “hybrid” approach has resulted in a design that exhibits a gain of 13 dBi over 360° by developing a disc like radiation pattern without a frequency dependent dispersive squint. Empirical device refinement produced a predicted S11 return loss better than -‐15 dB across the required range with an associated VSWR being lower than 1.4. Input impedance of the antenna was also shown to provide an adequate match between 57 GHz and 64 GHz. Future work will initially concentrate on the production of a prototype to experimentally validate the modelled results. Further to this is the need to investigate and reduce the shadowing effect of the support pillars especially at 57 GHz, along with the possibility of a further reduction in device radius. Associated with this will be an investigation into the use of metallised plastic antenna cones.

Every year the number of wireless enabled devices and the amount of data consumed continues to grow at an exponential rate. As these devices create and consume growing amounts of data, the wireless communications infrastructure must evolve to support the demand. Spectral efficiency gains in the existing 4G-‐based network are not well-‐placed to deliver the multi-‐Gbps 5G capacity anticipated. The world’s wireless standardization bodies are responding to the next generation 5G wireless challenge. For example, the ITU proposed the 24.25–27.5, 31.8–33.4, 37-‐40.5, 40.5–42.5, 45.5–50.2, 50.4–52.6, 66–76 and 81–86 GHz bands. Echoing the ITU proposal, the Federal Communications Commission (FCC) proposed new flexible service rules among the 28 GHz, 37 GHz, and 39 GHz bands.

The 70-‐90 GHz E-‐band region has been recognised by both OFCOM and ETSI in Europe as a target for light-‐licensing; in common with several other countries. The 70-‐90 GHz region has significantly lower oxygen absorption as compared to 60 GHz (Figure 3-‐18), but experiences rain-‐fall effects as shown in Figure 3-‐17 below:

Figure 3-‐17: Rain fade effects at mmW frequencies


Figure 3-‐18: mm-‐wave bands highlighting absorption peaks and troughs

Thus overall, it can be seen that the E-‐band also offers interesting possibilities for exploitation for future 5G network architectures, both for D2D applications, as well as D2I and fixed infrastructure (e.g. fronthaul and edge-‐haul) connectivities.


4. Virtualised CPE

4.1. VNF Modeling for vCPE The modelling of a Virtual Network Function (VNF) depends on the underlying MANO implementation. As CHARISMA shall be using the TeNOR NFVO for its MANO chores, the modelling of a vCPE has to be done within the TeNOR NF framework. The rest of this sub-‐section provides an overview of design of the VNF components and the VNF lifecycle.

4.1.1. VNF Components

VNF Structure: Generally speaking, a VNF is an executable software program that implements the whole or part of some network functions, and it can be hosted on a virtualised platform. VNFs are located between computer machines (virtualised or not) and physical networking devices, and are transparent to the computer nodes. In other words, from the computer nodes' point of view, they consider themselves to be interacting directly with physical networking devices. Most custom hardware appliances (e.g., network processors, digital signal processors, firewalls, etc.) can be implemented as VNFs and moved where and when needed. In the scope of the CHARISMA project, a VNF is a virtual machine or a group of virtual machines that implement network functions in software. The VNF high-‐level architectural model is represented in Figure 4-‐1. A VNF is characterised by two attributes: the operational functionalities and the management behaviour. The operational part explicitly defines the network functions that are supported, while the management part is responsible for the VNF lifecycle (i.e. start, stop, pause, scaling, etc.). Starting from the operational part, a VNF application may support one or more application network interfaces for communicating with other VNFs in the application layer. Incoming and outgoing data traffic (after being processed by the VNF) are passed through the Virtual Network Interfaces (VNIs). On the other hand, two specific interfaces exist for management purposes: More specifically, the VNF management socket interacts with Virtualised Infrastructure Manager(s) -‐ VIM(s); and the second management interface communicates with the TeNOR orchestrator.


Figure 4-‐1 VNF high-‐level architecture model

VNF Composition: A VNF can be composed from the interconnection of more than one NF applications. In this case, each NF is called a component of the VNF and is referred as Network Function Component (NFC). A Network Function Component is actually implemented by a Virtual Machine (VM). The diagram in Figure 4-‐2 represents a VNF composed by two VNFCs (i.e. Service Chaining case), one of them exposing one network interface, while the other being internal to the VNF.

Figure 4-‐2 VNF example with two VNFC

Proper VNF Descriptors and VNFC Descriptors should be in place, that indicate operational and management behaviours, used in launching, initiating and terminating a VNF. For example, the VNF Descriptors pose the minimum VNF infrastructure resource requirements that a VNF instance needs. Moreover, VNF Descriptors (VNFDs) provide details about the instance topology and VNF instance lifecycle operations. In addition, the VNF provides the description of the group of VNFCs that it contains. The VNF and VNFC properties, contained in corresponding descriptors, will be exposed through the VNF Management socket. In TeNOR, all relevant information is expressed using a metadata language. Since metadata permits the autonomous operation of each VNF and VNFC, direct interaction between the TeNOR Orchestrator and the VNFCs located inside of VNFs has been considered. Service graph or forwarding graph: In another direction, the usage of metadata for VNF description permits service chaining and service insertion, and building E2E services by composition. The VNF Forwarding Graph visualises this interconnection of VNFs and the traffic flow between them. More


specifically, more than one VNF can be connected to provide a new service, and this connection can be visualised through a graph. The TeNOR Orchestrator can use the VNF descriptors to create this service graph or forwarding graph by interacting with the VNICs of the VNFs. An example of a Service Graph is presented in Figure 4-‐3.

Figure 4-‐3 Service graph example with 3 VNFs

VNFD: The VNFD is composed of the following main information elements groupings: • VNF identification data, including:

− Data to uniquely identify the VNF vendor/provider;

− Type and description of the VNF, which help to identify the Network Function that is implemented as a Virtual NF, and enable interoperability of VNFs manufactured by different VNF Providers;

− Version. • VNF specific data, including:

− Specific VNF configuration data;

− Connectivity requirements and inter-‐dependencies of VNFCs;

− VNF lifecycle workflow scripts;

− Deployment flavours, specifying how many instances of each VNFC type and version to be instantiated based on service KPIs;

− Deployment constraints. • VNFC data, including:

− Type and identification, uniquely identifying the VNFC type;

− Specific VNFC configuration data and scripts;

− Deployment constraints;

− Virtual container files/images references, including the possibility to define packages of: VNFC binaries plus operating system, empty operating system, and/or empty virtual container (i.e., unloaded operating system).

• Virtualized resource requirements, including: − Compute resources, e.g. virtual CPU and virtual RAM assigned to the virtual container;


− Storage resources, e.g. size of the virtual disk assigned to the virtual container. Compute resources, e.g. virtual CPU and virtual RAM assigned to the virtual container;

− Storage resources, e.g. size of the virtual disk assigned to the virtual container; − Network resources, e.g. number and type of virtual NICs that are assigned.

4.2. Specifications & test set-‐up

4.2.1. vCPE Deployments and Specifications

Cloud Centric (Major functions run in cloud data centre)

Location Role Edge Cloud

Management, operations and troubleshooting

Basic probes and connectivity tests, network monitoring Configuration management, centralized monitoring and logging, provisioning, performance and fault management

CPE functions L2 forwarding only, overlay termination (IPsec VPN or other), Ethernet and wireless access

Routing, FW, NAT, network access control (NAC), security services (IPS, AV, proxy etc.), session border controllers (SBCs), additional business services

CPE-‐Centric Approach (Major functions on virtual infrastructure at branch/remote locations)

Location Role Edge Data Centre (provides policy and device configuration and centralized management)

Management, operations and troubleshooting

Basic probes and connectivity tests, network + virtual infrastructure monitoring and fault management

Configuration management, centralized monitoring and logging, provisioning, performance and fault management and SW distribution

CPE functions Ethernet and wireless access, overlay termination (IPsec VPN or other), routing, FW, NAT, NAC, security services (IPS, AV etc.), VPN, WAN-‐Opt, multi-‐link bonding, load-‐balancing, caching, additional business services

Additional enterprise services that are compute-‐intensive

Note: For enterprise deployments, the centralized functions in the data centre might be owned, hosted and operated by the business, or outsourced to either a service provider or managed directly by the vCPE solutions provider. Many of the enterprise vCPE approaches also offer an overlay-‐based model or a mixed model that provides multi-‐link aggregation, load-‐balancing or connection management to maximize use of enterprise WAN links.


4.2.2. vCPE Challenges and Implementation

As demonstrated, the virtualized edge represents a large leap in WAN technology with many potential benefits. But such technology shifts are not easy. Whether it’s an enterprise trying to build out vCPE, or service providers building their own virtual edge networks to provide customers with new services, this shift does not come without challenges.

The biggest challenges enterprises face as they manage their own connectivity, are the responses centred on the costs associated with rolling out and maintaining the environment and an overall lack of visibility. Another frequently cited challenge is the complexity of the environment, which, when combined with a lack of visibility, can make it hard to manage and optimize the deployment, as well as troubleshoot any issues to improve its performance.

4.2.3. Test set-‐up

In addition to traditional Fault, Configuration, Accounting, Performance, and Security (FCAPS) Management, the NFV Management and Orchestration framework introduces a new set of management functions associated with the lifecycle management of a VNF. The NFV ISG has focused on detailing these new sets of management functions, which include, but are not limited to: on-‐board a VNF, instantiate a VNF, scale a VNF, update a VNF, and terminate a VNF. A difference also worth highlighting relates to fault and performance management -‐ in a virtualised environment, this is the responsibility of different functional blocks at different layers. Thus, the correlation of faults, alarms and other monitored data such as performance metrics and resource usage, and the consequent fault resolution needed to operate the service in a reliable manner, will typically be distributed.

A vCPE environment is presented in the Figure 4-‐4 below. We are going to test both function migration efficiency with Smart NIC function acceleration, especially for low latency and performance efficiency. We are going to test the following: the VNF descriptor and other related work required to enable the vCPE for the MANO stack of CHARISMA; the part of the VNFCs (VNF Components) that the vCPE consists of; and the lifecycle management function, apart from usual ones, e.g. on-‐boarding, initialization, and related NFVI metrics.

Figure 4-‐4: vCPE environment

The test environment is shown below in Figure 4-‐5.


Figure 4-‐5: vCPE testing environment

4.2.3.1. Infrastructure metrics per sub-‐group and category Performance/Speed Capacity/Scale Reliability/Availability

• Throughput per NFVI node (frames/byte per second)

• Throughput provided to a VM (frames/byte per second)

• Latency per traffic flow • Latency between VMs • Latency between NFVI

nodes • Packet delay variation (jitter)

between VMs • Packet delay variation (jitter)

between NFVI nodes

• Number of connections • Number of frames

sent/received • Maximum throughput between

VMs (frames/byte per second) • Maximum throughput between

NFVI nodes (frames/byte per second)

• Network utilization (max, average, standard deviation)

• Number of traffic flows

• NIC availability (Error free connection time)

• Link availability (Error free transmission time)

• NIC mean-‐time-‐to-‐failure • Network timeout duration

due to link failure • Frame loss rate

4.2.3.2. Tests VNF vCPE CHARISMA project does not aim to develop specific functions (i.e. we will use any developed by SW vendors or developed in Open Source), but to offload and accelerate those functions to show higher performance, lower latency and reduced power consumption. We are going perform the following test subjects in order to measure and assess the VNFs:

• Pre-‐deployment validation of NFV Infrastructure

• vCPE data plane benchmarking L4-‐L7

• vCPE Forwarding Performance Benchmarking Test (Latency, performance., data loss)

4.2.3.3. Tests vCPE lifecycle MANO We are going perform the following test subjects to the vCPE lifecycle:

• Run a vCPE instance


• Configuration related functions

• Support 2 VNO on same infrastructure

• Update component

• vMME Control Plane Benchmarking

• vCPE's Decoupled Control and User Plane Testing

4.2.3.4. Pre-‐deployment validation of Network Services

We will be performing the following performance test for Network Services instantiation testing. The VNF Manager, in collaboration with the NFV Orchestrator, the VIM and the EM, is responsible for managing a VNF's lifecycle operation:

• VNF on-‐boarding.

• VNF instantiation.

• VNF updating.

• VNF termination.

In shared NFV environments, VNFs will likely be instantiated, scaled or terminated at the same instant that many other VNFs are executing in a steady state on the same server. This means that one VNF's lifecycle operation can both affect and be affected by the presence or performance of other VNFs executing at the same time, making it essential to thoroughly test the different phases of a VNF's lifecycle. The successful instantiation, scaling and termination of VNFs there requires validation of the associated methods and metrics. However, successful VNF on-‐boarding is considered a pre-‐requisite and is not addressed in the present document.


5. CHARISMA Security Features

5.1. Distributed e2e security 5.1.1. Security in previous mobile network architectures

The distributed e2e security features in CHARISMA depend on algorithms and methods implemented at the end-‐points of a connection. In a mobile network, this usually refers to user devices (UEs), and ultimately to between user devices and the services offered by the network. To provide e2e security, user data needs to be encrypted at the mobile device. Each previous mobile network generation has used a different encryption method (the A5/1-‐A5/4 methods were used in GSM; 128 bit encryption and the KASUMI algorithm is used in 3G [7]; while SNOW/AES is used in LTE). The following table gives an overview.

Table 5-‐1: Encryption techniques used in current mobile networks.

GSM 3G 4G LTE

Key length 64 bit 128 bit 128 bit

Encryption algorithm A5/0, A5/1, A5/2, A5/3 (KASUMI)

MISTY (previously), KASUMI

SNOW 3G, AES

Effort for attack Low High High

First used 1991 2001 2009

State Hacked

(A5/1 since 2009)

Hacked (compatibility mode with GSM), KASUMI since 2010

Not known

A generic 4G network architecture is shown in Figure 5-‐1, below. Here, the user equipment (UE) communicates wirelessly with the base station (eNodeB). ENodeBs are interconnected by the X2-‐C and X2-‐U interfaces, for control and data, respectively. The control plane exchange with the evolved packet core (EPC) network is passed via the S1-‐C interface to the mobility management entity (MME) and further to the home subscriber service (HSS), where the authentication of users takes place. The user plane (i.e. data) traffic is passed via S1-‐U to the serving gateway (S-‐GW) to the packet data gateway (P-‐GW) where it is routed into the public Internet and to specific services offered by the network operator, that also hosts the Policy and Charging Rules Function (PCRF) [9]. The P-‐GW assigns the IP addresses to the UEs. Communication between eNodeB and S-‐GW is passed through the GPRS tunnelling protocol (GTP), and only after the S-‐GW onwards to the P-‐GW is IP used.

While UEs are authenticated in the EPC, they communicate via unsecured transport networks. In addition, because of the flat IP architecture, communication between eNodeBs and core network is not authenticated. Here, one typically differentiates between the Access Stratum (AS) and Non Access Stratum


(NAS). The AS is terminated in the eNodeB and thereby protects control and data transport over the air interface. The user plane and control plane traffic between eNodeB and EPC is, however, not protected in the NAS, with only the encryption keys and the control traffic between eNodeB and MME being protected.

Communication between decentralized eNodeBs and centralized EPC is realized, in general, via the unprotected transport network, which consists of the fixed access-‐, metro-‐ and core networks that are partly or fully shared among multiple operators and services. The LTE user traffic can therefore be tapped most easily within the unsecured microwave links, which are part of the fixed access network. Note that around 50% of the eNodeBs worldwide are connected via microwave backhaul links. This is probably the biggest security weakness in the 4G mobile network infrastructure. However, enhanced security can be provided in LTE in two ways, which of which can also be combined.

Figure 5-‐1: Principal LTE network architecture

Over-‐the-‐top (OTT) e2e security can be introduced by using messenger applications, such as Signal and Threema. They provide e2e security for messages and voice data over an unsecured mobile network. The methods and protocols used in these applications can be adapted and implemented into the 5G protocol stack in order to provide native e2e security. Key exchange is also one of the challenging problems in encryption. One interesting approach is to exchange the key between Alice and Bob, when they physically meet; in this case, both parties generating a fingerprint (key), which can be encoded in a QR diagram and easily exchanged via a smartphone camera, as indicated in Figure 5-‐2. The drawback is that only the connection of known parties can be encrypted.

Figure 5-‐2: Fingerprint [10]


For VoIP traffic the ZRTP protocol has been defined in RFC6189 in order to agree on a session key and parameters for establishing unicast Secure Real-‐time Transport Protocol (SRTP) sessions. In any case forward secrecy should be implemented in order to protect past sessions against future compromises of secret keys or passwords. This is usually done by using both a long-‐term key and a session key. If the user devices do not support e2e encryption, the base stations that connect Alice and Bob should provide a connection with e2e security. The three levels of e2e security are depicted in Figure 5-‐3.

Figure 5-‐3: End points for e2e security in mobile network

Network-‐assisted end-‐to-‐end security can be introduced in 4G LTE by using the IPsec protocol in the backhaul between the eNodeB and the EPC. Consider the example illustrated in the Figure 5-‐4 below, where the backhaul traffic between the eNodeBs and the EPC is aggregated in two tiers, i.e., the access and aggregation networks. If the operator owns the aggregation tier only, whereas the access domain is shared with other operators, the latter can be regarded as less secure. In order to protect data in the transport network, e.g. if the access infrastructure is shared, mobile operators can currently implement a centralized security architecture, mainly due to the fact that the core network architecture in 4G LTE is likewise centralized. This means that between each eNodeB and the EPC, there is an IPSec tunnel, see Figure 5-‐4; but in order to protect the user data, this architecture significantly increases the latency, which is an issue in the context of CHARISMA.

EPC, MME

RU RU

Alice Bob

DUDU

E2e encryption on user devices(5G protocol stack)

E2e encryption for data units connectingAlice and Bob

E2e encryption on application level(e.g. Signal)

E2e security

Key exchange

Key exchange

Key exchange


Figure 5-‐4: Left: The centralized security architecture in 4G LTE leads to increases latency, because secure traffic has to be routed via the EPC. Right: Latency could be significantly reduced, if the X2 traffic could be

routed at the nearest common aggregation point, e.g. the lowest CAL node.

Consider for instance the critical handover function between the base stations, which is essential when measuring latency. When a handover takes place, the S1 interface is rerouted hard in the EPC. The latency critical function is however, that remaining (i.e. not yet sent) user data is copied over the X2 interface from the previous to the next base station. It is implemented in 4G LTE so that traffic is routed from one base station to the next.

For secure end-‐to-‐end transmission, the X2 data is passed also through the IPSec tunnel from the previous base station to the EPC, where the data is routed, and then sent back over the next IPSec tunnel to the next base station. However, the EPC can be located hundreds of kilometres away in 4G LTE, which implies tens of milliseconds latency. But the next base station may be much closer, typically 1 km or less.

Latency in the mobile backhaul can be significantly reduced by passing the critical X2 data over the nearest converged aggregation level (Figure 5-‐5, right). In a shared access network, operators can be assigned virtual sub-‐networks operated independently and privately. Operator-‐specific encryption could be used inside these sub-‐networks. However, this would imply that the critical routing functionality in the EPC is therefore moved closer to the base stations, ideally into the access network.

There has been an intense discussion inside 5G PPP about the new 5G network architecture. The major trends are depicted in Figure 5-‐5. As already said above, 4G LTE networks employ a centralized core network architecture, while the radio access network is entirely distributed. All base stations (eNBs) are connected via an IP-‐based network to the central node/cloud, which performs the functions of the IP packet core (EPC) and the mobile management (MME), which includes the routing.


Figure 5-‐5: Architecture view on 4G (centralised) and 5G (decentralised)

In the core, 5G tends to shift the EPC functionality closer to the base stations, which immediately implies that the EPC becomes somewhat less complex and more distributed in nature. The many small µEPCs are supervised by a central EPC/MME control network function. From the security point of view, distributing the EPC functionality is an improvement because distributed security is harder to attack. The main advantage, however, is that the latency can also be significantly reduced. The µEPC can be much closer to the base stations, so that the path lengths are thereby shorter.

Note also that there are security improvements in the 5G cloud radio access network (C-‐RAN) architecture where a functional split of the eNodeB is foreseen into a radio unit (RU) and a more centralized baseband unit (BBU). In this way, numerous RUs can be attached via a new fronthaul interface to one BBU, which allows significant improvements for the interference management. Towards the core network, the BBU behaves like a giant base station, having a large number of distributed antennas. Hence, the BBU in 5G will also have the S1 and X2 interfaces, like the eNodeB in 4G LTE.

Considering security, the new C-‐RAN concept has also considerable advantages. While the backhaul behind the eNodeB is fundamentally unsecure in 4G LTE, in particular if a microwave link is used, the compound link from the UE over the air to the RU and then via the microwave or fixed network connection to the centralized BBU is inherently secure. Only after the BBU, is a secure uplink to the µEPC needed again.

The cloud-‐based 5G architecture enables instantiation of virtualized core and RAN network functions among the clouds. In a shared network infrastructure, this implies that these network functions have to be encapsulated by a secure transport protocol, such as IPSec. Operators using the shared physical substrate of an infrastructure provider hence have to build secure islands inside each cloud, which are isolated from the other operators using the same physical substrate, and where their own virtual network functions (VNFs) can be operated. The only function that needs no isolation is that of routing, which is natively safe when using IPSec, while all other virtual network functions will probably need such security encapsulation.

The cloud infrastructure, i.e. the general-‐purpose processor on which virtual machines are instantiated and thereby virtual network functions are realized, is clearly a remaining security weakness in the cloud-‐based 5G infrastructure, because isolation between the tenants is virtual; but VNFs of different tenants can be physically processed in the same machine. At the low processing level, hence, tenants are not physically


isolated. One way out is using only certified cloud hardware in which interactions between the tenants can be considered to be impossible.

As a result, a combination of over-‐the-‐top and network-‐assisted end-‐to-‐end security is recommended to enable the shared use of 5G network infrastructures so that low latency is guaranteed while end-‐to-‐end communication is secure. The distributed e2e security for CHARISMA is still being currently investigated and will be described in more detail in the deliverable D2.5, which is due in M28.

5.2. Physical layer security The integrity and resilience of the CHARISMA architecture is guaranteed across a variety of levels, topological locations, and using a diverse set of technologies including both hardware and software-‐based approaches. From this perspective, the physical layer security can be assured via a variety of perspectives. In previous work we have already outlined a variety of hardware-‐based approaches which are most closely associated with Layer 1 (PHY layer) of the OSI model; however, appropriate interfacing with the next layer above this, Layer 2 or Data link layer is also of critical importance, and also represents an additional approach to assuring the physical layer security of the CHARISMA network. Here, we describe a SW-‐based approach to security and encryption that offers potential low-‐cost, ease of use and real-‐time operation, e.g. [11]. The technique described is based on a symmetric block cipher technique and has a large key-‐space (e.g. 384-‐bit). The T-‐key system is used to overcome the drawbacks of current symmetric encryption algorithms (e.g. DES, 3-‐DES and AES [12]) by using a different key container shape, lightweight rounds and different encryption key sizes. Encryption key manufacture is based around the concept of a 4D tesseract, such that 4-‐rounds and different sub-‐rounds are using to shift the tesseract and create a part of encryption key randomly. The XOR operation is employed due to its fast and lightweight nature. Three key sizes are suggested as examples, which have been tested and evaluated: T-‐{0,1}128, T-‐{0,1}256 and T-‐{0,1}512. Moreover, four lightweight coding rounds are applied to create these keys from what are designated as the 4D tesseract key containers. The execution speed of the T-‐key has been compared with the AES [12] cipher, and the results indicate that the first two encryption key sizes suggested are faster than the first two encryption keys of AES. Furthermore, the security evaluations carried out on the suggested algorithm showed full resistance to statistical attacks and that they pass the correlation coefficient test.

5.2.1. 4D Tesseract-‐key (T-‐Key) Concept

The tesseract or hypercube are the names of the suggested keys container, as a cube can be built by connecting corresponding vertices of two cubes. It is based on a 4-‐dimensional architecture decomposed into 24 squares and divided into an 8-‐cubes, and has 16 vertices and 32 edges [13][14]. Figure 5-‐6 below shows how the tesseract is built and reshaped.


Figure 5-‐6: Schematic construction of a 4D tessaract.

The suggested algorithm is based on the symmetric block cipher technique. It is believed that this is the first time the tesseract has been used in cryptography for real-‐time security applications. The main reason for using a block cipher in a multimedia environment is that the loss or damage of any block during transmission is acceptable and that there is no need to recover the lost information [15][16]. On the other hand, a stream cipher cannot decrypt any data after a part has been lost or damaged, since it is not known which part of the random stream has been affected [17]. The benefits and differences between the suggested tesseract algorithm as compared to other published algorithms are as follows:

1. The key size varies and can take any value starting from 32-‐bits up to 768 bits;

2. Each square is divided into 16 cells, with each cell holding a single binary digit;

3. The encryption key is generated by a XOR operation, which is conceptualised by XOR-‐ing the squares together and saving their result in a new square;

4. The squares’ segments are read both vertically and horizontally rather than only vertically or horizontally, as seen in traditional methods. This method helps to increase the key sizes while maintaining a reasonable processing time.

5. Each encryption key size requires a different number of squares to be generated. For instance, 4-‐squares are required to generate T-‐128; 8-‐squares to generate T-‐256; and 16-‐squares to generate T-‐512.

The simple, symmetric key (SSK) size template for the three suggested encryption key lengths described here are represented in the Table 5-‐2 below:


Table 5-‐2: The SSK template for the T-‐key

Part (Pn) no. P0 P1 P2 P3 P4

Part name Random start face of shifting process

Random directions

Random shifting times

Selected random T-‐square

Random encryption

key

Part size in bits

5 or 10 bits 16 bits 12 bits 20,40 or 80 bits depend on EK size

16 bits

Each one of the following SSKs is used with a different encryption key size:

• The First SSK size: the SSK for first T-‐key {0,1}128), and according to Table (1), the SSK size is:

SSK0=5+16+12+20+16=69 bits (3)

• The Second SSK size: the SSK size for the T-‐{0,1}256 according to table (1) is:

SSK1=10+16+12+16+40=94 bits (4)

• The Third SSK size: this SSK size is used with T-‐{0,1}512, and can be represented mathematically as following:

SSK2=10+16+12+80+16=134 bits (5)

5.2.1.1. Suggested Algorithm Specification A. Keys Container (Keys Home):

The keys container, keys’ home, store of keys, pool of keys or manufactured keys are the names that are used to describe the tesseract. The key container is used to generate a part of an encryption key with various sizes. In cryptography, the technique that is used to generate the encryption key (EK) is more important than the EK size. Consequently, this research found that the algorithm and the 4D tesseract was the best choice to create a very strong key of varied EK sizes by using an innovative technique of rounds. The suggested tesseract that is used has a particular function; it improved, becoming a good environment to build the encryption keys, as shown in the Table 5-‐3 below.


Table 5-‐3: Suggested Tesseract’s Algorithm Specification

No. Function Details

1 No. of tesseract faces 24

2 No. of cubes 8

3 No. of cells in each face 16

4 No. of bits in each cell 1

5 No. of bits in each tesseract’s faces Min. 16

6 No. of bytes in each tesseract’s faces Min. 2

7 No. of bits in tesseract vertical or horizontal Min. 384

8 No. of bytes in tesseract vertical or horizontal Min. 48

9 No. of bits in tesseract vertical or horizontal Min. 768

10 No. of bytes in tesseract vertical or horizontal Min. 96

B. Possible directions to move the cube:

There are 12 possible directions to shift the square’s segments in the tesseract. However, only four of them are selected randomly to shift the squares and the squares segments as well. The 12-‐directions are Rightwards (R), Leftwards (L), Upwards (U), Downwards (D), North East (NE), South West (S-‐W), North West (N-‐W), South East (S-‐E), Right Down (R-‐D), Right Up (R-‐U), Left Down (L-‐ D), and Left Up (L-‐U), and they can be applied in the square itself or with the others that connected with it directly. The direction size can be written as:

𝐷 = 𝐷! ∥ 𝐷! ∥ 𝐷! ∥ 𝐷! = 16 bits (1)

𝐷 = 𝑛 ∈ ℤ!; 0 ≤ 𝑛 ≤ 11; 𝑛 is a binary number with 4 digits

C. Shifting time in each direction

As explained before the suggested tesseract squares comprises of 4x4 cells, so a small number of shifting time is preferred for time saving purposes. Thus, shifting the T-‐square or FF segments four times in any directions provides a key that has the high quality requirements against brute force attack. Thus, the shifting times are 1, 2, 3 and 4. Assume that S refers to the shifting times

S=[000 001 010 011] (2)

𝑆 = 𝑛 ∈ ℤ!; 0 ≤ 𝑛 ≤ 3; 𝑛 is a binary number with 3 digits

5.2.1.2. T-‐Key Algorithm Components: A. Encryption Key (EK):


There are three sizes of encryption keys as explained earlier (i.e. T-‐128, T-‐256 and T-‐512 bits).

B. The XOR Operation:

The third component of the suggested algorithm is the XOR Operation. The first aim of using this operation in the proposed algorithm is to perform XOR-‐ing in plain text (PT) with the T-‐key, and for the results to be once again in PT status once the message has been decrypted. The second aim is to do the first round function.

C. Round Functions:

Rounds in cryptography are used to generate a very secure encryption key. In other words, rounds means the steps that are applied to the keys’ container in order to create the encryption key (EK). The number of rounds is not the same in all algorithms, as well as the technique of the actual rounds. Here, four main lightweight rounds are selected to be the producers that are used to generate the required EK. However, one of these rounds, namely, the XOR-‐ing operation is used various times and this process is then called a sub-‐round (SR). For example, the number of SRs done in T-‐{0,1}128 is less than the number of SRs in T-‐{0,1}256 and the number in T-‐{0,1}512, which is the biggest amongst the suggested encryption key sizes described here.

• Round 1. The first task of SSK: One of the main contributions in this algorithm is to assign responsibilities to the SSK. A new technique has been designed for the SSK to do two specific tasks with the same selected shuffling number. The first technique is used to mix-‐up the T-‐squares and rearrange their position either in the cube or in the tesseract itself.

• Round 2. The second task of SSK: The second task of SSK is that it uses shifting segments of the T-‐square in the same directions and same times of shifting that happened in the first task. This type of round never repeats itself, and is only applied once in each EK generation process.

• Round 3. XOR operation: Another novel approach in this research is using the XOR operation as one of the main rounds. This technique uses the XOR-‐ing operation in each pair of the selected T-‐squares, and stores their results on a different face. On the basis of the evidence currently available, we believe that this process does not impose any significant delay due to the small size of the XOR operation. In order to apply this step, the T-‐squares are selected randomly. This round has various SRs depending on the length of T-‐key.

• Round 4. Generate a Random Encryption Key (EK): The step to create a random encryption key that comes after the XOR-‐ing round above. The part of the encryption key (which is generated randomly) is the remaining part of the whole encryption key size. It represents 32-‐bits of the total EK sizes, in this research.

5.2.1.3. A Suggested Method To Generate T-‐128 The first SSK size (i.e. 69-‐bits) is used in this example to explain how to generate the first encryption key size (i.e. 128-‐bits). Compared to the other encryption key lengths, which are suggested, the T-‐{0,1}128 EK requires the lowest number of squares. Furthermore, it needs only one random square to generate its own cube that encompasses the complete shifting process, as indicated in the algorithm below:


Within T-‐128, 69-‐bits represent the length of the SSK sent by Alice to Bob. In this SSK following example, each data piece of SSK data takes a different text highlight colour in order to be understandable:

• The template of the SSK for the T-‐128 can be shown in the Error! Reference source not found.as follows:

• Table 5-‐4: SSK Distribution into T-‐128 SSK template.

In turn, the processing stages are as shown in the

below:

Table 5-‐5: Definition Each Part Of SSK Depends On The Generated SSK Digits Within T-‐128.

Random start

square of shifting process

Random directions

Random shifting times

Selected random T-‐square

Random encryption key

Total

r S-‐E, U, R-‐U, and L

4 times, 2 times, 3 times, and once.

t, s, k, and c

1101100110100000

69 bits

In general, at first, one of the tesseract squares is selected randomly in order to perform the front face (FF) of a cube’s task. After this selection process the other cube face is performed (FB, FU, FD, FR and FL). The

T-‐{0,1}128 generation Algorithm: Requires a square: A random square from the tesseract. The main square: the selected FF. The Shifting Process Location: Above FF creates the cube that will be the process location in the tesseract. The Process Type: the first duty of the SSK is to execute the shifting of the created cube. The Outputs: The output is passed onto the second SSK task.


round functions are done on the selected FF in order to shift the cube faces and the faces’ segments as well. After this process is completed, 4 squares from the created cube are selected at random, and used to make the first part of encryption key.

5.2.1.4. Results The experiment has been tested in Windows 7 using Java between two client PC’s, with MySQL used as the database in order to calculate the processing speed for each encryption key.

A. The performance speed between T-‐key and AES:

The table below shows the required average time between AES-‐CFB and T-‐key. The whole suggested encryption keys in both algorithms have been evaluated, with the T-‐ {0,1}128 being the faster encryption key, and T-‐{0.1}512 the slowest.

Table 5-‐6: The Performance Speed Comparison Between T-‐Key and AES

Algorithm EK size Relative processing time

AES-‐128 6.90011

AES AES-‐192 9.23321

AES-‐256 11.3327

T-‐128 4.087015

T-‐key T-‐256 8.361719

T-‐512 14.71942

B. Brute Force Attack:

In cryptography, it is very important to make the proposed algorithm very secure against a brute force attack [18][19]. The large key space is responsible for increasing the strength of the algorithms against such brute force attacks. Here, the suggested solution has a new key container with a very large number of keys, such that the tesseract has been developed to hold 384 bits. As a result, this algorithm is considered to be very strong against brute force attacks.

C. Correlation Coefficient Analysis:

The correlation coefficient (r) purpose is to measure the relationship strength between two variables (x, y) [20]. In order to examine the suggested algorithm against statistical attacks, the correlation test is performed and analysed. In cryptography, the correlation must be weak between any two examined data of the algorithm (i.e. PT, cypher text (CT), or EK). The correlation value is always (-‐1< r < 1). If the correlation equals zero, this means that the relationship between the selected values is weak [20][21]. Here, the relationship between the first 5 blocks of the plaintext is evaluated with the first 5 blocks of the cypher text (i.e. 128, 256 and 512 bits).


The first size result is as shown in:

Table 5-‐7: The Correlation Coefficient Result in the Size of 128-‐Bits

X=128 PT CT EK

Y=128 EK CT CT

Correlation Coefficient 0.0023 -‐0.074 0.066

The second size result is as shown in: Table 5-‐8: The Correlation Coefficient Result In The Size Of 256-‐Bits

X=256 PT CT EK

Y=256 EK CT CT

Correlation Coefficient 0.027 0.004 0.035

The third size result is as shown in:

Table 5-‐9: The Correlation Coefficient Result In The Size Of 512-‐Bits

X=512 PT CT EK

Y=512 EK CT CT

Correlation Coefficient 0.005 0.010 0.0099

D. The NIST Test Suite:

The NIST test suite is one of the randomness tests using cryptography random or pseudorandom number generators [22], and can be summarised as a statistical package that contains 15 tests in order to find out the different kinds of non-‐randomness that are available in a sequence [23]. In this type of test, the probability value (P-‐value) is compared with the significant level (α). P-‐value and α are fixed values [24], where:

P-‐value ∈[0, 1]. α ∈ [0.001, 0.01].

In this experiment, 1,800,000-‐bits are selected to be examined in NIST. The Table 5-‐10 below shows the result of the P-‐value within each type of test. The result shows that the selected data passed all the NIST suit of tests within the success criterion of 0.01<P-‐value and with a confidence of 99%.


Table 5-‐10: The P-‐Value In The Statistical Tests

No. Statistical Test Name P-‐value Conclusion

1 Frequency 0.190156 Success

2 Block Frequency 0.714287 Success

3 Cumulative Sums 0.822674 Success

4 Runs 0.248951 Success

5 Long Runs of Ones 0.743223 Success

6 Rank 0.655601 Success

7 Spectral-‐discrete Fourier Transform 0.582545 Success

8 Nonperiodic Template Matchings 0.236816 Success

9 Overlapping Template Matchings 0.190863 Success

10 Universal Statistical 0.989743 Success

11 Approximate Entropy 0.704137 Success

12 Random Excursions 0.176037 Success

13 Random Excursions Variant 0.348112 Success

14 Serial 0.866154 Success

15 Linear Complexity 0.785818 Success

5.2.1.5. Discussion The main aim of this discussion of a novel physical layer encryption solution has been to develop a novel cryptography solution for efficient security that is applicable to all kinds of data, and that provides a low latency performance suitable for CHARISMA. In this description, we have selected three encryption sizes: T-‐128, T-‐256 and T-‐512. In order to generate the encryption key four rounds were suggested for all encryption key sizes; however, there are other sub-‐rounds that differ in from size from one another. We have also discussed the sets of the encryption and decryption algorithms and calculated their relative speed performances, with the results of the suggested algorithms compared with the AES algorithm. The performance speed in the first two encryption keys of the suggested algorithm were faster than the first two encryption key sizes of AES. The suggested algorithm was also passed through the brute force attack examination. In this case, the suggested algorithm passed the correlation test, which also indicated that the relationships between plain text (PT) and cipher text (CT), plain text and encryption (EK) key, and CT and EK were weak. Finally, the T-‐key approach has passed all of the 15 tests in the NIST Test suite.


5.3. TrustNode multi-‐user & router platform environment Targeting an all IP infrastructure forces the architecture to be aware of ensuring secure layer 3 and layer 2 communications. From security point of view the authentication and data integrity should be provided by the network infrastructure, to provide data security beginning from the lowest level possible.

A common routing infrastructure is flexible and doesn't have restrictions respective to the address layout. On the other side this flexibility makes the IP routing vulnerable to attacks focusing on packet routing [25][26][27][28]. Using IPv6 offers a great possibility to restructure the routing infrastructure in physical and logical way [29]. One of the key facts proposed by CHARISMA is the hierarchical network structure, such that its hierarchical address layout, where specialised routing hardware is used to speed-‐up the traffic forwarding [30]. This has also been driven by the partner InnoRoute in the SELFNET and CHARISMA projects, using the flexible, and hardware accelerated routing hardware with the primary goal of flow-‐ and network-‐function acceleration. With the combination of secure, optimized hardware and hierarchically routing, both projects are addressing authentication and integrity issues. InnoRoutes modular hardware routing platform TrustNode offers two key technologies to address these issues:

• The first is MACSec which is implemented in hardware and provides the integrity of data exchanged between the devices [31].

• The second technology is InnoRoutes fast hierarchical routing concept 6Tree.

The routing of 6Tree traffic is fully implemented in hardware, using is a unique configuration parameter which tells the device its logical position in the network [32][33][30]. Using this concept the path of a packet through the network is strictly predefined by the value of the IPv6 address bits, which are inside the protection area of MACSec. By applying a plausibility check for the source address on incoming packets the network devices are not vulnerable to address spoofing attacks. Therefore receiving a 6Tree packet, the source address and the way through the 6Tree network is verified which authenticates the source toward the destination.


6. Conclusions

In this deliverable D2.2 we have continued laying the foundations of the physical layer (PHY) technologies required for the CHARISMA project to offer a distributed intelligence (cloud/cloudlet/fog-‐based) RAN access network suitable for 5G deployment. We have updated the descriptions of the management interfacings of the technology network elements, focusing on the TrustNode, MoBcache, 100G OFDM-‐PON, millimetre wave wireless backhauling and point-‐to-‐point links, as well as the Ericsson HDS 8000 data centre system that can be used to host the CHARISMA CMO system. Related to the distributed CMO system with its orchestration capabilities for the NFVs and VSFs that are integral to the CHARISMA concept, in this deliverable we have also reported on the vCPE technology that is also being developed, along with the distributed end-‐to-‐end security features, to be integrated with the VSFs being developed in WP3. In particular CHARISMA provides for an encryption tunnel which does not need to be terminated at the EPC (or µEPC) but can also be terminated at the two ends (end users) of the e2e connection. We also report on the 4D tesseract key (T-‐key) concept that has been developed for PLS within CHARISMA.

The results of the technologies presented in this report will also feed into the parallel tasks of WP3 (for CMO integration), and WP4 for the definition of the field-‐trials and lab-‐based demonstrator. In addition, the technologies developed here will continue to be developed in the final period of WP2, in particular feeding into the tasks T2.3 (hardware implementation of vCPE), T2.4 (distributed e2e v-‐security), and T2.5 (securing wireless multiuser networks). These developments will be reported upon in the subsequent WP2 deliverables of D2.3 (M24), D2.4 (M26), D2.5 (M28), and D2.6 (M30).


References

[1] M. Ulbricht, and J. Wagner, “Accelerated processing delay optimization in hierarchical networks using low cost hardware”, IEEE 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP), p.1-‐6, 2016

[2] https://tools.ietf.org/html/rfc6020

[3] Indigo [Online] https://floodlight.atlassian.net/wiki/display/Indigo/Indigo+-‐+Open+Source+OpenFlow+Switches+-‐+First+Generation

[4] Indigo – Open source OpenFlow Switches [Online] https://floodlight.atlassian.net/wiki/display/Indigo/Indigo+-‐+Open+Source+OpenFlow+Switches+-‐+First+Generation

[5] Cooley, James W and Tukey, John W., “An algorithm for the machine calculation of complex Fourier series”, Mathematics of Computation, Vol. 19, pp.297-‐301, 1965

[6] SPLIT RADIX' FFT ALGORITHM, Electronics Letters, 5.Jan.1984, Vol. 20, No. 1

[7] 3GPP 35.201

[8] M. Speth et al., “Optimum Receiver Design for Wireless Broad-‐Band Systems Using OFDM – Part I”, Trans. Commun. 47 (11), IEEE, 1999

[9] Evren Eren, Kai-‐Oliver Detken, „Ende-‐zu-‐Ende-‐Sicherheit bei Long Term Evolution (LTE)“, WCI 2013, Berlin, Germany

[10] https://github.com/WhisperSystems/Signal-‐iOS/wiki/FAQ

[11] Huang, C. C., Chen, P. Y. and Ma, C. H. (2012) A novel interpolation chip for real-‐time multimedia application. IEEE Transaction on Circuits and Systems for Video Technology, 22 (10): 1512-‐1525

[12] Zimmerman, P. (1999) An Introduction to Cryptography. Doubleday & Company, Inc., United States of America.

[13] Carter, J. S. and Mullens, D. (2011) Heron’s Formula from a 4-‐Dimensional Perspective. University of South Alabama Department of Mathematics and Statistics March 17.

[14] Barth, N. R. (2004) Computing Cavalieri’s quadrature formula by a symmetry of the n-‐cube. American Mathematical Monthly, 111 (9): 811-‐813.

[15] Tullimas, S., Nguyen, T. and Edgecomb, R. (2006) Multimedia streaming using multiple TCP connections. Submitted to ACM Transactions on Multimedia Computing, Communications and Applications, 5 (14): 1-‐22, November.

[16] W. Diffie and M. E.Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theoly, vol. 22, pp. 644 -‐ 654, 1976.


[17] Kessler, G. C. (2006) An Overview of Cryptography. Self-‐published.

[18] Menezes, A. J.,Vanstone, S. A. and Oorschot, P. C. V. (1996) Handbook of Applied Cryptography. CRC Press, Inc., Boca Raton, FL, USA.

[19] Naidu, A. and Deshmukh, A. Y. (2014) Design of high throughput and area efficient advanced encryption system core. International Conference on Communications and Signal Processing (ICCSP): 1974-‐1978 DOI: 10.1109/ICCSP.2014.6950189.

[20] George, R. T. and Gopakumar, K. (2014) Spatiotemporal chaos in globally coupled NCA map lattices using 3-‐D Arnold cat map for digital image encryption. 2014 First International Conference on Computational Systems and Communications (ICCSC): 203-‐208 DOI:10.1109/COMPSC.2014.7032648.

[21] Alam, S. S. and Bhattacharyya, S. (2014) A novel image encryption algorithm using hyper-‐chaos key sequences, multi step group based binary gray conversion and circular bit shifting logic. International Conference on Science Engineering and Management Research (ICSEMR): 1-‐9. DOI: 10.1109/ICSEMR.2014.7043596.

[22] Rukhin, A.. Soto, J., Nechvatal, J., Smid, M., Barker, E., Leigh, S., Levenson, M., Vangel, M., Banks, D., Heckert, A., Dray, K. and Vo. S. (2010) A Statistical Test Suite for Random and Pseudorandom Number Generators for Cryptographic Applications. National Institute of Standards and Technology (NIST) Special Publication 800-‐22, Rev. 1a, March. Available from: http://csrc.nist.gov/publications/nistpubs/800-‐22-‐rev1a/SP800-‐22rev1a.pdf

[23] Atteya, A. M. and Madian, A. H. (2014) A hybrid chaos-‐AES encryption algorithm and its implementation based on FPGA. 2014 IEEE 12th International New Circuits and Systems Conference (NEWCAS): 217-‐220. DOI: 10.1109/NEWCAS.2014.6934022.

[24] Razy, A. F. M., Naziri, S. Z. M., Ismail, R. C. and Idris, N. (2014) Investigation and design of the efficient hardware-‐based RNG for cryptographic applications. 2014 2nd International Conference on Electronic Design

[25] Shuaishuai Tan, Xiaoping Li, and Qingkuan Dong, “TrustR: An Integrated Router Security Framework for Protecting Computer Networks”, IEEE Communications Letters, 2, 376-‐379, 2016

[26] Feiyi Wang, Brian Vetter, and Shyhtsun Felix Wu, “Secure routing protocols: Theory and practice”, Technical report, North Carolina State University, 1997

[27] Jian Yin, and Sanjay Kumar Madria, “A hierarchical secure routing protocol against black hole attacks in sensor networks”, IEEE International Conference on Sensor Networks, Ubiquitous, and Trustworthy Computing (SUTC'06), 1, pp8, 2006

[28] Hitesh Ballani, Paul Francis, and Xinyang Zhang, “A study of prefix hijacking and interception in the Internet”, ACM SIGCOMM Computer Communication Review, 37, pp265-‐276, 2007

[29] R. Hinden and S. Deering , “Internet Protocol Version 6 (IPv6) Addressing Architecture”, Internet Engineering Task Force, RFC 3513 (Proposed Standard), April 2003 [note, obsoleted by RFC 4291]

[30] Marian Ulbricht and Jens Wagner, “Accelerated Processing Delay Optimization in Hierarchical Networks Using Lowcost Hardware”, 2016 10th International Symposium on Communication Systems, Networks and Digital Signal Processing (CSNDSP16), Prague, Czech Republic, July 2016


[31] “IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Security”, IEEE Std 802.1AE-‐2006, p.1-‐150, August 2006

[32] H.C. Choo, and S.J. Jang, “Method of operating internet protocol address and subnet system using the same”, US Patent 7,693,163, 2010

[33] A. Foglar, and S. Sonntag, “Router IP port for an IP router”, US Patent 7,499,450, 2009


Acronyms

5G 5th generation mobile network ACE Accelerated ALG Application Level Gateway AP Access Point APD Avalanche Photodiode API Application Programming Interface AR Access Router ARN Active Remote Node ARP Address Resolution Protocol AS Access Stratum ATX Advanced Technology eXtended AWG Arbitrary Waveform Generator/ Arrayed Waveguide Grating BBU BaseBand Unit BER Bit Error Rate BPSK Binary Phase Shift Keying BNG Broadband Network Gateway BOSA Bi-‐directional Optical Sub-‐assembly BRAS Broadband Remote Access Server BS Base Station CAL Converged Aggregation Layer CCD Charge-‐Coupled Device CDN Content Delivery Network CE Coexistence Element CFO Carrier Frequency Offset CGH Computer-‐Generated Hologram CLI Command Line Interface CO Central Office CP Cache Proxy CP Cyclic Prefix CPE Customer Premise Equipment CPU Central Processing Unit C-‐RAN Cloud Radio Access Network CRC Cyclic Redundancy Check


CST Computer Simulation Technology (AG) CT Cipher Text D2D Device to Device D2I Device to Infrastructure DAC Digital-‐to-‐Analog-‐Converter DC Data Centre DDM Digital Diagnostic Monitoring DDoS Distributed DoS DDR Double Data Rate DDS Direct Digital Synthesis DFB Distributed Feedback Lasers DFT Discrete Fourier Transform DHCP Dynamic Host Configuration Protocol DL Downlink DOP Degree of Polarisation DPDK Data Plane Development Kit DPI Deep Packet Inspection DoS Denial of Service DoW Description of Work DP Distribution Point DQPSK Differential Quadrature Phase Shift Keying DRAM Dynamic RAM DSCP Differentiated services code point DSP Digital Signal Processing DU Digital Unit e2e End-‐to-‐End EC European Commission ECMA European Computer Manufacturers Association EIRP Equivalent isotropically radiated power EK Encryption Key eNB/eNodeB Evolved Node B EPC Evolved Packet Core EML Externally Modulated Laser ETH Ethernet EVM Error-‐Vector-‐Magnitude FB Front Back FCAPS Fault, Configuration, Accounting, Performance, and Security FD Front Down FEC Forward Error Correction FF Front Face


FFT Fast Fourier Transform FIFO First In -‐ First Out FL Front Left FMC FPGA Mezzanine Card FPGA Field-‐Programmable Gate Array FR Front Right FSAN Full Service Access Network FSO Free Space Optics FU Front Up FW Firewall GbE Gigabit Ethernet GPON Gigabit Passive Optical Network GPRS General Packet Radio Service GTP GPRS Tunnelling Protocol GUI Graphical User Interface HD High-‐Definition HDMI High-‐Definition Multimedia Interface HDTV High Definition TV HG Hermite-‐Gaussian HGI Home Gateway Initiative HGW Home Gateway HP Holographic Plate HSS Home Subscriber Service HTTP Hyper Text Transfer Protocol HTTPS Hyper Text Transfer Protocol Secure HW Hardware IaaS Infrastructure as a Service I/Q In-‐phase/Quadrature ICMP Internet Control and Management Protocol ID Identification Data IDFT Inverse Discrete Fourier Transform IEEE Institute of Electrical and Electronics Engineers IETF The Internet Engineering Task Force Ifc Interface IFFT Inverse Fast Fourier Transform IMU Intelligent Management Unit IoT Internet of things IP Internet Protocol IPTV IP Television IPoE IP over Ethernet


IPS Intrusion Protection System ISI Inter-‐Symbol-‐Interference ITU International Telecommunication Union JSON JavaScript Object Notation JTAG Joint Test Action Group KPI Key Performance Indicators LO Local Oscillator LOS Line of Sight LP Low-‐Pass LTE Long Term Evolution MAC Media Access Control MANO Management and Organization MB MoBcache MBH Mobile Backhaul MDC Mobile Distributed Caching MD-‐SAL Model-‐driven Service Abstraction Layer µEPC Micro Evolved Packet Core MIMO Multiple-‐Input Multiple-‐Output MME Mobility Management Entity MMPX MicroMiniature PCB Connector mmW millimetre Wave MPLS Multiprotocol Label Switching MPPS Million Packets per second MPW Multi Project Wafer MU Multi-‐User MUX Multiplexer MVNO Mobile Virtual Network Operator NAC Network Access Control NAPT Network Address Port Translation NAS Non Access Stratum NAT Network Address Translation NBI NorthBound Interface NETCONF Network Configuration Protocol NF Network Function NFC Network Function Component NFV Network Functions Virtualisation NFVI Network Functions Virtualisation Infrastructure NFVO Network Functions Virtualisation Orchestrator NG-‐PON2 Next Generation Passive Optical Network 2 NIC Network Interface Card


NIST National Institute of Standards and Technology NLOS None Line of Sight NoSQL Not Only Structured Query Language O/E Optical-‐to-‐Electrical ODL OpenDayLite ODN Optical distribution Network OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiplexing Access OLT Optical Line Terminal OMCI Optical Network Unit Management and Control Interface ONT Optical Network Termination ONU Optical Network Unit OPEX Operating Expense OS Operating System OTT Over-‐The-‐Top content OVS Open vSwitch PaaS Platform-‐as-‐a-‐Service PC Personal Computer PCB Printed Circuit Board PCI Peripheral Component Interconnect PCIe Peripheral Component Interconnect Express pCPE Physical CPE PCRF Policy and Charging Rules Function PCS Physical Coding Sublayer PFP PreFetch Proxy P-‐GW Packet Gateway PHY Physical Layer PIC Photonic Integrated Circuits PIN Positive-‐intrinsic-‐Negative PLS Physical Layer Security PMA Physical Medium Attachment PNF Physical Network Functions PolSK Polarisation Shift Keying PON Passive Optical Network PPP Public Private Partnership/ PPPoE PPP over Ethernet PT Plain Text PtP Point-‐to-‐Point PTP Precision Time Protocol QAM Quadrature Amplitude Modulation


QPSK Quadrature Phase Shift Keying QKD Quantum Key Distribution QoS Quality of Service QR Quick Response RAM Random Access Memory RF Radio Frequency RFC Request For Comment RGW Residential Gateway RN Remote Node RPC Remote Procedure Call RSSI Received Signal Strength Indication RU Radio Unit SBC Session Border Controller SBI SouthBound Interface SC Small Cell SDN Software Defined Networks SFI SerDes Framer Interface SFO Sampling Clock Frequency Offset SFP+ Small Form Factor Pluggable S-‐GW Serving Gateway SLA Service level Agreement SNMP Simple Network Management Protocol SNR Signal to Noise Ratio SOA Semiconductor Optical Amplifier SP Service Provider SR Sub-‐Round SRIOV single root input/output virtualization SRTP Secure Real-‐time Transport Protocol SSH Secure SHell SSK Simple, Symmetric Key STB Set Top Box STP Spanning Tree Protocol syncE Synchronous Ethernet TCAM Ternary Content Addressable Memory TCL Tool command language TCP Transmission Control Protocol TDMA Time Division Multiple Access TIA Trans-‐Impedance-‐Amplifier TS Training Symbol(s) TWDM Time and Wavelength Division Multiplex


Tx Transmitter UE User Equipment UNI User Network Interfaces UPnP Universal Plug-‐and-‐Play USB Universal Serial Bus VAS Value-‐added Service vCPE Virtual CPE vE-‐CPE Virtual Enterprise CPE VIM Virtualised Infrastructure Manager vIT Virtual IT VLAN Virtual LAN VM Virtual Machine VNF Virtual Network Function VNFC Virtual Network Function Component VNFD Virtual Network Function Descriptor VNI Virtual Network Interface VoIP Voice over IP VPN Virtual Private Network vPOD Virtual Performance Optimized Datacentre VSWR Voltage Standing Wave Ratio WDM Wavelength Division Multiplexing WOC WAN Optimization Controller WP Work Package XFP 10 Gigabit Small Form Factor Pluggable XG-‐PON 10 Gb/s PON XML Extensible Markup Language ZRTP Zimmermann Real-‐time Transport Protocol

<END OF DOCUMENT>

charisma - d2.2 - v1€¦ · v0.1 11/10/2016 uessex table of contents v0.2 15/11/2016 hhi, icom,...

Documents