Question: In a CUPS architecture, when a user plane function detects a peer GTP-U entity restart via GTP-U Error Indication messages, what action is taken regarding PFCP sessions associated with the restarted entity?
Option 1: The user plane function sends a PFCP Node Report Request to the control plane function, reporting the restart and modification of affected PFCP sessions (e.g., removing F-TEID(s) allocated by the restarted entity).
Option 2: The control plane function autonomously identifies and modifies all PFCP sessions associated with the restarted GTP-U entity without receiving any report from the user plane function.
Option 3: All PFCP sessions are automatically terminated upon detection of a peer GTP-U entity restart, requiring new session establishments.
Option 4: The user plane function ignores the restart event for PFCP sessions, relying on periodic GTP-U Echo Requests to maintain connectivity.
Explanation: In a CUPS architecture, when a user plane function detects a peer GTP-U entity restart, it proactively reports this event to the control plane function using a PFCP Node Report Request. This report includes information about the restarted peer GTP-U entity and the modification of all associated PFCP sessions (e.g., removal of F-TEID(s) allocated by the restarted entity). This process ensures efficient management of affected sessions, potentially triggering further procedures like Downlink Data Notification for network-triggered service requests.