Ljubisa Crnadak Huawei2

Ljubiša Crnadak
Solution Manager
Cloud Core Solution Sales, CEE&Nordic Region
Virtualization Cloudification
HW and SW Decoupled
Pooled Fully
hardware distributed
resources architecture
1. On-demand self-service,
Decoupled 2. Broad network access,
Full 3. Resource pooling,
automation 4. Rapid elasticity
5. measured service.
2
3
207.17.117.20
Internet
Load
Balance
Pool
Only show single external
216.34.94.17 IP address to remote node
4
207.17.117.20
Packet # 1
Src - 207.17.117.20
Dest – 216.34.94.17 Internet
Load
Balance
Pool
5
207.17.117.20
Packet # 1
Src - 207.17.117.20
LB Translate to Load
internal IP address Balance
Pool
6
207.17.117.20
Packet # 1
Src - 207.17.117.20
Packet # 1
Src – 207.17.117.20
Dest – 172.16.20.1
Pool
7
207.17.117.20
Packet # 1
Src - 207.17.117.20
Packet # 1
Packet # 2 - return
Src – 207.17.117.20
Dest – 207.17.117.20
Dest – 172.16.20.1
Src – 172.16.20.1
Pool
8
207.17.117.20
Packet # 1
Src - 207.17.117.20
LB Translate to Load LB Translate to

internal IP address Balance external IP address
Packet # 1
Packet # 2 - return
Src – 207.17.117.20
Dest – 207.17.117.20
Dest – 172.16.20.1
Src – 172.16.20.1
Pool
9
207.17.117.20
Packet # 1
Src - 207.17.117.20
Dest – 216.34.94.17 Internet Packet # 2 - return
Dest - 207.17.117.20
Src – 216.34.94.17
LB Translate to Load LB Translate to

internal IP address Balance external IP address
Packet # 1
Packet # 2 - return
Src – 207.17.117.20
Dest – 207.17.117.20
Dest – 172.16.20.1
Src – 172.16.20.1
Pool
10
Internet Internet
Load Load
Client requests are Balance Balance Administrator sets ratio for
distributed evenly distributing Client requests
3:2:1:1
1 2 3 4 9 1 5 7 2 6 3 4
5 6 7 8 10 8 12 14 9 13 10 11
11
12
•Scale out as traffic grows •Capacity of resource pool is automatically
•Scale in as traffic decreases re-allocated between PS and CS in earthquake
•Rapidly recycle and reuse resources

Scale in for data traffic
•Fully automated scaling Voice

Capacity Scale out for voice traffic Voice
Capacity
Data Data
Capacity Earthquake Capacity
Tourist Tourist
Peak Non-Tourist Peak
Peak
Thailand Case Natural Disaster Case
13
UE1 UE2
LB
Subscriber Subscriber
registers here register here
Active Standby Standby Active
VNF
NFVI
8
14
UE1 UE2
LB
Subscriber Subscriber
VNF
NFVI
8
15
UE1 UE2
LB
Subscriber Calls here Subscriber

VNF
NFVI
8
16
UE1 UE2
• Resource utilization is only 50% as

LB
standby node is idle before becoming
Subscriber Calls here Subscriber active.
VNF
NFVI
8
17
UE1 UE2

LB
Subscriber Calls here Subscriber active.
• Both active and standby fail because of
Active Standby COTS failure.
Standby Active
VNF
NFVI
8
18
UE1 UE2

LB
Subscriber Calls here Call dropped Subscriber active.
Standby Active
VNF
NFVI
8
19
UE1 UE2

LB
Subscriber Calls here Call dropped Subscriber active.
Standby Active
VNF
NFVI
8
20
Traffic cannot be re-balanced quickly after scale out
Load Load Load Load Load Load
90%---------- 90%---------- 90%---------- 90%----------
10%---------- 10%----------
Subscriber register here New Subscriber register here
Service Processing Service Processing Service Processing Service Processing Service Processing Service Processing
+ + + + + +
User data User data Sale Out User data User data User data User data
+ + + + + +
Session data Session data Session data Session data Session data Session data
LB LB
Only New Only New

Subscriber’s Traffic Subscriber’s Traffic
21
90%---------- 90%---------- 90%---------- 90%----------
10%---------- 10%----------
+ + + + + +
+ + + + + +
LB LB
Existing Subscribers Only New Only New

22 Call Traffic Call Traffic
90%---------- 90%---------- 90%---------- 90%----------
10%---------- 10%----------
+ + + + + +
+ + + + + +
LB LB
Existing Subscribers Only New Only New

23 Call Traffic Call Traffic
Subscriber register here
+ + + + + +
User data User data User data User data User data User data
+ + + + Scale In + +
① ② ③ ④ ① ②
LB LB
LB LB
Call Traffic
24
+ + + + + +
User data User data User data User data User data User data
+ + + + Scale In + +
① ② ③ ④ ① ②
LB LB
LB LB
Call Traffic
Call Traffic
25
+ + + + + +
User data User data User data User data
Scale In
User data User data Lost Call
+ + + + + +
① ② ③ ④ ① ② There is no call
data
LB LB
LB LB
Call Traffic
Call Traffic
26
Traditional
N-Way
(All-Active)
Active-Standby
010101010001101010101001
Active 010101010101010101010001 Standby
Cloudified
27
VNF with 3-Tiers Cloudified Architecture
Distributed Session Database Layer
VM VM VM
Stateless Service Process Unit Layer
Orchestration
CloudIMS CloudEPC
Distributed Load Balancer Layer
VM VM VM
Cloud OS
Cloud Infrastructure
28
DPU
① DPU
①
SCU1 SCU2 SCU3 SCU4 SCU1 SCU2 SCU3 SCU4

④ Call
processing
④ processing
Call
② ③ ③ ②
Session Session
data data
User User User User

data data data Data
RDB RDB RDB RDB
Call traffic can be switched over to healthy VM quickly (~second) and no call loss.
29
Load Load Load Load Load Load Load Load Load
90%---------- 90%---------- 90%---------- 90%----------

72%---------- 72%---------- 72%---------- 72%---------- 72%----------
DPU
①
DPU
SCU1 SCU2 SCU3 SCU4 Scale Out SCU1 SCU2 SCU3 SCU4 SCU5
④ Call
processing
②
③
Session
data
User User User User

data data data data
RDB RDB RDB RDB
30
After scaling out, existing call traffic is re-balanced very quickly (~seconds)
①
DPU DPU
SCU1 SCU2 SCU3 SCU4 SCU5 SCU1 SCU2 SCU3 SCU4 SCU5
Scale In
Call
③
④ processing
②
Session Session
data data
User User User User

data data data data
RDB RDB RDB RDB
31
Flow Control Objective:
•Avoid system collapse because of traffic storm or unusual traffic.
• In NFV, CPU occupation information is If traffic control is only based on CPU load:
not accurate.
• Not Accurate: traffic is not balanced among VMs.
• Overestimate: Cause false flow control

Real Physical CPU Load from
CPU Load VM perspective
• Underestimate: Do not control traffic after overload. Cannot
60% handle signal storm in Telecom.
overestimate
V V V V
underestimate M M M M
40% 1 2 3 4
Traffic
Distribution
32
Host OS Occupation Idle VM Occupation
Enhance HA via COTS Agnostic Overload Control Mechanism:
Queue Flow Control
CPU, Memory, I/O,
Flow Control Message Delay
Notification
... Priority 1 Priority 1
...
Priority 2 Priority 2
... ...
Tag priority Priority N Message Message Execute Tag priority Priority N Message Message Execute
and put Dispatcher processor Flow and put Dispatcher processor Flow
messages to Control message to Control
different queue different queue VM (SCU/CCU/…)
VM (BSU/BSG/…)
• Under 1.5 times overload, ITU-T G.543 require that access success rate should reach 90%.
Non-Cloudified architecture cannot meet this requirement.
• After 2.8 times overload, Huawei IMS access success rate still reaches 90%.
33
• More than 50% network fault due to partially unhealthy behavior
(delay, jitter, packet loss, packet corrupted, etc.)
• Harder fault detection and recovery in layered cloud system
KPI-based Partially Unhealthy Detection and Auto-Healing

When Gap beyond expectation
Unhealthy VNF define system unhealthy Health VNF
VM KPI Monitor VM
History KPI Predetermined
Action
VM VM VM Gap VM VM VM
Success call ratio VM isolated
Registration ratio Real-time KPI VM migration
… …
VM VM VM VM
Supporting VNF/NS level fault self-healing
34
EMS:CloudU2000
CCE
alarm Real time monitoring of service Alarm occurs when
Fault Mgmt analyze Collect
KPI on VNF and VM KPI is going down
Collect service Action for

KPI Recovery
VNF1 VNF2
VM1 VM2 VM3 VM1 VM2 VM3
NFVI
35
CSC VNF1 VNF Pool
VNFC
KPI Collection &

LB VNFC Recovery Center
SBC1
VNFC
VNFC Pool
SBC2
CSC VNFn
… KPI Collection &
Recovery Center
VNFM
… VNFC
U2000/CCE
SBCn
KPI Collection &
LB VNFC Recovery Center
KPI Collection …
VNFC
Restful API
VNFC Healing
VNFC Pool
(Support 3rd
VNF)
VNF Healing
Sub-health
NFVI VIM
36
KPI based resource scaling
Real-time KPI
CAPS
Scale
"Zero" session
NO. of subs
vAPPs Monitoring
Call Success Rate
in / out interruption
Redundancy
Layered Synergy Active/standby Stateless N-Way VNF Cross-DC 99.999%
HA Mechanism New VM3 Reliability
Cloud VM3
VM2 Recreation VM2
VM1 VM1
OS Cluster N+M redundancy
Resources always
Cluster Hardware resource redundancy
HW available
Top N Failure and Deal Ways

Application Network
Single Single hard DC Cloud Guest OS
Abnormal Qos
server failure disk failure failure OS overhead Hang/Crash
terminated descending
Others Swap traffic to Others takes Read/write Others take
takes over another virtual over the failed Data from Cross-DC over the
App Layer redundancy
NONE
the failed one Network plane one’s traffic redundancy disk failed one
Re-Spawn VM VM migration
Cloud OS NONE NONE Re-Spawn VM NONE
(normal DC) to other DC
Reset VM
Hardware NONE NONE Isolated Isolated Manual check NONE NONE
37
Non-Cloudfication Cloudification
• 1+1 Redundancy, Non-distributed architecture • All-Active, Distributed architecture

Fully
distributed
• Data and service are coupled architecture • Data and service are de-coupled
• Centralized Database • De-centralized Database
• Resource reservation for Redundancy Pooled • Resource On-demand

hardware
• Low resource utilization efficiency resources • Maximize resource utilization
• Don’t rebalance after scale out • Auto-Scale with no any Call Lose
Full
• Auto-Scale in with Call Lose

automation
• Fault automatic detection and diagnosis,
auto-healing based on service KPI
38
TARGET ARCHITECTURE OF CLOUDEPC
Current Future
DB DB
PCRF CG
PCRF CG vCG
HLR-FE HSS-FE HLR-FE HSS-FE
Gr Gr R7 Gx R8 Gx
Gr S6a R7 Gx R8 Gx Ga
GGSN SGW/PGW GGSN + SGW/PGW vUGW

Gn
S11 S1-U Gn/S11
S1-U
Gn
SGSN MME SGGN + MME vUSN
S1-MME S1-MME
CloudEPC
BSC RNC eNodeB BSC RNC eNodeB
2G/3G PS 4G Unified
PS PS
Huawei CloudEPC VNF Architecture
OSS/BSS NFVO
EMS vU2000 vPRS VNFM

CLoudOpera
VNF CSM
vUSN vUGW vCG CloudEPC
NFVI
Virtualisation Layer
Fusionsphere (Openstack/KVM)
VIM
Fusion
COTS manager
+
E9000 S5500 CE6800 eSight
VNF Deployment Approach
Command Way Openstack As a Tool Huawei Openstack+MANO
(Manually, Low Efficiency) ( Semi-Automatic NFV ) ( Batch,Automatic,Dynamic NFV )
External Internal
External
Network1 Network1
External Internal
Network
Network2 Network2
OMU IPU SPU

SPU SPU SPU
OMU IPU SPU

VM VM VM
#setup network
Ifconfig eth0 0.0.0.0
brctl addbr br0
brctl addif eth0
#setup storage
qemu-img create -f qcow2 /vdisk.img 10G
#Create VM
virt-install \
-n mylinux \
--description " VM with RHEL 6" \
--os-type=Linux \
--os-variant=rhel6 \
--ram=2048 \
--vcpus=2 \
#Upload VNF
--disk path=/vdisk.img \
Huawei NFV Architecture: Comply with NFV and Keep Openness
NFV Management and
Orchestration
MANO (VIM + NFVO + VNFM )
Os-Ma NFVO
OSS/BSS Orchestrator
CloudOpera
Se-Ma Orchestrator
NFVO
Service, VNF and Infrastructure
Description
Or-Vnfm
• NFVO manage network service lifecycle
EMS 1
vU2000
EMS 2 EMS 3 Ve-Vnfm VNFM • (EPC, IMS, VOLTE…)
iManager U2000 VNF • NSD: NS descriptor, a set of files that describes the
CloudOpera
VNF vIMS vEPC
Manager(s)
CSM VNF topology and resource requirements during the
vGi-LAN
VNF 1
CloudIMS
VNF 2
CloudEdge
VNF 3
CloudMSE
Or-Vi lifecycle of the NS
Vn-Nf Vi-Vnfm
NFVI
Virtual Virtual Virtual
VNFM ( S-VNFM / G-VNFM)
HuaweiStorage
Computing Cloud OSNetwork VIM • VNFM manage VNF lifecycle
FusionSphere/3 rd Party Nf-Vi Fusion
Virtualised • (vUSN, vUGW, vCSCF…)
NFVI Virtualisation Layer
Vl-Ha
Infrastructure
Manager
Manager(s) VNFD: VNF descriptor, a set of files that describes
Huawei Hardware resources
COTS +eSight the VM topology and resource requirements during
Computing Storage Network
rd
HardwareE9000/3 Party
Hardware Hardware the ifecycle of the VNF
Execution reference points Other reference points Main NFV reference points
VIM
MANO • Manage physical resources lifecycle
Create VM , delete VM
Collect hardware alarm info.
CloudEPC On Board with MANO
Each VM Flavor
e.g. to deploy CloudEPC
Upload of NSD/ Directory Network
1
Based on TOSCA NFV Orchestrator Policy
•Network Service Descriptor Written in XML / yaml CloudEPC
2 Upload batch of the VNFD, Call VNFM

vUSN/vUGW/vCG
NS Descriptor
VNF Manager Read VNFD
Service ID (CloudEPC) VNF Manager
3 Check/Reserve the
Vendor (Huawei)
vUSN Description Resource
Version (VxRx)
5VMs for 5VMs for 3VMs for
VNFD Index vUGW Description vUSN vUGW vCG
4 Call VIM to Create
VNFFGD
…. /Delete the VM/
VLD
VIM VIM VIM Download IMG
Scale Policy VNF1 VNF2 VNF3
…
COTS
MWC 2017 – NFV Solution: Best Technology Enabler
Thank you
Copyright©2017 Huawei Technologies Co., Ltd. All Rights Reserved.
The information in this document may contain predictive statements including, without limitation, statements regarding the future financial
and operating results, future product portfolio, new technology, etc. There are a number of factors that could cause actual results and
developments to differ materially from those expressed or implied in the predictive statements. Therefore, such information is provided for
reference purpose only and constitutes neither an offer nor an acceptance. Huawei may change the information at any time without notice.

Ljubisa Crnadak Huawei2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ljubisa Crnadak Huawei2

Uploaded by

Copyright:

Available Formats

Ljubiša Crnadak

LB Translate to Load LB Translate to

LB Translate to Load LB Translate to

•Scale in as traffic decreases re-allocated between PS and CS in earthquake

•Rapidly recycle and reuse resources

•Fully automated scaling Voice

Thailand Case Natural Disaster Case

Active Standby Standby Active

Active Standby Standby Active

Subscriber Calls here Subscriber

Active Standby Standby Active

• Resource utilization is only 50% as

Active Standby Standby Active

• Resource utilization is only 50% as

• Resource utilization is only 50% as

• Resource utilization is only 50% as

90%---------- 90%---------- 90%---------- 90%----------

Subscriber register here New Subscriber register here

Only New Only New

90%---------- 90%---------- 90%---------- 90%----------

Subscriber register here New Subscriber register here

Existing Subscribers Only New Only New

90%---------- 90%---------- 90%---------- 90%----------

Subscriber register here New Subscriber register here

Existing Subscribers Only New Only New

Stateless Service Process Unit Layer

Distributed Load Balancer Layer

SCU1 SCU2 SCU3 SCU4 SCU1 SCU2 SCU3 SCU4

User User User User

90%---------- 90%---------- 90%---------- 90%----------

User User User User

User User User User

RDB RDB RDB RDB

• Overestimate: Cause false flow control

... Priority 1 Priority 1

KPI-based Partially Unhealthy Detection and Auto-Healing

Supporting VNF/NS level fault self-healing

Collect service Action for

VM1 VM2 VM3 VM1 VM2 VM3

KPI Collection &

Top N Failure and Deal Ways

Hardware NONE NONE Isolated Isolated Manual check NONE NONE

• 1+1 Redundancy, Non-distributed architecture • All-Active, Distributed architecture

• Centralized Database • De-centralized Database

• Resource reservation for Redundancy Pooled • Resource On-demand

• Auto-Scale in with Call Lose

GGSN SGW/PGW GGSN + SGW/PGW vUGW

EMS vU2000 vPRS VNFM

OMU IPU SPU

OMU IPU SPU

2 Upload batch of the VNFD, Call VNFM

You might also like