Project

General

Profile

Actions

Bug #1818

open

IuPS: CN should Iu Release in certain situations

Added by neels over 7 years ago. Updated about 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Iu interface
Target version:
-
Start date:
10/12/2016
Due date:
% Done:

0%

Spec Reference:
Tags:
3G

Description

I observe sporadic data service failure which is solved by reconnecting the UE.

The situation looks like this:

The UE keeps sending GMM Attach Requests and the SGSN keeps answering with GMM Attach
Accepts (more often than it receives Attach Requests even), but the process never
goes on after that. I notice the lack of Iu Releases.

When I put the phone in flight mode and back online, an Iu Release (and complete UE DE-REGISTER)
is done, and after that 3G data service works immediately and well.

The SGSN never sends and Iu Release on own accord nor invalidates the UE conn unless the
UE asks for an Iu Release.

There should be timeouts and the SGSN should do an Iu Release on a given conn at some
point. The UE will then re-connect with another InitialUE message and hopefully fix things.

There is possibly another hidden root cause for this situation, but this issue calls
for sane Iu Release timeouts by the SGSN.


Files

iups_sporadic_failure.pcapng iups_sporadic_failure.pcapng 179 KB pcap filtered 'sctp || gtp', obtained with nano3G, In the middle there loading xkcd.com worked, numerous other attemps resulted in "This web page is not available" neels, 01/23/2017 01:27 PM

Related issues

Related to OsmoSGSN - Bug #1977: 3G IuPS is unreliableClosedlynxis03/09/2017

Actions
Related to OsmoSGSN - Bug #3302: implement a FSM for GMM Attach RequestClosedlynxis05/29/2018

Actions
Related to OsmoSGSN - Bug #3908: "PS Activation" takes long time - missing Iu-Release Command after Attach CompleteResolvedlaforge04/07/2019

Actions
Actions #1

Updated by neels over 7 years ago

  • Description updated (diff)
Actions #2

Updated by laforge about 7 years ago

  • Assignee set to daniel
Actions #3

Updated by neels about 7 years ago

just now I tested again and saw IuPS not working most of the time.
I remember that previous tests also had this sometimes, so it seems to be some
race depending on when the user requests to contact the internet.

Attached find a pcap filtered 'sctp || gtp', obtained with nano3G.
In the middle there loading xkcd.com worked, numerous other attemps resulted
in "This web page is not available".

Actions #4

Updated by daniel about 7 years ago

Looking at the trace I can see that the difference between working and not working ist that the SecurityModeControl is answered with an UnsuccessfulOutcome (#618, #689, #720, others) instead of a SuccessfulOutcome (#197, #267).

We had this before, it seems to be an issue with the KeyValue and KeyStatus not matching what the UE expects.

The successful attempts are when using a new key value with status new (packets 207, 219) and this old key with status old (264, 267).

Then for some reason the next SecurityModeCommand has a different (new) key value, but the key status is still old (612). This then is answered with a reject (618). After we get into this the same dance continues with subsequent packets.

We should do two things:

  • if we receive a SecurityModeReject we need to choose a new key and reset the state to new in order to resync
  • fix the behaviour where a new key can be sent with keystatus old
Actions #5

Updated by neels about 7 years ago

  • Related to Bug #1977: 3G IuPS is unreliable added
Actions #6

Updated by neels over 6 years ago

daniel wrote:

  • if we receive a SecurityModeReject we need to choose a new key and reset the state to new in order to resync
  • fix the behaviour where a new key can be sent with keystatus old

This is likely a solution for #1977, excellent.

This issue here will be about more aggressive Iu Release on IuPS.

Actions #7

Updated by laforge over 6 years ago

  • Category set to Iu interface
Actions #8

Updated by laforge about 6 years ago

  • Assignee changed from daniel to 4368
Actions #9

Updated by laforge almost 6 years ago

  • Tags set to 3G
Actions #10

Updated by neels almost 6 years ago

  • Related to Bug #3302: implement a FSM for GMM Attach Request added
Actions #11

Updated by laforge almost 5 years ago

  • Related to Bug #3908: "PS Activation" takes long time - missing Iu-Release Command after Attach Complete added
Actions #12

Updated by laforge almost 5 years ago

the issue has been worked around for the attach with a patch from #3908. However, let's keep this issue open for the more comprehensive fix with timeouts as described in the comments above.

Actions #13

Updated by laforge almost 5 years ago

  • Assignee changed from 4368 to lynxis
Actions #14

Updated by laforge almost 5 years ago

The release procedure on the SGSN side should be performed as follows:

  • transmit of Iu-ReleaseCommand, start of a timer
    • somehow blocking/preventing any further communication on this connection. Possibly by FSM state transition
  • reception of Iu-ReleaseComplete (successful), or timeout
  • disconnection/termination of SCCP connection using N-DISCONNECT.req towards SCCP user SAP

See Section 8.5 Iu Release of TS 25.413 as well as section 4.5.1.1.3 of TS 25.410.

Actions #15

Updated by laforge about 4 years ago

  • Assignee deleted (lynxis)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)