Project

General

Profile

Actions

Bug #5116

closed

What to do with Iu timer X3314

Added by pespin almost 3 years ago. Updated almost 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/13/2021
Due date:
% Done:

100%

Spec Reference:

Description

This Iu timer is Osmocom specific, but is made to resemble T3314 timer from GERAN (also named READY timer).

The READY timer mission is to make the MM state transition from READY to STANDBY, which in PMM (UTRAN) matches the transition from CONNECTED to IDLE.

Recently the timer was fixed to behave properly upon expiry:
https://gerrit.osmocom.org/c/osmo-sgsn/+/23743 mm_state_iu_fsm: T3314 expiry must lead to PMM IDLE, not PMM DETACHED

The idea of this activity timer is to arm it whenever PMM state transitions to CONNECTED, and then rearm it every time there's some sort of activity, until there's none for some time, then we send a Release Command to close the conn with the HNGBW/RNC. That's the same principle as per spec-defined READY timer T3314.

However, there's still a fundamental problem with it: GTP-U in GERAN passes through the SGSN, but in UTRAN, the GTP-U stream goes directly from the HnodeB to the GGSN. Hence, there's no proper way to re-arm this timer upon activity in UTRAN, basically because the SGSN will never see (userplane data) activity. That explains why the E_MM_PDU_RECEPTION event exists for mm_state_gb_fsm, but doesn't exist for mm_state_iu_fsm.
As a result, the timer is currently never rearmed, which means it will transition to IDLE always after 44 seconds (default value) once it went into CONNECTED state.

So, unless there's some way to monitor about activity by asking the GGSN or the HNBGW or hNodeB, I see no point in having that timer there, specially with a short expire of 44 seconds.
I would agree perhaps with keeping it but having a much much longer expire time, like several minutes or even hours. Even then, it may make sense to set it to 0 by default (disable it, and rely only on the lower layers signalling end of the conn).

Actions #1

Updated by laforge almost 3 years ago

  • Assignee set to pespin

I would also think it make sense to remove the timer. In GERAN, this makes sense as we don't have the equivalent of a "SCCP connection" on the Gb interface.

But in UTRAN, there is a SCCP connection for each subscriber between RNC/hNB and SGSN. If the subscriber is no longer in the respective state, I'd expect the RNC/hNB to release that IuPS SCCP connection, whcih in turn means the SGSN cleans up its state.

SCCP has a built-in IT (inactivity timer). So should the RNC/hNB die, that timer would time out, and the SGSN-side local SCCP stack (provider) wold send a RELEASE.ind for that connection to the user (SGSN).

Actions #2

Updated by pespin almost 3 years ago

  • Status changed from New to In Progress
Actions #3

Updated by pespin almost 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 0 to 90
Actions #4

Updated by pespin almost 3 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)