Network Status Transfer for PGW Overload Handling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
User equipment (UE) incorrectly adds a trusted WLAN network's SSID to a blacklist due to temporary packet data network gateway (PGW) overload, leading to persistent access rejection even after network recovery, without clear rejection reasons in transparent single-connection mode (TSCM).
Innovation Solution
A network status information transfer method where a network device determines PGW overload and instructs a third-party server to send a message to the UE, including an identifier of the TWAN and overload indication, preventing the UE from adding the TWAN to the blacklist, using service capability exposure function (SCEF) for communication between network devices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the TWAN rejects access by UE when PGW is overloaded, then the PGW overload problem is addressed, but the UE wrongly adds the TWAN SSID to blacklist
Solution Approach 1:
A third-party server acts as an intermediary to convey the access rejection reason from the network side to the UE. The server receives the rejection reason from the network device and sends it to the UE, enabling the UE to understand that the rejection is due to temporary PGW overload rather than TWAN issues, thus preventing wrongful blacklisting.
Solution Approach 2:
The system implements a feedback mechanism where the network device sends the access rejection reason to the third-party server, which then provides this information back to the UE. This feedback loop ensures the UE receives accurate information about why access was rejected, allowing it to make informed decisions about reconnection attempts.
2Ease of operation
If no lower-layer signaling is enhanced for UE in TSCM mode, then the TWAN access simplicity is maintained, but the TWAN cannot notify the UE of specific access rejection reason
Solution Approach 1:
The third-party server serves as an intermediary that bridges the gap between the network device and the UE without requiring changes to the TSCM architecture. It receives rejection reason information from the network side and delivers it to the UE through existing signaling paths, maintaining simplicity while enabling information transfer.
Solution Approach 2:
The patent replaces the need for enhanced lower-layer signaling mechanisms with a higher-layer information delivery approach using the third-party server. This substitution avoids complicating the existing TSCM signaling architecture while achieving the same goal of informing the UE about access rejection reasons.
3Reliability
If the TWAN reselects a PGW to avoid overload, then the blacklist problem may be resolved, but the PGW selection mechanism includes load balancing that usually results in selecting another overloaded PGW
Solution Approach 1:
The third-party server provides feedback to the UE about the specific reason for access rejection (PGW overload), enabling the UE to understand that retrying with the same TWAN after overload recovery is appropriate. This feedback eliminates the need for ineffective PGW reselection and directs the UE to wait and retry.
Solution Approach 2:
Instead of having the TWAN actively reselect a different PGW to avoid overload, the patent inverts the approach by informing the UE of the overload condition and allowing the UE to retry when appropriate. This passive approach is more efficient than active reselection that typically fails due to load balancing directing to other overloaded PGWs.
Data Source
AI summary
The present disclosure describes a network status information transfer method. In one example method, a first message, transmitted by a third-party server to a user equipment (UE), is received by the UE. The first message comprises an identifier, associated with a trusted wireless local area networks (WLAN) network (TWAN), and first indication information indicating that a packet data network gateway (PGW) is overloaded. If the UE has added the identifier associated with the TWAN to a blacklist, the identifier associated with the TWAN is deleted, by the UE, from the blacklist in response to receiving the first message.