Вы находитесь на странице: 1из 46

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

1 Date : June 2018


Public Deliverable

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.

5G-MiEdge Page 1
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 Gia Khanh Tran khanhtg@mobile.ee.titech.ac.jp
Technology
Hiroaki Nishiuchi nishiuchi@mobile.ee.titech.ac.jp
Kei Sakaguchi sakaguchi@mobile.ee.titech.ac.jp
Sapienza University of Rome Mattia Merluzzi mattia.merluzzi@uniroma1.it
Sergio Barbarossa sergio.barbarossa@uniroma1.it
Fraunhofer- Heinrich-Hertz- Konstantin Koslowski konstantin.koslowski@hhi.fraunhofer.de
Institut
Panasonic Koji Takinami takinami.koji@jp.panasonic.com
INTEL Valerio Frascolla valerio.frascolla@intel.com

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

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

5G-MiEdge Page 3
4

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

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

5G-MiEdge Page 4
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

5G-MiEdge Page 5
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

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

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.

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

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

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.

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

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.

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

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.

TABLE 2.3.1 - PARAMETERS FOR THE LTE


Parameter Value
Modulation QPSK, 16QAM, 64QAM
Multiplexing OFDM (15kHz sub-carrier spacing, 4.7 or 5.2s cyclic prefix)
Coding LTE Turbo code (base coding rate R=1/3, K=4, QPP interleave)
Transmission 25 resource blocks (4.5MHz)
bandwidth
Channel model AWGN

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.

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

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
Spectral
CQI
Modulation Code rate efficiency
index
[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

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

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

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

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.

0
AWGN channel model
10
MCS 13
MCS 14
MCS 15
MCS 16
MCS 17
MCS 18
-1
10 MCS 19
MCS 20
MCS 21
PER

MCS 22
MCS 23
MCS 24
-2
10

-3
10
-6 -4 -2 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34
SNR, dB

Figure 2.2.2: PSDU Packet Error Rate (PER) vs. SNR performance for OFDM
modulations in case of frequency flat channel.

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

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].

C-plane
U-plane

U-plane
MeNB SeNB
(Master eNB) (Secondary eNB)
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.

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

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.
Small cell- Macro-
UE
BS BS

C-plane selects
the mm-wave
small cell-BS to
serve the UE.

Turn on command

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

Initiate directional connection

Figure 3.2.3 Initiation of the directional mmWave connection

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

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

config_parameters

Simulation setup

Warm Up
Simulation Create User
frames
configuration deployment association
processing

SLS core. Loop over frames

Feedback RX Channel User


generation processing generation scheduling

Save results simulation_results

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

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

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 2160 MHz 5 MHz 10 MHz 20 MHz
bandwidth
Channels 3 1 1
FFT size 512 512 1024 2048
Subcarrier 5.15625 MHz 0.015 MHz
frequency
spacing
OFDM sample 2640 MHz 7.68 15.36 30.72
rate MHz MHz MHz
Total Number 352 300 600 1200
of subcarriers
(OFDM)
Number of data 336 270 540 1080
subcarriers
in in in
(OFDM)
average average average
IDFT/DFT 0.194 μs / 0.292 66.67 μs
period (OFDM / µs
SC)

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

Guard Interval 48.4 ns / 36.5 ns 4.69 / 5.21 μs


duration
(OFDM / SC)
Symbol Interval 0.242 μs / 0.328 71.36 / 71.88 μs
(OFDM / SC) µs
Frame duration Variable (70-700 10 ms
μs for 8192
bytes)
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.

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

User position
77
119 105 89 75
250 26
12 80
200 103 73
97 19 67
10 28
150 5
1 22 31 52
100 3 18
Position y [m] 150 11 30 41
50 24
27 9 57
141 21
0 16
8 25
50 4
134 23 14
100 6 2
17 47
150 29 15
176 206
200 162 20 192
13
169 7 199
250
178 190 208
155
300 200 100 0 100 200 300
Position x [m]
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.
R t 
iˆ  arg max i
i 1, 2, N Ti t 
UE


Ti t   1 
1 
Ti t  1  Ri t   I iˆ  i

1
 
 tc  tc

Where Ri t  and Ti t  are instantaneous user rate and average user rate of the i th UE
respectively. N UE is the total number of UE in a cell. t c is a time window of the
averaging filter and I   is an indicator function.

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

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,
    
AH     min 12 , Am ,  3dB  70  , Am  25dB
   3dB  
     etilt  
AV     min 12 , SLAv ,  3dB  10  , etilt  15  , SLAv  20dB
   3dB  
A ,    min  AH    AV  , Am 

where 3dB and  3dB 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 2
     
G  ,   G0  12     12   
  3dB    3dB 
where G0 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)

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

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
 d 
 d   exp   ,
 d cor 
where d is a distance between 2 locations and d cor is a correlation distance. In order
to generate 2D correlated shadowing map, we introduce horizontal/vertical filter
coefficient a k and diagonal filter coefficient bk . If the resolution of the shadowing is
d res , these filter coefficients are given as follows
1  kd 
ak  exp  res 
d cor  d cor 
,
1  k 2d res 
bk  exp  
 d 
d cor  cor 
k is the running filter coefficient index. We cut the exponential decay function at
maximum distance of 4d cor and normalize each filter coefficient with d cor . We
initialize the map with normal distribution value then apply these filters in horizontal,
vertical and diagonal by convolutional operation as follows.
B x1,y  N 0,1
4 d cor d res 
B x2,y  a
k 0
k B x1,y  k

4 d cor d res 
B x3,y  a
k 0
k B x2k , y

4 d cor d res 
B x4,y   b B 
k 0
k
3
xk , y k

4 d cor d res 
B x5,y   b B 
k 0
k
4
xk , y  k

where Bx , y is a shadowing value of the position x, y  . 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.

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

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.

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

RSRP 
 Reference signal received power 
# of RE for reference signals
# of RB  RSRP
RSRQ 
RSSI
RSSI  Received power of signal  interference noise

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

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.

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

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).

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

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

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

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

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

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
Gamma distribution with shape and scale parameters
Traffic size
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

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

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

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
3GPP macro / 11ad
Antenna beam pattern (macro/small/UE) channel model /Half
wave dipole
Tx power (macro/small) 46 dBm / 10 dBm

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

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.

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

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
Lu , n
w (t ) 

Ou , n (t )  u ,n
B (t )
u

Tp
wu , n (t ) 
tu , n  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.

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

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,
 JM  WM Cu , j L rem  NS J S W C D rem 
R      min  M
, u      min  S u , s , jS , u , s 
 jM 1 uM jM  Mj Ts  s 1 jS 1 uSs , jS  Ss , j Ts 
  M   S 
where WM and WS are the available bandwidth at macro cell and small cell. Cu , j and M

Cu , s , jS are link capacity for user u, smallcell s. Ts is the timeslot width. Lu


is the rem

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. M j is the M

set of users belonging to a sector jM of macro cell BS and Ss , j is the set of users
S

belonging to a sector jS of small cell BS s. Du , s is the data stored in storage for user
rem

u and small cell s which is expressed in detail as


Du , s rem  min  CBTu , s , Lu rem 

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,
  tuend
, n  tu , n .

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.

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

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,

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

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

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

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

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

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

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

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

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.

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

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.

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

TABLE 4.3.4 Simulation parameters


Parameter Value
Average 107
computation
request arrival
rate 𝐴̅𝑘
Bits to be 5*105
transmitted in
each time slot
Computation 3*109
power of MEH
[CPU cycles/s]
Slot duration 100
[ms]
Latency 10
constraint [ms]
Number of UE 3
UE mobility 1 m/s
Carrier 60
frequency [GHz]
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.

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

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.

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

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.

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

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

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.

5G-MiEdge Page 46

Вам также может понравиться