HTTP Session Management for Real-Time AF-PCRF Communication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current solutions for two-way communication between a Policy and Charging Rules Function (PCRF) and an Application Function (AF) or Protocol Converter (PC) using HTTP protocols face inefficiencies, such as high signaling overhead and resource occupation, particularly in supporting real-time traffic plane events for a large number of users, due to limitations in TCP connections and protocol compatibility.
Innovation Solution
A session management method involving HTTP request messages with AF session identifier information is implemented, allowing for the establishment, modification, and termination of sessions, while managing TCP connections to enable real-time two-way communication, including the use of HTTP persistent connections and Diameter messages for session management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If HTTP protocols (Streaming or Long-Polling) are used for two-way communication between PCRF/PC and AF, then real-time notification capability is achieved, but network resource occupation and signaling overhead increase significantly
Solution Approach 1:
The patent implements periodic action through Long-Polling mechanism where the AF entity periodically sends HTTP requests to the PCRF/PC to check for notifications. Instead of maintaining continuous connections like Streaming, the system uses periodic polling requests that are suspended until data is available, achieving real-time notification capability while reducing network resource occupation compared to continuous Streaming connections.
2Productivity
If multiple TCP connections are maintained for supporting large number of users, then real-time communication capability is improved, but device complexity and resource management difficulty increase
Solution Approach 1:
The patent applies universality by making the AF entity support both HTTP client and HTTP server functions simultaneously. This multi-functionality allows the AF to handle multiple user connections through a unified interface, reducing device complexity. The AF can serve multiple users through its dual role, eliminating the need for separate connection management mechanisms for each user while maintaining real-time communication capability.
3Adaptability or versatility
If HTTP protocols are used instead of Diameter protocol for Rx interface, then protocol compatibility with third-party applications is improved, but two-way communication capability deteriorates
Solution Approach 1:
The patent uses the AF entity as an intermediary that bridges HTTP and Diameter protocols. The AF receives HTTP requests from third-party applications and translates them into Diameter messages for communication with the PCRF. This intermediary approach maintains protocol compatibility with third-party applications using HTTP while ensuring reliable two-way communication through the Diameter protocol's inherent capabilities.
Solution Approach 2:
The patent employs periodic action through Long-Polling where the AF periodically checks for Diameter messages from the PCRF and pushes them to HTTP clients when available. This mechanism translates the request-response nature of HTTP into a push-based communication model, achieving two-way communication capability comparable to Diameter while maintaining HTTP protocol compatibility for third-party application integration.
Data Source
AI summary
The embodiments of the present disclosure disclose a session management method, an Application Function (AF) entity, a policy server, and a Protocol Converter. The method includes: When an AF entity establishes an AF session with a policy server, the AF entity sends a first HTTP request message to the policy server, herein the AF entity sends AF session identifier information to the policy server via the first HTTP request message, or AF session identifier information is allocated by the policy server and is sent to the AF entity via an answer for the first HTTP request message. When the policy server notifies the AF entity of a traffic plane event of the above-mentioned AF session, the policy server sends a second HTTP request message carrying the AF session identifier information to the AF entity. The AF entity returns an answer for the second HTTP request message to the policy server.