You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix stale AMF CommunicationClient causing N1N2 transfer failures
After an AMF pod restart, SMF continues sending N1N2MessageTransfer
to the old AMF pod IP, causing PDU Session Establishment to fail
with T3580 expiry. This happens because:
1. CommunicationClient bakes in the AMF pod IP at session creation
and is never refreshed.
2. CommunicationClient is not JSON-serializable, so it's nil after
SMF recovers SMContext from MongoDB.
3. NRF accumulates stale NF registrations across pod restarts and
the NRF cache (15min TTL) returns stale entries on re-discovery.
4. The HTTP client has no timeout, so TCP connect to a dead pod IP
hangs for 60s+ — longer than the T3580 window.
Fix:
- Add SendN1N2TransferWithRediscovery() that wraps all N1N2 calls
with a 5-second context timeout. On failure, it re-discovers the
AMF by querying NRF directly (bypassing cache), prefers an AMF
with a different NfInstanceId than the failed one, and retries.
- Add RebuildCommunicationClient() on SMContext to reconstruct the
HTTP client from the stored AMFProfile after DB recovery.
- Replace all 5 direct CommunicationClient.N1N2MessageTransfer call
sites with the retry wrapper.
Verified on live cluster: after AMF pod kill, N1N2 transfer fails
in 5s, re-discovers new AMF, retries successfully. Total recovery
time 5.3 seconds vs permanent failure without the fix.
Signed-off-by: Vinod Patmanathan <vinod.patmanathan@forsway.com>
0 commit comments