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.orgHi Neels,
On Tue, Mar 12, 2019 at 05:04:09AM +0100, Neels Hofmeyr wrote:
> At first I had problems grasping the concepts, but in the end it worked pretty
> nicely to start two distinct BSC handlers like this:
>
> testcase TC_ho_inter_bsc() runs on MTC_CT {
> var BSC_ConnHdlr vc_conn0;
> var BSC_ConnHdlr vc_conn1;
> f_init(2);
>
> vc_conn0 := f_start_handler(refers(f_tc_ho_inter_bsc0), 53, 0);
> vc_conn1 := f_start_handler(refers(f_tc_ho_inter_bsc1), 53, 1);
> vc_conn0.done;
> vc_conn1.done;
> }
>
> It's walking all the way through inter-BSC Handover now (!) up until the point
> where I want to discard the call.
>
> Now I'm facing the simple problem that I want to call f_call_hangup() in the
> second f_tc_ho_inter_bsc1() -- but I have no cpars (CallParameters) with a
> valid MNCC callref nor the CC transaction ID, those are in the first function.
>
> How can I share cpars between those functions?
You cannot. THose are not different "functions", but you have to think of those
as separate processes runnign somewhere, possibly even on different machines.
Every TTCN3 component (at least in Titan) runs self-contained, as a
separate process. The only way of interacting with it is via
message-based / sequential transports, such as the test ports (message
or procedure based). Depending on the size/complexity of your setup,
each component could run on a different machine, and they use socket
based transports in between. Given that, you cannot have shared state
between them, as you cannot assume they'd have shared memory of some
sort. If they need to talk, then you have to implement some kind of
"IPC", e.g. by adding message or procedure ports between them and it
quickly becomes very complex.
For testing the MSC side of inter-BSC-handover, I would assume one
creates a single test component that has two BSSAP test ports, so
basically you can behave like BSC0 and BSC1 from within a single
testcase or any of its functions - as well as handle the MCCC side of
it. I also think that's the only way in which you can enforce a
particular order of events from your test. If you're runnign two
parallel compoments, each of which is testing only half of your IUT,
then they run completely concurrently without any synchronization.
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)