Cellular Network Infrastructure » Core Network (CN) » osmo-gbproxy

I believe the NAS Node Selection Function must take into account whether or not the given SGSN is currently available.

• SGSN 0 serves NRI 3
• SGSN 1 serves NRI 4

Now assume SGSN 0 has an outage.

Any traffic without TLLI or with TLLI mapping to the NULL NRI will now trigger the selection function. We currently choose any configured SGSN, unless it is administratively disabled with "no allow-attach". However, we do not check if the given PTP-BVC at that SGSN is currently available or not.

Another interesting question is what is supposed to happen with traffic with a NRI for the now-defunct SGSN pool member. If we simply route it to any other SGSN, that SGSN will not know what to do with that traffic? But at least it should then return some error to the MS, so the MS can re-attach?

laforge wrote:

Another interesting question is what is supposed to happen with traffic with a NRI for the now-defunct SGSN pool member. If we simply route it to any other SGSN, that SGSN will not know what to do with that traffic? But at least it should then return some error to the MS, so the MS can re-attach?

daniel , lynxis any feedback on this one? Any ideas? What is the expected behavior in your understanding of the specs?

laforge wrote:

Another interesting question is what is supposed to happen with traffic with a NRI for the now-defunct SGSN pool member. If we simply route it to any other SGSN, that SGSN will not know what to do with that traffic? But at least it should then return some error to the MS, so the MS can re-attach?

Yeah, I believe it will work just like you describe, I don't really see how SGSN pooling can help with this sort of failure (other than offering a new SGSN to reconnect to).

• Mark the SGSN as no allow-attach in gb-proxy so new connections ignore this SGSN
• Have the SGSN reallocate its NULL-NRI on (periodic) RA update, set the update timer to min. value and force the MS to stand-by

See https://projects.sysmocom.de/attachments/download/4350/SGSNs_in_Pool.pdf (pg. 8-10)

That way all MS currently on that SGSN will slowly migrate away and the SGSN can be taken offline.

But you are right that gbproxy currently doesn't handle the case correctly where an SGSN is down (e.g. because NS failed)

TTCN3 Test here: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/24442
Fails without the osmo-gbproxy fix.

Fix for osmo-gbproxy: https://gerrit.osmocom.org/c/osmo-gbproxy/+/24443

Patches are merged and the new test should pass on the next run