+ All Categories
Home > Documents > 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018...

5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018...

Date post: 26-Apr-2020
Category:
Upload: others
View: 2 times
Download: 0 times
Share this document with a friend
46
Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1 Date : June 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: M24 Actual date: M24 Authors: See list Work package: D4.1 Performance evaluation of 5G MiEdge based 5G cellular networks Security: Public Nature: Report Version: 1.0 Number of pages: 46 Abstract This deliverable reports system performance of 5G-MiEdge concepts through system level simulator developed and used in T4.1. Keywords 5G cellular networks, simulator architecture, millimeter-wave access, edge cloud, link-level simulator, system-level simulator, performance evaluation All rights reserved. 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.
Transcript
Page 1: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1 Date : June 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: M24

Actual date: M24

Authors: See list

Work package: D4.1 Performance evaluation of 5G MiEdge based 5G cellular networks

Security: Public

Nature: Report

Version: 1.0

Number of pages: 46

Abstract

This deliverable reports system performance of 5G-MiEdge concepts through system

level simulator developed and used in T4.1.

Keywords

5G cellular networks, simulator architecture, millimeter-wave access, edge cloud, link-level simulator,

system-level simulator, performance evaluation

All rights reserved.

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.

Page 2: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

2

5G-MiEdge Page 2

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

Tokyo Institute of

Technology

Gia Khanh Tran [email protected]

Hiroaki Nishiuchi [email protected]

Kei Sakaguchi [email protected]

Sapienza University of Rome Mattia Merluzzi [email protected]

Sergio Barbarossa [email protected]

Fraunhofer- Heinrich-Hertz-

Institut

Konstantin Koslowski [email protected]

Panasonic Koji Takinami [email protected]

INTEL Valerio Frascolla [email protected]

Page 3: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1 Date : June 2018 Public Deliverable

5G-MiEdge Page 3

Table of contents

Abbreviations and acronyms ......................................................................................... 5

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

1 Introduction ............................................................................................................. 9

2 Simulator architecture .......................................................................................... 10

2.1 The overall architecture .................................................................................. 10

2.2 Link level PHY abstraction [MWB-D4.1] ..................................................... 11

2.2.1 Link level PHY abstraction for 2GHz LTE ........................................ 11

2.2.2 Link level simulator for 60GHz WiGig .............................................. 13

3 System level simulator .......................................................................................... 15

3.1 Parameters for system level simulator ........................................................... 15

3.2 Resource management framework ................................................................. 15

3.2.1 Network architecture and C/U splitting .............................................. 15

3.2.2 Mobility management (cell association for U-plane) ......................... 16

3.2.3 Radio resource control ........................................................................ 16

3.3 System level simulator ................................................................................... 17

3.3.1 SLS procedure .................................................................................... 17

3.3.2 Simulations setup................................................................................ 18

3.3.3 SLS core and Loop over frames ......................................................... 20

3.3.4 System level simulator GUI ............................................................... 23

4 Performance evaluation ....................................................................................... 25

4.1 Revisit of 5G-MiEdge’s scenarios ................................................................. 25

4.2 Performance evaluation on data prefetching .................................................. 26

4.2.1 Extension of the basic SLS ................................................................. 26

4.2.2 System level simulator to evaluate data prefetching .......................... 26

4.3 Performance evaluation on computation offloading ...................................... 38

4.3.1 mmWave edge cloud for computation offloading .............................. 38

4.3.2 Problem statement .............................................................................. 38

4.3.3 Scenario Definition ............................................................................. 40

4.3.4 Simulation parameters and performance evaluation .......................... 41

Page 4: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

4

5G-MiEdge Page 4

5 Summary ................................................................................................................ 44

6 References .............................................................................................................. 46

Page 5: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

5

5G-MiEdge Page 5

Abbreviations and acronyms

Acronym Description

3GPP 3rd Generation Partnership Project

5G Fifth-generation wireless broadband technology

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

AP Access Point

BS Base Station

CDF Cumulative Distribution Function

C-Plane Control Plane

C-RAN Cloud RAN

CSI Channel State Information

C/U split Control/User-plane split

DL Downlink

EPC Evolved Packet Core

ETSI European Telecommunications Standards Institute

GUI Graphic User Interface

HetNet Heterogeneous Network

IEEE The Institute of Electrical and Electronic Engineers

ITU International Telecommunication Union

LTE Long Term Evolution

MCS Modulation-coding scheme

MEC Mobile Edge Computing or Multi-access Edge Computing

MEH Mobile Edge Host

MiEdge mmWave Edge cloud

mmWave Millimeter Wave

PER Packet Error Rate

PHY Physical Layer

PSDU Physical layer convergence procedure Service Data Unit

QoE Quality of Experience

QoS Quality of Service

Page 6: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

6

5G-MiEdge Page 6

RAN Radio Access Network

RSS Received Signal Strength

RSU Road Side Unit

Rx Receiver

SCME Spatial Channel Model and its Extension

SLS System Level Simulator

SINR Signal to Interference-plus-Noise Ratio

Tx Transmitter

UE User Equipment

UL Uplink

U-Plane User Plane

Page 7: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 7

Executive Summary

5G-MiEdge has the ambitious goal of looking beyond the current scope of 5G, to

address new use cases and create additional values for 5G users. The distinctive feature

of the 5G-MiEdge vision is to exploit the benefit of combining mmWave edge cloud,

liquid RAN C-plane, and user/application centric orchestration techniques. Current 5G

enhancements build on a radical increase of system capacity by incorporating massive

MIMO techniques, dense deployment of radio access points (AP), and much wider

bandwidth (new spectrum), all aspects facilitated by the use of mmWave

communications. However, the improvements that can be achieved at the access

stratum will still be insufficient to meet the challenging new 5G requirements.

Therefore, to provide an efficient platform serving several different new applications,

a paradigm shift is needed through the combination of mmWave and MEC proposed

in this project. MEC and mmWave technologies complement each other well:

mmWave access benefits from the distributed computation and storage capabilities of

MEC to optimize the communication strategies, incorporating cache prefetching, and

orchestration of APs at the edge. MEC benefits from the high data rate proximity

access to the edge cloud of mmWave, thus reducing latency and improving the Quality

of Experience (QoE).

As one of the measures of this project’s proposed technologies, this deliverable

describes the outcome of the work done in Task 4.1 ‘System level performance

evaluation’. It reports system performance evaluation of 5G-MiEdge concepts with

regard to the several selected scenarios and use cases through our developed system

level simulator (SLS). The overall architecture of the SLS, which many parts were

inherited from the consortium’s prior project called MiWEBA, is revisited. Detailed

parameters of the SLS are presented and the SLS is used to evaluate two typical MEC

applications: Data prefetching and computation offloading.

As our findings, the proposed architecture is effective for many purposes of edge

applications e.g. data prefetching and computation offloading. Performance evaluation

lead to two major observations:

1. Adding MEC at the edge with a proper prefetching algorithm can maximally

exploit ultra-high data rate of mmWave access, even with a low cost limited

backhaul.

2. The use of multi-link communications and the dynamic evolution of

computation queues offers great overall improvements to the system. Multi-

link communications are advantageous not only in case of blocking events, but

also in cases without blocking, since the data rate can be improved with the

same transmit power, or equivalently, the transmit power can be decreased to

obtain the same data rate.

Although the evaluated results are preliminary under several ideal assumptions, they

are still sufficient to show the benefit of combining mmWave edge cloud, liquid RAN

C-plane, and user/application centric orchestration techniques as proposed in this

project. Future deliverables D4.2 ‘Development of common/joint 5G MiEdge Testbed’

and D4.3 ‘Field trials toward Tokyo Olympic 2020’, will validate such effectiveness,

through real hardware and experimental results.

Page 8: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 8

Page 9: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 9

1 Introduction

This deliverable describes the outcome of the work done in Task 4.1 ‘System level

performance evaluation’. It reports system performance evaluation of 5G-MiEdge

concepts with regard to the investigated scenarios and use cases. Future deliverables

D4.2 ‘Development of common/joint 5G MiEdge Testbed’ and D4.3 ‘Field trials

toward Tokyo Olympic 2020’, targeting the hardware implementation and the

deployment of the final testbed, will build upon the results of this deliverable.

For the evaluation of the system level performance, a system level simulator (SLS)

was designed. It is based on the architecture presented in Section 2, separated into a

conventional LTE system and novel mmWave small cells, offering advanced features,

like the control- and user-plane (C/U) split , and generating effective user throughputs.

The system architecture in focus is based on the results of the deliverable ‘Architecture

of mmWave edge cloud and requirement for control signalling’ [D3.1], and is reported

once again here below.

Figure 1 - Control-/User-plane split in marco-/small-cell setup [D3.1]

Section 3 of this deliverable details the SLS, starting with fundamental parameters for

the simulations of mmWave small cells and overlaying macro cells. Then the resource

management framework is presented and fundamental features like C/U split, mobility

management and radio resource control are detailed. In Section 3.3 the system

simulator setup and the obtained results are presented. Section 4 is dedicated to

performance evaluation, when prefetching and caching data on mobile edge cloud

(Section 4.2) and when offloading heavy computation tasks (Section 4.3). Section 5

summarizes the main achieved results and gives an outlook on the work to be done in

the upcoming deliverables of work package 4.

Page 10: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 10

2 Simulator architecture

2.1 The overall architecture

Figure 2 – Block diagram for design of the system level simulator

(Red color parts will be explained in details in this document)

Figure 2 shows the block diagram for design of the overall SLS, knowing that the core

network is neglected. It is separated into a conventional Long Term Evolution (LTE)

system and the novel mmWave small cells system for both uplink (UL) and downlink

(DL). In this deliverable, only DL is presented. For the LTE system, it contains macro

cells where one macro cell is responsible for the control (C)-plane of all base stations

(BS) within the cell. LTE system’s parameters are based on 3GPP specifications. For

the novel mmWave small cells, only the mmWave U-plane access links with UE got

implemented at this stage of the work. The mmWave small cells’ C-plane is an open

issue to be discussed in WP3 and will be implemented in the future, if deemed

necessary. The access link parameters are adopted from both IEEE 802.11ad (WiGig)

as well as from parameters based on the MiWEBA project measurement results

[MWB-D5.1]. The mmWave small cells are assumed to be connected to the C-plane

of the LTE network (C-RAN) by backhaul or front haul. With the above architecture,

UE C-plane are only connected to the macro LTE, while UE U-plane can connect to

both systems (LTE macro or small cells). It should be noted that functionalities written

in RED color in Fig. 2 are novel ones which are quite different from conventional

3GPP ones.

As all UE are commonly connected to the macro BS’s C-plane, the architecture allows

user/application centric orchestration, developed in T3.3, such as optimal user

association and scheduling, time/frequency/space resource assignment etc.

Furthermore, novel models imitating UE’s movements and generated traffics are

developed to evaluate edge clouds’ capabilities e.g. prefetching/computation

offloading effectiveness, packet latency etc.

Page 11: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 11

To evaluate the real system level performance of LTE with mmWave overlay HetNet,

for each time slot of the user scheduler, the simulator calculates the instantaneous

SINRs of the UE for both conventional LTE and mmWave modes. The SINR metrics

are then recalculated into the modulation-coding schemes (MCSs) for both PHYs and

corresponding to that schemes packet error rate (PER) metrics, by using appropriate

LTE or mmWave PHY abstraction methodologies inherited from the MiWEBA

deliverable D4.1 [MWB-D4.1], thus providing the effective user throughput for each

PHY. This information may be further used for dynamic resource management at C-

plane. Long-term performances, e.g. average throughputs, are calculated at the end of

the scheduler by adapting to a time/frequency varying channels implemented for each

UE in the SLS. Such PHY abstraction are recast from [MWB-D4.1] in Sect. 2.2.

2.2 Link level PHY abstraction [MWB-D4.1]

2.2.1 Link level PHY abstraction for 2GHz LTE

The link-level simulator (LLS) for LTE evaluates link-level performance, such as bit

error rate (BER) and/or block error rate (BLER), on a given link channel condition.

The evaluation results of LLS are used for PHY abstraction on the SLS by means of

link-to-system mapping methods, e.g. Exponential effective SINR Mapping [TW05].

2.2.1.1 Link level simulator parameters

The physical downlink shared channel (PDSCH) is used to transmit the downlink user-

plane data on LTE. Therefore, the LLS evaluates the performance of PDSCH based on

the 3GPP specification [TS36.211, 212, 213]. The channel coding, modulation,

multiplexing and propagation channel on equivalent low-pass model have been

modeled in the LLS. The modeling of time-frequency resource scheduling, link

adaptation and time-frequency variant channel are role of SLS. Parameters for the LTE

LLS are summarized in Table 2.3.1.

The LTE supports scalable bandwidth allocation and flexible channel coding rate. The

channel coding scheme of the LTE is implemented as a combination of a fixed r=1/3

turbo encoder and a rate matching process. By means of rate matching, any arbitrary

code rate can be achieved from a fixed-rate mother code. The accurate code rate of a

code block is calculated by dividing the size of the transport block (TB), which is a

block of information bits to carry a MAC PDU (Medium Access Control Protocol Data

Unit), by the number of allocated time-frequency resources elements (REs) and the

modulation order.

TABLE 2.3.1 - PARAMETERS FOR THE LTE

Parameter Value

Modulation QPSK, 16QAM, 64QAM

Multiplexing OFDM (15kHz sub-carrier spacing, 4.7 or 5.2s cyclic prefix)

Coding LTE Turbo code (base coding rate R=1/3, K=4, QPP interleave)

Transmission

bandwidth

25 resource blocks (4.5MHz)

Channel model AWGN

Page 12: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 12

2.2.1.2 Evaluation results

The LLS is performed with typical coding rates that are defined on CQI table

[TS36.212]. Though the mother code rate r=1/3 is not listed in the CQI table, the

performance is necessary for mapping BLER performance with Incremental

Redundancy HARQ on SLS. The transmission bandwidth is set to 25 resource blocks

(4.5MHz). Table 2.2.1.2 shows the list of evaluated modulation and coding schemes.

Table 2.2.1.2: The evaluated modulation and coding schemes

CQI

index Modulation Code rate

Spectral

efficiency

[bps/Hz]

1 QPSK 78/1024 0.1523

2 QPSK 120/1024 0.2344

3 QPSK 193/1024 0.3770

4 QPSK 308/1024 0.6016

N/A QPSK 1/3 0.6667

5 QPSK 449/1024 0.8770

6 QPSK 602/1024 1.1758

N/A 16QAM 1/3 1.3333

7 16QAM 378/1024 1.4766

8 16QAM 490/1024 1.9141

9 16QAM 616/1024 2.4063

N/A 64QAM 1/3 2.0000

10 64QAM 466/1024 2.7305

11 64QAM 567/1024 3.3223

12 64QAM 666/1024 3.9023

13 64QAM 772/1024 4.5234

14 64QAM 873/1024 5.1152

15 64QAM 948/1024 5.5547

Page 13: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 13

Figure 2.2.1.2 LTE link level BLER performance on AWGN channel

The BLER performances evaluated by the LLS are shown on Figure 2.2.1.2. The link

adaptation function on scheduler selects a MCS to get the highest spectrum efficiency

while satisfying target BLER. In typical usage with Hybrid-ARQ supported system,

target BLER is set to 10–20%. Figure 2.2.1.2 shows that the LTE supports wide range

of MCSs to utilize wide range of SNR from -7dB to 19dB with BLER=10%.

2.2.2 Link level simulator for 60GHz WiGig

The Link Level Simulation (LLS) platform was designed to support modelling of

Physical (PHY) layer defined in the IEEE 802.11ad standard [802.11ad]. It can be used

as a standalone tool to verify link level behaviour and evaluate demodulator and

decoder performance, estimate Radio Frequency (RF) chain imperfections, comply

with Error Vector Magnitude (EVM) or Spectral Mask (SM) tests. This makes LLS an

essential tool for PHY layer performance verification and gets insight into algorithmic

part of the transceiver design. The LLS tool can be used as a part of the System Level

Simulation (SLS) platform applying to estimate overall system performance and

demonstrate simultaneous work of several hundreds or thousands users for the target

scenario. In that case the LLS platform is considered as a building block which

simulates a link between the pair of devices.

The approach running LLS for every link in order to evaluate system level

performance is not feasible for the great number of users due to computational

complexity and time consumption issue. Each LLS run would need decoding of the

packets which is a hard part of its signal processing pipeline and would require

significant time and computational resources. To overcome this issue PHY abstraction

model predicting Bit Error Rate (BER) or Packet Error Rate (PER) encoded

performance without modelling of the entire LLS data flow is introduced. In that

approach LLS is used to produce the basic set of the average BER versus Signal to

Page 14: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 14

Noise Ratio (SNR) curves for the considered modulations and encoding rates in the

frequency flat channel with Additive White Gaussian Noise (AWGN). These curves

are used as an input to the PHY abstraction model in order to get instantaneous

BER/PER performance estimation for every link considered in the SLS. This PHY

abstraction model is developed for the desired channel and depends on the considered

channel type.

Figure 2.2.2 shows Packet Error Rate (PER) vs. SNR performance comparison for

OFDM (Orthogonal frequency-division multiplexing) modulations in case of

frequency flat. The curve wes simulated for ideal channel knowledge and without RF

imperfections. SNR for OFDM modulation is introduced per subcarrier in frequency

domain.

Figure 2.2.2: PSDU Packet Error Rate (PER) vs. SNR performance for OFDM

modulations in case of frequency flat channel.

-6 -4 -2 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 3410

-3

10-2

10-1

100

AWGN channel model

PE

R

SNR, dB

MCS 13

MCS 14

MCS 15

MCS 16

MCS 17

MCS 18

MCS 19

MCS 20

MCS 21

MCS 22

MCS 23

MCS 24

Page 15: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 15

3 System level simulator

3.1 Parameters for system level simulator

In this section, fundamental parameters for the system level simulation are described.

The system in focus is a mmWave overlay HetNet and it is constructed by wide area

macro BS and small area coverage BS (smallcell BS). It is assumed that the LTE-based

macro BS works in the 2 GHz band, and the 802.11ad system based smallcell BS works

in the 60 GHz band. Parameters are based on the 3GPP and the IEEE802.11ad

standards. Moreover, outputs of other project tasks are also integrated in the SLS, in

particular the new mmWave channel model. The purpose of the SLS is to investigate

the potential of the mmWave overlay HetNet integrated with edge clouds. Therefore,

some parameters e.g. CSI feedback error, signal overhead, etc. are out of scope of the

project. Details can be found in [D4.1 MiWEBA].

3.2 Resource management framework

3.2.1 Network architecture and C/U splitting

One of the key elements of the network architecture is the data and control plane

separation that is called C/U splitting. As explained in D3.1, the architecture for C/U

splitting in 3GPP is taken as the basis to realize C/U splitting scheme for the mm-wave

Overlay HetNets integrated with edge clouds. More details can be found in [D3.1].

Figure 3.2.1 - Overview of C/U-plane splitting

In the C/U splitting scheme UE can get the C-plane data via MeNB (Master eNB) and

the U-plane data via MeNB and SeNB (Secondary eNB) as shown in Figure 3.2.1.

Typically, MeNB and SeNB are the macro eNB and smallcell eNB, respectively.

According to the proposed scheme, both reliable and high throughput communications

will be realized. To be more specific, the UE can keep a main C-plane connection

active, typically within a long-range macro cell, and activate U-plane connections to

different BSs which provide the best data traffic bearers according to both user and

network status.

The general concept of the C/U splitting scheme is independent of carrier frequencies.

Nonetheless, it is necessary to enhance the architecture by introducing more flexibility

and multiple design choices. Particularly, extended network functionalities are

required to deal with mmWave C/U split.

SeNB(Secondary eNB)

C-planeU-plane

U-plane

MeNB(Master eNB)

Page 16: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 16

3.2.2 Mobility management (cell association for U-plane)

In the C/U splitting scheme, basically the network selects the UE access points. The

proposed architecture can provide a more flexible and intelligent cell association and

mobility management, taking into account the status of the whole network.

U-plane connections can be established with both macro cells and small cells leaving

room for the development of optimized resource allocation algorithms. In general, two

types of mobility can be identified, a so-called small-scale mobility, where the UE

moves within the coverage of a single control-plane macro cell and performs user-

plane handovers through small cells, while traditional mobility occurs when the UE

crosses macro cell boundaries. Mobility management among different data networks

during active communication sessions is a challenging issue. However, the advantage

of the new system architecture is that the network has the full control of resource

selection.

On the other hand, the directionality of the mmWave links requires a new kind of

mobility support at the link or beam level, concept that is named beam forming

tracking. The beam forming tracking is a crucial part of the mmWave connectivity.

The directional mmWave link continuously changes, and therefore the beam forming

vectors must be updated frequently. Such information is needed on both ends of the

mmWave link. This functionality is therefore located at the smallcell control plane

[D3.1].

3.2.3 Radio resource control

When the UE is in the idle state, it is connected to the legacy macro BS. It is assumed

that the UE is not connected to a mmWave link when idle, in order to reduce the energy

consumption. This reduce both UE power consumption and network power

consumption. In fact, the mmWave BSs can be considered to be switched off when no

data session is active. When the session is initiated by a request from the macro BS,

the macro C-plane alerts the UE. Then the UE and the appropriate small cell initiate

the directional mmWave connection. This process is summarized in Figure 3.2.3.

UEMacro-

BS

Small cell-

BS

C-plane selects

the mm-wave

small cell-BS to

serve the UE.

Alert the UE to connect to the selected mm-wave small cell BS

Initiate directional connection

Turn on command

Figure 3.2.3 Initiation of the directional mmWave connection

Page 17: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 17

For the resource allocation, the small cell polls UE for their request to communicate

and allocates the needed time slots. The macro cell C-plane orchestrates the operation

of mmWave small cells and manages the wireless medium access of mmWave devices.

It also can be used to realize scenarios where a mmWave BS simultaneously

communicates with multiple UE. In addition, considering limited backhaul, resource

scheduling over the backhaul for data prefetching or computation offloading is also

considered to further improve system performance.

3.3 System level simulator

The SLS was developed to evaluate non-full-buffer scenarios. Full-buffer scenario

evaluates the upper-bound performance of the system where mmWave links are

assumed to be exploited over the entire evaluation period. However, such situation

occurs only when there are many high traffic users. To evaluate the performance of

mmWave overlay HetNet integrated with edge clouds in realistic case, it is important

to introduce non-full-buffer scenario. Details on their procedure and execution

parameters are described below.

3.3.1 SLS procedure

Figure 3.3.1 Basic SLS procedure

The description of how the proposed SLS work is described at a functional level in

Figure 3.3.1. The configuration parameters are used for SLS initialization. The

simulator initialization part consists of such functional blocks as Simulation

Simulation configuration

Create deployment

User association

Warm Up frames

processing

User scheduling

Channel generation

Feedback generation

RX processing

SLS core. Loop over frames

Save results

Simulation setup

config_parameters

simulation_results

Page 18: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 18

configuration, Deployment creation, User association and Warm-up frames processing.

As the simulation setup ends, the SLS core begins where the main simulations are

carried out. The SLS core is a loop where each iteration is one LTE sub-frame. Each

subframe consists of User scheduling, Channel generation, Rx processing and

Feedback generation. Simulation results are collected at each iteration and are saved

at the end of the loop.

A detail description of each functional block is provided in the following sections.

3.3.2 Simulations setup

3.3.2.1 Simulation configuration

The main functionalities of this block is to read the configuration file which is the input

of the SLS and to define the common simulation parameters and the specific

parameters for the technologies (LTE and mmWave), which are enabled for our

simulation. The LTE parameters are configured according to 3GPP specifications

[TS36.211, 212, 213, 331]. The numerology for the mmWave system parameters is

presented in Table 3.3.2.1.

As the extensive measurement results on channel delay characteristics [MWB-D5.1]

have shown, the mmWave system, which is targeted at outdoor communications,

requires some modifications of the IEEE 802.11ad parameters to make mmWave

frames transmission synchronous with LTE frames.

Table 3.3.2.1 MmWave system parameters

Parameter 802.11ad LTE Rel-11

System

bandwidth

2160 MHz 5 MHz 10 MHz 20 MHz

Channels 3 1 1

FFT size 512 512 1024 2048

Subcarrier

frequency

spacing

5.15625 MHz 0.015 MHz

OFDM sample

rate

2640 MHz 7.68

MHz

15.36

MHz

30.72

MHz

Total Number

of subcarriers

(OFDM)

352 300 600 1200

Number of data

subcarriers

(OFDM)

336 270

in

average

540

in

average

1080

in

average

IDFT/DFT

period (OFDM /

SC)

0.194 μs / 0.292

µs

66.67 μs

Page 19: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 19

Guard Interval

duration

(OFDM / SC)

48.4 ns / 36.5 ns 4.69 / 5.21 μs

Symbol Interval

(OFDM / SC)

0.242 μs / 0.328

µs

71.36 / 71.88 μs

Frame duration Variable (70-700

μs for 8192

bytes)

10 ms

In our simulation, traffic demands of each user are set. mmWave system can transmit

a huge amount of data in a very short time. However, since the coverage is limited,

only a few users can really take benefits. In order to use mmWave resource effectively,

users whose traffic demand is relatively high should be accommodated into mmWave

system properly. This simulator employs the Gamma distribution traffic model

[STSA14], which is made from actual traffic data in urban area, Japan. Figure 3.3.2.1

is a CDF of the user traffic. If the properties of traffic distribution will not change in

the future, we can predict future traffic demand by controlling the scale parameter of

the Gamma distribution.

Figure 3.3.2.1 - Traffic distribution CDF

3.3.2.2 Create Deployment

Functions of this block deploy BSs (Macro and Small cells) and UE according to

defined simulation scenario. We focused mainly on non-full-buffer scenarios as

follows.

In the simulation, 7 macro BSs are deployed in a hexagonal grid. After that smallcell

BSs are deployed randomly. Figure 3.3.2.2 shows the BS deployment condition. Blue

dot indicates macro BS and green dots indicate smallcell BSs.

Page 20: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 20

Figure 3.3.2.2 - BS deployment condition

UE are uniformly deployed in a target macro cell area and their moving directivity and

orientation are also set at this step.

3.3.2.3 User association

In non-full-buffer case, UE not always demand huge traffic, therefore mmWave is only

effective for specific UE. In order to exploit the potential of mmWave, we employ a

combinatorial BS association method. This association chooses the best user

combination which can maximize system rate by solving the combinatorial

optimization problem [STSA14].

3.3.2.4 Warm Up frames processing

Warm up simulations represents several iterations of SLS core. They are needed to get

first feedback and to put SLS into the steady state. The results for these transition

periods are counted in this deliverable.

3.3.3 SLS core and Loop over frames

3.3.3.1 User scheduling

In this block each BS performs user scheduling based on proportional fair (PF) metric.

Each BS calculates PF metric and allocate resources to users who can achieve the

highest PF metric.

iiItRt

tTt

tT

tT

tRi

i

c

i

c

i

i

i

Ni

ˆ11

11

maxargˆ

UE,2,1

Where tRi and tTi are instantaneous user rate and average user rate of the i th UE

respectively. UEN is the total number of UE in a cell. ct is a time window of the

averaging filter and I is an indicator function.

300 200 100 0 100 200 300

250

200

150

100

50

0

50

100

150

200

250

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

41

47

52

57

6773

75

77

80

89

97103

105119

134

141

150

155

162

169

176

178 190

192

199

206

208

User position

Position x [m]

Po

siti

on

y[m

]

Page 21: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 21

3.3.3.2 Antenna gain calculation

According to the BS and UE positions, all distances and relative angles between BS

and UE can be calculated. Path loss and antenna gain are calculated by using these

geometric parameters. Antenna beam pattern of LTE macro BS is a 3-sectorized pattern

given as follows,

m

vv

mm

AAAA

SLASLAA

AAA

,min,

dB20,15,10,,12min

dB25,70,,12min

VH

etiltdB3

dB3

etiltV

dB3

dB3

H

where dB3 and dB3 are the horizontal and vertical half beam width respectively, etilt

is a down tilt angle. The mmWave antenna beam pattern is given by IEEE 802.11ad

channel model.

2

3

2

3

0 1212,

dBdB

GG

where 0G is an antenna gain. The horizontal and vertical half beam width are 10 in

this simulation.

3.3.3.3 Channel generation

Figure 3.3.3.3-1 Time-frequency correlated channel transfer function

(Left above: LTE macro, Right above: LTE small, Bottom: mmWave small)

Page 22: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 22

The functions of this block generate serving and interfering channels for each UE

according to the defined channel modelling scenario. For LTE transmissions ITU

UMa/UMi channel models are used and it can be generated by SCME channel model

[SCME]. For mmWave transmissions the “Open Area” case of channel model

described in [MWB-D5.1] is used. The time-frequency correlated channel is shown in

Fig. 3.3.3.3-1.

Moreover, since we consider time transition and UE movement, spatial correlated

shadowing should be introduced. The spatial correlated shadowing is generated from

uncorrelated random shadowing. From the 3GPP standard [TR36.814], the distance

dependent correlation coefficient follows an exponential function

cor

expd

dd ,

where d is a distance between 2 locations and cord is a correlation distance. In order

to generate 2D correlated shadowing map, we introduce horizontal/vertical filter

coefficient ka and diagonal filter coefficient kb . If the resolution of the shadowing is

resd , these filter coefficients are given as follows

cor

res

cor

cor

res

cor

2exp

1

exp1

d

dk

db

d

kd

da

k

k

,

k is the running filter coefficient index. We cut the exponential decay function at

maximum distance of cor4d and normalize each filter coefficient with cord . We

initialize the map with normal distribution value then apply these filters in horizontal,

vertical and diagonal by convolutional operation as follows.

rescor

rescor

rescor

rescor

4

0

4

,

5

,

4

0

3

,

4

,

4

0

2

,

3

,

4

0

1

,

2

,

1

, 1,0

dd

k

kykxkyx

dd

k

kykxkyx

dd

k

ykxkyx

dd

k

kyxkyx

yx

BbB

BbB

BaB

BaB

NB

where yxB , is a shadowing value of the position yx, . After the correlation

calculation, the edge area is removed and the values of the remaining map are

appropriately scaled to have the desired mean value μ and standard deviation σ. The

procedure of this shadowing generation is shown in Fig. 3.3.3.3-2.

Page 23: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 23

Figure 3.3.3.3-2 Spatial correlated shadowing generation

3.3.3.4 Rx processing

This block performs the receive processing for each UE using the serving and

interfering channel from the previous step. The post processing SINR is used to obtain

PER by means of PHY abstraction described in [MWB-D4.1].

3.3.3.5 Feedback generation

Using the available knowledge about the channel state, each UE calculates suitable

MCS, Tx antenna weights, and rank indicator, and reports them to its serving station.

3.3.4 System level simulator GUI

We developed a GUI for SLS by MATLAB. We can check the simulation progress

visually. Figure 3.3.4 is a snapshot of the GUI.

Figure 3.3.4 - The SLS GUI

Partially seen in Fig. 3.3.4, the simulator can calculate instantaneous user throughput,

RSRP, RSRQ, SINR, cell throughput of each BSs, and system rate. The definition of

RSRP (Reference Signal Received Power) and RSRQ (Reference Signal Received

Quality) are as follows.

Page 24: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 24

noise ceinterferen signal ofpower ReceivedRSSI

RSSI

RSRPRB of #RSRQ

signals referencefor RE of #

power received signal ReferenceRSRP

Page 25: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 25

4 Performance evaluation

4.1 Revisit of 5G-MiEdge’s scenarios

The SLS is used to evaluate different scenarios of 5G-MiEdge. In this section, we

revisit 5G-MiEdge’s selected five typical scenarios, where two among them are further

chosen to be evaluated in consecutive sections e.g. Omotenashi services and outdoor

dynamic crowd.

Omotenashi services

The aim of this use case is providing a high data rate service for users that wish to

download a streaming video at some locations (airport, shopping mall, etc.). To

guarantee service continuity while the user is moving through the airport, it is useful

to predict the mobility pattern and pre-fetch data in advance. The evaluation of this

scenario will be presented in Sect. 4.2.

Moving Hotspot

In this use case, users benefit of a service (download or upload), during their trip on a

train through a local MEC Content Server through a Wi-Fi/WiGig hotspot. Even

though the user is moving fast, it is easy to predict the target MEH where the user will

be relocated. From past users' requests, it is then possible to prefetch contents on the

target MEH and then perform a data shower when the train arrives. Since this scenario

can be seen as an extension of the previous one by adding mobility to the hotspot, its

performance evaluation is out of scope of this deliverable.

2020 Tokyo Olympic

This use case requires a combination of ultra-high connection density, high data rate

and low latency, so that resources need to be optimized properly. Inside the stadium,

many services such as virtual reality can be provided. During a match, users do not

typically move and they will be typically served, based on application preferences.

Detailed performance evaluation of this scenario is provided in [D2.3].

Dynamic crowd

This use case consists of a high dynamic change of traffic pattern. In this case, the user

mobility can be tracked, but only within a certain accuracy. Hence, it may be advisable

to pre-configure a set of target MEH, in the neighborhood of the source MEH, to be

proactive in relocating the user service. This scenario requires continuous handovers

and selection of the most suitable APs to serve the users and will be evaluated in Sect.

4.3.

Automated driving

In this use case, mobility is extremely high and application relocation (for cooperative

perception, HD maps, safety etc.) should be provided every time a car moves from the

coverage area of a Road Side Unit (RSU) to another one. Evaluation of this scenario

requires a novel channel model among cars and between car and RSU, which are yet

available to this project. Thus, this deliverable does not include performance

evaluation of this scenario.

Page 26: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 26

4.2 Performance evaluation on data prefetching

4.2.1 Extension of the basic SLS

In this section, we extend the basis SLS architecture in Sect. 3 to enable performance

evaluation of data prefetching using mmWave edge cloud. Figure 4.2.1 shows the

architecture of the 5G cellular network in focus, which uses mmWave edge cloud. The

architecture is a HetNet that is composed of several mmWave small cells overlaid on

top of a conventional macro cell deployment. The macro cell BS collects context

information such as user mobility and traffic in the C-plane and deals with small and

real-time traffic in the U-plane. The small cell BS deals with large traffic in the U-

plane, so that the utilization of mmWave high speed access is needed. Based on the

latest status of the fiber penetration in the world, it would not be possible to broadly

deploy the mmWave access, due to fact that the huge amount of data flowing through

it would not be properly managed by the backhaul, which would act is this case as the

real bottleneck of the system. To address such limitation, storage is installed in each

small cell BS, with the main task of allowing for data prefetching. The prefeching is

expected to release the backhaul bottleneck and achieve high data rate and low delay

by showing full potential of mmWave access.

Figure 4.2.1 - Illustration of 5G cellular network using mmWave edge cloud

4.2.2 System level simulator to evaluate data prefetching

In order to evaluate the system performance on data prefetching, we extend the

developed SLS explained in Sect. 3. Figure 4.2.2 shows the SLS configuration. The

simulator is composed of four sections, set simulation parameters (yellow), generate

all status of users, BSs and channels (blue), measurement over time progress (red),

save the simulation results (green).

Page 27: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 27

Figure 4.2.2 - Updated SLS procedure extending for data prefetching.

4.2.2.1 Simulation parameters

In this block all parameters used in the simulation are defined, such as total number of

UE and BS, antenna configuration with respect to macro, small cell BS and UE, carrier

frequency and bandwidth, et al. All parameters are indicated in their respective relevant

parts.

4.2.2.2 Users and base stations deployments

In this block, deployments of macro cell, small cell BS and UE are generated. Figure

4.2.2.2 shows a possible deployment, which adopts a HetNet configuration. The focus

is on one macro cell with radius R (blue), surrounded by six macro cells that create

interference (green), and populated randomly by several hotspots with radius r. One

small cell BS is set at the center of the hotspot. A 3GPP hotspot model, based on the

ratio between the number of UE in the hotspot and outside of it, is used for defining

the positions of the UE, most of them are dropped within the hotspot [TR36.814]. Table

4.2.2.2 shows the main parameters of the deployment.

Table 4.2.2.2 - Parameters of deployment

Parameter Value

Macro cell radius 𝑅 250 m

Hotspot radius 𝑟 40 m

Number of hotspots 12

Page 28: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 28

Number of small BSs 12

Number of users 200

User dropping model 3GPP hotspot

Figure 4.2.2.2 - Illustration of users and base stations deployments

4.2.2.3 Generate user mobility and traffic

Mobility model

In the previous block, users (UE) are created following the 3GPP hotspot model.

Then in this block, after the initial UE allocation, users’ movements are triggered.

However, the 3GPP hotspot model does not support movements and therefore we have

developed a new mobility model to take into consideration the movements and the

time scale. Figure 4.2.2.3-1 shows an example of user’s mobility in the macro cell

under evaluation. The user’s movement process works as follows:

1. The user selects one hotspot area randomly as a destination when entering the

evaluation macro cell.

2. The user moves to the destination and stays there for a certain time.

3. The user goes outside of the macro cell.

4. The user enters the macro cell as a new user, then goes out of the macro cell

again and again until the end of evaluation time.

The user moves from the initial position (circle) to the end position (square).

Destination (star) in Fig. 4.2.2.3-1 is the final destination, which changes depending

on the state, i.e. if the user goes to the hotspot area or outside of the macro cell. The

user stays at nomadic position (triangle). Table 4.2.2.3-1 shows parameters of the

mobility model. Figure 4.2.2.3-2 shows user’s spatial distribution. It can be derived

from the Fig. 4.2.2.3-2 that the ratio between the average number of UE in the hotspot

and that outside the hotspot matches the 3GPP hotspot model.

Traffic model

In this block, the size and interval of user demand traffic are generated by the new

developed model. As a conventional model, a traffic model is used whose size is

decided following a gamma distribution, which is created by fitting a measurement

Page 29: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 29

data, and the obtained average parameter is multiplied by 1000, in anticipation of 10

years future. Table 4.2.2.3-2 shows the parameters of the traffic model. However, in

realistic environment, it should be considered that user traffic depends on user position

and status. Accordingly, based on conventional model, we developed a new traffic

model. In the model, walking users demand small data (e.g. mail, web), whereas users

that do not move demand large data (e.g. video, application update). Figure 4.2.2.3-3

shows the cumulative distribution function of the new traffic model. Red and blue

traffic are generated by the staying user and the and moving user, respectively. It can

be seen that large traffic and small traffic are separated depending on user state while

the distribution confirms a good match with the conventional model.

Table 4.2.2.3-1 Parameters of mobility model

Parameter Value

User speed 1 m/s

Grid width 25 m

Avg. staying time (exp dist.) 500 s

Table 4.2.2.3-1 Parameters of traffic model

Parameter Value

Traffic size Gamma distribution with shape and scale parameters

of 0.2892 and 2.012 ×105 respectively

Traffic bias 4 kbit

Traffic interval Exponential distribution of avg. 8 s

Timeout 60 s

Figure 4.2.2.3-1 Illustration of user’s mobility

Page 30: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 30

Page 31: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 31

Figure 4.2.2.3-2 Illustration of user’s spatial distribution

Figure 4.2.2.3-3 Illustration of CDF of traffic size

4.2.2.4 Generate channel

In Sect. 4.2.2.3, positions of users and BSs are decided. This block generates a detailed

antenna structure and all channels between users and BSs using the QuaDRiGa channel

generator. The channel generator enables the modeling of MIMO radio channels for

specific network configurations such as heterogeneous configurations. Table 4.2.2.4

shows parameters of UE and BS antenna configuration. Macro and small cell BSs

basically confirm 3GPP and IEEE802.11ad standard. Each macro and small cell BS

has 3 sector antennas. Especially, small cell BS has massive elements antenna, a

backhaul line with limited resource and a storage.

Table 4.2.2.4 - Parameters of UE and BS antenna configuration

Parameter Value

Carrier frequency (macro/small) 2.1 GHz / 60 GHz

Bandwidth (macro/small) 10 MHz / 2.16 GHz

Number of sectors (macro/small) 3 / 3

Number of antenna elements (macro/small/UE) 4 / 128 / 2

Antenna height (macro/small/UE) 25 m / 4 m / 1.5 m

Antenna beam pattern (macro/small/UE)

3GPP macro / 11ad

channel model /Half

wave dipole

Tx power (macro/small) 46 dBm / 10 dBm

Page 32: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 32

Figure 4.2.2.4 Illustration of small cell base station equipment

4.2.2.5 Backhaul resource allocation (Prefetching)

We assume heterogeneous networks considering limited backhaul resource. In the

environment, the way to allocate the limited resource greatly affects the performance.

Prefetching process

In this section, it is explained how to prefetch user data in reality. For prefetching, it is

important to select appropriate indices of small cell BS s, user u and traffic n. They are

decided based on context information collected via C-plane of macro cell BS. Figure

4.2.2.5-1 shows illustration of a periphery of the small cell BS s. The process is as

follow:

1) Get user destination information by any application (e.g. calendar)

2) Predict traffic and connectable small cell BS 𝑠 at the destination

3) Regard user within time window Tp as target to prefetch when user approaches

the destination

4) Select user 𝑢 and traffic 𝑛 by prefetching algorithm

In the process 2, connectable small cell BS means a BS to maximize SINR. It is

possible to understand SINR (communication area) by measuring it and making power

map beforehand. In the process 3, Tp is a time window to start prefetching. In the

process 4, prefetching algorithm means an algorithm which selects proper user u and

traffic n in the users regarded as target to prefech at the process 3 and is explained in

the next section.

Page 33: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 33

Figure 4.2.2.5-1 Illustration of a periphery of the small cell s

Prefetching algorithm

In the last step in the prefetching process, combination of user u and traffic n is selected

by prefetching algorithm. Figure 4.2.2.5-2 shows illustration of traffic demand at the

small cell s. The horizontal and vertical axes show time and traffic demand,

respectively. A user u demands data n whose size is Lu,n at time tu,n. Now, we consider

which traffic backhaul resource CB should be allocated to at time t. In this simulation,

we compare two algorithms. The one is round robin (RR) which randomly selects user

u and traffic n. The other is weighted proportional fairness (WPF) which sets an

objective function considering user context information and selects user u and traffic

n to maximize it. The objective function Ou,n(t) is defined as

,

, ,

p

,

,

( ) ( )( )

( )

u n

u n u n

u

u n

u n

LO t w t

B t

Tw t

t t

where Bu(t) is the allocated backhaul resource to user u until time t, wu,n(t) is weight

coefficient taking into account the traffic generation time tu,n for user u and traffic n at

time t. wu,n(t) is a ratio of Tp against margin time defined as the difference between tu,n

and t. α is called PF coefficient which changes priority of weight coefficient. There are

two reasons why we set the function form like this. First, large traffic should be

accommodated to small cell BS to utilize fully mmWave high speed capacity

(conversely it is possible to deal with small traffic with macro cell). Second, wu,n(t)

increases as traffic generation time tu,n approaches time t, that means to allocate data

in advance as much possible in the storage before users really download the traffic.

Page 34: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 34

Figure 4.2.2.5-2 Illustration of traffic demand at the small cell s

4.2.2.6 Performance indices

In this simulation, we define two indices to evaluate performance of edge cloud.

System rate

System rate R is defined as a total rate of all macro and small cell as follows,

S SM

SM

M S ,M SM S

remremS , ,M , ,

1 1 1s s,

min , min ,j s j

N JJu s ju j u su

j u s j uj s j

W CW C DLR

T T

M SM S

where WM and WS are the available bandwidth at macro cell and small cell. and

are link capacity for user u, smallcell s. Ts is the timeslot width. rem

uL is the

instantaneous remaining traffic demand of user u. Ns is the total number of small cell

BSs. JM and JS are the number of sectors at macro cell BS and smallcell BS. is the

set of users belonging to a sector jM of macro cell BS and is the set of users

belonging to a sector jS of small cell BS s. rem

,u sD is the data stored in storage for user

u and small cell s which is expressed in detail as

rem rem

, B ,min ,u s u s uD C T L

where Tu,s is the total timeslot for user u at small cell s decided by the presented

prefetching algorithm. Namely, if not prefetching, limited backhaul restricts small cell

rate and system rate will decrease. However, if prefetching is applied, mmWave high

speed access will be released from the backhaul bottleneck and fully demonstrate the

capability. Eventually, it is expected that the system rate will increase.

Delay on access

Delay on access τ is defined as the gap between time tu,n at which user demands

traffic and time tu,nend at which all of the demand traffic is delivered. The formula

is represented as follows, end

, ,u n u nt t .

However, because a timeout is introduced in traffic model, the delay cannot

exceed this value. If mmWave access is utilized effectively with prefetching or

sufficient backhaul, the delay on access is expected to be decreased.

M,u jC

S, ,u s jC

MM j

S,Ss j

Page 35: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 35

4.2.2.7 Simulation results

In this section, the simulation results are shown. Figure 4.2.2.7-1 shows the system

rate defined in previous section for each backhaul capacity on the condition that the

number of users, the storage limit and the time window are 200, infinity and 500s,

respectively. In the figure, red circle, green triangle and blue square show WPF

algorithm, RR and without prefetching, respectively. In the case of zero or too small

backhaul capacity, small cell BSs do not function and the system rate is equivalent to

only macro cell rate which has about 100Mbps. In the case of 10Gbps or more ones,

the system rate even without prefetching achieves the maximum rate. This means

prefetching function is not needed with sufficient backhaul, however, it is unlikely

from the viewpoint of current low optical fiber penetration rate in the world. The most

noteworthy point is at 1Gbps backhaul. The system rate with prefetching is much

bigger than that without prefetching. The result proves that it is possible to improve

deterioration of system rate thanks to effect of prefetching and storage. In addition, the

system rate with WPF algorithm is bigger than that with RR and achieves about 95%

of maximum rate achieved without prefetching at 10Gbps backhaul. From the result,

superiority of including the algorithm is validated.

Figure 4.2.2.7-2 shows the average of the delay on access defined in previous section

for each backhaul capacity on same condition with Fig. 4.2.2.7-1. Only macro cell

(zero backhaul capacity) cannot accommodate most of large demand traffic expected

in the next 10 years and the delay becomes equal to the timeout set in Sect. 4.2.2.3. In

particular, WPF with 1Gbps backhaul capacity reduces to about 33% of the delay

without prefetching.

Figure 4.2.2.7-3 shows the system rate for each number of users on the condition that

the backhaul capacity, storage limit and the time window are 1Gbps, infinity and 500s,

respectively. The system rate increases linearly from 0 to 200 users because the

network still has sufficient communication resources and thus most of demanded

traffic were successfully delivered in this region. In the next region of 200 to 500 users,

deliverability of demanded traffic starts to decrease due to the shortage of

communication resources and therefore the system rate increases slowly due to

saturation. From 500 or more users, the system reaches its limitation and the system

rate converges a constant value. Comparing the two algorithms, it is shown that the

gap of their system rates increases as the number of users increases. In short, in the

environment where many users exist, the presence of the proposed algorithm will be

more important.

Figure 4.2.2.7-4 shows the loss of system rate for each storage limit and time window

on the condition of i.e. 1Gbps backhaul capacity, WPF algorithm and 200 users,

respectively. The loss of system rate is defined as a ratio against maximum system rate.

In this figure, the colors show the loss level and the boundaries are drawn every 1% of

loss. Basically, storage limit and time window should be set to small value because

small storage limit keeps installation cost down and small time window prevents

deterioration of performance from miss-prefetching if the error of context information

is included. However, as shown in the figure if those values are too small, the loss of

system rate increases. The reason is that a large amount of data cannot be stored in too

small value storage, and prefetching is not in time for traffic generation time in case

of too small time window. Therefore, proper values should be selected. For example,

Page 36: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 36

if we select 6GB and 50s as values of storage and time window respectively, we can

achieve the equilibrium point in the zone of zero loss.

Figure 4.2.2.7-1 System rate for each backhaul capacity

Figure 4.2.2.7-2 Avg. access delay for each backhaul capacity

Page 37: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 37

Figure 4.2.2.7-3 System rate for each number of users

Figure 4.2.2.7-4 Loss of system rate for each storage limit and time window

Page 38: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 38

4.3 Performance evaluation on computation offloading

4.3.1 mmWave edge cloud for computation offloading

In this section, the focus is on computation offloading of computationally heavy tasks

from mobile devices to edge cloud resources through mmWave small cells. The 5G

cellular network architecture with mmWave edge cloud we consider is shown in Fig.

4.3.1. For our evaluation with this architecture, U-plane is handled by mmWave small

cell BS due to the need of the high-speed access necessary to meet strict latency

constraints. The entity responsible of running users’ applications is a mobile edge host

(MEH), accessible from the mmWave small cells through a backhaul (blue line in the

figure). Offloading heavy applications to a MEH enable mobile users in running them

within low latency constraints, with reduced power consumption. Given this

architecture, in the next sections we will formulate the problem of computation

offloading and show an exemplary scenario considering user mobility and multi-link

communications as a way to counteract blocking events, typical of mmWave

communications. Finally, we will show performance evaluation.

Figure 4.3.1 – 5G cellular network with mmWave edge cloud for computation

offloading

4.3.2 Problem statement

In our evaluation, we assume that the applications the users are running (e.g. real time

object recognition) are too computationally heavy to be run at the mobile side, so that

offloading is necessary. As performance metrics, we use computation queues,

communication queues, and the transmit power for the offloading. It has been

extensively studied that it is convenient, in terms of transmit power, to jointly allocate

communication and computation resources, see e.g., [BSDL14], [SSB15]. Here, radio

and computation resources are jointly optimized in a slot fashion, based on the current

queue states, with the objective of minimizing the total transmit power under latency

constraints. We consider time as divided in slots, and in each time slot a certain amount

of computation requests is generated, with a corresponding number of bits to be

transmitted to transfer the execution to the MEH. Each user is also capable, when

possible, of communicating with multiple links (two in our scenario) at the same time,

to reduce the power consumption and to counteract blocking events typical of

Page 39: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 39

mmWave communications, as in [BCMC17], [BCM17]. Each AP is then connected to

a MEH through a high capacity backhaul, as shown in Fig. 4.3.2, where vehicles

represent obstacles, i.e. typical blocking objects.

Figure 4.3.2 - Computation Offloading Scenario

We denote by 𝑄comp,𝑘(𝑡) the computation queue of user 𝑘 at time slot 𝑡 (CPU cycles)

and by 𝑄comm,𝑘(𝑡) the communication queue (bits), by 𝑝𝑘,𝑖(𝑡) the transmit power of

user 𝑘 over link 𝑖 , 𝑎𝑘,𝑖(𝑡) the channel gain, 𝐵 the bandwidth, 𝑓𝑘 the computation

resources allocated to user 𝑘 by the MEH (CPU cycles/s). Then, the optimization

problem in time slot 𝑡 can be written as follows:

where

Page 40: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 40

is a decision variable, based on the availability of the 𝑖-th AP for user 𝑘. In particular,

user 𝑘 will transmit over link 𝑖 if and only if this is not blocked. Constraint 𝑖) is the

latency constraint, so the one that couples the communication and the computation

time. Constraint 𝑖𝑖) and 𝑖𝑖𝑖) ensure that the transmit power is in the feasible region of

the optimization problem, i.e. the transmit power of a device is positive and less than

a power budget. Constraint 𝑖𝑣) is relative to the feasible region for the computational

resources. In particular, computation resources allocated to a user cannot exceed the

total computation power of the MEH. Finally, constraint 𝑣) ensures that the sum of all

computation resources allocated to the users admitted to the offloading does not exceed

the total computation resources of the MEH. Indeed, in each time slot the algorithm

also performs an admission control phase, based on the feasible set of the problem. Of

course, if a user finds both links blocked, it is not admitted to the system. In particular,

when a certain user is not admitted to the offloading procedure, its computation and

communication queues are cumulated in its buffer during all time slots, until it is not

admitted again. Then, it will have to transmit all the information that has not been

transmitted and the MEH has to perform all the computations that have not been

performed. This condition will affect the overall transmit power. The evolution of the

computation queues can be written as follows

where 𝐴𝑘(𝑡) is the amount of computation requests arrived at the previous time slot,

modeled as a random process with mean �̅�𝑘

4.3.3 Scenario Definition

In Fig. 4.3.2 we show an exemplary scenario, composed by a road intersection and

three users wishing to offload their applications to a MEH through two different

mmWave APs. We consider that, due to obstacles (represented by vehicles in this case),

the communication toward a specific AP can be interrupted. When both links are

available, each user sends information to both APs, which are linked to a MEH through

a high capacity backhaul, so that they send information bits necessary to transfer the

applications. In this scenario, UE 3 is moving while the other two users have no

mobility, but all users continuously send information bits to be processed (e.g. images

for object detection). While UE 3 moves, a blocking event may occur, as in Fig. 4.3.3,

where we show some snapshots of the evolution of the scenario.

Page 41: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 41

Figure 4.3.3 - Evolution of the scenario

In this setting we compare the performance of the double link case with a single link

case in which, when a blocking event occurs, the user has to wait until the link is again

available. We evaluate the performance in terms of power consumption, while looking

at the evolution of the computation queues.

4.3.4 Simulation parameters and performance evaluation

In this section we show the performance of computation offloading in the scenario

presented in section 4.3.3, with simulation in MATLAB environment. U-plane is

handled by mmWave small cells, with parameters as defined in Table 3.3.2.1 in Sect.

3. We assume that both mmWave AP and the UE are capable of exploiting

beamforming techniques thanks to multi-antenna systems. Other simulation

parameters are related to MEH capabilities (edge cloud related parameters) and UE’s

radio and computation requests and are reported in Table 4.3.4.

Page 42: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 42

In Figs. 4.3.4-1 and 4.3.4-2 we show the performance of the proposed algorithms in

terms of cumulative transmit power and computation queues, respectively. Each

evaluation is done for a single link case, in which a user is capable of communicating

with a single link at a time, and for the double link case. Looking at Fig. 4.3.4-1, it is

possible to see the gain of exploiting double link communications, in terms of transmit

power, both during non-blocking conditions (from time slot 1 to time slot 200) and

when a blocking occurs (around time slot 200). Indeed, in this case, the single link

waits for the blocking to end and cumulates computation requests and bits to be

transmitted. When the blocking ends, the UE transmits all the cumulated requests,

increasing the transmit power due to the latency constraint. In Fig. 4.3.4-1, we show

the evolution computation queues. In particular, the first two users maintain their

queues stable in both cases, since no blocking events occur for UE1 and UE2, while

the queue of UE3 experiences an increase around time slot 200, in correspondence of

the occurrence of the blocking event.

After time slot 200, UE3 is able to communicate and sends all the cumulated bits with

the corresponding computation requests to the MEH.

TABLE 4.3.4 Simulation parameters Parameter Value

Average

computation

request arrival

rate �̅�𝑘

107

Bits to be

transmitted in

each time slot

5*105

Computation

power of MEH

[CPU cycles/s]

3*109

Slot duration

[ms]

100

Latency

constraint [ms]

10

Number of UE 3

UE mobility 1 m/s

Carrier

frequency [GHz]

60

Page 43: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 43

Figure 4.3.4-1 Overall cumulative Transmit power vs. Time slot

Figure 4.3.4-2 Evolution of the computation queues vs. Time slot

To summarize, in this section we evaluated the performance of computation offloading

in a urban scenario with the mmWave edge cloud, showing the advantages of multi-

link communications and the dynamic evolution of computation queues. Multi-link

communications are advantageous not only in case of blocking events, but also in cases

without blocking, since the data rate can be improved with the same transmit power,

or equivalently, the transmit power can be decreased to obtain the same data rate.

Page 44: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 44

5 Summary

This deliverable concludes task T4.1: System level performance evaluation. It provides

detailed information on the following aspects:

Simulator architecture

Development and implementation of the system level simulator

Performance evaluation

With the system level simulator, based on the described simulator architecture, a

thorough performance evaluation on prefetching algorithms and multi-link

connectivity was conducted.

The in-depth evaluation lead to very promising results:

1. Data prefetching drastically improves the system performance and further

increase the data rates

2. Multi-link communication not only improves the overall data rates, but also

greatly benefits the system reliability in case of blocking events.

Even though the results are preliminary and without the constraints and limitations of

hardware and outdoor scenarios, they do provide a great starting point and necessary

parameters for the hardware developed in task T4.2: Development of common/joint

5G-MiEdge Testbed and finally T4.3: Field trials toward Tokyo Olympic, when the

developed system will be extensively evaluated in real-world scenarios.

Page 45: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 45

Page 46: 5G-MiEdge · Deliverable Horizon2020 EUJ-01-2016 723171 Date: 5G-MiEdge D4.1 Public June 2018 Deliverable 5G-MiEdge Page 10 2 Simulator architecture 2.1 The overall architecture Figure

Deliverable Horizon2020 EUJ-01-2016 723171 5G-MiEdge D4.1

Date: June 2018

Public Deliverable

5G-MiEdge Page 46

6 References

[802.11ad] "Implementation of 60 GHz WLAN Channel Model," IEEE 802.11 doc. 0854r3.

[BCM17] S. Barbarossa, E. Ceci, M. Merluzzi, “Overbooking radio and computation

resources in mmW-mobile edge computing to reduce vulnerability to channel

intermittency”, 2017 European Conference on Networks and Communications

(EuCNC 2017), pp. 1-5, June 2017

[BCMC17] S. Barbarossa, E. Ceci, M. Merluzzi, E. Calvanese-Strinati , “Enabling effective

Mobile Edge Computing using millimeterwave links”, 2017 IEEE International

Conference on Communications Workshops (ICC 2017), pp. 367 - 372, May

2017

[BSDL14] S. Barbarossa, S. Sardellitti, P. Di Lorenzo, “Communicating while Computing:

Distributed Cloud Computing over 5G Heterogeneous Networks”, IEEE Signal

Processing Magazine, Special Issue on Signal Processing for the 5G Revolution,

November 2014, pp. 45-55.

[D2.3] 5G-MiEdge deliverable D2.3, “Design of mmWave antennas for 5G enabled

stadium”, Available online at: http://5g-miedge.eu.

[D3.1] 5G-MiEdge deliverable D3.1, “Architecture of mmWave edge cloud and

requirement for control signaling”. Available online at: http://5g-miedge.eu. [MWB-D4.1] System Level Simulator Specification

[MWB-D5.1] Channel Modeling and Characterization

[STAS14] H. Shimodaira, G. K. Tran, K. Araki, K. Sakaguchi, S. Nanba, T. Hayashi and S.

Konishi, "Cell Association Method for Multiband Heterogeneous Networks,"

Personal, Indoor and Mobile Radio Communications (PIMRC Workshops),

2014 IEEE 25th International Symposium on, Sep. 2014.

[SSB15] S. Sardellitti, G. Scutari, S. Barbarossa, “Joint Optimization of Radio and

Computational Resources for Multicell Mobile-Edge Computing”, IEEE Trans.

on Signal and Information Processing over Networks, June 2015, pp 89-103.

[SCME] D. S. Baum, J. Salo, M. Milojevic, P. Kyösti and J. Hansen, "MATLAB

implementation of the interim channel model for beyond-3G systems (SCME),"

May 2005. [Online]. Available: http://www.tkk.fi/Units/Radio/scm/.

[TR36.814] 3GPP TR 36.814, "Further advancements for E-UTRA physical layer aspects".

[TS36.211] 3GPP TS 36.211, "Evolved Universal Terrestrial Radio Access (E-UTRA);

Physical channels and modulation".

[TS36.212] 3GPP TS 36.212, "Evolved Universal Terrestrial Radio Access (E-UTRA);

Multiplexing and channel coding".

[TS36.213] 3GPP TS 36.213, “Evolved Universal Terrestrial Radio Access (E-UTRA);

Physical layer procedures”.

[TS36.331] 3GPP TS36.331, Evolved Universal Terrestrial Radio Access (E-UTRA); Radio

Resource Control (RRC); Protocol specification.

[TW05] E. Tuomaala and H. Wang, "Effective SINR approach of link to system mapping

in OFDM/multi-carrier mobile network," in Proc. Int. Conf. Mobile Tech., Appl.

Syst., Nov. 2005.


Recommended