Bug #2012
closedCTRL interface encapsulation over IPA link is missing when using libosmo-sigtran
Added by laforge about 7 years ago. Updated almost 5 years ago.
100%
Description
When OsmoBSC uses libosmo-sigtran for the A interface transport, it misses the capabiliy to transport/encapsulate the MGCP messages inside the IPA multiplex (like used towards osmo-bsc_nat). This must be ported over from old OsmoBSC.
Related issues
Updated by laforge about 7 years ago
- Related to Feature #1843: Add SCCP/M3UA signaling transport as alternative to IPA multiplex to osmo-bsc added
Updated by dexter almost 7 years ago
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.
Updated by laforge about 6 years ago
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.
Updated by laforge almost 6 years ago
- Related to Bug #2544: IPA/SCCPlite not fully supported from new osmo-bsc.git added
Updated by laforge almost 6 years ago
- % Done changed from 0 to 70
Updated by laforge over 5 years ago
- Assignee changed from laforge to neels
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.
Updated by neels almost 5 years ago
- Status changed from New to Feedback
- Assignee changed from neels to laforge
I am not active in this direction, please reassign...
Updated by pespin almost 5 years ago
- Related to Bug #2536: MGCP tunneling missing from IPA support in libosmo-sigtran added
Updated by pespin almost 5 years ago
- Status changed from Feedback to In Progress
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?
I still need to find how the GPS data is feeded into the BSC. Once I know that, I can add a TTCN3 BSC test by:- 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.
Updated by pespin almost 5 years ago
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.
next steps:- 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
Updated by pespin almost 5 years ago
- Status changed from In Progress to Feedback
- % Done changed from 70 to 90
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.
Updated by pespin almost 5 years ago
- Status changed from Feedback to Resolved
- % Done changed from 90 to 100
Merged, closing.