Cellular Network Infrastructure » cni-legacy » OpenBSC » OsmoNITB

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?

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.

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.