Project

General

Profile

Actions

Feature #5507

open

Optimize reset time after SGSN is restarted

Added by pespin 10 months ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
libosmogb
Target version:
-
Start date:
03/31/2022
Due date:
% Done:

0%

Spec Reference:

Description

scenario:
osmo-pcu <-> osmo-gbproxy <-> osmo-sgsn, using ip-sns.

SGSN is restarted. Gbproxy keeps testing its peers using NS_ALIVE and expecting NS_ALIVE_ACK. The PCU side keeps working fine. The SGSN, since it was restarted, answers back with NS_STATUS cause="PDU not compatible with the protocol state (0x0a)" and PDU IE containing the NS_ALIVE.

When receveing this, the gbproxy basically ignores it, and keeps retrying the NS_ALIVE procedure on the gbproxy<->sgsn side for "timer tns-alive 3" "timer tns-alive-retries 10" times (3GPP TS 48.016 sec 7.4b). Meanwhile, PCU sees the connection as if it was up (because gbproxy is still interacting on that part of the conn).

Finally the 3sec*10 time iteration is over and NS_RESET+NS_RESET_ACK, NS_UNBLOCK+NS_UNBLOCK_ACK, BVC_RESET+BVC_RESET_ACK is done.
After that, we see both gbproxy<->sgsn sending NS_ACTIVE+NS_ACTIVE_ACK one each other correctly.

Now, the point here is that this reset procedure takes unnecessarily long (3*10 secs), which it could be done almost immediatelly, since the gbproxy can detect something is wrong with the SGSN when it receives the first NS_STATUS containing the NS_ALIVE.

The SGSN, upon receiving NS_STATUS with cause="PDU not compatible with the protocol state (0x0a)" and containing NS_ALIVE PDU, should trigger immediatelly the RESET procedure, instead of waiting for 3*10 secs.

This can probably implemented in the ns2 library in libosmocore?

Actions #1

Updated by lynxis 10 months ago

  • Project changed from osmo-gbproxy to libosmocore
  • Category set to libosmogb
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)