3GPP 5G Control Plane Service Based Architecture

1. 3GPP 5G Control
Plane Service Based
Architecture
Sridhar Bhaskaran • 11.08.2018
https://www.linkedin.com/in/sridharbhaskaran/
http://cellularinsights.blogspot.in/
Need, Use Cases, Current State
and Future

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

3. 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-S
C
LTE - Evolved Packet Core (EPC)
- Release 13 Architecture
● Too many point to point
interfaces.
● Different protocols.
● Long cycles for
development

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

5. Need for Change - Use
Cases
5

6. 5G Requirements (from NGMN)
6

7. 5G Use Case Category Definition (NGMN)
7

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

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

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

11. R15 Service Based
Architecture
11

12. 5G Core Network Architecture
Courtesy: http://www.3gpp.org/news-events/3gpp-news/1930-sys_architecture

13. 5G Control Plane Protocol Stack
Nsmf, Nsmsf, Namf, Nother all carry upper part of NAS over HTTP/2 multipart message

14. 5G Service Based Architecture - Protocol
Stack
14

15. 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)
Network
Function
Service
Consumer
(E.g SMF,
PCF that
needs to send
N1 / N2
message)
2. Discover the API endpoint of NF service
producer
3. HTTP/2 request to API URI invoking
specified HTTP method in OpenAPI
4. HTTP/2 response
API
compliant
to
OpenAPI
3.0 spec

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

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

18. 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.3GPPRELEASE.MINOR.PATCH pattern
● Detailed security guidelines in 3GPP TS 29.501 (to be agreed)

19. Security
19
Intra PLMN (Non Roaming and
Local Break Out Cases)
Inter PLMN (Roaming)
NF
Service
Producer
NF
Service
Consume
r
TLS
https:// URI
OAuth2.0
Authorization
NF
Service
Consume
r
Visited
PLMN
SEPP
HPLMN
SEPP
NF
Service
Producer
TLS
TLS
TLS 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

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

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

22. Network Slicing in Core
22

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

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

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

26. 3GPP Release 16 and
Beyond
26

27. 3GPP Release 16 and Beyond
● Enhanced Service Based Architecture
● 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
27

28. 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/
28

29. 3GPP 5G Core Network Stage 3 Specifications
29
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

30. 3GPP 5G Core Network Stage 3 Specifications
30
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.cde 5G Sytems; PLMN Interconnection; Stage 3

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

32. Thank You
32