Project

General

Profile

Bug #1818

IuPS: CN should Iu Release in certain situations

Added by neels about 1 year ago. Updated 3 months ago.

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

0%

Spec Reference:

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.

iups_sporadic_failure.pcapng - 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" (179 KB) neels, 01/23/2017 01:27 PM


Related issues

Related to OsmoSGSN - Bug #1977: 3G IuPS is unreliable New 03/09/2017

History

#1 Updated by neels about 1 year ago

  • Description updated (diff)

#2 Updated by laforge 10 months ago

  • Assignee set to daniel

#3 Updated by neels 10 months 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".

#4 Updated by daniel 9 months 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

#5 Updated by neels 9 months ago

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

#6 Updated by neels 3 months 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.

Also available in: Atom PDF