Hi,
I've got the problem that optional steps seem to not be possible in
'interleave' statements.
What I want: accept either BSSMAP Assignment Request or Iu Rab Assignment:
interleave {
[g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... };
[not g_pars.ran_is_geran] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { ... };
[] other {...};
[] complex {...};
[] steps {...};
}
But that's illegal syntax; works for altsteps, but not for interleave. Even in
the language spec, there is no token between the interleave braces. How
unfortunate.
Options I am considering:
1) moving the optionals into a separate altstep
var default assignment;
if (g_pars.ran_is_geran) {
assignment := activate(as_BSSMAP_assignment());
} else {
assignment := activate(as_RANAP_assignment());
}
interleave {
[] other {...};
[] complex {...};
[] steps {...};
}
deactivate(assignment);
or
2) blatant code dup
if (g_pars.ran_is_geran) {
interleave {
[] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... };
[] other {...};
[] complex {...};
[] steps {...};
}
} else {
interleave {
[] BSSAP.receive(tr_RANAP_RabAssReq) { ... };
[] other {...};
[] complex {...};
[] steps {...};
}
}
3) boolean dance and break
var boolean done1 := false;
var boolean done2 := false;
var boolean done3 := false;
var boolean done4 := false;
interleave {
[] BSSAP.receive(tr_BSSMAP_AssignmentReq) {
if (not g_pars.ran_is_geran) {
setverdict(fail);
}
done1 := true;
if (done1 and done2 and done3 and done4) { break; }
};
[] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) {
if (g_pars.ran_is_geran) {
setverdict(fail);
}
done1 := true;
if (done1 and done2 and done3 and done4) { break; }
};
[] other { done2 := true; if (done1 and done2 and done3 and done4) { break; } };
[] complex { done3 := true; if (done1 and done2 and done3 and done4) { break; } };
[] steps { done4 := true; if (done1 and done2 and done3 and done4) { break; } };
}
1) is bad because the interleave may exit without having seen an actual assignment at all.
Also interacting with local variables isn't allowed in this kind of altstep.
Also if there are more optional parts, the side-altsteps become hard to understand.
Also the altstep needs to "repeat;" so that it doesn't break the outer interlave,
which makes us accept more than one of the optional message.
2) is bad because it is code dup.
3) is bad because of code clutter that is likely to cause weird failure when
the interleave is modified. I am already using this method somewhere... but.
Are there other options??
Why is this coming up? I am preparing for a change in osmo-msc during call
setup, and I am making the ttcn3 call testing more flexible and cleaning things
up. As a result, some more tests are moved to using f_mo_call_establish()
instead of copy-pasting it. That makes some Iu tests go from passed to FAIL,
because the f_mo_call_establish() is unable to do the above distinguishing
between BSSMAP and IU.
We can also choose to ignore those Iu tests that start to fail.
But I am curious whether there is a way for optional interleave steps in ttcn3.
Thanks,
~N
Dear Osmocom community,
I just upgraded gerrit to 2.16.12, the latest version of the 2.16 branch,
still featuring the option to use the old UI.
While reading through change logs, I just discovered that one can actually
send responses to gerrit e-mail notifications, and those changes will end up
creating new comments int he gerrit database/UO:
http://gerrit-documentation.storage.googleapis.com/Documentation/2.14/intro…
Maybe that's useful for some of you here...
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi all,
DW-TV has just released a video report on the community owned and operated
cellular networks within TIC, the Mexican partner of Rhizomatica.
You can find the (Spanish only) video at
https://www.dw.com/es/telefon%C3%ADa-ind%C3%ADgena-en-defensa-del-derecho-a…
I recommend to watch the full video to catch some glimpses into the
life of people in one of the communities operating their own Osmocom
based cellular network.
If you don't have the time to follow the full video, some pointers
below:
* from 4:35 you can see how the taxi service (the only form of public
transport!) can pick up people anywhere in the region after they
make a mobile phone call
* from 12:50 onwards, the BTS is introduced, and its role (and that of
the BSC) are explained in a nice animation.
* from 18:49 you can see the part covering the role Osmocom
and sysmocom are playing in the development of the underlying
technology. You can also catch a glimpse of the sysmocom office
Especially for somebody who's never been there in person, it is very
enlightening to see more about how people use it. And the technology
geek in me of course enjoys the work related to power supply, including
the home-made inverter for solar charging (from 16:12)
Let me conclude with the statement that I'm extremely happy about
(and proud of) the amazing work that Rhizomatica, TIC and friends are
doing. It's great to see Osmocom code being put to use in such a
meaningful way, and for what it was crated: To enable people (literally
anyone) to operate their own cellular networks in whatever way,
independent of large multi-national corporations. There are just very
few places where people have actually managed to do this, given all the
legal, political, economic constraints, including spectrum licensing.
Thanks to Peter, Keith and his colleagues for dedicating many years to
this cause.
Thanks to DW-TV and Eva Usi (the reporter behind this piece).
Further links (in case you weren't aware of those projects/entities):
https://www.rhizomatica.org/https://www.tic-ac.org/
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
