ttcn3: more than one BSC

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Tue Mar 12 21:07:25 UTC 2019


Hi Neels,

On Tue, Mar 12, 2019 at 06:47:43AM +0100, Neels Hofmeyr wrote:
> The really interesting part then is the 24.007 11.2.3.2 N(SD) sequence number
> patching. Took me a moment to realize that when the one BSC wants to send CC
> DTAP while the other has advanced in N(SD) sequence numbering, the DTAP sent
> from TTCN3 is rejected as duplicate because TTCN3 has lost the MS state. So
> some way or other .. we need to manually tweak the TTCN3 N(SD) state to match
> the actual DTAP flow, or keep a common MS state in TTCN3 that sorts this out
> across BSCs.

That's another indication that somehow the component architecture of the
test isn't right.

Either one goes for the "single component with two BSSAP ports [one for
each emulated BSC]" approach I suggested in my previous e-mail, or one
has to separate the "simulated MS component" from the "simulated BSC
component".  This way you could "disconnect" a test port between the MS
and BSC0 and re-connect that port to BSC1, while the MS component
retains all of its state.  Sounds more complex to implement than the
"single component with two BSSAP ports" approach.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list