You are on page 1of 66

An

 introduction  to  5G


architecture  and  use  cases

Ahmed  Elmokashfi
Simula Metropolitan  CDE

Summer  School  in  Future  Energy  Information  Networks  


September  7th 2018
1G 2G 3G 4G 5G

1980 1990 2000 2010 2020


2
*img-­‐src:  ClipartPanda.com
The  focus  has  so  far  been  on  supporting  
voice,  data  and  better  spectral  efficiency    

Generation Spectral  efficiency  (bps/Hz)


1G 0.064  
2G 0.17-­‐0.45
3G 0.51  – 4.22
4G 7.3  -­‐ 30
3
Src:Clarke RN.  Expanding   mobile  wireless  capacity:  The  challenges  presented   by  technology   and  economics.  Telecommunications   Policy.  2014 Sep  1;38(8-­‐9):693-­‐708.
The GSM Family - Delivering on Promises

HSPA+ in 2008 LTE


172 Mbps
HSPA in 2005

HSPA+
EDGE in 2003 42 Mbps

3G in 2001 HSPA
14.4 Mbps
EDGE
WCDMA 473 kbps
GPRS in 2000
384 kbps
GSM First call
made in 1991 GPRS
114 kbps HSPA: 120 million cnt
GSM
9.6 kbps
3G WCDMA: 238 million cnt

2G GSM: 3.8 billion cnt


1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
Source: Wireless Intelligence, June, 2009

NEARLY TWO DECADES OF PROVEN TECHNOLOGY AND EXPERIENCE


4
© GSM Association 2009 HSPA+ peak theoretical data rate reaches up to 42 Mbps when using single carrier with QAM 64 and 2x2MIMO
However,  no  substantial  architectural  
innovations  since  2G
Radio  Radio
Access  aksessnett
Network  (RAN) Core  
Network  
Mobilt (CN)
kjernenett Eksternt nett

LTE
MME( HSS(

Serving( PDN(
GW( GW(

EPS bearer The  


Interne5(
Internet

RNC( SGSN( GGSN(

PDP context
Datatrafikk

UMTS HLR( Signaleringstrafikk


5
Mobile  traffic  is  expected  to  grow  to  49  
exabytes per  month  by  2021  
49  EB

35  EB
Exabytes
per  Month
24  EB

17  EB
11  EB
7  EB

2016 2017 2018 2019 2020 2021

The  number  of  connected  devices  is  projected  to  


grow  by  50%  from  8  to  12  billions  
6
*src:  Cisco  VNI  
Outline

5G  vision  

Operators Verticals Enterprise 3rd party

Management & Orchestration


5G  realization  
Service Layer

(MANO)
Control Plane User Plane

Mapping
Configuration Life-Cycle
Functions Functions

Network Function Layer

Radio
(Edge) Core
Access Control Allocation
Cloud Network
Network
Infrastructure Layer

Challenging  use  cases:


The  smart  grid  as  an  example

7
U S E R E X P ERIE N
CE CO
N TI N
UIT Y
MOBILE DATA VOLUME
10 Tb/s/km2

E2E LATENCY PEAK DATA RATE


5 ms 10 Gb/s
25 ms
T I C A L S E RV I C E S

10 Gb/s/km2
100 Mb/s
RELIABILITY MOBILITY
99.999% 99.99% 4G 500km/h
I

90 days 1 K/km2
O N C R

5G
M IS S I

SERVICE DEPLOYMENT TIME NUMBER OF DEVICES


90 minutes 1 M/km2
ENERGY EFFICIENCY
10% of current consumption

HINGS
T OF T
Source:  The  5G  Infrastructure Public   Private  Partnership:
the next generation of communication networks and  services. INTERNE 8
5G  Infrastructure Association,   2015
5G  aims  to  cater  for  services  with  diverse  
requirements  
Enhanced  Mobile  Broadband

Ultra  Reliable  Low  


Massive  Machine  
Latency  
Type  Communication  
Communication  

9
Source:  Teyeb et.  al.  “Evolving LTE  to   fit the 5G  future”.  Ericsson  Technology  R eview,  2017.
Use case category User Experienced Data Rate E2E Latency Mobility
Broadband access in DL: 300 Mbps 10 ms On demand,
dense areas UL: 50 Mbps 0-100 km/h
Indoor ultra-high DL: 1 Gbps, 10 ms Pedestrian
broadband access UL: 500 Mbps
Broadband access in DL: 25 Mbps 10 ms Pedestrian
a crowd UL: 50 Mbps
50+ Mbps everywhere DL: 50 Mbps 10 ms 0-120 km/h
UL: 25 Mbps
Ultra-low cost DL: 10 Mbps 50 ms on demand: 0-
broadband access for UL: 10 Mbps 50 km/h
low ARPU areas
Mobile broadband in DL: 50 Mbps 10 ms On demand, up
vehicles (cars, trains) UL: 25 Mbps to 500 km/h
Airplanes connectivity DL: 15 Mbps per user 10 ms Up to 1000
UL: 7.5 Mbps per user km/h
Massive low- Low (typically 1-100 kbps) Seconds to hours on demand: 0-
cost/long-range/low- 500 km/h
power MTC
Broadband MTC See the requirements for the Broadband access in dense areas and 50+Mbps
everywhere categories

Ultra-low latency DL: 50 Mbps <1 ms Pedestrian


UL: 25 Mbps
Resilience and traffic DL: 0.1-1 Mbps Regular 0-120 km/h
surge UL: 0.1-1 Mbps communication: not
critical
Ultra-high reliability & DL: From 50 kbps to 10 Mbps; 1 ms on demand: 0-
Ultra-low latency UL: From a few bps to 10 Mbps 500 km/h
Ultra-high availability DL: 10 Mbps 10 ms On demand, 0-
& reliability UL: 10 Mbps 500 km/h
Broadcast like DL: Up to 200 Mbps <100 ms on demand: 0-
services UL: Modest (e.g. 500 kbps) 500 km/h 10
Source:  5G  White  Paper.  NGMN  Alliance,  2015
5G  timeline  (I)

Source:  https://5g-­‐ppp.eu/wp-­‐content/uploads/2015/02/5G-­‐V ision-­‐B rochure-­‐v 1.pdf


11
5G  timeline  (II)

Source:  3GPP
12
Outline

5G  vision  

Operators Verticals Enterprise 3rd party

Management & Orchestration


5G  realization  
Service Layer

(MANO)
Control Plane User Plane

Mapping
Configuration Life-Cycle
Functions Functions

Network Function Layer

Radio
(Edge) Core
Access Control Allocation
Cloud Network
Network
Infrastructure Layer

Challenging  use  cases:


The  smart  grid  as  an  example

13
Key  enabling  technologies
There are already several vendors and operators deploying cloud packet core for 4G. In
combination with new architectures, such as control and user plane separation (CUPS),
experience with a cloud-based 4G core can give operators an advantage in the deployment
of NG Core. Specifically, factors such as service automation, resource orchestration and
resiliency will transfer from cloud EPC to NG Core.

Innovative  radio  technologies


Network Slicing & Automated Lifecycle Management
NB-­‐IoT,  eMTC
mmWave,  flexible  frames,  …
One of the important commercial objectives of 5G is to enable operators to support multiple
service types on a common physical network infrastructure. In this way, 5G will act as an
enabler to growth markets, such as Industry 4.0, connected car, VR, and so on. As noted
above, each of these services has specific performance requirements.

Network slicing is proposed to support these services on a common infrastructure – although


in practice, it is likely that discrete equipment optimized for the use case may also be used
in some cases. This requires the performance parameters associated with the slice to be
supported across the network, from the user equipment (UE) and radio to the cloud-hosted
application, as shown in Figure 3. In some cases, this will involve bringing the application
closer to the users (for example, using edge computing); in other cases, the RAN or transport
network will require a particular configuration. NG Core, which manages sessions, quality of
service (QoS), security, policy, etc., sits at the heart of the process.

Figure 3: End-to-End Network Slicing

Source: Heavy Reading


14
Network  Slicing
*  source:  Heavy  Reading:  S ervice-­‐O riented   5G  Core   Networks
There is some precedent for "slicing" in mobile networks with APNs and DECOR, but there is
QoS, etc.) but also some extended attributes such as the level of resiliency, management and
control desired. The provider must take care of meeting the requirements and managing the
available resources.
5G  overall  architecture

Figure 2-1: Overall Architecture


Source:  5G  PPP  Architecture   Working  Group  -­‐ White  Paper,  Dec,  2017 15
to support handover
next generation core,
to

5G  will  have  several  deployment  scenarios between eNBtoand


support
gNB.handover bet
between
An eLTE eNB eNB and gNB.
can also An
An eLTE eNB can also
connect to the next c
connect to the next
generation core, and g
generation core, and
LTE/LTE-A NRLTE/LTE-A LTE/LTE-A LTE/LTE-A
NR macro handovermacro
LTE/LTE-A between eNB han
Non-­‐Standalone  (NSA) NR LTE/LTE-A macro
Standalone  (SA)handover between eNB
(a) (a) and gNB canand
begNB
fullycan be fully an
(a)
managed through thethrough the
managed m
EPC EPC EPC core Next generation
Next generation Next Next
coregeneration generation
core
Next corecore
generation Next generation core ne
next generation
next core.
generation core.
User and User and User and
Control and Control and
User planeuser planes User planeControl and User plane
Control Control
control control Control control
user planes planes
user planes plane planesplane plane planes

Control and Control and Control and Control and


Control and user planes Control and user planes
user planes user planes
user planes user planes
Data flow Data flow Data flow Data flow
Data flow LTE eNB LTE eNB NR gNB NRNR gNB
gNB
eLTE eNB
Data flow NR gNB
NR gNB
eLTE eNB NR gNB
NR gNB NR gNB eLTE eNB NR gNB
(c)
(b) (c)
(b) (c)
(b) Standalone  (SA)  +  co-­‐existence   with  legacy  LTE  
Next generation core
Next generation core
Next generation core
Next generation core Next generation core EPC Next generation core
Next generation core Next generation core EPC Next generation core
core Next generation core EPCUser plane Next generation core
Control and User plane
user planes Control and
User plane
Control and user planes
Control and
user planes user planes
Control and
user planes NR gNB
Control and
eLTE eNB
Data flow NR gNB
eLTE eNB
user planes NR gNB
Lien,   Shao-­‐Yu,  et  al.  "5G  new  radio:   Data flowLTE eNB eLTE eNB NR gNB
NR gNB
eLTE eLTE eNB
Waveform,  frame  structure,   (d) eNB
multiple   access,   NR gNB (e) LTE eNB
Data flow NR gNB eLTE eNB
eLTE eNB I EEE  communications  
and  initial  access."   (d)
NR gNB (e) 16
Deployment NR gNB
Figure 51.5.6  
magazine   (2017):  64-­‐71.scenarios of NR. LTE eNB
eLTE eNB
other and communicate via application programming interfaces (APIs).

The  core  network  will  witness  the  most  


Point-to-Point Architecture

radical  innovation  since  2G  


There are two representations of the next-generation architecture in TR 23.799: a point-to-
point architecture, shown in Figure 4, and a service-based architecture, shown in Figure 5.

Figure 4: Point-to-Point Next-Generation Reference Architecture

Point-­‐to-­‐Point  
Source: 3GPP TR 23.501, January 2017,reference   architecture  
Figure 4.2.3-2
17
Source:  3GPP  TR  23.501,  January  2017,  Figure  4.2.3-­‐2
Both models comprise, more or less, the same functional elements; both offer a formal split
The  core  network  will  witness  the  most  
software-oriented architecture (SOA) model enables short time to market for new services
and greater flexibility for system updates. The challenge for early 5G deployments is that
the network cloud platform, and associated operating models, are not mature enough for

radical  innovation  since  2G  


production networks. Therefore, this may be a Phase 2 deployment.

Figure 5: Next-Generation Service-Based Architecture

Source: 3GPP TR 23.501, January 2017, Figure 4.2.3-1


Service-­‐Based  architecture  
Release 15 & Release 16
Not all the required NG Core capabilities can be included in Phase 1 (Release 15), which 18
is
Source:  3GPP  TR  23.501,  January  2017,  Figure  4.2.3-­‐1
in some ways a "bare bones" release intended to make early deployments possible. A good
SDN  separates  the  control  and  data  planes  
and  allows  for  network  programmability      
VERSION 2.01 5
VERSION 2.01 5

Networking
Networking
Net(App(1(
Net(App(1( Net(App(2( Net(App(n"
Net(App(n"

Abstract network views


Abstract network views
Open northbound API
plane

Conventional
Open northbound API
plane

Network(Abstrac,ons((e.g.,(topology(abstrac,on)(

NetworkingConventional
Network(Abstrac,ons((e.g.,(topology(abstrac,on)(
Control

Global network view


Control

Network(Opera,ng(System((SDN(controllers)(
Global network view
Network(Opera,ng(System((SDN(controllers)(
Open southbound API
Data Plane

Network$Applica2ons$
Open southbound API
Intrusion$
Data Plane

MAC$ Rou2ng$ Load$


Network$Applica2ons$ Detec2on$

Networking
Learning$ Algorithms$ Balancer$
System$
es Intrusion$
evic MAC$ Rou2ng$ Load$
SDN$controller$
Detec2on$

Software-Defined
D
ng Learning$ Algorithms$ Balancer$
ardi System$
rw
Fo es
vic
g De
Network Infrastructure Software-Defined SDN$controller$
n
ardi
rw
Fig. 4. SDN architecture and its fundamental abstractions.
Fo
Network Infrastructure
The distribution abstraction should shield SDN applications
Fig. 4. the
from SDNvagaries
architecture of and distributed
its fundamental state,abstractions.
making the distributed Fig. 5. Traditional networking versus Software-Defined Networking (SDN).
With SDN, management becomes simpler and middleboxes services can be
control problem a logically centralized one. Its realization delivered as SDN controller applications.
requires a common distribution layer, which in SDN resides
in the NOS. This "layer has two essentialcomprehensive  
functions. First,
The distribution
Source:  Kreutz,   abstraction
Diego,  et  al.   Software-­‐ should shield SDN
defined  networking:  A   applications 19
it is Presponsible
survey."   for installing
roceedings  of  the  IEEE   the
103.1  (2015):  14-­‐control
76. commands on the operating systemnetworking
or SDN controller. This approach has several
from
forwarding the vagaries devices. of distributed
Second, it state, collects making
status theinformation
distributed Fig. 5. Traditional versus Software-Defined Networking (SDN).
etwork Function, as the software implementation of a network function which is capable of

NFV  decouples  software  implementation  of  


he NFVI.

ucture (NFVI), including the diversity of physical resources and how these can be virtualised.
s the execution of the VNFs.
HAN_LAYOUT_Author Layout 1/30/15 1:39 PM Page 91

network  functions  from  hardware      


ment and Orchestration, which covers the orchestration and lifecycle management of physical
re resources that support the infrastructure virtualisation, and the lifecycle management of VNFs.
ment and Orchestration focuses on all virtualisation-specific management tasks necessary in the
ork.

Typical network appliances


NFV-based approach

Virtual
appliances
Firewall CDN NAT

General purpose
DPI VPN IPTV servers

Standard storage
Router PGW IMS and switches

Figure 1. From dedicated hardware-based appliances for network services, such as firewalls, content
Figure 1: High-level NFV framework delivery networks (CDNs), network address translation (NAT), deep packet inspection (DPI), virtual
private networks (VPNs), IPTV, routers, packet data network gateways (PDN-GWs or PGWs), and
nables dynamic construction and management of VNF instances and the relationships IP multimedia subsystems
between(IMSs), to software-based NFV solutions.
ontrol, management, dependencies and other attributes. ETSI  NFV  reference  architecture  
To this end, there are at least three
VNFs that are centred around different perspectives and contexts of a VNF. These perspectives
In this article, we first present the related model of 3GPP when all or some instances of
work and key technical requirements of NFV. 3GPP-defined network elements are virtualized.
n deployment/on-boarding perspective where the context can be a VM, We then introduce its architectural framework. IETF has formed the Service Function Chaining
Source:  https://www.etsi.org/technologies-­‐clusters/technologies/nfv We also describe several use cases of NFV, (SFC) working group to study how to dynamical-
Han,  Bo,   et  a l.  "Network  function   virtualization:  Challenges  and  opportunities  
loped software package perspective where the context can be several inter-connected for   VMs andof athe cellular core ly steer data traffic through a series 20
including the virtualization of network
innovations."  IEEE   Communications  
mplate that describes their attributes, Magazine  5 3.2  (2015):  90-­‐97. network and home network. Finally, we discuss functions, either physical or virtualized. In this
the open research issues and point out future article, we review some of the existing work and
NFV  has  several  open  challenges  
§ Performance  
-­‐ A  carrier  grade  performance  is  expected    

§ Management  
-­‐ Heterogenous  physical  resources  

§ Reliability  and  stability  


-­‐ Efficient  monitoring  and  control

§ Security  
-­‐ Third  party  VNFs 21
Source:  5G  PPP  Architecture   Working  Group  -­‐ White  Paper,  Dec,  2017 22
addition to supporting a wide range of services and devices, 5G will make the best use of a wide array
spectrum available across regulatory paradigms and spectrum bands. Previous generation networks

5G  Radio  must  support  a  wide  range  


imarily operated in licensed spectrum bands below 3 GHz, 5G will bring the next level of convergence
th support for licensed, shared, and unlicensed spectrum from the very beginning. Moreover, 5G will

of  frequencies  and  spectrum  types


xpand spectrum usage to low-bands below 1 GHz, mid-bands between 1 GHz and 6 GHz, and high-
ands above 24 GHz, loosely known as mmWave, which will open up vast amount of bandwidths for
xtreme data rates and capacity that were previously not usable for wide-area mobile communications.

Figure 4: 5G will natively support all different spectrum types

ualcomm is pioneering spectrum sharing technologies today with various efforts including LTE-U15,
AA16, LWA17, CBRS18, LSA19, and MulteFire. 5G will be built to natively support and advance these

Qualcomm.  M aking  5G  NR  a  reality.  December  2016 23


ITU Recommendation ITU-R M.2083-0, September, 2015; http://www.itu.int/rec/R-REC-M.2083-0-201509-I
LTE  supports  carrier  bandwidth  up  to  
20  MHz  with  fixed  OFDM  numerology  

OFDM  sub-­‐carriers  are  spaced  by  15  kHz


Resource  block  is  fixed  to  180  kHz  in  frequency  and  1  slot  long  in  time
http://rfmw.em.keysight.com/wireless/helpfiles/89600b/webhelp/subsystems/lte/c 24
ontent/lte_overview.htm
1 Scalable OFDM numerology with scaling of subcarrier spacing
ay, LTE supports carrier bandwidths up to 20 MHz with mostly a fixed OFDM numerology - 15 k
In  5G-­‐NR  OFDM  sub-­‐carrier  spacing  
ing between OFDM tones or sub-carriers33. 5G NR, on the other hand, will introduce scalable OFD
erology to support diverse spectrum bands/types and deployment models. For example, 5G NR mu
will  scale  with  the  channel  bandwidth
ble to operate in mmWave bands that have wider channel widths (e.g., 100s of MHz). It is critic
he OFDM subcarrier spacing is able to scale with the channel width, so the FFT34 size scales su
processing complexity does not increase exponentially for wider bandwidths.

merology Definition
eform, Numerology and Frame Structure
able subcarrier spacing
Figure 10: Example usage models,∆𝑓
channel 𝜇
= 2bandwidths,
· 15 𝑘𝐻𝑧and subcarrier spacing
Qualcomm.  M aking  5G  NR  a  reality.  December  2016 25
meters
k-to-averagedefining
power ratio a numerology:
• Cyclic prefix (i.e. Normal/Extended)
µ Δf = 2µ·15 kHz Cyclic Prefix
µ Δf = 2µ·15 kHz Cyclic Prefix
0 15 kHz Normal
0 15 kHz Normal
1 30 kHz Normal Data < 6 GHz
1 30 kHz Normal Data < 6 GHz
2 2 60 kHz60 kHz Normal, Extended
Normal, Extended
Data
Data>> 66 GHz
GHz
3 3 120 kHz
120 kHz Normal
Normal
4 4 240 kHz
240 kHz Normal
Normal Specified but
Specified but
5 5 480 kHz
480 kHz Normal
Normal not
notsupported
supported
Frame Structure inin Rel-
Rel- 15
15
Waveform, Numerology and Frame Structure
© Keysight Technologies 2017
© Keysight Technologies 2017
Understanding the 5G NR Physical
Understanding
Layer
the 5G NR Physical
Page 18
Layer Page 18
SUBFRAME
– Frame: 10 ms 1 ms

– Subframe: Reference period of 1 ms 15 SLOT


kHz 1 4 sym b ols
– Slot (slot based scheduling)
Variable  
• 14 OFDMlength  
symbols s lot  duration  
1 ms

helps   in   supporting  URLLC  


30 SLOT
• One possible scheduling unit kHz 1 4 sym b ols
- Slot aggregation allowed
use  c•ases
Slot length scales with the subcarrier spacing 500 µs

- 𝑆𝑙𝑜𝑡 𝑙𝑒𝑛𝑔𝑡ℎ = 1 𝑚𝑠Τ 60 SLOT


2𝜇
kHz 1 4 sym

– Mini-Slot (non-slot based scheduling)


250 µs
• 7, 4 or 2 OFDM symbols
120
SLOT
14 s

• Minimum scheduling unit kHz

Keysight.  Understanding   the  5G  NR  Physical  Layer.  Nov  2017


125 µs 26
Mobile-­‐IoT  must  be  scalable,  energy  
efficient  and  ubiquitous  

27
IoT  applications,  however,  have  
diverse  requirements  

Shorter   to  medium   battery  life Battery  life  5-­‐10  years


Medium   coverage Ubiquitous   outdoor   coverage
Some  mobility   Some  mobility  
Latency  in  order  of   seconds Medium   to  high   reliability  
Latency  <  10  seconds

Battery  life  10-­‐15  years Mains  powered


Outdoor   and  deep  indoors   (+20dB)   Outdoor   and  indoors  
Stationary Stationary
Medium   to  high   reliability   low  to  high   reliability  
Latency  10  to  60  seconds Latency  <  30  seconds
28
GSMA  white  Paper.  3GPP  Low  Power  wide  Area  Technologies
Future  IoT  applications  will  have  stricter  
reliability  and  latency  requirements  

Factory  automation Intelligent  transportation   Smart  grids


systems

Latency:  0.25  to  10ms   Latency:  10  to  100ms   Latency:  3  to  20ms  
PLR:  10E-­‐9 PLR:  10E-­‐3  to  10E-­‐5 PLR:  10E-­‐6

PLR:  Packet  Loss  Rate


Schulz,  Philipp,   et  al.  "Latency  critical   IoT  applications   in  5G:  Perspective  on  the  design  of  radio  interface  
and  network  architecture."   IEEE  Communications   Magazine  55.2  (2017):  70-­‐78. 29
3GPP  
3GPP R elease  113
Release 3  standardized
standardized  ttwo wo  
solutions  
solutions fforor  ccurrent
urrent  aand
nd  ffuture
uture  IIoT
oT
NB-IoT
NB-­‐IoT eMTC
LTE  C
LTE at.  N
Cat. NBB LTE  C
LTE at.  M
Cat. M11

Deployment
Deployment   In-Band
In-­‐Band  LLTE,
TE,  gguard-
uard-­‐ In-Band
In-­‐Band  LLTE
TE
band  LTE  
band LTE aandnd  
standalone
Bandwidth 180 KHz
180  KHz 1.08
1.08  MHz
MHz
Peak data
Peak  d ata  rrate
ate ~150 kbps
~150  kbps 1 Mbps
1  Mbps
Latency 1.6s-10
1.6s-­‐10  s 10-15 mss
10-­‐15  m
Max
Max  UE
UE  ttxx power 23 orr  20  dBm
23  o 20 dBm 23 orr  20  dBm
23  o 20 dBm
Power
Power  Saving
Saving PSM,
PSM,   eDRX PSM,
PSM,   eDRX
Duplex Half Full/Half
Complexity
Complexity  relative
relative   10% 20-25%
20-­‐25%
to  LTE
to LTE
30
NOKIA.  LTE-­‐M  – Optimizing  LTE  for  the  Internet  of  Things,  2015
● The physical
Stand alone operation. A possible scenario is the utilization DL channels
of currently used GSMare always QPSK

eMTC coexists  with  LTE,  while  NB-­‐IoT  can  


frequencies. With their bandwidth of 200 kHz there with
remaining on both sides of the spectrum
is stilleither
a guardoneinterval
or twoofantenna
10 kHz ports, AP0 an
quency Block Coding (SFBC) is applied. Onc

coexist  with  LTE  or  be  deployed  alone
Guard band operation, utilizing the unused resourcescheme
blocks within
appliesan to
LTE carrier'sNPDCCH, and N
NPBCH,
guard-band
Like in LTE, each cell has an assigned phys
● In-band operation utilizing resource blocks within an LTE carrier
cell ID (NCellID). Totally 504 different values
These modes are visualized in the following figure: ded by the secondary synchronization signa
tion Signals", on page 13.

3.2.1 Frame and Slot Structure

In the DL, OFDM is applied using a 15 kHz s


(CP). Each of the OFDM symbols consists o
Frame  structure  similar  to  LTE  but  the  bandwitdh
Figure 3-1: Operation modes for NB-IoT max  system   bandwidth  
of 180 kHz. Seven OFDMA is   symb
much  lower  180  KHz as  opposed  to  2Physical
0  
slot Mhas
Hz  the following resource grid [9]:
Layer
For the stand alone operation, the GSM carriers in the right part of the figure are only
Downlink
shown as an example in order to indicate that this is a possible NB-IoT deployment. Of
course, this operation mode also works without neighboring GSM carriers.
In the in-band operation, the assignment of resources between LTE and NB-IoT is not
fixed. However, not all frequencies, i.e. resource blocks within the LTE carrier, are
allowed to be used for cell connection. They are restricted to the following values:
Table 3-1: Allowed LTE PRB indices for cell connection in NB-IoT in-band operation

LTE system 3 MHz 5 MHz 10 MHz 15 MHz 20 MHz


bandwidth

LTE PRB indices 2, 12 2, 7, 17, 4, 9, 14, 19, 2, 7, 12, 17, 22, 4, 9, 14, 19, 24, 29, 34,
Figure 3-4: Frame structure for NB-IoT for DL and UL with 15kHz subcarrier spacing
for NB-IoT syn- 22 30, 35, 40, 45 27, 32, 42, 47, 39, 44, 55, 60, 65, 70, 75, 31
www.rohde-­‐schwarz.com/appnote/   1MA266
chronization 52, 57, 62, 67, 72 80, 85, 90, 95
Each  NB-­‐IoT/eMTC carrier  can  support  
10000x    devices  per  cell      
10 4
LTE-M, App. 1
Number of supported users per sector [1000s]

10 3 LTE-M, App. 2
NB-IoT, App. 1
NB-IoT, App. 2

Average Session Delay [ms]


10 3

10 2

10 2
1
10
LTE-M, App. 1
LTE-M, App. 2
NB-IoT, App. 1
NB-IoT, App. 2
10 0 10 1
Outdoor & road Indoor 10 dB Indoor 20 dB Indoor 30 dB Outdoor & road Indoor 10 dB Indoor 20 dB Indoor 30 dB

. 5: Number of supported users per sector in the rural area. Fig. 4: Average session delay in the rural area.
§ App.1  models  a  secure  information  
0.3
exchange  and  uses  4  payloads
with multiple payloads in each direction.
§ App.2   models  a  mobile  autonomous  
LTE-M, App. 1
LTE-M, App. 2
reporting  
The average MCL for thewith  
outdoor a  txandpayload  
road users o
isf  124
dB for both technologies, and according to fig. 2a they
0.25
128   o r  256   b ytes  u plink  
a nd  29   bytes  
achieveack   downlink        
nsumption [mWh]

NB-IoT, App. 1
NB-IoT, App. 2 thus similar data rates. However, NB-IoT has higher
overhead as illustrated in fig. 2b and therefore a longer delay.
0.2
Lauridsen,   Mads,  et  al.  "Coverage  and  capacity  analysis  of  LTE-­‐M  and  NB-­‐I oT  in  a  
For the indoor users experiencing 10 dB penetration 32 loss the
rural   area."  V ehicular  Technology  Conference   (VTC-­‐F all),  2016  IEEE  84th.  I EEE,  2016. average MCL for both technologies is about 133 dB and
NB-­‐IoT  enhances  coverage  by  using  
transmission  repetitions    
Data Transfer
User Plane CIoT EPS optimisation

Figure 5-5: Example of an arrangement for NPUSCH transmission with repetitions. For the case of no
repetitions, the slot sequence shown in (b) would be transmitted.

§ 2x  Forrepetitions   translates  into  3dB  coverage  gain


the case of a 15 kHz subcarrier spacing, a transport block, named test word (TW),
§ 2x  isslots
repetitions  
transmitted on tworRUs
esults   i n  
(a), where 0 .5x  
each RUshas
peed   a nd  
the format of 32 x   l atency  
subcarrier over 8
(b). A total number of 8 repetitions is applied. In Figure 5-5 T denotes the n-th
n
slot of the first RU, Wm the m-th slot of the second RU.

In a first step, the two slots T1 and T2 are transmitted. This pair is repeated three more 33
www.rohde-­‐schwarz.com/appnote/   1MA266
times, so that there are 4 transmissions of these slots. Then the same procedure is
when the radio module
It is recommended that was turned
a “store andback on. policy
forward” The reattach
should procedure consumes
be supported a The
for PSM. small

Cellular  IoT  has  two  mechanism  to  help  


amount
operatorofshould
energy, but the storing/forwarding
consider cumulative energytheconsumption of reattaches
last received packets or can become
an SMS (whichever
significant over the lifetime of a device. Therefore, battery life could be extended
is supported) to be sent to the device when it awakens. At a minimum, the last packet if this of
procedure could be
100 bytes should beavoided.
sent, to allow the customer to send a simple message. Any

devices  conserving  battery  power


store/forward limitations or errors should be communicated to the customer as part of a
When a device initiates PSM with the network, it provides two preferred timers (T3324 and
service level agreement.
T3412); PSM time is the difference between these timers (T3412-T3324). The network may
accept these values or set different ones. The network then retains state information and the
6.2 eDRX configurations
device remains registered with the network. If a device awakes and sends data before the
Extended of
expiration Discontinuous Reception
the time interval (eDRX)
it agreed is an
with the extension
network, of an existing
a reattach LTEisfeature,
procedure not which
can be used
required. by IoT devices to reduce power consumption. eDRX can be used without PSM
Power  Saving  Mode  (PSM)
or in conjunction with PSM to obtain additional power savings.

Today, many smartphones use discontinuous reception (DRX) to extend battery life between § UE  initiated  
recharges. By momentarily switching off the receive section of the radio module for a
fraction of a second, the smartphone is able to save power. The smartphone cannot be mechanism
contacted by the network whilst it is not listening, but if the period of time is kept to a brief § Akin  to  power  off  but  
moment, the smartphone user will not experience a noticeable degradation of service. For
example, if called, the smartphone might simply ring a fraction of a second later than if DRX the  UE  remain  
was not enabled. registered
eDRX allows the time interval during which a device is not listening to the network to be
greatly extended. For an IoT application, it might be quite acceptable for the device to not
be reachable for a few seconds or longer.

Whilst not providing


Figure the same
2: TAU levels of Area
(Tracking powerUpdating)
reduction period
as PSM,and
for PSM
somecycle
applications
eDRX may provide a good compromise between device reachability and power
For Extended  Discontinuous  Reception  (eDRX)
consumption.
example, for a monitoring application, the radio module in a device might be configured
by an application to enable PSM, negotiate a 24-hour time interval with the network and § Negotiated  upon  
attachment  
Page 13 of 35
§ The  UE  shuts  off  its  
receiver  during   eDRX
§ Up  to  3  hours

34
GSMA.  NB-­‐I oT  DEPLOYMENT  GUIDE  to  Basic  Feature  set  Requirements   April   2018
Early  measurements  of  pilot   NB-­‐IoT  
commercial  deployments

35
Measurements  show  that  deployments  
meet  expectations  to  a  large  extent    
Current    (mA)

Assuming  that  we  are  using  a  CR2032  battery  with  235  mAh capacity  
and  128  bytes  payload  and  6  activity  periods  per  day
Total  Load  during  transmission  (mA) Life  time  (years)
300  mA ~17
Up  to  1500  mA ~10
36
Initial  measurements  indicate  that  
delays  may  go  well  beyond  the  10s  limit  
RTT    (sec)

Time
37
NB-­‐IoT  faces  a  number  of  challenges   including
complexity  and  methods   for  KPI  evaluation
§ Large  parameter  space    
-­‐ PSM,  eDRX
-­‐ Repetitions  
-­‐ Carrier  bandwidth

§ Diverse  use  cases  with  different  SLA  requirements


-­‐ Low  traffic  volumes
-­‐ New  metrics  are  needed  for  describing  reliability

38
softwarization, programmability and allows for the innovation necessary to enrich the offered

Key  to  the  realization  of  5G  vision  is  the  


services. Network softwarization techniques may be used to realize and manage network slicing.
Network slicing provides the means by which the network operators can provide network
programmable capabilities to both OTT providers and other market players without changing their
slicing  the  network  on  a  per  service  basis
physical infrastructure. Slices may support dynamic multiple services, multi-tenancy, and the
integration means for vertical market players (such as, the automotive industry, energy industry,
healthcare industry, media and entertainment industry).

Figure
Source:  5G  PPP  Architecture   Working  Group  -­‐ 2-3: Network
White  Paper,  Dec,  2017 Slicing Representation [2-16] 39
A  generic  framework  for  5G  networks

40
Management  and  Orchestration  Entity  
(MANO)  -­‐ I
§ It  comprises  three  parts:
-­‐ NFV  Orchestrator  
-­‐ VNF  Manager    
-­‐ Virtualized  Infrastructure  Manager

§ Translates  uses  cases  and  models  into  services  and  


slices:
-­‐ VNF  instantiation  
-­‐ VNF  chaining    
-­‐ Service  life  cycle  management
41
Management  and  Orchestration  Entity  
(MANO)  -­‐ II

42
ETSI  GS  NFV-­‐M AN  001  V 1.1.1  Network  F unctions   Virtualisation (NFV);  M anagement  and  O rchestration
Realizing  E2E  slicing  involves  several  
5GPPP Architecture Working Group 5G Architecture White Paper

trade-­‐offs  (I) ISO-OSI


Protocol layers
Stand- Slice Slice Resource- Resource-
alone with own with unaware unaware
slice spectrum shared slice slice Core
resource Network

MUX

PDCP
Common
PDCP / RLC Processing RLC

QoS-sched. QoS-sched. QoS-sched. QoS-sched. (possibly slice-unaware)


MAC
MUX controlled by common MAC scheduler/res. broker

Common Baseband Processing

Combiner PHY

Common RF and Antenna

Figure 2-6: Options for slice multiplexing and their relation to the OSI protocol stack [2-
Source:  5G  PPP  Architecture   Working  Group  -­‐ White  Paper,  Dec,  2017 26] 43
Realizing  E2E  slicing  involves  several  
trade-­‐offs  (II)

§ How  to  virtualize  radio  resources?


-­‐ Dedicated  vs  shared

§ What  is  the  proper  network  function  granularity?


-­‐ monolithic  vs  composable?

§ How  to  describe  services?


-­‐ Human  readable  vs  non-­‐human  readable  
44
There  is  no  agreement  on  how  to  
virtualize  the  RAN

45
Foukas,  X.,  Patounas,  G.,  Elmokashfi,  A.,  &  M arina,  M.  K.  (2017).  Network  slicing  in  5G:  S urvey  and  challenges.  IEEE  Communications   Magazine,  55(5), 94-­‐100.
Fine  grained  function  allow  for  flexible  
service  composition  at  the  expense  of  
increased  complexity  

46
Foukas,  X.,  Patounas,  G.,  Elmokashfi,  A.,  &  M arina,  M.  K.  (2017).  Network  slicing  in  5G:  S urvey  and  challenges.  IEEE  Communications   Magazine,  55(5), 94-­‐100.
The  MANO  entity  is  still  in  the  
conceptual  phase

47
Foukas,  X.,  Patounas,  G.,  Elmokashfi,  A.,  &  M arina,  M.  K.  (2017).  Network  slicing  in  5G:  S urvey  and  challenges.  IEEE  Communications   Magazine,  55(5), 94-­‐100.
A  number  of  issues  must  be  resolved  
before  implementing  E2E  slicing  fully    
§ Dynamic  and  fine-­‐grained  spectrum  sharing  based  
RAN  virtualization
-­‐ Multi-­‐RAT  virtualization  
-­‐ RAN  as  a  service  
§ Frameworks  and  standards  for  defining  granular  
network  functions
§ Adaptive  and  dynamic  management  and  
orchestration  plane  
-­‐ Integrating  measurements  and  control  
-­‐ Anticipatory  and  predictive  analytics 48
Outline

5G  vision  

Operators Verticals Enterprise 3rd party

Management & Orchestration


5G  realization  
Service Layer

(MANO)
Control Plane User Plane

Mapping
Configuration Life-Cycle
Functions Functions

Network Function Layer

Radio
(Edge) Core
Access Control Allocation
Cloud Network
Network
Infrastructure Layer

Challenging  use  cases:


The  smart  grid  as  an  example

49
working Protocols
Unlike  the  traditional  power  grid,  the  
sain Rehmani, and Martin Reisslein, Fellow, IEEE
smart  grid  is  dependent  on  distributed  
control  
ng trans-
communi-
ution, and
nagement
peed, reli-
echnology
nd usage.
n wireless
es in SGs,
ions tech-
are highly
ations by
his paper
radigm in
network
ion tech-
d SG sys-
ches with
Khan,  Athar  Ali,  Mubashir  Husain  Rehmani,   and  M artin  Reisslein.  "Cognitive  radio  for  smart  grids:  Survey  of  architectures,   50
CR-based
spectrum   sensing  mechanisms,   and  networking   protocols."   IEEE  Communications   Surveys  &  Tutorials  18.1  (2016):  860-­‐898.
Distribution  automation  within  NANs  is   C. Kalalas et al.: Cellular Communications for Smart Grid NANs

arguably  the  focal  point  of  the  smart  grid      

Kalalas,  Charalampos,  L inus  Thrybom,  a nd  Jesus  A lonso-­Zarate.  " Cellular  communications for  smart  g rid  n eighborhood area   51
FIGURE 1. AHierarchical
networks:   smart
 survey." IEEE   grid architecture.
A ccess Two parallel interdependent domains, the power system and the communication network, form the
4  (2016):  1 469-­1493.
infrastructure of the smart grid. The power distribution grid along with the corresponding NAN constitute the heart of the new power system. In the
Distribution  automation  functionalities  
require  reliable  interactions  between  IEDs    
§ Distributed  control  and  protection  
-­‐ Time  critical  control  messaging  
-­‐ Fault  identification  

§ Wide-­‐area  monitoring  system  


-­‐ Combine  data  from  Phasor  Measurement  units

§ Real  time  monitoring  of  distribution  equipment  


for  example  capacitor  banks,  re-­‐closers  and  
switches
52
Reliability    
The  smart  grids  
Protection communications  feature  
diverse  requirements  
99.999% Regulation

99.99%
Monitoring

99.9% Alarms Measurements

99%

Latency  
20msec 2s 10s 5m 53
Kuzlu,   Murat,  Manisa Pipattanasomporn,   and  S aifur Rahman.  "Communication   network  requirements   for  major  smart  grid  applications   in  HAN,  NAN  and  WAN."  Computer  
Networks  67  (2014):  74-­‐88.
A  meta-­‐requirement  is  that  the  inter-­‐
dependence  should  not  increase  chances  
LETTERS
of  cascades NATURE | Vol 464 | 15 April 2010

a b c

Figure 1 | Modelling a blackout in Italy. Illustration of an iterative process of at the next step are marked in green. b, Additional nodes that were
a cascade of failures using real-world data from a power network (located on disconnected from the Internet communication network giant component
the map of Italy) and an Internet network (shifted above the map) that were are removed (red nodes above map). As a result the power stations
implicated in an electrical blackout that occurred in Italy in September depending on them are removed from the power network (red nodes on
2003 20
. The networks are drawn using the real geographical locations and .
map). Again, the nodes that 1will
Buldyrev,   Sergey  V .,  et  al.  "Catastrophic   cascade  of  failures  in  interdependent   networks."  Nature  464.7291  (2010):   025be disconnected from the giant cluster 54
at the
every Internet server is connected to the geographically nearest power next step are marked in green. c, Additional nodes that were disconnected
NB-­‐IoT  is  already  being  considered  for  
connecting  smart  meters

Portugal   Belgium  

https://www.u-­‐blox.com/en/press-­‐releases/portugal-­‐presents-­‐first-­‐nb-­‐iot-­‐smart-­‐mete r
https://www.mobileeurope.co.uk/press-­‐wire/proximus-­‐launches-­‐nb-­‐i ot-­‐t o-­‐connect-­‐1-­‐3m-­‐smart-­‐mete rs 55
Measurement  nodes  spread  
across  Norway

About  100  active  stationary  


measurement  nodes    

Multi-­‐homed  to  all  major  


Norwegian  MBB  operators  

Operational  since  July  2013

56
LTE  networks  do  not  ensure  a  consistent  
low  delay  <  50ms  even  when  stationary
1
0.9
Fraction of connections

0.8
0.7
0.6
0.5 Oper-A-median
0.4 Oper-A-99.5th%
Oper-A-99.9th%
0.3 Oper-A-99.99th%
Oper-B-median
0.2 Oper-B-99.5th%
0.1 Oper-B-99.9th%
Oper-B-99.99th%
0
10 100 1000 10000
RTT(msec)

57
Although  LTE  networks  offer  high  
availability,  they  do  not  meet  the  smart  
grid  requirements      
1
Fraction of connections

0.9 Telenor
Telia
0.8 NNorway
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
99.7 99.75 99.8 99.85 99.9 99.95 100
OA (%)
Elmokashfi,  Ahmed,  Dong  Z hou,   and  Džiugas Baltrünas.   "Adding  the  next  nine:  An  investigation   of  mobile  broadband   networks  availability."  I n  M obiCom.  ACM,  2017.
Multihoming  can  help  providing  consistent  
delays  and  availability  

1 1
Telenor-Telia

Fraction of nodes
0.9 0.9
Fraction of connections

0.8 0.8 Telenor-NNorway


0.7 0.7 Telia-NNorway
0.6 0.6
0.5 0.5
0.4 0.4
0.3 0.3
median
0.2 99.5th% 0.2
99.9th%
0.1
99.99th% 0.1
0
10 100 1000
0
99.99% 99.999% 100%

99

0
.9

10
RTT(msec)

.9
99

99
OA %
Delays  still  need  to  reduced  by  an  order  of  magnitude

Elmokashfi,  Ahmed,  Dong  Z hou,   and  Džiugas Baltrünas.   "Adding  the  next  nine:  An  investigation   of  mobile  broadband   networks  availability."  I n  M obiCom.  ACM,  2017.
5G  NR  sDDcalable  nDDumerology   can  
DFC: 60 kHz
Other: 15 kHz DD
DC DC DC DC DD GP UC

significantly   reduce  the  air  interface  delayTime


DD: 15 kHz
DD DC DD GP UC UC UD UD UD UD UD UD UD UD GP DC GP UC UD UD UD UD
Other: 60 kHz
DC Downlink control UC Uplink control DD Downlink data UD Uplink data GP Guard period
(b)
Time
Number of subcarriers
PRB grid
in a PRB is fixed to 12
PRB composed of subcarriers
with spacing 15 kHz  2m+2
PRB composed of subcarriers
with spacing 15 kHz  2m+1
PRB composed of subcarriers
with spacing 15 kHz  2m
PRB composed of subcarriers
m- 1
with spacing 15 kHz  2
Frequency
(c)

. Frame structure
0.5msec   of NR.
sub-­‐frame  results  in  approximately  4msec  uplink  delay

thogonal frequency-division multiplexing ed to adapt to different levels of inter-sy


M)Lien,  
symbol durations,
Shao-­‐Yu,  et  al.   CP lengths,
"5G  new  radio:  Waveform,   and
frame  structure,   on. initial  interference
soaccess,  and  
multiple   (ISI) at 5different
access."  I EEE  communications  magazine   5.6  (2017):  64-­‐71.carrier freque
Supporting  extreme  requirements   𝑅𝐸2𝐸 = 𝑅𝑈𝐸 𝑅𝑅𝐴𝑁 𝑅𝐶𝑁 𝑅𝐴𝑆 (1)

necessitates  an  end-­‐to-­‐end  consideration  


where 𝑅𝑈𝐸 , 𝑅𝑅𝐴𝑁 , 𝑅𝐶𝑁 and 𝑅𝐴𝑆 represent the reliability of the UE, RAN, CN and AS, respectively.

The elements that influence the E2E reliability are illustrated in Figure 6. The 𝑅𝑅𝐴𝑁 is also referred to as the reliabil
on the access link The
(AL), 𝑅 of.nodes includes the AP, the edge node hosting the AS and the CN nodes in between the AP and edge
number𝐴𝐿
node, such as switches, routers, points of concentration and UPFs. The CN nodes between the AP and edge node
RE2E
are referred to as forwarding nodes.

The total number of links and the total number of nodes in the E2E network can be expressed as a function of the
total number of forwarding nodes that are placed between the AP and the edge server, 𝑁𝑖 as given by the following
equations. UE AP CN Node AS
𝑁𝑙𝑖𝑛𝑘𝑠 = 𝑁𝑖 + 1 (4)
𝑁𝑛𝑜𝑑𝑒𝑠 = 𝑁𝑖 + 2

The number ofR forwarding


UE
RRANis equivalent to the number
nodes RCN of hops in the path from the AP toRthe
ASedge node. This
is illustrated in Figure 7.

Number of Nodes, Nnodes


Note: RRAN = RAL from simulations in phase 2.1 [2]

CN CN CN Edge
AP Figure
Node 6: End-to-end
Node reliability
Node Node

The reliability of the UE, 𝑅𝑈𝐸 and the reliability of the AS, 𝑅𝐴𝑆 include both hardware and software failures. For th
Number of Forwarding Nodes, Ni
purpose of this analysis, both 𝑅𝑈𝐸 and 𝑅𝐴𝑆 are (routers/switches/UPFs)
assumed to be one, which corresponds to 100% reliability.
Figure 7: Forwarding Nodes in the CN.
The reliability of the RAN depends on the probability of correctly decoding a packet within the packet latency boun
The probability of link failure, 𝑃𝑓,𝑙𝑖𝑛𝑘 depends on the transport medium (e.g., fibre, copper, microwave). Typical values
which depends onforthe bothprobability
End-­‐and
𝑃𝑓,𝑙𝑖𝑛𝑘
NGMN  5G  Extreme  Requirements:   𝑃𝑓,𝑛𝑜𝑑𝑒
to-­‐End  
ofrange
failure
fromof
Considerations,  
the
10−6
Aug  
AL,
to 10
2018
−4 denoted as 𝑃
[16] [17]. For simplicity,
𝑓,𝐴𝐿 . This
it is value
assumed that allis
of the errorandrate that is determine
the nodes
links in the CN have the same probability of failure. However, the analysis can be easily generalised to the case
in Phase 2.1 [2]. The RAN reliability is thus given by the following equation
𝑡𝑇𝑥 = (10)
𝛼𝐶𝑙𝑖𝑛𝑘

Supporting  extreme  requirements  


where 𝑃𝑠𝑖𝑧𝑒 is the packet size and 𝛼 is the fraction of the link capacity, 𝐶𝑙𝑖𝑛𝑘 , that is allocated for the target use case.

necessitates  an  end-­‐to-­‐end  consideration  


Figure 9 illustrates the processing delays at each node.

Edge Node

App App
Present. Present.
Session Session
Transport Transport
PDCP PDCP 5G Reliable 5G Reliable
RLC RLC Tunnel Tunnel
MAC MAC L2 L2 L2
PHY PHY L1 L1 L1
UE gNB/eNB Router/ UPF AS
Switch

tUE tRAN tAS tTP tprocess


Figure 9: Processing Delays at the UE, RAN, CN and AS.

6.3NGMN  5G  Extreme  Requirements:  


Joint ReliabilityEnd-­‐ to-­‐End   Considerations,   Aug  2018
and Latency Analysis
Service  placement  is  central  to  reliably  
For Target 3, the assumptions are as follows:


Latency in the RAN, 𝑡𝑅𝐴𝑁 = 1 ms
Cell radius 𝑟𝑐 = 250m

reducing  delay  
• Packet size, 𝑃𝑠𝑖𝑧𝑒 = 40 Bytes
• The capacity of each link = 1 Gbps
• Fraction of the link capacity allocated to the target use case 𝛼𝐶𝑙𝑖𝑛𝑘 = 100 Mbps (i.e. 𝛼 = 0.1),
• Node processing delay, 𝑡𝑝𝑟𝑜𝑐𝑒𝑠𝑠 = 200 μs

The maximum CN distance versus the number of forwarding nodes for Target 3 is illustrated in Figure 13.

Latency Analysis Latency Analysis


500 600
Max CN Distance (km)

Max CN Distance (km)


400 500
400
300
300
200
200
100 100
0 0
0 1 2 3 4 5 6 7 8 9 10 0 1 2 3 4 5 6 7 8 9 10
Number of Forwarding Nodes Number of Forwarding Nodes

Target Latency = 10.5 ms Target Latency = 11.0 ms Target Latency = 1.5 ms Target Latency = 2.0 ms

Target Latency = 12.0 ms Target Latency = 3.0 ms

Figure 13: Latency analysis for Target 3.


Figure 11: Latency analysis for Target 1.

, the assumptions are as follows:


RAN  latency  10msec 5G Extreme Requirements: E2E Considerations,
Version 2.0, 16–Aug–2018
RAN  latency  1msec
ency in the RAN, 𝑡𝑅𝐴𝑁 = 5 ms
radius 𝑟𝑐 = 250m
cket size, 𝑃𝑠𝑖𝑧𝑒 = 40 Bytes
e capacity of each link = 1 Gbps
ction of the link capacity allocated to the target use case 𝛼𝐶𝑙𝑖𝑛𝑘 = 100 Mbps (i.e. 𝛼 = 0.1),
de processing delay, 𝑡𝑝𝑟𝑜𝑐𝑒𝑠𝑠 = 200 μs
NGMN  5G  Extreme  Requirements:   End-­‐to-­‐End   Considerations,   Aug  2018

m distance in the CN versus the number of forwarding nodes for Target 2 is illustrated in Figure 12. In
Multi-­‐homing  can  help  relaxing  reliability  
requirements  on  individual  paths

Single  path  reliability   Path  Redundancy   Overall  Reliability  


90.000% 6 99.999900%
99.000% 3 99.999900%
99.900% 2 99.999900%
99.990% 2 99.999999%
99.999% 2 100.000000%

§ Inherent  tradeoff  between  resource  efficiency  and  added  reliability


§ Informed  selective  duplication  can  boost  reliability  and  constrain  
resource  usage    
-­‐ Duplications  during  handover
-­‐ Duplications  upon  interference/congestion  detection  
NGMN  5G  Extreme  Requirements:   End-­‐to-­‐End   Considerations,   Aug  2018
There  is  a  need  to  evaluate  different  
approaches  to  redundancy  
dundancy is illustrated in Figure 20, where two redundant paths are created
N.

No Redundancy in CN Redundancy in CN Edge Node

Application Server Application Server Application Server

UPF UPF UPF

MN SN
Redundant Paths
MN SN

MN SN
UE UE
Packet Duplication
Packet Duplication in RAN Packet Duplication in RAN
Using DC or CA Using DC or CA UE

DC Architecture with Two Connections to the CN

icationFigure
in RAN 21:usingRedundancy
Dual Connectivity in the RAN or and the CN.
Carrier There are two connections to the CN through one
Aggregation.
Figure 22: Redundancy Using DC with Two Conne
NGMN  5G  Extreme  Requirements:  
RAN node (e.g. MN). End-­‐to-­‐E nd   Considerations,   Aug  2018
5G  vision  is  very  ambitious.  The  main  blocks  are  
being  worked  out,  but  key  challenges  remain    
There  is  a  need  for  building  adaptive,  
carrier  grade,  infrastructure  agnostic  VNFs  

To  fully  realize  dynamic  slicing,    the  


MANO  must  go  beyond  the  basic  
instantiation  of  VNFs

Supporting  extreme  requirements  


mandates  taking  an  E2E  approach  to  
improving  reliability    

You might also like