16 Oct
2018
16 Oct
'18
5:50 a.m.
Dear all
We are facing the following problem and hope you can help us:
- We use OSMO as UMTS core emulation, working with our real NodeB
- During UE attach procedure we see from SGSN "Location Update
Reject"
and afterthat UE is released.
- We do the comparison test with real UMTS core and our real NodeB,
here
it works properly, UE can attach successful.
We assume there is some Osmo configuration problem but we have not
found the root cause, we very appreciate if you can take a look and give us
some advice.
Here is the current message flow of UE attach
10.2.9.200 10.2.9.139 RANAP 170 (RUA) InitialUE-Message
(DTAP) (MM) Location Updating Request
10.2.9.139 10.2.9.200 RANAP 158 SACK (RUA) DirectTransfer
(DTAP) (MM) Authentication Request
10.2.9.200 10.2.9.139 RANAP 222 SACK (RUA)
InitialUE-Message (DTAP) (GMM) Attach Request
10.2.9.139 10.2.9.200 RANAP 122 SACK (RUA) DirectTransfer
(DTAP) (GMM) Identity Request
10.2.9.200 10.2.9.139 RANAP 118 (RUA) DirectTransfer (DTAP)
(MM) Authentication Failure
10.2.9.139 10.2.9.200 RANAP 158 SACK (RUA) DirectTransfer
(DTAP) (MM) Authentication Request
10.2.9.200 10.2.9.139 RANAP 154 SACK (RUA) DirectTransfer
(DTAP) (GMM) Identity Response
10.2.9.139 10.2.9.200 RANAP 162 SACK (RUA) DirectTransfer
(DTAP) (GMM) Authentication and Ciphering Req
10.2.9.200 10.2.9.139 RANAP 110 (RUA) DirectTransfer (DTAP)
(MM) Authentication Response
10.2.9.139 10.2.9.200 RANAP 138 SACK (RUA)
SecurityModeCommand
10.2.9.200 10.2.9.139 RANAP 98 (RUA) SecurityModeComplete
10.2.9.139 10.2.9.200 RANAP 122 SACK (RUA) CommonID
10.2.9.200 10.2.9.139 RANAP 166 SACK (RUA) DirectTransfer
(DTAP) (GMM) Authentication and Ciphering Resp
10.2.9.139 10.2.9.200 RANAP 134 SACK (RUA) DirectTransfer
(DTAP) (MM) Location Updating Accept
10.2.9.139 10.2.9.200 RANAP 122 (RUA) SecurityModeCommand
--> 10.2.9.139 10.2.9.200 RANAP 106 (RUA) DirectTransfer (DTAP)
(MM) Location Updating Reject
10.2.9.139 10.2.9.200 RANAP 102 (RUA) Iu-ReleaseCommand
10.2.9.200 10.2.9.139 RANAP 114 SACK (RUA)
Iu-ReleaseComplete
10.2.9.200 10.2.9.139 RANAP 102 (RUA) SecurityModeReject
10.2.9.200 10.2.9.139 RANAP 102 (RUA) Iu-ReleaseRequest
10.2.9.139 10.2.9.200 RANAP 118 SACK (RUA)
Iu-ReleaseCommand
10.2.9.200 10.2.9.139 RANAP 114 SACK (RUA)
Iu-ReleaseComplete
Thanks and regards
Tuan Lam
16 Oct
16 Oct
12:34 p.m.
Surely you have noticed the MM Location Updating Reject message in your pcap.
You are attaching fine to the SGSN (GMM), but are being rejected by the MSC
(MM). Hence your phone doesn't like it and leaves.
~N
12:43 p.m.
Actually, the GMM attach doesn't complete, either.
The messages look a bit confusing, with a bunch of Location Updating Accept
followed by a final Location Updating Reject due to "Congestion". The causes may
be
- two simultaneous MM attach requests from the same subscriber,
- timeout after attaching, e.g. phone sends no TMSI Reallocation Complete
It's hard for me to see what is going on there, take a look at the MSC's logs.
As soon as the MSC attach works out, the phone will continue to try at the SGSN.
~N
12:59 p.m.
Hello Mr. Neels Hofmeyr
Vielen Dank fuer die schnelle Antwort :-)
Actually we also have seen the "Congestion" in the log but we have not
understood why
We have modified the SGSN configuration: set auth-policy to accept-all.
We repeat the UE attach with this configuration but still MSC sends
"Location Update Reject"
I attach the new pcap file, msc log and sgsn log. I very appreciate if you
can take a look to that.
Vielen Dank
Tuan Lam
-----Original Message-----
From: Neels Hofmeyr [mailto:nhofmeyr@sysmocom.de]
Sent: Tuesday, October 16, 2018 5:43 PM
To: Lam Ngoc Tuan
Cc: osmocom-net-gprs(a)lists.osmocom.org
Subject: Re: Problem with SGSN Location Update Reject during UE attach
Actually, the GMM attach doesn't complete, either.
The messages look a bit confusing, with a bunch of Location Updating Accept
followed by a final Location Updating Reject due to "Congestion". The causes
may be
- two simultaneous MM attach requests from the same subscriber,
- timeout after attaching, e.g. phone sends no TMSI Reallocation Complete
It's hard for me to see what is going on there, take a look at the MSC's
logs.
As soon as the MSC attach works out, the phone will continue to try at the
SGSN.
~N
2:19 p.m.
On Tue, Oct 16, 2018 at 05:59:08PM +0700, Lam Ngoc Tuan wrote:
We have modified the SGSN configuration: set
auth-policy to accept-all.
No. For 3G, you require authentication, hence you need an external HLR that
provides auth tuples, for both MSC and SGSN.
I was unable to extract the attached rar file, please send a .tar or .tar.gz
instead, or even better, just post a link to a pastebin, so we don't fill up
people's mail inboxes.
In your first trace it seems that your authentication did work out, i.e. HLR
configured properly, but in the end the UE failed to respond with a TMSI
Reallocation Complete. That's a very weird situation, I would normally
associate that with an unreliable / unaccurate SDR based solution. But I assume
you are using a nano3G?
~N
2026
days inactive
2026
days old
osmocom-net-gprs@lists.osmocom.org
4 comments
2 participants
participants (2)
-
Lam Ngoc Tuan -
Neels Hofmeyr