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