Sridhar BhaskaranHuawei Technologieshttps://www.linkedin.com/in/sridharbhaskaran/http://cellularinsights.blogspot.in/

Agenda

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

PGW

MME

SGW

HSS

PCRF AAA

ePDG

SCEF

Untrusted non 3GPP Access (e.g Public WiFI)

LTE - Evolved Packet Core (EPC) - Release 8/9 Architecture

3

PGW

MME

SGW

HSS

PCRF AAA

ePDG

Untrusted non 3GPP Access (e.g Public WiFI)

RCAF

GTP

Diameter

IKEv2

GTP

Diameter

IKEv2

TLV over SCTP

TWAP/TWAG

MTC-IWF

SMS-SC

LTE - Evolved Packet Core (EPC) - Release 13 Architecture

● Too many point to point interfaces.

● Different protocols.● Long cycles for

development

Issues of P2P Architecture

4

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

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?

15

Network Function Service (E.g SMF PDU Session Service)

Network Repository Function (NRF)

1. Register NF Service (API URI, API profile)

1. Register NF Service (API URI, API profile)

Network Function Service Consumer (E.g SMF, PCF that needs to send N1 / N2 message)

2. Discover the API endpoint of NF service producer2. Discover the API endpoint of NF service producer

3. HTTP/2 request to API URI invoking specified HTTP method in OpenAPI3. HTTP/2 request to API URI invoking specified HTTP method in OpenAPI

4. HTTP/2 response4. HTTP/2 response

API compliant to OpenAPI 3.0 spec

Benefits of Service Based Architecture

16

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

Benefits of HTTP/2 - JSON

17

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

API Design Principles

18

● 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

Security

19

Intra PLMN (Non Roaming and Local Break Out Cases)

Inter PLMN (Roaming)

NF Service Producer

NF Service Consumer

TLS

https:// URIOAuth2.0 Authorization

NF Service Consumer

Visited PLMN SEPP

HPLMN SEPP

NF Service ProducerTLS Recommended

NDS (IPSec) may be used if TLS is not used

TLS

1. HTTPS API, OAuth2.0 Auth token for URI of NF service producer

2. Encapsulate whole HTTP/2 message into another HTTP POST

3. Decapsulate original HTTP/2 message and call API end point

Security - Challenges

20

● 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

Allowing IPX to Modify HTTP/2 Messages

21

NF Service Consumer

NF Service Producer

SEPP on Service Consumer PLMN

SEPP on Service Producer PLMN

IPX IPX

2. HTTP/2 Request: “:authority” = FQDN/port of NF service producer; “:path” = API URI path of NF service producer

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

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 protected with JWS. Security sensitive information subjected to JWE

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 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 LAN23

R16 - Enhanced Service Based ArchitectureTR 23.742

24

● Register the NF services along with NF service parameters

● Parameters include: Service Type of Producer, S-NSSAI, Service Area Information, Service Zone ID, Service Set ID etc

Service Framework

NRFAPI

Routing

NF Service Producer

NF Service Consumer

● HTTP Request to NF Service Producer

● Based on HTTP headers, JSON attributes, the service framework discovers the NF producer to route to

● API Routing towards discovered NF service producer

Service discovery responsibility moved from NF service consumer to Service Framework

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

26

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

3GPP 5G Core Network Stage 3 Specifications

27

Sl.No Spec Number

Title

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

Network Slicing in Core

28

5G Core Network Features - Network Slicing

UE RAN MME SGW

PGW (APN1)

PGW (APN2)

PGW (APN3)

● 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

UE RAN AMF

SMF1

SMF2

SMF3

UPF1 DN-1

UPF2 DN-2

UPF3 DN-3

● 1 UE - can connect to multiple core network slices● Each slice identified by an S-NSSAI● AMF is common to all slices UE uses● 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● 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

LTE - Evolved Packet Core (EPC) 5G Core Network (5GC)

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

Summary

1. 5G Core Network is a Paradigm Shift

2. First truly cloud native architecture

3. API based - Easy 3rd party application integration

4. First truly converged core for all access

5. Diverse use case support

32

Thank You