Cellular Network Infrastructure » Radio Access Network » OsmoBSC

To be 100% sure, this is not about the CTRL-Interface right?

Problem here: I still do not have a working ONW setup. The RTP streams get stuck somewhere, would be nice if we could fix this.

During a recent discussion it became aparrent how important this is for deployments behind NAT. There's one IPA/SCCPlite connection between BSC and BSC-NAT, and that connection must handle BSSMAP, CTRL, MGCP and possibly more.

Architecture-wise, we'll have to add some mode in which CTRL (in libosmoctrl) can register/bind to a sub-flow of the libosmonetif IPA stream creted by libosmo-sigtran. Not yet sure how it will look in the end.

https://gerrit.osmocom.org/#/c/osmo-bsc/+/9340

patch has been merged. TTCN-3 test pending.

Assigning this to neels as he's doing SCCPlite interop testing. After having completed native SCCPLite, it is getting time to test against the osmo-extended IPA multiplex of bsc-nat, where this issue becomes relevant.

I am not active in this direction, please reassign...

Some related information I gathered so far in order to add some tests in ttcn3-bsc and ttcn3-bscnat:

When the BSC starts and establishes a link to the NAT, trx is (are) in a certain state (usually rf_locked=1). See osmo-bsc VTY "rf_locked" and "rf-lock-exclude".
Then, if a GPS is configured, the bsc is supposed to report its position every 5 mn (or what has been configured in place of the default value).
Upon location report (see osmo-bsc CTRL TRAP "location-state"), CTRL traps are issued by the BSC and caught by external software running attached to the NAT CTRL iface.
The controlling software attached to BSCNAT replies BSC with commands to apply. See VTY command "rf_locked 0"?
The identifier for the bsc is always the ‘bsc id' as defined in the NAT.

Manually Triggering "location-state" from BSC:

$ telnet localhost 4242
enable
generate-location-state-trap 0
exit

I also found a VTY command "bsc-rf-socket" (src/osmo-bsc/bsc_rf_ctrl.{c,h}) which seems related, but I'm not sure what's about. Seems to be a unix socket from which somebody can query and set "rf-locked" of BSC?

• Faking a position
• sending VTY command "generate-location-state-trap 0"
• Expect a CTRL trap to be sent on the CTRL IPA conn
• Send an "rf-locked 0/1" on it
• Somehow check that rf-locked was applied correctly (through VTY or perhaps through TRAP generated by BSC with the information about status changed).

On the BSC-NAT, we can do something similar, by sending a "location-state" message through BSC CTRL IPA conn, and make sure BSC-NAT forwards it correctly, as well as answers from TTCN3 on the other side reach the ttcn3 emulated BSC.

Added infrastructure to be able to interact with Muxed CTRL over IPA on the MSC-Side (in BSC tests), and added a test to verify "location" setting and resulting TRAP is sent fine.

• Expand test to lock/unlock the BSC after receiving the TRAP on the MSC side.
• Add similar test for BSC-NAT.

remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14406 lib/RAN: Introduce CTRL_CLIENT port to access CTRL muxed in RAN IPA conn
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14407 bsc: Introduce test TC_ctrl_location

Submitted bunch of patches to have similar stuff in BSC-NAT:

remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14410 bscnat: Move generic code to wait for test into its own function
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14411 bscnat: Refactor BSC_MS side code to allow different actions per test
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14412 bscnat: Refactor MSC side code to allow different actions per test
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14413 bscnat: Add function to run actions on test per BSC component
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14414 bscnat: Introduce test TC_ctrl_location
remote: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/14418 lib/IPA_Emulation: Build IPA_CTRL conditionally based on define

Once merged we can close this ticket.

Merged, closing.