RAN UPPE for Edge Computing Traffic Offloading
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing SDN implementations, such as Open vSwitch, have limitations in processing packets for multi-access edge computing (MEC) as they can only process fields within the packet, like source or destination IP addresses, lacking visibility into packet-level data necessary for designing OpenFlow rules based on access point name (APN) or bearer ID, which are crucial for traffic offloading in cellular networks.
Innovation Solution
The introduction of a RAN User Plane Processing Entity (RAN UPPE) that extends SDN capabilities by converting matching fields not contained in the packet into matching fields inside the packet, enabling packet filtering for traffic offloading, and performing GTP user data tunneling encapsulation and decapsulation, allowing external entities to designate traffic for offloading at the packet or bearer level.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of information
If existing SDN implementations (Open vSwitch) process only packet fields like source or destination IP addresses, then the processing simplicity is maintained, but the visibility into packet-level data (APN, bearer ID) is lost, preventing effective traffic offloading
Solution Approach 1:
The RAN UPPE acts as an intermediary component between the existing SDN controller and the packet processing system. It receives packets from the RAN, extracts high-level attributes (APN, bearer ID) that are not directly visible in standard packet fields, translates them into suitable matching fields for OpenFlow rules, and forwards the processed packets to the SDN controller. This mediator enables the system to access packet-level data without fundamentally redesigning the core SDN processing architecture.
Solution Approach 2:
The packet processing function is segmented into separate modules: the RAN UPPE handles the extraction and translation of packet attributes, while the SDN controller maintains its existing packet forwarding functionality. This segmentation allows the complex attribute extraction to be isolated in a dedicated component, preventing complexity from propagating throughout the entire SDN system while still enabling enhanced traffic offloading capabilities.
2Manufacturing precision
If traffic offloading is enabled at packet or bearer level, then traffic management precision is improved, but the system complexity increases due to additional processing entities and protocols
Solution Approach 1:
The system changes the parameters used for traffic identification from standard packet fields (source/destination IP) to network-specific attributes (APN, bearer ID). The RAN UPPE translates these high-level attributes into formats suitable for OpenFlow rule matching, enabling precise traffic offloading at bearer level without requiring fundamental changes to the SDN controller's existing rule processing mechanisms.
Solution Approach 2:
The RAN UPPE performs preliminary processing of packets by extracting and translating packet attributes before they reach the SDN controller. This preliminary action prepares the packets with the necessary transformed fields, so that when the SDN controller receives them, it can directly use existing OpenFlow rule matching capabilities without additional processing complexity.
3Adaptability or versatility
If GTP user data tunneling encapsulation and decapsulation is performed, then packet routing flexibility is improved, but the processing time and computational overhead increase
Solution Approach 1:
The RAN UPPE performs GTP encapsulation and decapsulation as a preliminary action before packets reach the SDN controller. By completing these time-consuming operations in advance, the SDN controller receives packets that are already prepared for routing decisions, eliminating the need for it to perform these operations and reducing overall processing time.
Solution Approach 2:
The RAN UPPE creates transformed copies of packet attributes, extracting high-level information (APN, bearer ID) and converting it into formats suitable for OpenFlow rule matching. This copying process allows the original packets to be forwarded to the SDN controller with the necessary translated attributes already in place, avoiding repeated processing of the same data.
Data Source
AI summary
There is disclosed example techniques to include obtaining a filtering rule via a control plane message that includes information to identify a source of a general packet radio service (GPRS) tunneling protocol (GTP) user-plane (GTP-U) packet. The example techniques also include configuring, based on the information to identify the source, a virtual switch to identify the source of the GTP-U packet to use in the filtering rule to cause a received GTP-U packet to be sent to a local edge server or a mobile core network for processing based on at least a portion of a first extension header included in the GTP-U packet.