Actions
Bug #4337
openosmo-msc: Don't send LU-Reject after LU-Accept if no TMSI Realloc Complete is received
Status:
New
Priority:
Normal
Assignee:
-
Category:
Mobility Management
Target version:
-
Start date:
12/17/2019
Due date:
% Done:
0%
Resolution:
Spec Reference:
Description
pespin> neels, hi! I'm looking at some osmo-gsm-tester tests. I see osmo-msc answering a LU Request with an LU Accept, and 4 seconds later answer it with a LU Reject (cause: congestion 22)
<pespin> the reject seems to be triggered by fsm.c:322 msc_a(IMSI-901700000015253:MSISDN-7770:TMSInew-0x0E475C08:GERAN-A-1:LU)[0x612000010420]{MSC_A_ST_AUTH_CIPH}: Timeout of X1
<pespin> is that expected?
<pespin> is it because a TMSI Reallocation Complete is expected from uplink?
<pespin> I'm not really sure if it's correct sending a LU Reject after already having sent an LU accept...
<pespin> neels, I introduced a TTCN3 that reproduces the scenario: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/16648
<neels> pespin, so in a setup without TMSI, the LU Accept is the end of it. However, with TMSI enabled, the LU Accept sends the newly assigned TMSI for future conns
<neels> so then we are only successful when the MS responds with "TMSI Reallocation Complete"
<neels>I'm not 100% sure whether we should still regard the LU as successful, but the code as it is now completely rejects when the TMSI reallocation didn't work, on purpose
<pespin>30 yes, been learning that while looking at it later. Does it make sense to send a reject after already having sent an Accept thought?
<neels>IIRC I took that behavior from the osmo-nitb code base, we'd need to ride the specs to find out for sure
<pespin>30 neels, any hint on where to look at?
<neels>(sorry for not answering sooner, I missed the highlight)
<pespin>30 np
<neels> TS 24.008 or 48.008 maybe?
<LaF0rge> neels: it most be in 04.08 or its successors, 24.008 is a good guess as it describes L3 MM+CC. 48.008/08.08 sounds rather unlikely
<LaF0rge> 44.018 also not likely, as that's the RR part of 04.08.
<neels> yep, 48.008 is about BSSAP...
<pespin> neels, LaF0rge TS 24.008 4.3.1.5 "If the RR connection is lost before the TMSI REALLOCATION COMPLETE message is received, the network shall release all MM connections, if any. Furthermore, the network should consider both the old and the new TMSI as occupied for a certain recovery time."
<pespin> and during that period (old and new TMSI as occupied afaiu): the network can use the IMSI or if the MS sneds something then the TMSI realloc procedure is restarted. It can even consider the new TMSI as valid if the MS is using it afterwards.
<pespin> so afaiu that implies the LU is one part, and TMSI realloc is another stage afterwards which happens to go together in the same message in LU Accept for performance timing reasons
<pespin> so LU reject shouldn't be sent at that point.. or is that the meaning for "release all MM connections" ?
<neels> I interpret "release all connections" as a "Clear Command", which we normally do after a LU.
<neels> so it seems we should see it as an accepted LU
<neels> (but in practice it's not something that typically happens)
<neels> (so if we fix the behavior, we're not likely to see any practical impact at all.)
Related test: TTCN3 MSC_Tests.TC_lu_imsi_timeout_tmsi_realloc
Related issues
Actions
