5g-miedge · francesca cuomo mattia merluzzi [email protected]...

57
Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4 Date : August 2018 Public Deliverable 5G-MiEdge Page 1 5G-MiEdge Millimeter-wave Edge Cloud as an Enabler for 5G Ecosystem EU Contract No. EUJ-01-2016-723171 Contractual date: M26 Actual date: M26 Authors: See list Work package: D2.4 Method of site specific deployment of mmWave edge cloud Security: Public Nature: Report Version: 1.0 Number of pages: 57 Abstract This deliverable reports second year results of WP2, specifically the methods of site specific deployment, optimization and prototyping of mmWave edge cloud. Keywords millimeter-wave, millimeter-wave access, millimeter-wave backhaul, edge cloud, mobile edge computing, site specific deployment, backhaul mesh node, backhaul mesh architecture, backhaul mesh prototype All rights reserved.

Upload: nguyenhuong

Post on 21-Feb-2019

214 views

Category:

Documents


0 download

TRANSCRIPT

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date : August 2018 Public Deliverable

5G-MiEdge Page 1

5G-MiEdge Millimeter-wave Edge Cloud as an Enabler for 5G Ecosystem

EU Contract No. EUJ-01-2016-723171

Contractual date: M26

Actual date: M26

Authors: See list

Work package: D2.4 Method of site specific deployment of mmWave edge cloud

Security: Public

Nature: Report

Version: 1.0

Number of pages: 57

Abstract

This deliverable reports second year results of WP2, specifically the methods of site specific

deployment, optimization and prototyping of mmWave edge cloud.

Keywords

millimeter-wave, millimeter-wave access, millimeter-wave backhaul, edge cloud, mobile edge computing,

site specific deployment, backhaul mesh node, backhaul mesh architecture, backhaul mesh prototype

All rights reserved.

2

5G-MiEdge Page 2

The document is proprietary of the 5G-MiEdge consortium members. No copy or distribution, in

any form or by any means, is allowed without the prior written agreement of the owner of the

property rights.

This document reflects only the authors’ view. The European Community is not liable for any use

hat may be made of the information contained herein.

Authors

Fraunhofer Heinrich

Hertz Institute

Thomas Haustein

Konstantin Koslowski

[email protected]

[email protected]

CEA-LETI Antonio De Domenico

Nicola di Pietro

[email protected]

[email protected]

Sapienza University of

Rome

Sergio Barbarossa

Stefania Sardellitti

Francesca Cuomo

Mattia Merluzzi

[email protected]

[email protected]

[email protected]

[email protected]

Tokyo Institute of

Technology

Kei Sakaguchi

Khan Tran Gia

Makoto Nakamura

[email protected]

[email protected]

[email protected]

Panasonic Koji Takinami

Tomoya Urushihara

[email protected]

[email protected]

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date : August 2018 Public Deliverable

5G-MiEdge Page 3

Table of contents

Abbreviations .................................................................................................................. 5

Executive Summary ........................................................................................................ 7

1 Introduction ............................................................................................................. 8

2 Overall architecture of mmWave edge cloud in selected scenarios .................... 9

2.1 Omotenashi services ......................................................................................... 9

2.2 Dynamic crowd .............................................................................................. 14

2.3 Autonomous driving ....................................................................................... 18

3 Design and analysis for site specific deployment of mmWave edge cloud ....... 24

3.1 Modeling and optimization of multi RAT HetNet.......................................... 24

3.2 Interference management in mesh backhaul networks .................................. 32

3.2.1 Interference management methods ..................................................... 32

3.2.2 MMBN architecture............................................................................ 33

3.2.3 MmWave AP deployment ................................................................... 34

3.2.4 Channel assignment ............................................................................ 35

3.2.5 Beam selection.................................................................................... 36

3.2.6 Power allocation ................................................................................. 36

3.2.7 Simulation model................................................................................ 37

3.2.8 Simulation results ............................................................................... 38

3.3 Dynamic resource allocation, considering the best trade-off between queues

and power consumption ................................................................................. 40

3.3.1 Introduction ........................................................................................ 40

3.3.2 Problem formulation and proposed solution ...................................... 40

3.3.3 Numerical results ................................................................................ 46

4 Mesh backhaul prototyping ................................................................................. 49

4.2 Software-defined wireless mesh networks for mobile edge computing ........ 50

4.2.1 MmWave wireless mesh network ....................................................... 50

4.2.2 Mobile edge computing ...................................................................... 51

4.3 Node prototyping ............................................................................................ 51

4.3.1 Prototype designs................................................................................ 51

4.3.2 Movable mmWave antenna ................................................................ 52

4

5G-MiEdge Page 4

4.3.3 Computation device ............................................................................ 52

4.3.4 Next steps ........................................................................................... 53

5 Summary (FHG, 1page) ....................................................................................... 54

6 References .............................................................................................................. 55

5

5G-MiEdge Page 5

Abbreviations

Acronym Description

AMF Access and Mobility management Function

AP Access Point

APC AP Controller

AS Application Server

BF Beam-Forming

BS Base Station

CAPEX Capital Expenditure

CDN Content Delivery Network

D2D Device-to-Device

EVM Error Vector Magnitude

HD High Definition

HetNet Heterogeneous Network

ISD Inter Site Distance

LiDAR Light Detection And Ranging

LoA Levels of Automation

LOS Line Of Sight

MEC Mobile edge cloud (computing)/ multi access edge computing

MEH Mobile Edge Host

mmWave Millimeter-wave

MBS Macro Base Station

MMBN Millimeter-wave Mesh Backhaul Network

MSF MEC Service Function

NLOS Non Line Of Sight

OBU On-Board Unit

OPEX Operating Expenditure

PPP Poisson Point Process

RAN Radio Access Network

RAT Radio Access Technology

RSSI Received Signal Strength Indicator

RSU Roadside Unit

6

5G-MiEdge Page 6

SBS Small cell Base Station

SDN Software Defined Network

SINR Signal to Interference plus Noise Ratio

SIR Signal to Interference Ratio

UE User Equipment/Entity

V2V Vehicle-to-Vehicle

V2X Vehicle-to-Everything

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 7

Executive Summary

The EU-Japan funded research project 5G-MiEdge (Millimeter-wave Edge cloud as

an enabler for 5G ecosystem) envisions to design, develop and demonstrate an

innovative 5G architecture, which manages to smartly and smoothly combine

millimeter-wave (mmWave) access/backhauling with mobile edge cloud (computing)/

multi access edge computing (MEC). This deliverable belongs to WP2, which runs

from month 4 to 30 of the 36-month lifetime of the project.

WP2 is in charge of millimeter-wave edge cloud for 5G RAN deployment and works

in tight cooperation with WP1 and WP4. It builds upon architecture and scenarios from

WP1 and creates the foundation for WP4, focusing on the implementation of a proof-

of-concept testbed and system evaluation.

This deliverable begins with the deployment of mmWave edge cloud in specific

scenarios, including the deployment method of mmWave access points (APs) with

capabilities for caching/prefetching, computation and relaying. The following sections

present details on the optimization of deployed radio resources by using predicted

traffic load and adapting routes, channels and backhaul links.

The highlights of this deliverable are:

Overall architecture of mmWave edge cloud in selected scenarios in Section 2

Design and analysis for site specific deployment of mmWave edge cloud in

Section 3, split into:

o Modeling and optimization of multi radio access technology (RAT)

heterogeneous network (HetNet)

o Interference management in mesh backhaul networks

o Dynamic resource allocation, considering the best trade-off between

queues and power consumption

Mesh backhaul prototyping in Section 4

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 8

1 Introduction

The EU-Japan funded research project 5G-MiEdge (Millimeter-wave Edge cloud as

an enabler for 5G ecosystem) envisions to design, develop and demonstrate an

innovative 5G architecture, which manages to smartly and smoothly combine

mmWave access/backhauling with MEC. This joint work focuses on mmWave edge

cloud, the architecture in selected scenarios, site-specific deployment and prototyping

of mesh backhaul nodes.

This deliverable is part of WP2, which runs from month 4 to 30 of the 36-month

lifetime of the project and is in charge of mmWave edge cloud for 5G radio access

network (RAN) deployments. The focus of the work is on site specific methods for

deployment of mmWave edge cloud.

This deliverable is split in five sections.

The first section is this introduction, followed by the overall architecture of mmWave

edge cloud in selected scenarios.

The second section gives an overview on three selected scenarios:

Omotenashi services

Dynamic crowd

Autonomous driving

Including the specific constraints for each scenario, that need to be carefully

considered in the deployment of the mmWave edge cloud network.

In the third section, the design and analysis for site specific deployment of mmWave

edge cloud are presented. This section is split into three parts, each focusing on an

important aspect of the site specific deployment. Section 3.1 shows modelling and

optimization of multi RAT heterogeneous networks, Section 3.2 focuses on

interference management in mesh backhaul networks, and Section 3.3 explains

dynamic resource allocation when considering the best trade-off between queues and

power consumption.

The fourth section details on prototyping of mesh backhaul nodes, considering the

previously explained constraints for the scenarios, running evaluations on the testbed

and working towards the final goal of this project: Verifying the developed ideas and

concepts in extensive field trials.

Finally, the deliverable is concluded with a summary of achievements and outlook for

future work in Section 5.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 9

2 Overall architecture of mmWave edge cloud in selected

scenarios

This section explains the system architecture, requirements and specific deployment

constraints of mmWave edge cloud networks for three carefully selected scenarios.

2.1 Omotenashi services

Figure 2.1-1 shows the system architecture of Omotenashi services. As reported in

D1.3, it consists of the non-3GPP MiEdge RAN (Wi-Fi) and the 3GPP network. User

Equipment (UE) are assumed to connect to the non-3GPP network, e.g. in the airport

facility scenario.

Before arrival at the airport, MEC service function (MSF) collects the user context

information (user location, user profile, subscriptions, etc.), as well as other context

such as content popularity, cached contents, etc. Based on these contexts, the content

and application data are pre-fetched from the application server (AS) to the mobile

edge host (MEH), which is located at the central management center.

Figure 2.1-1 is based on a private service scenario where the private operator owns the

non-3GPP network. The local MSF (L-MSF) takes over the role of MSF of the 3GPP

network to provide locally optimized services. The context information, which are

required to run the specific services, will be transferred from MSF to L-MSF.

L-MSF predicts mobility pattern at the airport, and relocates cashed

contents/application state among multiple MEHs for optimum use of distributed MEH

resources. For example, at the airport the user mobility is well predictable from the

entrance to the departure gate. In addition, the departure gate area is heavily crowded

only when the boarding time is approaching. Therefore, there will be available

resources in MEHs, which are located in less crowded area. L-MSF performs

optimization and resource allocations among MEHs via the Mp3 interface control

signaling.

Figure 2.1-1 System Architecture of Omotenashi service [D1.3]

ASDN

Central Management Center

WiGig Signage

MEH

AP

MEH

N6

UE

AP

MEH

mmWave link

Mp3

MSF

AMF

SMF

NEFNO1

NO2

NO3

3GPP

NL4

GW

NL2

UPF

MEHN1

NL2

L-MSF

M iEd g e RAN ( n on -3 GPP)

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 10

In order to realize multi-Gbps throughput in densely populated area, content delivery

network and RAT must be integrated. In the following, key enablers for Omotenashi

services are described.

Edge cloud contents delivery network

Figure 2.1-2 shows the high-level architecture of the overall network that is taken into

consideration. The WiGig equipped digital signage (WiGig signage) employs 60 GHz

mmWave wireless connection based on WiGig/IEEE 802.11ad standard, which

provides multi-Gbps content delivery for user terminals. To avoid backhaul congestion

from the cloud to WiGig signages, the edge cloud content delivery network (edge cloud

CDN) is introduced. The edge cloud consists of local storages and WiGig signages,

which are located at the edge of the network. The content and application data are pre-

fetched to the local storages based on the user context information. Most of the pre-

fetching process can be done during low traffic periods, such as overnight.

Multi-user gigabit access

Assuming that multiple users download contents simultaneously, the content delivery

system could suffer from throughput degradation due to congestion at the WiGig

signage. To avoid this, the WiGig signage is equipped with multiple WiGig modules,

as illustrated in Figure 2.1-3. Each WiGig module adopts beam-forming (BF)

technology, which steers the antenna beam by using the phased array antenna. This

mitigates interference among WiGig links, thus enabling multi-Gbps throughput in the

multi-user environment.

W iGig

Ed g e Clo u d

Con ten ts D istr ib u tio n

Ba ck h a u lN etw o rk

W iGigSig n a g e

Loca l Sto ra g e

Figure 2.1-2 Edge cloud content delivery

network

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 11

Figure 2.1-3 Multi-user Gigabit/s access technology

WiGig/Wi-Fi HetNet

Due to large path loss, the communication distance of WiGig is typically limited up to

about 10 m. To extend the area coverage, the WiGig/Wi-Fi heterogeneous network

(HetNet) is employed. Figure 2.1-4 shows the concept of WiGig/Wi-Fi HetNet where

authentication, connection management as well as browsing the content list are

executed via Wi-Fi, so to achieve a wider coverage. The WiGig connection is available

within the WiGig area for users to download the contents to their terminals with multi-

Gbps throughput.

Figure 2.1-4 WiGig/Wi-Fi HetNet

Figure 2.1-5 illustrates a block diagram of the WiGig signage. It consists of WiGig

modules, a Wi-Fi AP, a local storage and an AP controller (APC). The APC manages

the WiGig connections. While the user terminal is connected to Wi-Fi, the APC

periodically collects expected link quality via Wi-Fi for connection management

[Figure 2.1-5 (1)]. When the user terminal requests WiGig connection, the APC

connects the terminal to one of the WiGig modules, which provides the best link

quality [Figure 2.1-5 (2)]. When the user requests the content download from the

application, the user terminal starts downloading from the local storage via WiGig

[Figure 2.1-5 (3)].

W iGig

… W iGigM od u le

W iGig Area

Con n ect &Dow n loa d

W i-Fi

W iGig

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 12

Application-centric WiGig/Wi-Fi cooperative connection management

In WiGig/Wi-Fi HetNet, the WiGig connection procedure directly affects user

experience. For example, if the user’s download request triggers WiGig connection

establishment, it introduces additional latency due to the connection establishment

procedure. To minimize the latency, an application-centric connection management

scheme is newly proposed [MTN17].

Figure 2.1-6 shows a state transition diagram of the download application on the user

terminal, which consists of (a) content catalogue, (b) content details, (c) downloading

status, (d) download completed and (e) content playback.

When the user launches the application, the user terminal connects to the WiGig

signage via Wi-Fi, and the (a) content catalogue, which consists of preview thumbnails,

is displayed. When the user selects one of the available contents, the application

transits to display (b) content details. At the same time, the user terminal starts

connecting to the WiGig module in the WiGig signage. If the user presses the

download button, the application displays the (c) downloading status, and content

downloading begins. When downloading has finished, the application transits to show

(d) download completed, and the WiGig link is automatically disconnected. The user

may then proceed to view the content in (e) content playback.

I n sid e o f th e W iGig Sig n a g e

W iGigM od u le

W i-FiAP …

APC

Sto ra g e

( 1 )( 2 )

( 3 )

( 1 )

Figure 2.1-5 Block diagram of WiGig signage

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 13

Figure 2.1-6 State transition diagram of application

Figure 2.1-7 illustrates the operation steps. In the proposed method, the WiGig

connection is initiated when the user selects the content. Here we specify the required

time for WiGig connection as ΔT1, and the time lag between content selection and

pressing download button as ΔT2. Then, the WiGig connection is established in ΔT1.

When the user presses the content download button after ΔT2, the application starts

download without delay.

Based on our measurement results, the proposed method establishes the WiGig

connection before the download request with about 90% probability. Details will be

reported in the forthcoming deliverable D2.2.

Figure 2.1-7 Operation steps of application-centric connection management

(a) ContentCatalogue

(b) ContentDetails

(c) DownloadingStatus

(d) DownloadCompleted

Start

Connect Wi-Fi

Select Content /Start Connect WiGig

Back Button /Disconnect WiGig

Download Button

Finish Download /Disconnect WiGig

Cancel Button/Disconnect WiGig

Back Button

Play Button

(e) ContentPlayback

Back Button

Dow n loa dSta r t

Tim e[ s]

Th rou g h p u t[ Gb p s]

Con ten tSe lectio n

W iGigCon n ected : 1 /

D iscon n ected : 0

( a ) Con ten t Ca ta lo g u e

( b ) Con ten t Deta i ls

( c) Dow n lo a d in g Sta tu s

( d ) Dow n loa d Com p leted

⊿T1

⊿T2

Ap p l ica tio nSta te

Dow n lo a dCom p letio n

2

1

Tim e[ s]

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 14

2.2 Dynamic crowd

This use case focuses on a medium outdoor area located in the metropolitan city center

where thousands of people may spend part of their daily life. The area is characterized

by several possible outdoor hotspots like bus stops, stations and recreation parks. Users

at such outdoor hotspots might download large volume contents, such as tourist and

shopping information, high definition 3D live broadcast of a game happening at a

stadium nearby, or upload and share through social networking sites (SNS) photos and

videos recently taken nearby. They can also download multi-language information, 3D

indoor maps, shopping promotion video clips, 4K/8K live videos etc. for better

shopping experience at the next destination nearby e.g. shopping departments around

the Shibuya station.

Figure 2.2-1 Dynamic crowd use case

The significant difference of these use case against the other ones is that the traffic

pattern changes dynamically throughout a day, in accordance to users’ activities, e.g.

changing from light to very busy traffic in specific hours of a day. In such a dynamic

environment, network densification with many number of mmWave APs overlaid on

the current LTE cells is effective to accommodate traffic in peak hours.

However, the huge number of the needed APs in this use case leads to the problem of

high capital expenditure (CAPEX) and operating expense (OPEX). One solution to

relax the problem is to use mmWave meshed network for the backhaul network of APs,

as depicted in Figure 2.2-1. By using the mmWave meshed network, the CAPEX can

be reduced by removing deployment cost of wired backhaul. Furthermore, the OPEX

can also be reduced by introducing dynamic ON/OFF and flexible path creation in the

backhaul network in accordance with the time variant and spatially non-uniform traffic

distributions. Such flexible control of the backhaul network is enabled by Software

Defined Network (SDN) technology using out-band control interface over the LTE.

Figure 2.2-2 shows the 5G-MiEdge architecture for the outdoor dynamic crowd where

the wireless backhaul meshed networks are compliant to the 3GPP architecture. The

3GPP network provides both control plane and data plane for both UE and mesh

wireless backhaul. About mesh wireless backhaul, since mesh relay is yet to be

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 15

discussed in 3GPP for backhaul link, donor may be an anchor point of the relay

network. In this figure, the MSF collects the users’ context information (location, user

profiles, subscriptions etc.), as well as other content-related information, such as

content popularity, and data from the (mobile and fixed) MEHs to optimize the MEH

resource usage. The MSF also has a sub-function dedicated to controlling the local

mesh backhaul network. This sub-function collects context-information of the mesh

routers themselves e.g. location, radio link condition, link availability etc., to

dynamically construct the wireless backhaul, transferring data plane to the supported

UEs. Using these sub-functions and functions of MSF, data can be pre-fetched from

the AS to the MEH located at the small cell gateway.

Figure 2.2-2 System Architecture of ODC (3GPP case)

Figure 2.2-3 shows the signaling procedures. MSF collects the users’ context

information (location, user profiles, subscriptions), and other content-related

information (content popularity and data from the RAN’s MEH) to optimize the MEH

resource usage.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 16

Figure 2.2-3 Signalling of ODC (3GPP case)

In addition, MSF optimizes the mesh backhaul routes and informs the optimization

results to the donor. In the latter case, MSF similarly collects the users’ context

information and optimizes the (central and edge) MEHs resource usage. It also pre-

fetches data from the AS to the MEH.

Regarding the link budget of the mmWave backhaul links, it was concluded in the

MiWEBA project [MiWEBA D5.1] that from indoor and outdoor channel

measurements for 28 GHz - 100 GHz bands:

Rain/Oxygen seems to be no problem for inter site distance (ISD) < 200 meters

Path loss exponent might be similar as for lower frequency bands at line of

light (LOS) ~ 2.0, non-line of sight (NLOS) ~ 3.4-3.5, compared to free space

model

There is similar reflection loss as for lower frequency bands but much higher

diffraction loss

Blockage model is important and needs to be investigated further

Open issues are for example human body shadowing or reflections due to moving

vehicles or attenuation by dense vegetation in cities. More exploration is needed to

elaborate on whether mmWave systems are noise or interference limited.

In the MiWEBA project, FHG conducted supporting outdoor channel measurements

for the street canyon reference scenario. It implemented ray-tracing models for the

street canyon propagation scenarios accordingly and simulated them. A feedback loop

with Intel equipment was established to evaluate measurement and simulation data,

extract channel parameters for characterization of the channel, and verify and calibrate

the simulation data further. Analysis of this data proves the feasibility of mmWave

small cells but at the same time the high time variance of the propagation channel. This

high time variance is caused by movement of the UE itself as well as pedestrians and

cars moving by. These effects and strategies to establish stable connections using

electronically steerable antennas or BF antennas have also been investigated

[MiWEBA D5.2, D5.3, and D5.4].

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 17

Orange did experimental measurements in order to develop models in the frequency

band 40 and 60 GHz for both indoor and outdoor environments as well. Focus was on

the development of path-loss models integrating rainfall effects, Oxygen absorption

and bandwidth impact. A similar conclusion that mmWave backhaul link of short

distance was not affected significantly by the effect of rain attenuation was also drawn.

Furthermore, KLAB also provided data that for 60GHz fronthaul link, the link length

to be supported under strong rain of 20mm/h with probability of 99.97% was 1500m

without FEC and 5000m with FEC, which is quite longer than the expected backhaul

link length of up to 100m [MiWEBA AR10.1] experience in the 5G-MiEdge project.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 18

2.3 Autonomous driving

Automated driving is considered as one of the three most important use cases of future

5G systems [5GPPPWP AV]. The 1st phase of 5G Vehicle-to-Vehicle (V2V) and

Vehicle-to-Everything (V2X) communications aims at driver assistance systems and

exchanges messages either directly between vehicles or via appropriate infrastructure

[TR22.885]. These messages are transmitted in case of an emergency or as so-called

awareness messages, which contain information such as location, speed and heading

direction. However, the 2nd phase of 5G V2X aims for automated driving applications,

where automated control software becomes primarily responsible for monitoring the

environment and the driving vehicles, referred to as Levels of Automation (LoA) in

the range 3 to 5 [SAE].

Target scenarios for automated driving considered in this project are complex urban

city environments as in Figure 2.3-1, where many invisible hidden objects exist behind

buildings and tracks as well as unexpected and unequipped bicycles and pedestrians.

In such a complex environment, it is likely that Roadside Units (RSU) are deployed to

monitor the latest traffic conditions by cameras and LiDAR (Light Detection And

Ranging) sensors. However, this information in the RSU are not fully utilized to assist

driving for safety purpose so far.

Figure 2.3-1 Automotive traffic scenarios in urban city environments

Automated driving systems require highly resolved and dynamic maps in order to

maneuver vehicles safely. Since the resolution of current maps used for car navigation

is definitely not sufficient, high resolution and real-time maps, also called dynamic

High Definition (HD) maps, become indispensable [SH16]. Figure 2.3-2 shows an

example of HD map generated with a LiDAR sensor, which is used to monitor the car

surroundings and display the same as a high-resolution and real-time point cloud. Even

though the final values depend on the resolution of the actual HD map, an estimation

of 1 Gbps appears reasonable as a typical data rate requirement for exchanging HD

map information via V2V/V2X links. Indeed, mmWave seems to be the most

convenient means to provide such high data rates for multiple V2V/V2X links

coexisting in the scenario [CVG16].

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 19

Figure 2.3-2 HD map measured by LiDAR as a high-resolution point cloud

[SH16]

Cooperative perception of HD maps using extended sensors

In complex urban city scenarios, self (egocentric) perception based automated driving,

as in [Ang13], cannot work anymore due to many invisible hidden objects. Therefore,

automated vehicles require helps from sensors located at RSUs as electrical mirror in

addition to the sensors equipped in the surrounding vehicles. Cooperative perception

is realized by exchanging sensor data between vehicles and RSUs and is necessary in

order to widen or enhance the visibility area of HD maps [KQC15] [HFL15]. This

concept allows a more accurate localization of objects and more important, due to a

superior bird's eye view, prevents that objects remain not visible and undetected, due

to the ego-perspective of the sensors mounted on the vehicle. This external object

detection capability is particularly critical for a safe realization of automated driving

in complex urban scenarios. Figure 2.3-3 shows an example of cooperative perception

in an urban city scenario. A sensor located at a RSU on a traffic light in front and a

sensor located on vehicles in front are orchestrated and used for cooperative perception

to realize safe automated driving.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 20

Figure 2.3-3 Cooperative perception for automated driving

mmWave based V2V/V2X for extended sensors

Based on the results provided in [D1.1], the enhanced V2V/V2X communication

targeting at automated driving requires a data rate of 1Gbps per link, end-to-end

latency of less than 10 ms per link and a communication range of more than 150 m, in

order to put safe automated driving into practice by exchanging raw (or lightly

processed) sensor data. Such high requirements cannot be realized with current

technologies [TR22.885]. Hence, 3GPP initiated related work in Release 15 and

beyond, which is named eV2X (enhanced V2X) [TR22.886]. Consequently, the

utilization of mmWave and MEC technologies are becoming increasingly important

for the field of automated driving.

Figure 2.3-4 shows an example of a system diagram proposed in [KS17] [D1.1] for

mmWave based V2V/V2X in order to realize a real-time exchange of HD maps

between On-Board Units (OBUs) mounted in vehicles and RSUs. All communication

links between OBUs and RSUs are directly connected through proximity-based

services, namely Device-to-Device (D2D) communication, as specified in [TS23.303].

However, differently from standard D2D, this V2V/V2X system uses mmWave

channels to fulfill the requirements of 1 Gbps data rate and less than 10 ms latency.

The communication range of mmWave links can be extended to more than 150 m, if

highly directional antenna beams are used. One challenge in this system might be the

antenna beam alignment between OBUs and RSUs, however [VSB16] [CVG16] show

the feasibility of using mmWave in vehicular scenarios. The system coexists with the

conventional V2X system [TR22.885], which supports cloud-based services such as

traffic jam forecast and long-range traffic navigation.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 21

Figure 2.3-4 mmWave based V2V/V2X for cooperative perception

A block diagram of OBU and RSU is shown in Figure 2.3-5, where the difference

between the OBU and RSU is solely the automated driving unit. The OBU/RSU

receives the HD maps from surrounding OBU/RSUs via mmWave V2V/V2X links

and fuses them with its own HD sensor data in the HD map-processing unit. This

process corresponds to the cooperative perception. This combined HD map with its

widened visibility area is used for automated driving decisions and in addition is

transferred to neighboring OBU/RSUs. However, before transmitting the fused HD

map, the HD map processing unit selects the area of interest (or control resolution of

HD map area by area) dependent on the location of receiver OBU/RSUs to avoid

exponential increase of data rate. The OBU/RSU is a unification of mmWave and MEC,

since the HD map-processing unit is considered as MEC to compute cooperative

perception at the edge of the network.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 22

Figure 2.3-5 RSU and OBU composed of mmWave and MEC

System architecture and signaling for the automated driving use case

Figure 2.3-6 shows a refined system architecture proposed by the 5G-MiEdge project

for automated driving use case developed in [D1.3]. The OBU installed in vehicles is

composed of sensors (e.g. LiDAR), MEH, and UE. On the other hand, there are two

options in the RSU. The one is UE type similar with the OBU consisting of sensors,

MEH, and UE. The other is BS type consisting of sensors, MEH, UPF, and RAN. In

the case of the UE type, the OBU/RSU receives the HD maps from surrounding

OBU/RSUs via V2V/V2X links using mmWave PC5 interface. In the case of BS type,

the V2X links between RSU and OBU are established by mmWave Uu interface. The

cooperative perception application deployed in the MEH fuses the received HD maps

with its own HD sensor data for extending visibility area of the HD map to be used for

safety driving.

Figure 2.3-6 Refined system architecture for automated driving

Figure 2.3-7 shows a refined signaling for automated driving. When users buy vehicles

with an option of the cooperative perception, the UE triggers MEC (V2X) registration

to the MSF via NO1 interface, and MEC (V2X) service activation to the AS via NO2

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 23

interface. Then the AS updates the service information managed in the MSF located in

the 5G core. The MSF allocates MEC resources in the MEHs via NL2 interface for the

cooperative perception application. In the case of BS type RSU, the AS deploys the

cooperative perception application to the RSU via N6 and N9 interfaces. In the case of

UE type RSU and the OBU, the cooperative perception application is deployed via Uu

from either macro BSs or the RSUs. In the case of isolated area without 5G network

operator, the cooperative perception application can also be deployed via PC5 interface

from other RSUs or OBUs as ad-hoc mode. During driving of vehicles, the ProSe

function [TR23.703], or Access and Mobility management Function (AMF), collects

context information, e.g. vehicle locations, service profiles, and subscriptions to

control the mmWave PC5 by using the PC3 interface over sub-6 GHz C-plane from

macro BSs for ensuring the cooperative perception service.

Figure 2.3-7 Refined signalling for automated driving

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 24

3 Design and analysis for site specific deployment of

mmWave edge cloud

Site specific deployment of mmWave edge cloud systems needs careful planning and

evaluation of the used concepts and technologies. In this section we explain three key

design components:

Modeling and optimization of multi RAT HetNet

Interference management in mesh backhaul networks

Dynamic resource allocation, considering the best trade-off between queues

and power consumption

3.1 Modeling and optimization of multi RAT HetNet

Figure 3.1-1 multi RAT HetNet system model

In the previous deliverable D2.1 [D2.1], we have focused on the analysis of coverage

aspects for a heterogeneous network characterized by multiple RATs. We now take

into account cell loads to show how tier and RAT selection biases can improve the user

average throughput.

Past researches have characterized the load by using the average number of associated

users in a cell [Elshaer2016]; however, we have provided a more realistic

characterization by considering a dynamic traffic model. In addition, in contrast with

the literature, we have optimized the user throughput while considering signal-to-

interference-plus-noise ratio (SINR) outage constraints as well as overloading

constraints.

3.1.1.1 Cell load characterization

We consider a model in which users arrive in the system, download a file, and leave

the system. Any new download by the same user is considered as a new user. The

arrival process of the new users is Poisson distributed with an intensity λ

[users ·s−1·m−2] and these new users are uniformly distributed over the network area

A. The average file size is σ [bits/user]. When there are n users simultaneously served

by a BS, the available resources are equally shared between them in a Round Robin

fashion.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 25

According to our model of the traffic arrival process, the traffic density is given as

w = λ ⋅ σ [bits/s/m2]. For a single cell scenario, the load of the cell of area A can be modelled as

𝜌 = ∫𝑤

𝑅(𝑠)A

ds,

where R(s) is the physical data rate of a user located at s.

In case of Poisson-Voronoi cells, the average load is generally difficult to evaluate

because of the randomness in the shape and sizes of the cells. Furthermore, in a multi-

cell scenario, the load of a cell depends on the SINR characteristics of the cell, which

in turn, depends on the load of the other cells in the network.

We know from the ergodicity of the Poisson Point Process (PPP), that the fraction of

the BS of type tvr that are idle is equal to the fractional idle time of the typical BS of

same type. Here 𝑡 ∈ {𝑀, 𝑆}, 𝑣 ∈ {𝐿, 𝑁} and 𝑟 ∈ {𝑚, 𝜇} represent the tier (Macro base

station, MBS, and Small cell base station, SBS), visibility state (LOS, NLOS) and RAT

(mmWave, sub-6GHz) respectively. Accordingly, assuming that the load of the typical

BS of type tvr is given by �̅�𝑡𝑣𝑟. Then, the fraction of idle BS of type tvr is given by 1-

�̅�𝑡𝑣𝑟. We substitute this value for all tvr in the calculation of the load as

�̅�𝑡𝑣𝑟 = ∫𝑤𝐴𝑡𝑣𝑟

𝐵𝑟𝑙𝑜𝑔2(1 + 𝛾)𝑝𝑡𝑣𝑟(�̅� , 𝛾) 𝑑𝛾

𝐴

,

where the pdf of the SINR (𝑝𝑡𝑣𝑟(�̅� , 𝛾)) is a function of the average idle fraction

of the BS and �̅� is a vector of the fraction of idle BSs of all BS types, i.e., �̅�= [�̅�𝑡𝑣𝑟]

for all tvr. 𝐴𝑡𝑣𝑟 is the area of the typical cell of type tvr, and 𝐵𝑟 is the bandwidth of the

RAT r. This fixed-point equation is then solved in an iterative manner to obtain the actual load

of the BS of all the tiers (starting from zero load). Then, the SINR coverage probability

at a threshold γ with 1 - �̅�𝑡𝑣𝑟 fraction of BSs idle, given that the user is associated with

a sub-6GHz BS of tier t and visibility state v, is given by

P𝐶𝑡𝑣𝜇 (�̅�, γ) = ∫ exp ( −γ ⋅ σN,μ2 ⋅ x −∑𝐴𝑡′𝑣′ (𝛾, 𝑥, 𝜌𝑡′𝑣′𝜇 ))

t′v′

0

fξtvμ1(x)dx

where,

𝐴𝑡′𝑣′(𝛾, 𝑥, 𝜌𝑡′𝑣′𝜇) = ∫𝛾𝑥

𝑦+𝛾𝑥

𝑙𝑡′ Λ𝑡′𝑣′𝜇′ (𝑑𝑦, 𝜌𝑡′𝑣′𝜇), ∀ 𝑡

′ ∈ {𝑀, 𝑆}, 𝑣′ ∈ {𝐿, 𝑁}.

Additionally, 𝑙𝑡′= x if 𝑡′ = 𝑡, 𝑙𝑡′ = 𝑄𝑇 ⋅ 𝑥, when 𝑡 = 𝑀 and 𝑡′ = 𝑆 and 𝑙𝑡′ =𝑥

𝑄𝑇

when 𝑡 = 𝑆 𝑎𝑛𝑑 𝑡′ = 𝑀. Here QT is the tier selection bias and fξtvμ1(x) is the

distance distribution of the strongest BS of type tvr. σN,μ2 is the noise in the sub-6

GHz band.

The intensity measures Λtvr are obtained by modifying 𝜆𝑡𝑣𝑟 to 𝜆𝑡𝑣𝑟𝜌𝑡𝑣𝑟 to the

expressions for intensities in Eq. (2) in [Ghatak2018] for each BS type. The calculation

for the mmWave BS follows in the same way.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 26

It should be noted that in case of a Poisson distributed network, there exists a non-zero

fraction of unstable cells (𝜌 < 1), which cannot handle their load.

3.1.1.2 Analysis of the bound on overloading probabilities

In this section, we investigate the relation between the cell overloading probabilities

and the traffic density, based on the analytical bound derived in the Lemma 1

[Ghatak2018].

LEMMA 1: The probability of a typical cell of type tvr to be unstable is bounded as

𝑃(𝜌𝑡𝑣𝑟 ≥ 1) ≤ min {𝜎𝑡𝑣𝑟2

(1 − �̅�𝑡𝑣𝑟)2, �̅�𝑡𝑣𝑟 } .

Where, 𝜎𝑡𝑣𝑟2 = 𝐸[𝜌𝑡𝑣𝑟

2 ] − �̅�𝑡𝑣𝑟 is the variance of the load, which can also be

calculated, similar to �̅�𝑡𝑣𝑟 by using the SINR coverage probability of the typical user.

Figure 3.1-2 Tightness of the bound on probability of overloading

We can now investigate the relation between the cell overloading probabilities and the

traffic density, based on the analytical bound derived in Lemma 1.

Let 𝜆𝑆

𝜆𝑀 represents the number of small cells deployed for each macro cell. We see in

Figure 3.1-2 that for 𝜆𝑆

𝜆𝑀= 5 the proposed bound is relatively loose, but it provides the

operator the guarantee that the overload probability will not exceed this value.

Based on this bound and a constraint on the overall outage probability, a conservative

network sizing can be derived.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 27

Figure 3.1-3 Minimum required deployment density for a given traffic density

In Figure 3.1-3, we show the minimum small cell deployment density required such

that feasible biases exist to meet both theses constraints. The more stringent the

constraints are, the more SBSs the operator should deploy. When the traffic density is

low, the outage probability is the limiting constraint and accordingly, the minimum

deployment density is the one required to maintain coverage. However, as traffic

density increases, overloading probability is determining the required number of small

cell to comply with the system requirements.

3.1.1.3 Average user throughput

The average downlink throughput that a user receives from a BS of type tvr is

𝑇𝑡𝑣𝑟 = 𝑤 𝐴𝑡𝑣𝑟𝑁𝑡𝑣𝑟

,

where 𝑁𝑡𝑣𝑟 is the average number of active users in a cell, which can be approximated

by using the mean cell approach. The mean cell is defined as a hypothetical cell that

has the same average load as that of a typical cell.

Lemma 2: The downlink average user's throughput in a non-overloaded mean cell of

type tvr is [Ghatak2018]

𝑇𝑡𝑣𝑟 = 𝜆𝜎1 − �̅�𝑡𝑣𝑟�̅�𝑡𝑣𝑟

𝐴𝑡𝑣𝑟

The average user throughput is then given by theorem of total probability as

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 28

𝑇 = ∑ 𝑃𝑡𝑣𝑟𝑇𝑡𝑣𝑟𝑡𝑣𝑟 .

Due to the different operating bandwidths, the bias values that provide the optimal user

throughput may lead to weak SINR, which in turn increases the outage. Thus, to

guarantee the communication reliability, it is necessary to consider an SINR constraint

on the selection of the optimal biases. We define the outage probability with respect to

a SINR threshold 𝛾 as

𝑃𝑜,𝑡𝑣𝑟(𝛾𝑚𝑖𝑛) = 1 − 𝑃𝐶𝑡𝑣𝑟(𝛾𝑚𝑖𝑛).

Therefore, we introduce the notion of effective throughput, which measures the

throughput of the users, which are not in outage, as

𝑇𝑒𝑓𝑓(𝛾𝑚𝑖𝑛) = ∑𝑃𝑡𝑣𝑟𝑇𝑡𝑣𝑟𝑃𝐶𝑡𝑣𝑟(𝛾𝑚𝑖𝑛)

𝑡𝑣𝑟

In our work, we optimize 𝑄𝑇 and 𝑄𝑅 so as to maximize the average effective user

throughput 𝑇𝑒𝑓𝑓(𝛾𝑚𝑖𝑛) under the constraint of a maximum outage probability

𝑃𝑜,𝑡𝑣𝑟(𝛾𝑚𝑖𝑛) ≤ 𝑃0

for every BS type tvr.

3.1.1.4 Rate optimal choice of tier and RAT selection biases

In this section, we discuss optimal tier and RAT selection biases with respect to the

average effective throughput. To guarantee a good coverage, we impose a constraint

on the outage probability (from 7.5 to 12.5%).

Figure 3.1-4 Throughput optimal MBS association probabilities

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 29

The MBS association probability corresponding to the optimal QT as a function of the

traffic density is shown in Figure 3.1-4. Depending on the ratio of densities, users are

offloaded from MBS to SBS (for low SBS densities) or vice-versa (for high SBS

densities).

Figure 3.1-5 Optimal downlink user throughput

In Figure 3.1-5, we show the optimal effective downlink throughput as a function of

the traffic density for various deployment densities and outage constraints. We observe

that more stringent outage constraints result in lower downlink throughput in the

network. This is because biases are mainly optimized to guarantee coverage also for

cell edge users. We also observe that increasing the SBS density not only results in

higher throughput, but also increases the range of traffic densities that the network can

serve, i.e., the network capacity. In this evaluation, we have obtained the downlink

throughput by considering that the users in overloaded BSs receive zero throughput.

Therefore, even though the network as a whole can serve traffic densities up to 1

Gbps/m2, the MBS tier is overloaded for much lower traffic densities. Accordingly,

the network is no longer well dimensioned for the region of traffic densities beyond

the MBS overloading points.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 30

Figure 3.1-6 Optimal association probabilities for different outage probability

constraints

Furthermore, in Figure 3.1-6, we plot the optimum association probabilities as a

function of outage probability with λS

λM = 50 and traffic density of 200 bits/s/m2. We

see that for more stringent outage constraints, sub-6GHz service in SBSs becomes

necessary, in addition to mmWave service, to satisfy the QoS constraints of outage

and overloading simultaneously, thus justifying the interest of deploying dual band

SBSs.

Figure 3.1-7 Effective user throughput for λ_S/λ_M =200

As a conclusion, in dense SBS deployments (see Figure 3.1-7), the users do not suffer

from outage even in the case of high tier biases. In this case, QR should be high enough

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 31

to maximize the mmWave association probability. In case of λS

λM = 200, this results in

a maximum throughput of around 30 Gbps at QT = 10 dB and QR = 6 dB.

Figure 3.1-8 Effective user throughput for λ_S/λ_M =50

In sparse SBS deployments (Figure 3.1-8), high values of QT are desirable to offload

traffic from overloaded MBSs. However, as the SBS ranges increase, mmWave

becomes unattractive for users at the SBS cell edges. We can observe that increasing

QR beyond a certain limit pushes the SBS users in outage, thereby decreasing the

effective throughput. The maximum average throughput in this scenario, considering

the regime of biases where the MBS tier is not overloaded, is 10 Mbps at QT = 6 dB

and QR = 3 dB.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 32

3.2 Interference management in mesh backhaul networks

3.2.1 Interference management methods

The mmWave overlay HetNet is an architecture that fits the requirements of enhanced

Mobile Broadband communication. Such architecture is composed of conventional

LTE macro cell BS covering a wide area, and many mmWave APs within the coverage

area. However, when all backhaul link apply wire connections, backhauling

connection cost becomes too high. Consequently, there is the need to look at other

more advanced kind of architectures, in order to reduce the installation costs.

The mmWave mesh backhaul networks (MMBNs) is one of those advanced

architectures that can cope with the varying traffic by connection flexibility. MMBN

assumes the existence of many links. In the real environment, interference often

happens, with the consequence that the maximum achievable system rates become

worse, due to the irregular building placement. We focus in this subsection therefore

on interference management for MMBN networks, e.g. new design rules for mmWave

APs deployment.

Optimization for interference management of MMBN, including node placement,

channel selection and beam steering, is an NP-hard problem, due to the large number

of involved unknown parameters. Therefore, we proposed a heuristic approach, which

can achieve reasonable performance via three steps i.e.

Mesh node deployment

Channel assignment

Best beam selection and power allocation

Figure 3.2-1 shows some of the most important interference management methods.

When mmWave APs are deployed linearly, antennas establishing links face each

other directly. Interference component is attenuated only as a function of distance

separation between links. Therefore, bad SINR performance is expected in this

scenario. However, when mmWave AP are deployed in zigzag as our proposal,

antennas establishing links do not face each other. Through this angular

manipulation, the largest interference component from the adjacent hop is

expected to be reduced.

We assume IEEE802.11ad standard for mmWave access and backhaul owing to

its available broadband. The band is divided into 4 channels. We assume access

and backhaul links use each 2 channels to avoid their mutual interference. For

backhauling channel allocation, the complexity of a full search will increase

exponentially against the total number of backhaul links that is not feasible for

dynamic network formation in practice. We propose a sub-optimal heuristic

approach to tackle the above issue. First, the channel allocation at the GW with

multiple sectors (interfaces) each connecting to different route is decided by an

exhaustive search to maximize the minimum SINR among the interfaces, knowing

that the interference component here is between different sectors of the GW.

Second, for each route departing from the GW, since interference from adjacent

hop has been reduced significantly owing to the zigzag deployment explained

above, there is no necessary to switch the channel by each hop.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 33

MmWave communication assumes LOS connection between mmWave APs via

beam-forming (BF). Beam steering functionality is therefore available in most of

mmWave devices. We employ such functionality as one of the methods to avoid

interference. Specifically, the networks select beams via wall reflection instead of

the normal direct beam when necessary to avoid explicit interference, at especially

intersection of roads where multiple routes overlap.

Multi-hop relay capacity is defined as the link with lowest data rate (or

equivalently lowest SINR) called the bottleneck. Such bottleneck can be

efficiently alleviated by applying proper power allocation at each hop, to

maximize the minimum SINR link along the target route.

Figure 3.2-1 Interference management methods

3.2.2 MMBN architecture

In this work, we assume that the network is composed of only one macro cell. LTE

macro cell BS originally plays both roles as U-plane supplying data to UEs and C-

plane controlling the communication quality. This work assumes C/U-splitting

architecture such that LTE macro cell which employs microwave band and has large

coverage is responsible for only the C-plane of the network e.g. association between

UE and AP, mesh backhaul construction between APs including channel allocation,

beam selection and power allocation. On the other hand, U-plane is offloaded to the

access interfaces of mmWave APs. MmWave GW is the only small cell BS (AP) with

high-speed wired backhaul working as the gateway for MMBN to the core network.

In other words, it plays a role as the U-plane source for all other mmWave APs. This

work assumes the GW with ideal wired backhaul has several sectors, which can

simultaneously connect to different interfaces of mmWave APs via multi-hop relay to

enable route multiplexing. Figure 3.2-2 depicts a typical MMBN architecture.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 34

Figure 3.2-2 MMBN architecture

3.2.3 MmWave AP deployment

We assume that MMBN is deployed at ground level as seen in Figure 3.2-3. MmWave

APs are assumed to be attached on street lampposts taking into account realistic

environments. The height of lampposts are set as 6m and the width of road with two

traffic lanes is about 6m.

Figure 3.2-3 Street model and deployment of mmWave APs

Received Signal Strength Indicator (RSSI) changes by not only deployment of

mmWave APs but also transceivers’ angular alignment, since BF is employed in

mmWave communication for compensating propagation loss. When mmWave APs are

deployed linearly, antennas establishing links face each other directly. Interference

component is attenuated only as a function of distance separation between links.

Therefore, bad SINR performance is expected in this scenario. However, when

mmWave AP are deployed as we propose in this paper (see Figure 3.2-3), antennas

establishing links do not face each other. Through this angular manipulation, the

largest interference component from the adjacent hop is expected to be reduced.

Therefore, mmWave APs are deployed not facing one another both vertically (at

4m/6m heights of lampposts successively) and horizontally (on each side of the road

respectively), as shown in Figure 3.2-3.

Owing to such zigzag deployment, nulls are almost steered to the adjacent hop to

reduce interference. This section explains this effect mathematically. Using antenna’s

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 35

beam pattern as an approximation of a sinc function, the half-width is given by road

width, height of APs and distances among them as follows

𝑃r(𝜙) = |𝐸0′ |2 sinc2 (

𝑘𝐷𝐴2sin𝜙)

where 𝑃r is the antenna direction gain, |𝐸0′ | is the maximum complex amplitude, 𝑘 is

the wavenumber, 𝐷𝐴 is the antenna separation and 𝜙 denotes angle deviation from the

beam axis. We establish the following relationship, letting the half-power beam width

of azimuth direction and the first null direction be denoted as 𝜙−3dB and 𝜙α

respectively,

𝜙−3dB = 0.88𝜆

𝐷𝐴

𝜙α ≡1

0.88𝜙−3dB =

𝜆

𝐷𝐴

By substituting the road width of 6m and lamppost interval of 50m to the above

equation, we derive that the LOS beam will not interfere the adjacent hop if 𝜙−3dB ≤5deg is designed. In addition, the antenna direction gain can be approximated by the

following equation

𝐺 ≅4π

𝜃−3dB𝜙−3dB

where 𝜃−3dB is the elevation half-power beam width.

3.2.4 Channel assignment

This work utilizes the IEEE 802.11ad (WiGig) standard for mmWave access and

backhaul owing to its available broadband. The band is divided to 4 channels. This

work assumes access and backhaul links use each 2 channels to avoid their mutual

interference. For backhauling channel allocation, a full search will require 𝑁CH𝑁LINK

times of measurement, where 𝑁CH= 2 is the total number of channels available for

backhaul and 𝑁LINK is the total number of backhaul links. Since the search

exponentially increases against the number of links, it is not feasible for dynamic

network formation in practice. This work proposes a sub-optimal heuristic approach

to tackle the above issue. First, the channel allocation at the GW with multiple sectors

(interfaces) each connecting to different route is decided by an exhaustive search to

maximize the minimum SINR among the interfaces, knowing that the interference

component here is between different sectors of the GW. Second, for each route

departing from the GW, since interference from adjacent hops has been reduced

significantly owing to the zigzag deployment explained above, there is no necessary

to switch the channel by each hop. Against this conventional approach, this paper

proposes to switch the channel by every two hops as depicted in Figure 3.2-4.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 36

Figure 3.2-4 Street model and deployment of mmWave APs

3.2.5 Beam selection

MmWave communication assumes LOS connection between mmWave APs via BF.

Beam steering functionality is therefore available in most of mmWave devices. This

work employs such functionality as one of the methods to avoid interference in

MMBN. Specifically, the networks select beams via wall reflection instead of the

normal direct beam when necessary to avoid explicit interference.

For the sake of low complexity, such mechanism is only conducted at intersection of

roads. We store up to three candidates of strong azimuth beam directions beforehand

to realize real-time search. Elevation angle search is not necessary in this work due to

restricted height difference of antenna on the lampposts.

3.2.6 Power allocation

Multi-hop relay capacity is defined as the link with lowest data rate (or equivalently

lowest SINR), which is called the bottleneck. On the other hand, such bottleneck can

be efficiently alleviated by applying proper power allocation at each hop. Since this

paper assumes SDN-controlled MMBN by C-plane of the LTE macro cell, centralized

optimization of power allocation is possible at the macro BS based on link channel

condition feedbacks from mmWave APs. For each route of MMBN, we define the link

gain from the transmitter of the 𝑗th link to the receiver of the 𝑖th link as 𝑔𝑖𝑗 the SINR of

each link as 𝛾. The SINR 𝛾 can be calculated as the follows

𝛾(𝑖) =𝑔𝑖𝑖𝑝𝑖

𝑃n + ∑ 𝛿𝑖,𝑗𝑔𝑖𝑗𝑝𝑗𝑗≠𝑖=

𝑃𝑖𝑖𝑃n + ∑ 𝛿𝑖,𝑗𝑃𝑖𝑗𝑗≠𝑖

where 𝑝𝑖 denotes the transmit power of the the 𝑖th link, 𝑃𝑖𝑗 denotes the received power

observed at the receiver of the 𝑖th link from the transmitter of the 𝑗th link. 𝛿𝑖,𝑗 is the

Kronecker-Delta which has unit value if the two links use a same channel frequency

and zero otherwise. When the noise power 𝑃n is negligible compared to the

interference power ∑ 𝛿𝑖,𝑗𝑃𝑖𝑗𝑗≠𝑖 , which is the case of our MMBN, the SINR can be

approximated as the SIR (Signal-to-Interference-Ratio) 𝛾𝑖′. Ignoring the noise term,

the above equation can be rewritten as follows

∑𝑔𝑖𝑗

𝑔𝑖𝑖𝑝𝑗

𝑗≠𝑖

=𝑝𝑖𝛾𝑖′ = 𝜏𝑖𝑝𝑖

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 37

where 𝜏𝑖 is the inverse of SIR, which can be interpreted as the Error Vector Magnitude

(EVM). Thus, the power allocation can be solved by the following optimization

problem,

find : 𝒑 ∈ ℝ𝑁Link

minimize : 𝜏

subject to : 𝑨𝒑 = 𝜏𝒑

0 < 𝑝𝑖 ≤ 𝑝max

where 𝒑 = [𝑝1, 𝑝2, … , 𝑝𝑁Link ]𝑇 ∈ ℝ𝑁Link is the power transmission vector, and 𝑨 ∈

ℝ𝑁Link×𝑁Link with 𝑎𝑖𝑗 =𝑔𝑖𝑗

𝑔𝑖𝑖 and 𝑎𝑖𝑖 = 0 is defined as the interference matrix. We can

calculate 𝜏 as the maximum eigenvalue 𝜆max of the matrix 𝑨.

𝜏 = 𝜆max(𝑨) = max{𝜆(𝑨)}

The optimal power allocation is therefore given via the corresponding eigenvector

taking into account the power constraint.

3.2.7 Simulation model

Performance evaluation of the proposed algorithm for MMBN is conducted via ray-

tracing simulation. The ray-tracing simulation model is explained in this section as

depicted in Figure 3.2-5. In this document, we assume MMBN are deployed in an

environment with intensive user distribution. Terrain model is made in reference to

Shibuya, a crowded station in Tokyo and mmWave APs are deployed approximately

every 50 m, based on lampposts placement. The conventional approach is defined as

linear deployment of mmWave APs (green points), while the proposed approach

applied zigzag deployment (red points).

Figure 3.2-5 Terrain model for simulation

Table 3.2-1 shows each used simulation parameter. These parameters refer to the IEEE

802.11ad standard. The number of paths and APs are set to 25 and 28, respectively.

Dielectric constant and conductivity of concrete are set in reference to mmWave. Beam

selection techniques in Section 3.2.5 are used at intersection areas marked by blue

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 38

circle in Figure 3.2-5 in only case of applying route multiplexing as explained later in

Section 3.2.8.

Table 3.2-1 Simulation parameter

Parameter Value

Carrier freq. 60 GHz

Bandwidth 2 × 2.16 GHz

Link Down

Tx power 10 dBm

Antenna gain 32 dBi

Half width of azimuth 5 deg

Half width of elevation 5 deg

Propagation loss 20 log10(4𝜋𝑑 𝜆⁄ )

Dielectric constant 3.3

Conductivity 0.015 S m⁄

Noise power density −174 dBm/Hz

Noise factor 10 dB

We compute throughput of backhaul links by mapping MCS and the achieved SINR

𝛾𝑖 . Due to multi-hop relay, the performance of the network is evaluated at the

bottleneck link. We compare with the conventional approach with linear node

deployment and therefore channel switching per every two hops.

3.2.8 Simulation results

Scalabilities of the proposed mechanism are evaluated in two scenarios i.e. without

and with route multiplexing. In the former, route multiplexing is not applied and we

evaluated bottleneck link capacity when each multi-hop route is extended radially far

from the GW. In the latter case of with route multiplexing, certain APs are assumed to

be sink nodes, while the others only play the role of relay nodes. For each sink node,

we assume that source information from the GW are relayed to each sink node via two

route multiplexing. Numerical results are summarized in Figure 3.2-6, where the x-

axis shows the AP distance from GW and the y-axis shows the bottleneck capacity up

to that distance. The maximum achievable throughput of each link is upper bound by

6.76 Gbps according to the IEEE 802.11ad standard.

(a) Without route-multiplexing scenario

Figure 3.2-6 (a) shows that the conventional approach cannot reduce interference

effectively, because mmWave APs were deployed linearly. On the other hand, the

proposed approach can alleviate interference up to 250 m from mmWave GW. In

other words, the effect of the proposed interference mechanism was confirmed.

(b) With route-multiplexing scenario

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 39

(a) Without route multiplexing

(b) With route multiplexing

Figure 3.2-6 Coverage-Throughput relationship

Since two-route multiplexing is considered in this scenario, the maximum throughput

becomes 13.5 Gbps, which doubles the upper bound in the case of single route. As

shown in Fig. Figure 3.2-6 (b), throughput achieved only about 10 Gbps in

conventional approach. That is due to intra-route and inter-route interference that could

not be tackled by the conventional scheme. On the other hand, throughput was about

13.5 Gbps in the proposed approach. The result again confirms the effectiveness of the

proposed mechanism for interference management in even multi-route multiplexing

scenario.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 40

3.3 Dynamic resource allocation, considering the best trade-off

between queues and power consumption

3.3.1 Introduction

In this section, we present an approach for dynamic resource allocation for

computation offloading, building on the tools of Stochastic Optimization [NEE10].

Computation offloading aims at transferring applications from the mobile devices to

the MEH to reduce the device power consumption and enable low latency execution

of computationally heavy tasks. Our previous approaches, such as [BAR17] and

[SMB18], are static and the optimization is performed for a given application and

system state, considering that the computation requests and the corresponding bits to

be transferred for the offloading are known in advance. This new study is useful for

those applications in which computation demands are generated continuously at the

mobile side, and the arrival probabilities of such requests are unknown. In this case,

the evolution of the system in terms of computation queues, radio channels, user’s

position etc. is taken into account in the optimization. It will be shown that a per-slot

optimization, based on this current state information, can achieve good performance

in terms of long-term average transmit power while stabilizing the computation queues.

A trade-off between power consumption and queue lengths (i.e. execution delay) is the

main goal of this investigation. The approach is based on the recent work [MAO17],

in which the authors aim at minimizing the long-term average weighted sum power

consumption of both the mobile device and the MEH, under the constraint of keeping

the computation queues stable. The power consumption is considered the one for

transmission plus the one for local execution. In particular, we suppose that tasks can

be split into an arbitrary number of subtasks, so that the execution is split into a local

execution (at the mobile side) and a remote execution (at the MEH). Then, in each time

slot, a decision is taken to split the application and to allocate radio and computation

resources for the execution.

3.3.2 Problem formulation and proposed solution

We consider a scenario with 𝐾 mobile users and 𝑁 AP’s and 𝑁 MEHs, each of them

associated to one pair AP-MEH. Each user can access a single AP to offload part of its

computation tasks through a certain AP to its associated MEH. The optimization,

which will be described further in this section, is performed in a per-slot fashion. In

time slot 𝑡, the association of a generic user 𝑘 to the pair AP-MEH 𝑛 is described by

the assignment variable 𝑎𝑘𝑛(𝑡) as follows

{𝑎𝑘𝑛(𝑡) = 1, if user 𝑘 is assigned to the pair AP − MEH 𝑛𝑎𝑘𝑛(𝑡) = 0, otherwise

For the communication part, we denote by ℎ𝑘𝑛(𝑡) the channel power gain between

user 𝑘 and AP 𝑛 , by 𝑝𝑘𝑛(𝑡) the transmit power used for the uplink transmission of

offloaded tasks, and by 𝛼𝑘𝑛(𝑡) the fraction of the bandwidth allocated to user 𝑘 during

time slot 𝑡. Then, the maximum transmission rate during time slot 𝑡 can be written as

𝑅𝑘𝑛(𝑡) = 𝛼𝑘𝑛(𝑡) 𝐵 log2 (1 +ℎ𝑘𝑛(𝑡)𝑝𝑘𝑛(𝑡)

𝛼𝑘𝑛(𝑡)𝑁0𝐵)

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 41

where 𝑁0 is the noise power spectral density. As already mentioned, the execution is

split into a local and a remote execution. We also denote by 𝑓𝑘𝑙(𝑡) the local CPU cycle

frequency and by 𝐽𝑘 the number of bits per CPU cycle. Our aim is to minimize the

long-term average power consumption under constraints on the stability of the local

and remote computation queues. Given the computation split, for each user 𝑘 during

time slot 𝑡 , we consider a local queue backlog Q𝑘𝑙 (t) and a remote queue backlog

Q𝑘𝑟 (t), in bits. Then, we define the overall queue backlog for each user as

𝐐𝑘(𝑡) = (Q𝑘𝑙 (t), Q𝑘

𝑟 (t)) (1)

In each time slot, new tasks arrive. Some tasks are executed locally, while other tasks

are offloaded to the MEH. Then, the evolution of the local queue backlog can be

written as follows

Q𝑘𝑙 (t + 1) = max(Q𝑘

𝑙 (t) − Δ ⋅ 𝑓𝑘𝑙(𝑡) 𝐽𝑘 − Δ∑𝑎𝑘𝑛(𝑡)𝑅𝑘𝑛(𝑡)

𝑁

𝑛=1

, 0) + 𝐴𝑘(𝑡)

where 𝐴𝑘𝑛(𝑡) are the new arrivals, which arrive according to an unknown process, and

Δ is the slot duration. The queue backlog at the MEH side evolves as follows

Q𝑘𝑟 (t + 1) = max(Q𝑘

𝑟 (t) − Δ∑𝑎𝑘𝑛(𝑡)𝑓𝑘𝑛(𝑡)

𝑁

𝑛=1

, 0)

+ min(max(Q𝑘𝑟 (t) − Δ ⋅ 𝑓𝑘

𝑙(𝑡) 𝐽𝑘, 0), Δ∑𝑎𝑘𝑛(𝑡) 𝑅𝑘𝑛(𝑡)

𝑁

𝑛=1

)

where 𝑓𝑘𝑛(𝑡) is the CPU cycle frequency allocated by MEH 𝑛 to user 𝑘. Concerning

the power consumption of the mobile device, we consider it as the sum of the transmit

power 𝑝𝑘𝑛(𝑡) and the power consumption for local execution 𝑝𝑘𝑙 (𝑡) = 𝛾𝑘𝑓𝑘

𝑙(𝑡)3 ,

where 𝛾𝑘 is the effective switched capacitance of the CPU and 𝑓𝑘𝑙(𝑡) is the CPU cycles

frequency used in the 𝑡-th time slot. Our aim, is now to study an assignment strategy

coupled with a dynamic resource allocation to minimize the long-term power

consumption under queue stability constraints. More specifically, the problem can be

formulated as follows

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 42

where 𝑃𝑘 is the maximum power budget of user 𝑘, 𝐹𝑘𝑙 is the maximum local CPU cycle

frequency, while 𝐹𝑛 is the maximum CPU cycle frequency of MEH 𝑛. Constraints

1) guarantees that the queues are mean rate stable

2) is relative to the feasible set of the transmit power

3) and 4) ensure that each user is allocated a portion of the bandwidth and that the

sum does not exceed the available bandwidth, respectively

5) ensures that each user gets a portion of the bandwidth of AP 𝑛 if and only if it is

associated to that AP

6) ensures that the local CPU cycle frequency is non negative and does not exceed its

maximum value, dictated by the device

7) forces the assignment variable to be binary

8) ensures that a user is associated to only one AP-MEH pair

9) ensures that the total number of CPU cycles performed in one slot by the MEH does

not exceed the maximum one, which is forced by its computation power. Note that we

are considering the case with a single core running tasks of all users. To solve this

problem, we build on Lyapunov optimization as in [MAO17], which leads to an

optimization strategy that solves a deterministic problem in each time slot. Indeed, our

approach is based on the Lyapunov function, which represents a scalar measure of the

queue congestion of the network (for more details, we referred to [NEE10]). In

particular, we will consider the minimization of the conditional Lyapunov drift, with a

penalty function used to control the power consumption.

Thus, given a system with 𝐾 users and current queue backlogs defined in (1), we can

define the Lyapunov function as

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 43

𝐿(𝚯(𝑡)) =1

2∑[Q𝑘

𝑙 (𝑡)2 + Q𝑘𝑙 (t)2]

𝐾

𝑘=1

where

𝚯(𝐭) = (𝐐1(𝑡),… , 𝐐𝐾(𝑡))

We can now define the conditional Lyapunov drift as follows

Δ(𝚯(t)) ≜ 𝔼{𝐿(𝚯(t + 1)) − 𝐿(𝚯(t))|𝚯(t)}

where the expectation depends on the control policy, and is with respect to the random

channel states.

It can be shown that the Lyapunov drift has an upper bound that can be minimized in

each time slot, guaranteeing strong stability of the queues as far as the arrival rates are

within the capacity region. However, taking actions in this direction may result in an

unnecessary power consumption. Then, we now introduce a penalty function for the

power minimization plus queue stabilization. In particular, given the same queue

backlogs, we define the drift-plus-penalty function as follows

Δ𝑝(𝚯(t)) = Δ(𝚯(t)) + 𝑉 ⋅ 𝔼{𝑝(𝑡)|𝚯(t)}

where 𝑝(𝑡) is the power consumption and 𝑉 is a weighting parameter that represents

the trade-off between queue backlogs and power consumption. Due to Little’s law

[LIT61], this is equivalent to find a trade-off between power consumption and average

delay. In our particular case, it can be shown that Δ𝑝(𝚯(t)) is upper-bounded as

follows

where 𝐶 is a positive constant. Then, instead of minimizing the drift-plus-penalty

function in every time slot, we can minimize the upper bound, building on the

following result [NEE10]. Given a random variable 𝜔 with unknown distribution, a

control policy 𝜓 ∈ 𝛹𝜔 and a cost function 𝑐(𝜓, 𝜔), there is at least one action 𝜓𝜔min

that minimizes 𝑐(𝜓,𝜔) over all 𝜓 ∈ 𝛹𝜔 . Then, the control policy that minimizes

𝔼{𝑐(𝜓,𝜔)} is the one that observe 𝜔 and selects a minimizing action 𝜓𝜔min. Then,

problem can be solved by solving the following problem in each time slot

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 44

where 𝜓(𝑡) = {{𝑝𝑘𝑛(𝑡)}𝑘,𝑛, {𝑓𝑘𝑙(𝑡)}

𝑘, {𝑓𝑘𝑛(𝑡)}𝑘,𝑛, {𝑎𝑘𝑛(𝑡)}𝑘,𝑛} , 𝛹𝜔(𝑡) is the feasible

set of control actions for problem 𝒫 , according to constraints 1) − 9) given the

random events 𝜔(𝑡) = {{𝐴𝑘(𝑡)}𝑘, {ℎ𝑘𝑛(𝑡)}𝑘,𝑛} . Since the problem including the

assignment is a mixed integer nonlinear programming (MINLP) problem, it is, in

general, NP-hard. To solve it, we use a low complexity algorithm based on matching

theory with transfers, showing to achieve good performance with respect to an SINR-

based association. Thus, we treat the assignment and the optimization problem

separately. First, we solve the assignment problem, and then we optimize resources in

each time slot for every set UE-AP-MEH. Before describing the proposed assignment

algorithm, it is useful to present the solution of problem 𝒫1 for a given AP, which can

be solved efficiently by splitting it into 3 sub-problems: local CPU cycle frequency

allocation, optimal bandwidth and power allocation, and remote optimal scheduling

[MAO17], [MDB18]. Denoting by 𝒮𝑛 the set of users associated to AP-MEH 𝑛, the

resource allocation is performed for each 𝒮𝑛, 𝑛 = 1,… ,𝑁.

3.3.2.1 First sub-problem: Optimal local CPU-cycle frequency allocation

For the optimal local CPU-cycle frequency allocation, it can be shown that the optimal

solution is the following

𝑓𝑘,opt𝑙 (𝑡) = min{𝐹𝑘

𝑙 , √𝑄𝑘𝑙 (𝑡) ⋅ Δ ⋅ 𝐽𝑘3𝛾𝑘𝑉

}, ∀ 𝑘 ∈ 𝒮𝑛

3.3.2.2 Second sub-problem: Optimal bandwidth and power allocation

Note that, as shown in [MAO17], only users with 𝑄𝑘𝑙 (𝑡) > 𝑄𝑘

𝑟(𝑡) will offload their

tasks. Intuitively, this happens because, if 𝑄𝑘𝑟(𝑡) ≥ 𝑄𝑘

𝑙 (𝑡), offloading tasks incurs in

transmit power consumption and greater execution delay. We denote by 𝒮′𝑛 the set of

users associated to AP-MEH 𝑛 during time slot 𝑡 , for which 𝑄𝑘𝑙 (𝑡) > 𝑄𝑘

𝑟(𝑡) . For

simplicity, in this scenario we consider the bandwidth as equally shared by all users so

that the bandwidth allocation for 𝒮𝑛 is given as follows

𝛼𝑘𝑛 = {

1

|𝒮′𝑛 |, if 𝑘 ∈ 𝒮′𝑛

0, 𝑜𝑡ℎ𝑒𝑟𝑤𝑖𝑠𝑒

Given the bandwidth allocation, the optimal power allocation is given as follows

𝑝𝑘𝑛(𝑡) =

{

min{𝛼𝑘𝑛𝐵max{

(𝑄𝑘𝑙 (𝑡) − 𝑄𝑘

𝑟(𝑡)) Δ

ln 2 ⋅ 𝑉−

𝑁0ℎ𝑘𝑛(𝑡)

, 0} , 𝑃𝑘 } , if 𝑘 ∈ 𝒮′𝑛

0, otherwise

3.3.2.3 Third sub-problem: Optimal scheduling

It can be shown that the optimal scheduling at the MEH is based on the following

solution: at each time slot, only one device will be scheduled and is the one with the

highest value 𝑄𝑘𝑟(𝑡) 𝐽𝑘 . Denoting by 𝑘𝑚𝑎𝑥 this device, we can write the optimal

scheduling as follows

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 45

𝑓𝑘𝑛(𝑡) = {𝐹𝑛, if 𝑘 ∈ 𝒮𝑛 ∩ 𝑘 = 𝑘

𝑚𝑎𝑥

0, otherwise

Having described the optimal resource allocation strategy, we can now describe the

assignment process, which is based on the tools of Matching Theory [HAN17] (for

college admission), with a consequent coalitional game for college transfers. Matching

theory is a powerful tool to associate agents from to different sets with polynomial

complexity. In particular, the assignment problem is a many-to-one matching problem,

in which one agent from set (AP) can be associated to more than one agent from the

other set (UE). A typical example of this problem is the college admission process, in

which colleges accept a number of applicant students as far as they do not exceed the

maximum number, which is called quota in the context of matching theory. The aim is

to find a stable assignment. An assignment is called unstable if there are two applicants

𝛼 and 𝛽 who are assigned to colleges 𝐴 and 𝐵, respectively, although 𝛽 prefers 𝐴 to 𝐵

and 𝐴 prefers 𝛽 to 𝛼 [GAL62]. Gale and Shapley, in [GAL62], presented the Deferred

Acceptance algorithm for college admissions and stable marriages, which is proved to

converge to a stable matching in with polynomial complexity. The algorithm is based

on preference functions (utilities) of agents from both sets. For our algorithm, each

user builds a ranking of AP-MEH and vice versa. The application of matching theory

to wireless communications gained a lot of attention in the last years [HAN17]. In this

context, the main problem is the inter-dependence of preference functions, since

preferences a user are affected by preferences of other users, due to resource sharing.

As an example, the more users access an AP, the less radio resources are allocated to

each user. In this case, the problem of matching becomes complex and the deferred

acceptance algorithm is not sufficient to achieve good performance. For this reason,

we start building on the same strategy of [SAAD14] and [SMB18], in which the

assignment problem is split into two subgames: a deferred acceptance algorithm based

on potential preference function, and a transfer subgame in which users can request to

be transferred to improve their utilities. Then, the main task is to define the preference

functions used for the matching process. The first step is to perform the deferred

acceptance algorithm based on potential utilities. For this purpose, we use the expected

optimal value of objective function at each AP-MEH as preference functions. In

particular, during the first phase, users build their preferences assuming that all AP

accept all users as far as they do not exceed their maximum quota. Then, every user

computes the expected optimal value of the objective function of problem 𝒫1. More

specifically, let 𝐺𝑘𝑛∗ be the expected optimal value of the objective function of 𝒫1 for

user 𝑘 accessing the pair AP-MEH 𝑛. Then, each user ranks the pairs AP-MEH based

on the following utilities

𝑈𝑘𝑛 = −𝐺𝑘𝑛∗

Each AP builds its preference functions based on the highest SINR. Based on these

preference functions, the deferred acceptance algorithm is used to find the assignment.

The first phase leads to the creation of coalitions. A coalition 𝒞𝑛is the set of users

assigned to AP-MEH 𝑛, while the set of all coalitions is called partition. Since users

do not know preferences of other users, this solution can be unbalanced and can lead

to a situation in which many users are associated to a certain pair AP-MEH, thus

leading to shortage of resources. For this reason, a second phase in which users can

request to be transferred is performed. Indeed, with the assignment generated by the

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 46

first phase, users have more information on which AP are more congested, and can

rebuild their expected utilities. Then, a user 𝑖 will request to be transferred if the

transfer improves its utility. We define the welfare of a coalition 𝒞𝑛, the sum of all

utilities of users in 𝒞𝑛

𝑊(𝒞𝑛) = ∑ 𝑈𝑘𝑛𝑘∈𝒞𝑛

Based on this definition, a transfer is accepted if and only if the following two

conditions hold:

1) The target AP-MEH 𝑛′ pair does not exceed its quota 𝑞𝑛′

2) The social welfare, defined as the sum of the welfares of the two coalitions, is

improved

The second condition can be formalized as follows

𝑊(𝒞𝑛\{𝑖}) +𝑊(𝒞𝑛′ ∪ {𝑖}) > 𝑊(𝒞𝑛) +𝑊(𝒞𝑛′)

This second subgame ends when there are no transfer requests or no more transfers are

accepted. This second phase, is proved to converge to a Nash stable partition, and its

output is the final assignment, denoted by 𝒮𝑛.

3.3.3 Numerical results

We now perform the assignment, coupled with resource allocation, in the scenario with

5 UE and 3 pairs AP-MEH, as depicted in Figure 3.3-1. With the blue arrows we show

the SNR-based association, by which every user is associated to its best mmWave AP

in terms of signal to noise ratio.

Figure 3.3-1 Scenario

We assume mmWave communications with path loss in dB between a generic user 𝑘

and AP 𝑛 given by

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 47

where 𝑑𝑘𝑛 is the distance between the user and the AP, and 𝑑0 is the reference distance,

set to 5 m. We consider a MIMO system with 4 antennas at the UE side and 16 antennas

at the BS side, a bandwidth 𝐵 = 200 MHz, and a slot duration of 10 ms. A maximum

local and remote CPU cycle frequency of 109 and 3 × 109 CPU cycles/s are assumed,

respectively. We run our evaluation over 5000 slots, averaging over the arrival

probabilities with 100 realizations. We show the performance of the proposed

matching algorithm when this is performed at each time slot, assuming a slot duration

of 10 ms. However, changing the association at every time slot means to transfer the

state of the application running in one MEH to another MEH, so it is a very complex

operation in real context. Then, to reduce the complexity, we show the performance

when the matching algorithm is used every 100, and 500 slots. Moreover, we compare

these results with the SNR-based association. The results are shown in terms of

average transmit power vs. the parameter 𝑉 and the average queue lengths vs. 𝑉. In

Figure 3.3-2 we show the average queue length vs. the parameter 𝑉. Note that, as 𝑉

increases, the average queue length increases as well, since it is more important to keep

the power consumption limited. Indeed, the drift-plus-penalty algorithm reaches the

optimal power consumption for high 𝑉. This can be seen in Figure 3.3-3, where the

average power consumption is plotted vs. 𝑉, showing its optimal values for the highest

values of 𝑉 . Note that, for such values, the long-term average power consumption

reaches the optimal value while stabilizing the queues. We can also note that using the

strategy of optimizing the association every 100 times slots achieve results close to the

ones in which the association is changed in each time slot. This suggest that this lower

complexity strategy can be used without degrading performance. Other strategies

achieve degraded but much better performance than the SNR-based association.

Figure 3.3-2 Average queue length power consumption vs. V

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 48

Figure 3.3-3 Long-term average power cosnumption vs. V

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 49

4 Mesh backhaul prototyping

The final goal of this project is to verify the developed ideas and concepts in large field

trials, based on the five scenarios we developed and constantly refined in the first

period of this project and concluded in our deliverable D1.3 [D1.3].

In the previous sections, we selected three of those scenarios and explained details on

the architecture and specifications, the following passage will briefly summarize the

requirements and conclude what features the mesh backhaul prototype nodes need to

provide.

Omotenashi services

This scenario requires high data rates in an area with dense deployment and many users.

We need to deploy a large number of nodes and have them create a reliable and fast

backhaul network. The nodes need to support caching and prefetching of content.

Dynamic crowd

In this scenario, a large number of users will move throughout the deployed network.

This requires flexible data rates, reconfiguration of routes and, if possible, even the

topology. Controlling power states of the nodes will further increase the efficiency of

the deployed network. Caching and prefetching are necessary, controlled by algorithms

predicting the movement of users.

Autonomous driving

Vehicles send large amounts of raw sensor data to the roadside units, where the data is

processed, added to the existing HD maps and distributed to all vehicles in the area.

This requires high data rates, very low latency and edge computing on the nodes.

Requirements on the nodes

When taking care of those requirements, the prototype nodes need:

Data rates of multiple Gbps

Latency below 1 ms

Range of over 200 m

Reduced interference in dense deployments

Multi-Access edge computing

Power saving

Central orchestration

For this, we are developing a testbed. It uses an architecture like the one shown in

Figure 3.3-1 and is based on two key technologies in this project, i.e. MmWave

communication and edge computing.

The testbed architecture consists of multiple nodes in a meshed topology. Each node

is equipped with several mmWave interfaces using BF arrays, and selected nodes

feature edge cloud functionality. A SDN controller, via OpenFlow over a separate

control channel, centrally orchestrates the whole system, incorporating the developed

concept of splitting control and user-plane.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 50

Additionally there are two novel features in the testbed. First the mmWave interfaces

can be dynamically aligned [BMSB2018], to adapt the entire network to the changing

demands of our proposed scenarios. Second, the orchestrator, further increasing the

network efficiency and reducing power usage, also controls the power state.

Figure 3.3-1 Testbed architecture

4.2 Software-defined wireless mesh networks for mobile edge

computing

As introduced, the concept we focus on is an mmWave wireless mesh network with

central orchestration and mobile edge computing. Using mmWave communication

allows data rates of multiple Gbps with a device-to-device latency below 1 ms.

4.2.1 MmWave wireless mesh network

The designed testbed exposes the following features of each node to the SDN

controller:

Dynamic routing

Antenna alignment

Power control

To fully exploit the capabilities of the mesh topology and meeting the changing

demands, when exposing the network to a dynamic use-case, the routes need to be

reconfigured dynamically. While this is a basic feature for SDN controlled networks,

the developed concept goes one-step further and allows the controller to re-align

interfaces and modify the entire topology, aggregate links to increase data rates in

heavily loaded areas, while other areas are idle and have links available. Sending entire

nodes to sleep and waking them again, when necessary, further reduces the power

usage.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 51

4.2.2 Multi-Access edge computing

Our second 5G-MiEdge technology, multi-access edge computing, is used to

cache/pre-fetch content and execute tasks at the closest MEH. Caching/prefetching can

drastically reduce the load on the core network and increase the responsiveness for the

UE requesting content. Edge computing reduces the load on the UE while also offering

a very low latency in contrast to offloading tasks to computation centers.

In the designed testbed, there will be multiple MEHs available, so the SDN controller

can dynamically assign jobs to the different MEHs and migrate them from one to

another, when the MEHs are loaded or the UE moves through the area.

4.3 Node prototyping

In order to meet those demands, we designed prototypes of the mesh backhaul nodes.

The following sections will first present two different prototype designs and

specifications of the internal hardware components.

4.3.1 Prototype designs

A first design is displayed in Figure 4.3-1; it shows the rendering of a mesh backhaul

node that can be mounted on a pole. On the left side, a regular rendering is presented;

the rendering on the right side has transparent walls to allow a closer look on the

internal hardware components. This design consists of three compartments for

movable mmWave links that are stacked on top of each other. It offers great flexibility

for the node location, e.g. on streetlights or temporary posts for large area outdoor

installations. The first design does not yet include a computation device for edge cloud

functionality; it is a pure backhaul node.

Our second design, shown in Figure 4.3-2 shows an enhanced version, based on the

same initial design. Like in the last figure, there is a transparent rendering on the right

side and in addition to the two compartments for movable mmWave links, this node

has a dedicated compartment for a computation device. This design shows a wall-

Figure 4.3-1 Pole-mounted mesh backhaul node

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 52

mounted node, which allows mounting on existing infrastructure, greatly increasing

the number of possible deployment locations.

4.3.2 Movable mmWave antenna

For the required link range, the used mmWave frontends need to be equipped with

reflect arrays. These arrays offer a reduced beam with of just 6°. This does not only

greatly reduce the interference on other nodes in the close vicinity, it also results in a

gain of 26 dBi, allowing a link range of over 200 meters.

With the reflect array and the narrow beam, the links need to be aligned towards the

target node. In the prototype, this is achieved with a mount that can be rotated by 360°

horizontally and 30° vertically. Allowing the mmWave link to be aligned to any other

station within the link range.

These prototypes are already being used in the testbeds in Berlin and Tokyo, preparing

for outdoor deployments and extensive field trials.

4.3.3 Computation device

As some of the nodes will act as mobile edge host, they need to be equipped with a

computation device. In real-world deployments, this device has to be very powerful

and equipped with a large storage.

For testbeds and evaluations, the constraints are a little less restrictive, therefore Intel

NUC devices were chosen. They offer a perfect compromise between size, power

usage and computation power, storage capabilities. The bottom compartment in Figure

4.3-2 is specifically designed for this device.

Figure 4.3-2 Wall-mounted mesh backhaul node

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 53

4.3.4 Next steps

This section is all about planning and designing the backhaul nodes. Work package 4

will use this research and implement those designs, develop the testbed and evaluate

it on the selected scenarios.

This task is already running and the upcoming deliverable D4.2 will contain final

designs, details on implementation and evaluation results.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 54

5 Summary

This deliverable D2.4 belongs to WP2, which runs from month 4 to 30 of the 36-month

lifetime of 5G-MiEdge and is in charge of mmWave edge cloud for 5G RAN

deployments.

Up to now, WP2 has released two deliverables:

D2.1 Requirement and scenario definition for mmWave access, antennas and

area planning for mmWave edge cloud (June 2017)

D2.3 Design of mmWave antennas for 5G enabled stadium (June 2018)

In this deliverable, we have finalized our methods of site specific deployment of

mmWave edge cloud. First, we explained the specific requirements of three selected

scenarios:

Omotenashi services

Dynamic crowd

Autonomous driving

This includes all the constraints for the deployment of an mmWave mesh backhaul

network for future testing and performance evaluations on the designed scenarios.

Then the design and analysis for site specific deployment of mmWave edge cloud are

presented:

Modeling and optimization of multi RAT HetNet

Interference management in mesh backhaul networks

Dynamic resource allocation, considering the best trade-off between queues

and power consumption

The last section contains the concepts and designs for mesh backhaul prototyping,

taking care of all the carefully calculated requirements in the designed scenarios.

With the results from this deliverable, we developed a solid base for the WP4 task of

designing, implementing and deploying a 5G-MiEdge testbed. It will consist on a

centrally orchestrated mmWave mesh backhaul network, with C/U split and mmWave

access.

More details on mmWave access will be presented in the upcoming deliverable D2.2,

planned to be finalized in December 2018.

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 55

6 References

[5GPPPWP AV] 5GPPP White Paper, “5G automotive vision,” Oct. 2015

[Ang13] A. D. Angelica, “Google’s self-driving car gathers nearly 1GB/sec,” May

2014. Available online: http://www.kurzweilai.net/googles-self-driving-car-

gathers-nearly-1-gbsec

[BAR17] S. Barbarossa, E. Ceci, M. Merluzzi and E. Calvanese-Strinati, "Enabling

effective Mobile Edge Computing using millimeterwave links," 2017 IEEE

International Conference on Communications Workshops (ICC Workshops),

Paris, 2017, pp. 367-372.

[BMSB2018] K. Koslowski et al, “SDN Orchestration to Optimize meshed Millimeter-

Wave Backhaul Networks for MEC enhanced eMBB use cases”, BMSB 2018

[CVG16] J. Choi, V. Va, N. Gonzalez-Prelcic, R. Daniels, C. R. Bhat, R. W. Heath,

“Millimeter-wave vehicular communication to support massive automotive

sensing,” IEEE Commun. Mag., vol. 54, no. 12, pp. 160-167, Dec. 2016.

(Same with CVG16)

[D1.1] 5G-MiEdge deliverable D1.1, “Use Cases and Scenario Definition”, Available

online at: http://5g-miedge.eu.

[D1.3] 5G-MiEdge Deliverable D1.3, “System Architecture and Requirements”,

Available online at: http://5g-miedge.eu.

[D2.1] 5G-MiEdge Deliverable D2.1, “Requirement and scenario definition for

mmWave access, antenna and area planning for mmWave edge cloud”,

Available online at: http://5g-miedge.eu.

[Elshaer2016] H. Elshaer, M. N. Kulkarni, F. Boccardi, J. G. Andrews, and M. Dohler,

“Downlink and uplink cell association with traditional macrocells and

millimeter wave small cells,” IEEE Trans. Wireless Commun., vol. 15, no. 9,

pp. 6244–6258, Sep. 2016.

[GAL62] D. Gale and L. S. Shapley, “College Admissions and the Stability of

Marriage”, Mathematical Association of America

[Ghatak2018] G. Ghatak, A. De Domenico, M. Coupechoux, Coverage Analysis and Load

Balancing in HetNets with mmWave Multi-RAT Small Cells, in IEEE

Transactions on Wireless Communications, vol. 17, no. 5, pp. 3154-3169,

May 2018. doi: 10.1109/TWC.2018.2807426

[HAN17] Zhu Han, Yunan Gu, and Walid Saad. 2017. Matching Theory for Wireless

Networks (1st ed.). Springer Publishing Company, Incorporated.

[HFL15] L. Hobert, A. Festag, I. Llatser, L. Altomare, F. Visintainer, A. Kovacs,

“Enhancements of V2X Communication in Support of Cooperative

Autonomous Driving,” IEEE Commun. Mag., vol.53, no.12, pp.64-70, Dec.

2015.

[KQC15] S.W. Kim, B. Qin, Z. J. Chong, X. Shen, W. Liu, M H. Ang, E. Frazzoli, D.

Rus, “Multivehcle cooperative driving using cooperative perception: design

and experimental validation,” IEEE Trans. Intel. Transpor. Systems, vol. 16,

no. 2, pp. 663-680, Apr. 2015.

[KS17] K. Sakaguchi et al., "Where, When, and How mmWave is Used in 5G and

Beyond," IEICE Trans. Electron., vol. E100–C, no. 10, pp. 790-808 Oct. 2017.

(Invited)

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 56

[LIT61] Little J.D.C, "A proof of the queueing formula: L=λW,

Operations research, 9, pp. 383-387

[MAO17] Y. Mao, J. Zhang, S. H. Song and K. B. Letaief, "Stochastic Joint Radio and

Computational Resource Management for Multi-User Mobile-Edge

Computing Systems," in IEEE Transactions on Wireless Communications,

vol. 16, no. 9, pp. 5994-6009, Sept. 2017.

[MiWEBA

AR10.1]

The first annual report of MiWEBA, 2014.

[MiWEBA D5.1] Channel Modeling and Characterization

[MiWEBA D5.2] Development of highly-directional steerable mm-wave antennas concept

[MiWEBA D5.3] Highly-directional steerable mm-wave antennas prototype

[MiWEBA D5.4] Development of beam steering techniques for highly directional steerable

mm-wave antennas

[NEE10] M. J. Neely, “Stochastic network optimization with application to

communication and queueing systems”, Synth. Lect. on Comm. Netw.s, vol.

3, no. 1, pp. 1–211, 2010.

[SAAD14] W. Saad, Z. Han, R. Zheng, M. Debbah and H. V. Poor, "A college admissions

game for uplink user association in wireless small cell networks," IEEE

INFOCOM 2014 - IEEE Conference on Computer Communications, Toronto,

ON, 2014, pp. 1096-1104.

[SAE] SAE International, “Automated Driving Levels of Drigning Automation are

defined in New SAE International Standard J3016”

https://www.sae.org/misc/pdfs/automated_driving.pdf

[SH16] Heiko G. Seif, Xiaolong Hu, “Autonomous Driving in the iCity – HD Maps

as a Key Challenge of the Automotive Industry,” ELSEVIER, Engineering,

pp.159-162, June 2016.

[MTN17] M. Kobayashi, T. Urushihara, N. Shirakata, K. Takinami, "Cooperative

WiGig/Wi-Fi Multi-User Content Delivery System with Application-Centric

Connection Management", SmartCom 2017.

[SMB18] S. Sardellitti, M. Merluzzi, S. Barbarossa, “Optimal association of mobile

users to multi-access edge computing resources”, 2018 International

Conference on Communications (ICC), Kansas City, USA, 2018, pp. 1-6

[TR22.885] 3GPP TR22.885, Study on LTE support for vehicle to everything (V2X)

services, V14.0.0, Dec. 2015.

[TR22.886] 3GPP TR22.886, Study on enhancement of 3GPP support for 5G V2X

services, V15.0.0, Dec. 2016.

[TR23.703] 3GPP TR23.703 V12.0.0, “Study on architecture enhancements to support

Proximity-based Services (ProSe),” Feb. 2014.

[TS23.303] 3GPP TS23.303, Proximity-based services (ProSe); Stage 2

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D2.4

Date: August 2018

Public Deliverable

5G-MiEdge Page 57

[VSB16] V.Va, T. Shimizu, G. Bansal, and R. W. Heath Jr., “Millimeter Wave Vehicular

Communications: A Survey,” Foundations and Trends® in Networking,

vol.10, no.1, pp.1-113, June 2016.