It checks location-state TRAP is forwaded correctly in BSC-NAT from BSC
towards locally connected CTRL client, with variable names updated to
contain BSC/BTS indexes.
It also verifies commands can be applied (SET) in inverse direction.
Change-Id: If28aba011a1903788cacbc10c0b62954925d4b1f
Each test can now plug in different actions to be done by the emulated
BSC_MS, by passing a function to f_init(). Old hardcoded behaviour (main())
is renamed and used in already existing tests.
Change-Id: Ic82ca333267535c5859e6439deacbf3b1d1fe391
This will allow RAN_Emulation to have better knowledge on the protocol
stack in use, and behave differently based on that information.
For intance, forthcoming commit will append OsmuxSupport IE only if
transport is BSSAP AoIP.
Change-Id: Ife62e328af2d3f2475ff93249f2138820c7ddabb
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Test verifies once osmux is enabled in osmo-bsc, BSSMAP RESET (ACK)
contains Osmux Support IE and that it correctly handles BSSMAP ASsign
Req with Osmux CID.
Related: OS#2551
Depends: osmo-bsc 6de754cdde5319af3059d8fc6abf85037ec7eacc
Depends: titan.ProtocolModules.BSSMAP Iaf1e137269c0da20b2c96fd104b57edf336693af
Change-Id: If69c716dc06d61d810c32d1720a237c7535baca8
The RAN_Emulation currently unconditionally provides BSSAP and MGCP support.
Let's re-structure the code so that support for those protocols is now
possible to enable/disable at compile time.
This patch is in preparation of introducing RANAP support in RAN_Emulation.
Change-Id: Id53ba3ff05f9946230e0e4a759245de14a0f9fbd
Related: OS#2856
So far, BSSMAP_Emulation supported only a transport over BSSMAP.
However, we soon intend to merge support for RANAP in order to
simulate RANAP/Iu connections as well as BSSMAP. Let's start
by renaming some of the existing types/functions/ports/modules
without introducing any functional changes just yet.
Related: OS#2857, OS#2856
Change-Id: Iecbcb0c6c136baad9460eca40606bb4010d8882d
It's quite cumbersome if the user of the BSSMAP_Emulation (the ConnHdlr)
will have to manually decode the DTAP in every BSSAP/DTAP message he
receives (and encode on the transmit side). Let's introduce a new
optional mode in which the DTAP messages are already decoded for
more convenient matching inside the ConnHdlr.
Change-Id: I35cd4ea78aca0ce7c7d745e082d7289882c11e81
So far, BSSMAP_Emulation used the SCCPasp_SP_PORT directly, explicitly
calling BSSAP encode/decode functions while processing the primitives.
Let's clean this up and use the BSSAP_CodecPort which has meanwhile
been developed as a dual-faced port that can be stacked between SCCPasp
and the user to avoid any manual encode/decode function calls.
Change-Id: Icded789d18f3469f74e16f552df2c7ac44ac4294
Pau Espin
Harald Welte
Daniel Willmann