Vous êtes sur la page 1sur 15

5G Service Based Architecture enables

universal core

Hannu Flinck, 18.09.2018

1 © Nokia 2018 Public


Why 5G? New user demands – with extremely diverse requirements

Devices Smart Factories


1.5 GB/day 1 PB/day

Billions of sensors Autonomous driving


connected 1ms latency Design and architecture principles:
flexible | scalable | automated | cloud native
software centric | dynamic network slicing

2 © Nokia 2018 Public


Unleashing the potential of 5G – driven by Service Based Architecture

Intelligent
Powerful
Efficient
Flexible

Digital Value Platforms


Nokia Bell Labs
innovation in action Augmented Cognition Systems 5G Future X
Programmable Network OS
Universal Adaptive Core
Short
Autonomously waves
optimized coverage & wires
& capacity Long
Software- fibers
defined

Converged
Emerging Devices Massive Scale Converged Smart Network Node
& Sensors Access Edge Cloud Fabric

3 © Nokia 2018 Public


Architectural shifts are underway…

HIGHEST MOST
Architectural shift 3: PERFORMANCE PERSONALIZED

Distributing the Core Cloud… in


the Network LOWEST COST NFV
Edge PER BIT
Architectural shift 1:
Architectural shift 4:
Cloud/Access SDN
Distributing the Access Network Architectural shift 2: Virtualizing the Network

Software-Defining the Network

Large Low • Current radio processing and


Today number number control is distributed.
• Current core is centralized.
BTS Core

• Radio processing and control


Radio Core
processing processing more centralized for scalability.
Target • Core more distributed for low
Edge cloud
BTS Core latency.

4 © Nokia 2018 I Public


Cloud-native approach for the 5G core network
Web-scale capacity with programmability Code Plan

Culture
Dev Ops
Build

Test

Microservices
Upgradeability / Scalability
Functional split Service
architecture

Containers
C C C C Deployment
Cloud-native architecture

Common SW
5G Future X

Smart Network
Fabric

5 © Nokia 2018 Public


3GPP Control Plane evolution
from boxes to cloud native Network Functions and services
NG core: reference point based
Common Data layer
AUSF NG13 UDM

NG8
NG12 NG10

Control Plane AMF NG11 SMF NG7 PCF NG5 AF

NG15

NG4
NG1 NG2 NG4

User Plane
UE (R)AN NG3 UPF NG9 UPF NG6 DN

NG6

DN

Source TR 23.799 V2.0

NG core: Service Based Architecture

Service Based Architcture using


N2 N4 cloud native Network Functions
N3
RAN N6
UPF DN
6 © Nokia 2018
Service Based Architecture (SBA)
Scalable core architecture for the 5G era
5G Universal Adaptive Core
Common Data Layer
Major Changes
5G cellular access
5G Service-Based Control Plane • Control Plane – User Plane Separation
programmable per slice
• Service Based Architecture (SBA)
• Compute Storage Separation
WLAN access

Agile Virtual Edge/Core


• Flexible distribution, scaling of edge and core functions
Wireline access • Access specific control functions minimized, and
Programmable User Plane contained in edge functions

Scalable data center & IP/optical network

Common core platforms deliver all services over all forms of access

7 © Nokia 2018 Public


Network Functions are made out of Network Function Services
Service consumers use services over well defined REST-interfaces

NF_service1_interface NF_service2_interface NF_service n_interface

Network Network Network


Function Function
… Function
Service 1 Service 2 Service n

Network Function (NF)

• NF service: a functionality exposed by a NF through a service based interface.


• NF services should be self-contained, reusable and independent.
• Within a given communication context, a service may take the role of either service
consumer or service producer.

8 © Nokia 2018 Public


Service Based Architecture
Principles of network function and service discovery

NF discovery: NRF
Consumer obtains a list of candidate NFs NF registration:
via NRF query; candidates are based Network functions register
on NF type, set, network slice, services/capabilities to the
1
required services. 2 NRF (directly or via OAM)

Consumers should
cache NRF responses Consumer Producer Producer
3
to keep NRF load low NF NF NF
 subscribe to NRF updates
NF selection:
Consumer selects one of the Producer Producer
candidate producer NFs based NF NF
on criteria such as load,
location, and other metadata

NF selection separated from discovery to allow flexible NF-specific selection methods


9 © Nokia 2018 Public
Microservices design pattern applied to 5G Network Functions
How to find optimal size for microservices
• Microservices are an architectural and organizational style to software development.
• Microservices:
– Unit of distribution with single responsibility. AMF V-SMF NF consumers

– Part of a distributed system. UPF


Session Manager
– Are loosely-coupled. Function

– Have a single bounded context. Nsmf_PDUSession N4 Nsmf_EventExposure

– Contained in their own server (VM or container). Service area and


NAS SM message UPF selection
roaming management
• Challenges: handling

– Finding the optimal size of a microservice is an art. N3 tunnel topology


UDSF management
– Complexity moves to interactions of the microservices.
– How to design communication across microservice boundaries?
– A microservice will often use a combination of sync and async communication styles.

10 © Nokia 2018 Public


Granularity and scalability of Network Functions and their services
Modelled as microservices: define the bounded context
Ideal microservice • X-axis scaling:
granularity – Multiple copies of the service
behind a loadbalancer.
– Provides capacity and high
availability.
• Y-axis scaling:
– Number of microservices.
– Size measurements: e.g.
number of responsibilities,
number of files/LOC.
– Number of interactions.
• Z-axis scaling:
– Each service/server is
responsible for only a subset
of the data.
Scale cube
11 © Nokia 2018 Public
Role of Service Framework in 5G
Discovery, selection and routing

3GPP model for Rel. 15 – “Centralized discovery” Service Framework discussions for Rel. 16
– Service Mesh for micro-services

N
Service Framework. Could be a sidecar proxy
A R B A B (e.g. a utility in Kubernetes Pod) loosely
F
coupled to the main application container
IP ntw

C D C D

Centralized discovery and availability monitoring by NRF (Network Centralized control plane for discovery, availability monitoring, selection
Repository Function), with distributed selection and message routing. and message routing with distributed user plane (“sidecar”)

12 © Nokia 2018 Public


Use of microservices leads to Service Mesh approach
Microservice = unit of distribution with bounded context
• Microservices approach leads to hundreds to thousands of small service instances that may be
rescheduling from moment to moment by the orchestrator.
• Each micro service can be written in a different language with different libraries leading to different
versions and behavior of protocols.
• Service mesh is a networking abstraction layer above TCP/IP to handle service to service
communications.

Host Host In case of more capable


POD/Container proxy like Linkerd, this
POD/Container
Service
POD/Container deployment will cost
Service
POD/Container POD/Container
Service POD/Container few hundred MBs of
Service Service
Service
POD/Container memory per pod.
Proxy ProxyService
Proxy
Shared Proxy (ENVOY, Linkered,
etc.)

13 © Nokia 2018 Public


QUIC vs. HTTP/2
Does QUIC bring any advantages over HTTP/2 in the SBA or microserve settings?
• Connection Setup delay ~ latency
• 3 RTTs and 1 RTT for reconnect with HTTP/2.
• QUIC can achieve faster connection establishment by combining encryption and connection
handshakes: 1 RTT and 0-RTT.
• BUT for 0-RTT Data is limited to idempotent requests.
• Stream Multiplexing in both.
• Helps to avoid head of line blocking. But needs mapping of request–responses to their own parallel
streams.
• BUT what about the bounded context? A shared connection seems to create a shared context!
• Connection Migration.
• QUIC allows connection migration while a session is in progress. BUT only for client side.
• Maybe MPQUIC would be helpful here.
• Pluggable Sender Side Congestion Control in QUIC at the application level.
• Interference with other traffic? May vary between implementations.
• Improved header compression and Improved Recovery and Acknowledgement..
• Are these useful inside a DC?
14 © Nokia 2018 Public
Conclusions

• 5G core is being re-designed to be cloud native in the Service Based Architecture.


• Services are currently grouped into Network Functions that expose their contained
services to NF consumers. A centralized Network Repository Function offers service
discovery.
• The interaction model of the services follows REST client – server model that has its own
limitations.
• In micro-service philosophy bounded context defines the service granularity. But how to
factor in optimal use of HTTP2 and QUIC multiplexing and connections?
• Not clear if QUIC really provides justifiable benefits in this use case.
• How would transition to QUIC happen?
• HTTP2 over QUIC? A proxy GW?

15 © Nokia 2018 Public

Vous aimerez peut-être aussi