Idle Session Timeout Settings

Feature Summary and Revision History

Summary Data

Table 1. Summary Data

Applicable Product(s) or Functional Area

cnSGW-C

Applicable Platform(s)

SMI

Feature Default Setting

Disabled – Configuration required to enable

Related Documentation

Not Applicable

Revision History

Table 2. Revision History

Revision Details

Release

First introduced.

2021.02.0

Feature Description

The stale session timeout determines the duration for which the SGW-U sessions can remain inactive before they are terminated. On the cnSGW-C platform, the SubscribeCtx represents the subscriber session. The SGW-U establishes a connection with peers, such as:

  • MME and PGW using the S11 or S4 interface
  • PGW on the S5 or S8 interface

When the peers delete the peer session, the SGW-U doesn't receive the deletion message or inadvertently misses them. In such situations, the SGW-U sessions remain idle and continue to receive the calls but do not process or respond to the request. To prevent the stale sessions from using the resources, the idle timeout feature enables the SGW-U to receive new subscriber session requests after deleting the old or stale sessions.

How it Works

This section describes how this feature works.

A subscriber session is idle when data traffic activity is not steered towards it as it is inactive for a stipulated time.

The session manager on the user plane tracks the state of the call line. Sessions for which the session manager does not record the call line data traffic are determined as idle. Using the idle session timeout configuration, you can set the time interval for which the session can remain idle before it times out. The idle timeout configuration is set when the session is established. The SGW-U sends the timeout configuration to the user plane in the Sx Session Establishment Request. In case of multi-PDN calls, the calls directed towards a stale session are cleared after the inactivity report is generated for all PDNs.

Every second, the SGW-U monitors the data traffic activity to determine the session's idleness status. On identifying a stale session, the user plane updates the User Plane Inactivity Report in the Sx Session Usage Report and sends it to cnSGW-C to convey that the session is idle. Further, the cnSGW-C initiates a session deletion request towards its peers.

Based on the network environment, configure the idle timeout configuration in seconds. The accepted range of the timeout value is 1–4294967295 seconds. The timeout configuration is applicable at the SGW-U service profile level enabling the idle timeout handling for the set of subscribers handled by the SGW-U service.

Call Flows

This section describes the key call flows for this feature.

Inactivity Report Call Flow

This section describes the Inactivity Report call flow.

Figure 1. Inactivity Report Call Flow
Table 3. Inactivity Report Call Flow Description

Step

Description

1

The MME sends the Create Session Request to the GTP-EP (S11).

2

The GTP-EP (S11) forwards the Create Session Request to the SGW.

3

The SGW-SVC sends the Session Idle Timer in IE = USER INACTIVITY as part of Sx Session Establishment Request to the Protocol.

4

The SGW-U reads the Session Idle Timer from USER INACTIVITY and stores it at the CLP level.

The UPF sends the Sx Session Report Request to the Protocol.

5

The Protocol sends the Sx Session Report Request to the SGW-SVC.

6

The SGW-SVC sends the Sx Session Report Response to the Protocol.

7

The Protocol sends the Sx Session Report Response to the UPF.

8

The SGW-SVC sends the Delete Session Request to the GTPC-EP.

9

The GTPC-EP sends the Delete Session Request to the PGW.

10

The SGW-SVC sends the Delete Bearer Request to the GTP-EP.

11

The GTP-EP sends the Delete Bearer Request to the MME.

12

The MME sends the Delete Bearer Response to the GTP-EP.

13

The GTP-EP sends the Delete Bearer Response to the SGW-SVC.

14

The PGW sends the Delete Session Response to the GTPC-EP.

15

The GTPC-EP sends the EGTP Delete Session Response to the SGW-SVC.

16

The SGW-SVC sends the Sx Session Deletion Request to the Protocol.

17

The Protocol sends the Sx Session Deletion Request to the UPF.

18

The UPF sends the Sx Session Deletion Response to the Protocol.

19

The Protocol sends the Sx Session Deletion Response to the SGW-SVC.

Idle Timer Handling on UPF Call Flow

This section describes the call flow when the idle timer is received in the Create Session Request on the UPF.

Figure 2. Idle Timer Handling on UPF Call Flow
Table 4. Idle Timer Handling on UPF Call Flow Description

Step

Description

1

If the value of idle_timeout_sec is greater than zero, the timer is started on UPF with granularity of one second.

Else, idle timeout is disabled.

2

The timer timeouts every second. Checks if the difference in current time and last packet received is greater than idle_timeout_sec or not. If the time difference is greater than idle_timeout_sec, then UP sends the Sx Session Report Request with Report Type = UPIR (Inactivity Report) to CP (cnSGW-C).

Value
     

Reactivity Report Call Flow

This section describes the Reactivity Report call flow.

Figure 3. Reactivity Report Call Flow
Table 5. Reactivity Report Call Flow Description

Step

Description

1

The MME and the SGW-SVC process the initial attach request.

2

The Protocol-SXA and the SGW-UPF perform the user inactivity exchange in the Sx Session Establishment Request.

3

If the inactivity is observed in PDN-1, the SGW-UPF sends the Sx_Session_Report_Request with type User Plane Inactivity Report to the Protocol-SXA.

4

 The Protocol-SXA sends the Sx_Session_Report_Request to the SGW-SVC.

5

The SGW-SVC sends the Sx_Session_Report_Response to the Protocol-SXA.

6

The Protocol-SXA forwards the Sx_Session_Report_Response to the SGW-UPF.

7

The PGW-UPF sends the data for the EBI-6 (in PDN-1) to the SGW-UPF.

8

The SGW-UPF sends the Sx_Session_Report_Request with IE Report-Type = User Plane Re-Activity Report to the Protocol-SXA.

9

The Protocol-SXA sends the Sx_Session_Report_Request with IE Report-Type = User Plane Re-Activity Report to the SGW-SVC.

10

The SGW-SVC responds with the Sx_Session_Report_Response to the Protocol-SXA.

11

The Protocol-SXA sends the Sx_Session_Report_Response to the SGW-UPF.

After receiving the Sx_Session_Report_Response on the control plane, SGW-SVC clears the Inactivity Report Flag for the PDN.

Clear Call Handling Call Flow

This section describes the Clear Call Handling call flow.

Figure 4. Clear Call Handling Call Flow
Table 6. Clear Call Handling Call Flow Description

Step

Description

1

On the SGW, the control plane receives the User Plane Inactivity Report in Sx Session Report Request. The control plane evaluates if PDN in the request is the latest PDN, or the inactivity report has already reported other PDNs. The control plane initiates the ClearCall procedure.

2

After receiving the ClearCall message, the cnSGW-C triggers a Session Deletion Request to its peers.

3

The SGW sends the Delete Bearer Request to the S11/MME.

4

The SGW sends the Delete Session Request to the S5/PGW.

5

On receiving the Delete Session Request, SGW clears resources on the UPF by sending a Sx Session Delete Request.

Feature Configuration

To configure this feature, use the following configuration:

config 
  profile sgw sgw_group_name 
    session-idle-timer session_idle_timer 
    end

NOTES:

  • session-idle-timer session_idle_timer —Specify the maximum duration in seconds for which a session remains idle. After the configured time is reached, the system automatically terminates the session. The accepted range contains integers in the range of 1–4294967295. The default value is zero indicating that the idle session is disabled.

Configuration Example

The following is an example configuration.

config
   profile sgw sgw1
     session-idle-timer 1000
     end

Configuration Verification

To verify the configuration:

show running-config profile sgw sgw1 session-idle-timer
profile sgw sgw1
session-idle-timer 1000