Project

General

Profile

Bug #2691

Old TMSI paged after LU

Added by zecke 7 months ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
11/29/2017
Due date:
% Done:

0%

Estimated time:
Spec Reference:

Description

While working on the scripting of "mobile" I noticed a funny paging issue.

  • Do UL from mobile
  • Send SMS from NITB and start paging to mobile
  • "shutdown" mobile
  • "no shutdown" mobile
    • UL happens
    • TMSI reallocation
  • NITB will continue paging the old TMSI

The issue got introduced in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 when separating the subscribers...

History

#1 Updated by neels 7 months ago

  • Status changed from New to Feedback
  • Assignee set to zecke

UL means LU (Location Update) I presume.

The issue got introduced in 6d804b1a7e375213cb4b3e437c2b9b8c68872164 when separating the subscribers...

ugh, my bad.

I wonder though why it happens, because

subscr_paging_dispatch() {
       bsub = bsc_subscr_find_or_create_by_imsi(net->bsc_subscribers,
                                                subscr->imsi);
       bsub->tmsi = subscr->tmsi;

}

So IIUC it is the paging that is ongoing from before the LU and has not received a response yet. Then when the TMSI is reallocated, the old paging continues. i.e. we want to abort any ongoing pagings on a LU for a subscriber?

For the case of SMS, it should actually retry to page again some time later, with the correct TMSI, right?

#2 Updated by zecke 7 months ago

  • Subject changed from Old TMSI paged after UL to Old TMSI paged after LU

#3 Updated by zecke 7 months ago

Yes LU (in core network it is UL..).

Right when paging begins the TMSI is correct, during paging the TMSI is changing (and not updated). So there are three "issues"

  • gsm_subscr changes should propagate to bsc_subscr
  • our default time to page is unusual large (so a retry of SMS sending might take "a" bit)
  • once we have the RF channel for LU.. we could send SMS after the LU accept (or wait until the TMSI reallocation complete)

I have to figure out what of this applies to osmo-msc and we can solve it there.

#4 Updated by neels 7 months ago

UL vs LU: in our code it's called lu / location updating all the way to the HLR :)

zecke wrote:

  • gsm_subscr changes should propagate to bsc_subscr

That's a problem in the separate MSC/BSC setup by definition. We cannot change the TMSI in the middle of a paging. The proper way in terms of A interface would be to stop paging and then start a new paging.

  • our default time to page is unusual large (so a retry of SMS sending might take "a" bit)

On 33c3 we still had to increase that to get a successful paging response..... maybe something is wrong there?

  • once we have the RF channel for LU.. we could send SMS after the LU accept (or wait until the TMSI reallocation complete)

I have to figure out what of this applies to osmo-msc and we can solve it there.

So you're specifically concerned with osmo-nitb here? I guess it still makes sense to think of it in terms of what the A interface is defined to do.

#5 Updated by laforge about 1 month ago

  • Assignee deleted (zecke)

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)