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

This seems to be some sort of issue in TTCN3 - at least with TC_bvc_reset_ptp_from_bss

The pcap shows that we sent a BVC-RESET as a response to each of the SGSNs (pkt 580, 584) and we also receive an ACK for both (586, 588).

11:09:47.434843 603 BSSGP_Emulation.ttcnpp:1262 Rx BVC-RESET from BVCI=20011
11:09:47.434870 593 BSSGP_Emulation.ttcnpp:1261 Matching on port BVC succeeded:  matched
11:09:47.434876 603 BSSGP_Emulation.ttcnpp:1264 Sent on MGMT to mtc @BSSGP_Emulation.BssgpResetIndication : { bvci := 20011 }
11:09:47.434901 593 BSSGP_Emulation.ttcnpp:1261 Receive operation on port BVC succeeded, message from GbProxy_Test-BSSGP(SGSN[0])(591): @NS_Emulation.NsUnitdataIndication : { bvci := 0, nsei := 101, nsvci := 101, sdu := '2204824E2B078108088862F224334F00753B'O, bssgp := { pDU_BSSGP_BVC_RESET := { bssgpPduType := '22'O ("\""), bVCI := { iEI := '04'O, ext := '1'B, lengthIndicator := { length1 := 2 }, unstructured_value := '4E2B'O ("N+") }, cause := { iEI := '07'O ("\a"), ext := '1'B, lengthIndicator := { length1 := 1 }, cause_Value := '08'O ("\b") }, cell_Identifier := { iEI := '08'O ("\b"), ext := '1'B, lengthIndicator := { length1 := 8 }, mccDigit1 := '2'H, mccDigit2 := '6'H, mccDigit3 := '2'H, mncDigit3 := 'F'H, mncDigit1 := '4'H, mncDigit2 := '2'H, lac := '334F'O ("3O"), rac := '00'O, cI_value := '753B'O ("u;") }, feature_bitmap := omit, extended_Feature_Bitmap := omit } } } id 3
11:09:47.434923 593 BSSGP_Emulation.ttcnpp:1261 Message with id 3 was extracted from the queue of BVC.
11:09:47.434926 mtc GBProxy_Tests.ttcn:2457 Message enqueued on SGSN_MGMT from GbProxy_Test-BSSGP(SGSN[1])-BVCI20011(603) @BSSGP_Emulation.BssgpResetIndication : { bvci := 20011 } id 27
11:09:47.434942 593 BSSGP_Emulation.ttcnpp:1262 Rx BVC-RESET from BVCI=20011
11:09:47.434973 593 BSSGP_Emulation.ttcnpp:1264 Sent on MGMT to mtc @BSSGP_Emulation.BssgpResetIndication : { bvci := 20011 }
11:09:47.434975 603 BSSGP_Emulation.ttcnpp:1267 Sent on BVC to GbProxy_Test-BSSGP(SGSN[1])(601) @NS_Emulation.NsUnitdataRequest : { bvci := 0, nsei := 0, lsp := 20011, sdu := '2304824E2B'O, bssgp := omit }
11:09:47.434975 mtc GBProxy_Tests.ttcn:2459 Matching on port SGSN_MGMT failed: Sender of the first message in the queue does not match the from clause: GbProxy_Test-BSSGP(SGSN[1])-BVCI20011(603) with 593 unmatched
11:09:47.435005 mtc GBProxy_Tests.ttcn:2432 Matching on port SGSN_MGMT failed: Type of the first message in the queue is not @BSSGP_Emulation.BssgpStatusIndication.
11:09:47.435042 mtc GBProxy_Tests.ttcn:2457 Message enqueued on SGSN_MGMT from GbProxy_Test-BSSGP(SGSN[0])-BVCI20011(593) @BSSGP_Emulation.BssgpResetIndication : { bvci := 20011 } id 28

So we receive the ResetIndication, but the sender is wrong:

Sender of the first message in the queue does not match the from clause: GbProxy_Test-1">BSSGP-BVCI20011 with 593 unmatched

In the test we hard-code SGSN0

var BSSGP_BVC_CT sgsn_bvc_ct := f_get_sgsn_bvc_ct(0, bvc_cfg.bvci);

but this time TTCN3 actually handles the Reset from SGSN1 first and this unmatched message blocks the port...

We probably need to make these tests aware of the SGSN-pool and expect a BVC-reset from all SGSNs in the pool.

A similar thing seems to be happening in the other test case where we only activate an altstep for the first SGSN, but the message from the second one is handled first:

var BSSGP_BVC_CT sgsn_bvc_ct := f_get_sgsn_bvc_ct(0, bvc_cfg.bvci);

Proposed fix here:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/22361

There are multiple other tests that are not "pool-aware", I'll create a follow-up issue.