Split TNGF Gateway Architecture for Independent CP-UP Scaling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The monolithic design of the Trusted Non-3GPP Gateway Function (TNGF) in existing 3GPP specifications leads to increased deployment costs, difficulty in scaling and evolving control-plane and user-plane functionalities independently, and inflexibility in deployment locations.
Innovation Solution
Implementing a split TNGF architecture that separates the TNGF into distinct functionalities: TNGF-Control Plane (TNGF-CP), TNGF-User Plane (TNGF-UP), and TNGF-Secure Gateway (TNGF-SG), allowing for independent scaling and flexible deployment of these components.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If a monolithic TNGF design is used, then the system structure is simple, but deployment costs increase and scaling becomes difficult
Solution Approach 1:
The TNGF is divided into separate control-plane and user-plane functionalities, allowing independent deployment and scaling. The control-plane handles signaling and management functions, while the user-plane handles data traffic, enabling flexible deployment architectures that reduce overall system cost.
Solution Approach 2:
The user-plane functionality is extracted from the control-plane, allowing it to be deployed in different locations (e.g., near the UE for edge computing scenarios). This extraction enables cost reduction by placing computational resources closer to users, reducing backhaul costs and improving performance.
2Adaptability or versatility
If a monolithic TNGF design is used, then the system is easy to manage, but independent scaling of control-plane and user-plane functionalities is difficult
Solution Approach 1:
By segmenting the TNGF into control-plane and user-plane functions, each can be scaled independently based on demand. The control-plane can be scaled to handle more signaling connections, while the user-plane can be scaled to handle more data traffic, providing adaptability without complicating overall system management through standardized interfaces.
3Adaptability or versatility
If a monolithic TNGF design is used, then the deployment architecture is simple, but deployment location flexibility is reduced
Solution Approach 1:
The user-plane functionality is extracted and can be deployed in edge locations close to UEs, while the control-plane remains in centralized network locations. This extraction enables flexible deployment architectures that adapt to different service requirements, such as low-latency applications that benefit from edge computing.
Solution Approach 2:
Different parts of the TNGF are deployed in different locations optimized for their specific functions. The control-plane is deployed in secure, centralized locations for robust management, while the user-plane can be deployed locally at edge sites to provide low-latency service to specific user groups.
Data Source
AI summary
Apparatuses, methods, and systems are disclosed for a split TNGF. One apparatus includes a processor that receives a request from the AMF. Here, the request is sent during registration of the remote unit with the mobile communication network via the apparatus, where the request contains a first security key. The processor selects a TNGF-SG and sends a first message to the selected TNGF-SG that contains the first security key, an identity of the remote unit and a destination address and port indicating where the remote unit is to send signaling messages for the mobile communication network. The processor receives a second message from the selected TNGF-SG and establishes a first connection with the remote unit via the selected TNGF-SG. The processor completes the registration of the remote unit with the mobile communication network.