I'm trying to test inter-BSC Handover in ttcn3.
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?
The transaction_id and callref determined by the MNCC and CC messages that happened in f_tc_ho_inter_bsc0 need to move over to f_tc_ho_inter_bsc1, much like the MS has moved to the other BSC.
So it would make sense to have some global struct representing the MS which both BSC_ConnHdlr instances can access, if that is at all possible ... ?
As a bit of a weak workaround, I could inter-BSC handover right back to the first BSC and then f_call_hangup() there :P
~N
On Tue, Mar 12, 2019 at 05:04:09AM +0100, Neels Hofmeyr wrote:
So it would make sense to have some global struct representing the MS which both BSC_ConnHdlr instances can access, if that is at all possible ... ?
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.
As a bit of a weak workaround, I could inter-BSC handover right back to the first BSC and then f_call_hangup() there :P
Which works! except for the CC Release not getting recognised because of N(SD).
So, yes, I'm seeing the first actual inter-BSC Handovers happening in ttcn3-msc-test :)
Next, I'll go for some real-hardware testing.
~N
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
Hi 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 -
Neels Hofmeyr