Sridhar Bhaskaran

Huawei Technologies
https://www.linkedin.com/in/sridharbhaskaran/
http://cellularinsights.blogspot.in/
 Typical Point to Point Core Network Architecture
until 4G

Issues with P2P Architecture in Virtualized / Cloud

Scale Deployments

Need for Change - Use Cases

Current 5G Service Based Architecture as of 3GPP

Agenda Release 15

● Protocol Layering
● Benefits of HTTP/2 + JSON
● API Design Principles
● Network Slicing
● Security
● Challenges

Future
2
From 4G P2P Architecture to 5G Service
Based Architecture LTE - Evolved Packet Core (EPC)
- Release 13 Architecture
LTE - Evolved Packet Core (EPC) SMS- MTC-
SC IWF
- Release 8/9 Architecture
SCEF HSS
HSS

RCAF

MME PCRF AAA

MME PCRF AAA

SGW PGW
SGW PGW TWAP/
ePDG TWAG
ePDG
Untrusted non 3GPP
Untrusted non 3GPP Access (e.g Public WiFI)
Access (e.g Public WiFI)

● Too many point to point

GTP
interfaces.
GTP Diameter
● Different protocols.
Diameter IKEv2
● Long cycles for
IKEv2 TLV over SCTP 3
development
Issues of P2P Architecture
● GTP-C messages based on a pre-established tunnel state - TEID.

● Diameter interfaces support both stateful (via session ID) and stateless interactions.

● Stateless cloud scale deployment of GTP / DIAMETER require custom front end load balancers

○ Can be used only in telco

○ Don't meet economies of scale

● New feature development and deployment require telco vendors to support new GTP / Diameter
messages, interop testing ⇒ Long cycles. No large scale open market availability of developers that are
well versed with GTP / Diameter, leading to vendor lock-ins.

4
Need for Change - Use
Cases

5
5G Requirements (from NGMN)

6
5G Use Case Category Definition (NGMN)

7
Use Cases Driving New 5G CN
● Diverse use cases - one network cant fit all ⇒ Network Slicing.

○ Independent deployment and management of each slice

○ Ability to own and manage a slice from a different administrative domain (e.g 3rd party
enterprise)

○ Same application but provided by different enterprises

○ Support for vertical market deployments

○ Multi persona UE. One UE connects to multiple/different end to end networks (e.g private
browsing, office VPN; car connecting to car infotainment network as well as car factory for real-
time diagnostics and control)

● Plug and play deployment of new features ⇒ Network Interactions via APIs ⇒ Service Based
Architecture.

● Control Plane - User Plane separation from day 1 ⇒ Enabling SDN - centralized CP/distributed UP.
8
Use Cases Driving New 5G CN
● Application influence on traffic steering.

● Support for Ethernet and Unstructured PDU types allowing deployment of LAN services over 3GPP
radio.

● Support for Edge Computing ⇒ Local Area Data Network (LADN), Uplink Classifiers and Branching
Points with Multihomed IPv6.

● On demand mobility ⇒ Session and Service Continuity Modes (SSC Modes)

● Reduced signalling between UE and Core Network for IDLE-ACTIVE state transition + Energy efficient
state handling at UE ⇒ RRC Inactive.

● Common authentication framework for any access (3GPP, WLAN, Wireline). Common core for any
access (3GPP, WLAN, Wireline) ⇒ True fixed-mobile convergence.

● Architectural Enablers for Virtualized / Cloud based Deployments ⇒ Support for stateless NFs.

9
Architectural Enablers for Cloud Deployment

● Storage of Network Function and session state in an unstructured data storage function (UDSF).

○ Allows session state to be separated from signalling thus enabling stateless NFs

● From protocol based signalling ⇒ API based core network signaling interaction.

○ Allows new features to be developed by reusing APIs

○ Direct interaction with needed NF via API

○ API and service discovery via NRF

● Ability to change the TNL (Transport Network Layer) address to UE session state binding anytime.

10
R15 Service Based
Architecture

11
5G Core Network Architecture

Courtesy: http://www.3gpp.org/news-events/3gpp-news/1930-sys_architecture
5G Control Plane Protocol Stack

Nsmf, Nsmsf, Namf, Nother all carry upper part of NAS over HTTP/2 multipart message
5G Service Based Architecture - Protocol
Stack

14
How does it all work?

2. Discover the API endpoint of NF service

API
compliant
1. Register NF Service (API URI, Network producer
API profile)
to Repository
OpenAPI Function Network
3.0 spec
(NRF) Function
Network
Service
Function
Consumer
Service (E.g 3. HTTP/2 request to API URI invoking (E.g SMF,
SMF PDU specified HTTP method in OpenAPI
PCF that
Session
needs to send
Service)
N1 / N2
4. HTTP/2 response message)

15
Benefits of Service Based Architecture

● APIs registered in a service registry - NRF.

● APIs discovered and used by any authorized consumer - opens out network for 3rd party application
integration.

● Authorization based on OAuth 2.0 - NRF acts as authorization server issuing access tokens.

● APIs based on formal spec (OpenAPI 3.0) allowing automatic code generation.

● Faster develop - test - deploy cycles - DevOps model - due to ready availability of tools and
infrastructure for HTTP / REST APIs.

16
Benefits of HTTP/2 - JSON
● Ready availability of off
the shelf HTTP/2
servers and client
libraries

● Scaling backend
instances by
terminating API
endpoints at a reverse
proxy

● Ready availability of off

the shelf reverse
proxies (NGINX,
Apache etc)
17
API Design Principles

● RESTFul as much as possible - Level 2 Richardson Maturity Model.

● Custom operations with resources for RPC like semantics.

● API major version carried in URI

○ Eg. {apiRoot}/n<nf>-<service-name>/v1

● API formally defined in OpenAPI 3.0 spec (yaml file)

● API version in OpenAPI spec consists of 4 numbers

○ MAJOR.MINOR.PATCH pattern

● Detailed security guidelines in 3GPP TS 29.501

18
Security

Intra PLMN (Non Roaming and Inter PLMN (Roaming)

Local Break Out Cases)
2. Encapsulate whole
HTTP/2 message into
another HTTP POST

Visited
HPLMN
https:// URI PLMN
TLS SEPP
SEPP
OAuth2.0
Authorization NF
NF
Service
Service TLS Consume 3. Decapsulate original
Producer
r HTTP/2 message and
call API end point

NF
NF
Service
Service
TLS Recommended Consume 1. HTTPS API,
OAuth2.0 Auth token Producer
r
NDS (IPSec) may be used if TLS is not for URI of NF service
producer
used 19
Security - Challenges
● HTTP requests are end to end - “:authority” pseudo header refers to API endpoint host

● SEPPs act as proxies on path

● How can SEPP intercept TLS if HTTP client tries to setup end to end TLS with HTTP server in another
PLMN?

○ Bump in TLS / TLS interception solutions?

● It's not just SEPP acting as proxy. IPX providers between PLMNs want visibility into inter PLMN
messages as well.

● IPX providers want to modify the messages based on inter PLMN policies.

● How to allow IPX providers to insert modifications without compromising security?

● See detailed liaison exchanges between 3GPP SA3 and GSMA in S3-173407 and S3-180338
20
Allowing IPX to Modify HTTP/2 Messages
2. HTTP/2 Request: “:authority” = FQDN/port of NF
service producer; “:path” = API URI path of NF service
producer

3. SEPP creates a new POST request with

headers, payload of original request in /2/
encapsulated as JSON attributes. The
whole encapsulated block is integrity
NF Service protected with JWS. Security sensitive NF Service
information subjected to JWE
Consumer Producer
SEPP on SEPP on
Service Service
Consumer Producer
PLMN PLMN
IPX IPX

1. HTTP/2 “:method=GET/PUT/POST…”
“:authority = FQDN/port of NF service producer”
Transport is TLS with SEPP (Open: SEPP to do bump
in TLS?)
4. IPX-es insert their modifications as JSON
patch instructions into a separate block in
the outer HTTP POST request. IPX
insertions are digitally signed with JWS.
5. SEPP decapsulates the original
payload, verifies JWS signature and then
21
reconstructs / forwards original HTTP/2
request to NF service producer
3GPP Release 16 and
Beyond

22
3GPP Release 16 and Beyond

● Enhanced Service Based Architecture (FS_eSBA)

● Study on use of QUIC as transport protocol underneath HTTP APIs (FS_QUIC)

● Support for massive IoT - core network enhancements to support cellular IoT features in 5G

● Support for Ultra Reliable and Low Latency Communication (URLLC) - new QoS characteristics,
enhanced UPF placement logic, Enablers for ultra reliability

● Wireless Wireline Convergence

● Support for Enhanced Network Automation using Analytics

● Multicast and Broadcast support over 5G

● 5G LAN
23
R16 - Enhanced Service Based Architecture
TR 23.742
Service Framework

API
NRF Routing
● Register the NF services ● HTTP Request to NF Service
along with NF service Producer
parameters ● Based on HTTP headers, JSON
● Parameters include: attributes, the service framework
Service Type of Producer, discovers the NF producer to
S-NSSAI, Service Area route to
Information, Service Zone ● API Routing towards discovered
ID, Service Set ID etc NF service producer

NF Service NF Service
Producer Consumer

Service discovery responsibility moved from NF service consumer to

Service Framework 24
3GPP 5G Core Network Specifications

● 5G System Requirements - TS 22.261

● 5G System Architecture - TS 23.501

● 5G System Procedures and Call Flows - TS 23.502

● 5G Security - TS 33.501

● 5G Network Slice Management - TS 28.530

● http://www.3gpp.org/ftp/Specs/archive/23_series/

● http://www.3gpp.org/ftp/Specs/archive/22_series/

25
3GPP 5G Core Network Stage 3 Specifications
Sl.No Spec Number Title

1 TS 29.500 5G System; Technical Realization of Service Based Architecture; Stage 3

2 TS 29.501 5G System; Principles and Guidelines for Services Definition; Stage 3

3 TS 29.502 5G System; Session Management Services; Stage 3

4 TS 29.503 5G System; Unified Data Management Services; Stage 3

5 TS 29.504 5G System; Unified Data Repository Services; Stage 3

6 TS 29.505 5G System; Usage of the Unified Data Repository services for Subscription Data; Stage 3

7 TS 29.507 5G System; Access and Mobility Policy Control Service; Stage 3

8 TS 29.508 5G System; Session Management Event Exposure Service; Stage 3

9 TS 29.509 5G System; Authentication Server Services; Stage 3

10 TS 29.510 5G System; Network function repository services; Stage 3

26
 3GPP 5G Core Network Stage 3 Specifications
Sl.No Spec Title
Number

11 TS 29.511 5G System; Equipment Identity Register Services; Stage 3

12 TS 29.512 5G System; Session Management Policy Control Service; Stage 3

13 TS 29.513 5G System; Policy and Charging Control signalling flows and QoS parameter mapping; Stage 3

14 TS 29.514 5G System; Policy Authorization Service; Stage 3

15 TS 29.518 5G System; Access and Mobility Management Services; Stage 3

16 TS 29.519 5G System; Usage of the Unified Data Repository Service for Policy Data, Application Data and
Structured Data for Exposure; Stage 3

17 TS 29.520 5G System; Network Data Analytics Services; Stage 3

18 TS 29.521 5G System; Binding Support Management Service; Stage 3

19 TS 29.522 5G System; Network Exposure Function Northbound APIs; Stage 3

20 TS 29.573 5G Sytems; PLMN Interconnection; Stage 3 27

Network Slicing in Core

28
5G Core Network Features - Network Slicing
LTE - Evolved Packet Core (EPC) 5G Core Network (5GC) SMF1
PGW
(APN1)

PGW UE RAN AMF SMF2

UE RAN MME SGW
(APN2)

PGW
(APN3) SMF3
● 1 UE - connect to one Dedicated Core Network (DCN)
● 1 DCN can support multiple applications (APN)
● Same application support in multiple DCNs require repeated
configurations for same APN but different DCN in DNS

UPF1 DN-1
● 1 UE - can connect to multiple core network slices
● Each slice identified by an S-NSSAI
● AMF is common to all slices UE uses UPF2 DN-2
● SMFs specific to each slice
● SMFs selected via NRF specific to the slice (S-NSSAI)
● NRFs + SMFs can be in different administrative domain from AMF UPF3 DN-3
● SMFs select UPF
● Traffic routing of each slice is independent and isolated
● RAN supports slicing at the radio
● Network Slice Selection Policies provided to UE to
select a slice for a given application 29
Use Cases Enabled by 5G Slicing

1 UE - common AMF - but multiple slices with slice specific SMF, UPF and PCF

Courtesy: http://www.3gpp.org/news-events/3gpp-news/1930-sys_architecture
Other Use Cases Enabled by 5G Slicing
● For vertical applications - operators can spawn SMF, UPF, PCF in separate slice
instance(s) for that vertical market and route UE traffic for those vertical applications.
● Testing of new features in the network by deploying a specific slice and configuring a
specific set of UEs to use that slice (through UE Configuration Update NAS
procedures).
 1. 5G Core Network is a Paradigm
Shift

2. First truly cloud native

architecture

Summary 3. API based - Easy 3rd party

application integration

4. First truly converged core for all

access

5. Diverse use case support

32
Thank You