Project

General

Profile

Bug #5116

What to do with Iu timer X3314

Added by pespin 24 days ago. Updated 15 days 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).

Associated revisions

Revision 3caa7f6d (diff)
Added by pespin 23 days ago

Iu: Drop timer X3314

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

The idea of this activity timer was 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.

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, the RNC/hNB should release that IuPS SCCP connection, whcih
in turn means the SGSN cleans up its state.
Furthermore, 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).

TLDR; this timer is not really needed and cannot be implemented
properly in UTRAN, so let's remove it.

Related: OS#5116
Change-Id: Ibc71829e417bf2dd0c27deb842369dd4f17010d6

History

#1 Updated by laforge 24 days 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).

#2 Updated by pespin 23 days ago

  • Status changed from New to In Progress

#3 Updated by pespin 23 days ago

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

#4 Updated by pespin 15 days ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)