Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

From 3GPP TS 48.018 Section 8.4

A BVC-RESET procedure is performed because of recovery procedures related to:
- a system failure in the SGSN or BSS that affects GPRS BVC functionality (e.g. processor recovery);
...
The BSS may also send BVC-RESET as a means to create the initial mapping between BVCIs and cell identifications. After any of the possible events stated above, the status of the affected BVCs may be inconsistent at the SGSN and the BSS. After performing the BVC Reset procedure all affected BVCs are assumed to be unblocked at the SGSN. The reset procedure forces a consistent state upon SGSN and BSS by requiring that after the completion of the BVC-Reset procedure the BSS initiates the block procedure for all affected BVCs that are marked as blocked at the BSS.

Even more interesting, section 8.4.1 seems to hold the key:

After any failure affecting the NSE, the party (BSS or SGSN) where the failure resided shall reset the signalling BVC. After sending or receiving a BVC-RESET PDU for the signalling BVC, the BSS shall stop all traffic and initiate the BVC-RESET procedure for all BVCs corresponding to PTP functional entities of the underlying network service entity. The BSS must complete the BVC-RESET procedure for signalling BVC before starting PTP BVC-RESET procedures.

So the SGSN does not need to know the BVCI of the individual PtP-BVCs, but it should simply send a BVC-RESET for the signaling BVC (BVCI=0), which should then trigger the related recovery. Let's try to implement that and test it.

Does OsmoSGSN/OsmoPCU support actual static Gb configuration? When we tried to configure that on the OsmoPCU/OsmoGbProxy side, we had to patch the code to achieve static Gb configuration (see our branch). The code was not clean enough to submit it for the master, though.

We also saw that in our case, a commercial SGSN sends BVC-RESET to our PCU as soon as it detects the NSE down, and keeps re-sending it until our PCU responds with ACK. I can share some traces if they could help.

https://gerrit.osmocom.org/c/osmo-sgsn/+/19027 should fix this. Adding a TTCN3 test case is not straight-forward as the BVC-RESET is only sent at start-up of the process, and we don't restart the SGSN during tests - and only start tests well after the SGSN has been started.

patch long merged