Cellular Network Infrastructure » Core Network (CN) » OsmoHLR

See also: http://lists.osmocom.org/pipermail/openbsc/2018-October/012260.html

Hi Keith,

thanks for this report!

I've managed to reproduce the problem in my virtual network,
and implemented a fix for that, please see:

https://gerrit.osmocom.org/11341/

In short, the problem is that 'structured' SS requests are not answered at all.
We should reject such requests by sending returnError message until we start to support them.

Nice! Thanks for fixing that!

I wonder if there should be some kind of "failsafe" timer also on the MSC (or maybe it's BSC side) that would shutdown the channel in the case that the HLR became unresponsive.

I should have also included a trace of the call that I mentioned in the email.. Let me try to get that now before I pull your HLR patch....

OK, Maybe I'll make a new ticket for this, but as it is possibly not easy to reproduce without the bug mentioned here, I'll put it here for now..

This is what I do and what I observe, using a Nokia 6070.

Dial *#21# + SEND

BSC at this point shows:

OsmoBSC# show lchan s
BTS 0, TRX 0, Timeslot 1 TCH/F, Lchan 0, Type TCH_F, State ESTABLISHED - L1 MS Power: 5 dBm RXL-FULL-dl:  -47 dBm RXL-FULL-ul:  -50 dBm

Some several minutes later, phone TX is still active, TCH is still active.
I issue drop bts from BSC
Phone display shows Request not completed

(in the pcap, I didn't wait so long before dropping the bts)

Adding Capture of A/GSUP for above description.

Further,

With the HLR patch in place, the KRZR now camps, issues the SS and goes idle. All Good. :)
Subsequently calling the KRZR from the Nokia (with the error provoked in freeswitch by #3650) results in a lingering SDCCH on the KRZR!

(with osmo-sip-connector patched to override the payload_type, call sets up, connects, and completes with success)

Still, It strikes me we are missing something. abis pcap of the above attached.

A / GSUP pcap for above. (there's some OsmoVTY, SIP and freeswitch console noise in there too)

Note, these A /GSUP captures were not captured at the same time as the abis, but it was the same sequence of events.

Hi Keith,

I wonder if there should be some kind of "failsafe" timer
also on the MSC (or maybe it's BSC side) that would shutdown
the channel in the case that the HLR became unresponsive.

Yep, definitely. I created an issue, please see: #3655.

With the HLR patch in place, the KRZR now camps,
issues the SS and goes idle. All Good. :)

Should we mark this issue as "resolved" then?

Subsequently calling the KRZR from the Nokia
results in a lingering SDCCH on the KRZR!

If it's still related to the SS/USSD, I am feeling a bit lost :)

The following test case confirms that the problem was actually solved:

https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11960/

so, closing.