Hi Harald, Sylvain,
My current
ideas are:
1) Create a separate L1CTL message, that would be
used to carry Measurement Reports. This way
we wouldn't need to extract them from the
L1CTL_DATA_REQ messages manually.
I don't see much advantage in creating a new L1CTL message.
I mean detecting it's a measurement report is super easy so
I'd just stick with L1CTL_DATA_REQ.
As sylvain already stated, there doesn't seem to be a need
for yet another extra primitive. For the MS side, it is a
DATA_REQ on the uplink SACCH SAPI.
Introducing a new L1CTL message for Measurement Reports would
allow us to avoid mixing up the L1CTL code with GSM 04.08 code
at least in 'firmware/layer1/l23_api.c':
#include <osmocom/gsm/protocol/gsm_04_08.h>
...
struct gsm48_hdr *gh = (struct gsm48_hdr *)(data_ind->data + 5);
if (gh->proto_discr == GSM48_PDISC_RR
&& gh->msg_type == GSM48_MT_RR_MEAS_REP) {
printd("updating measurement report\n");
l1a_meas_msgb_set(msg);
...
I believe the L1CTL code shall be abstracted from the upper layer's stuff.
We could instead introduce a new field in 'l1ctl_info_ul' structure
(replacing one padding byte), and reuse it somehow, for example,
as a field for some flags, one of which might indicate that this
particular message is a Measurement Report. So, this way we would
not even break backward compatibility with the firmware:
- old FW will continue to check the gsm48_hdr,
- new FW will get rid of GSM 04.08, and check flags.
Another interesting moment is that the mobile application actually
sends the first Measurement Report *before establishing a channel*,
so in case of trxcon, the first one is just being dropped, because
I don't mix up the L1CTL code with GSM 04.08 stuff there. Having
some kind of indication (flags or separate message) would solve
this problem.
2) Keep the
last Measurement Report somewhere, and
transmit it until a new one is arrived from
the higher layers.
That makes sense. However, that cached last measurement
report should have some kind of age attached. There's no
point in tranmitting neighbor measurements that are 5 minutes
old, particularly not for a mobile user.
The cached Measurement Report would be updated as soon as we
receive a new one from the higher layers. And AFAIK, the mobile
application does send the reports much more frequently than
once in 5 minutes ;)
I think 55ms might be indeed a bit tight to account
for
Caylpso->UART->osmocon->mobile->osmocon->UART->Calypso.
At 115200 bps, there's onyly 633 characters in that period.
Hoewver, I think we shouldn't focus too much on the
constraints of the slow serial link of calypso phones here.
In the worst case, our measurement reports will
be 480ms old, so be it.
Yep, I will ask Piotr to check what does the MS Tester from
Sylvain think about such potentially delayed measurements
from Calypso PHY...
Extremely useful device (thanks again!), but I wish it could
provide the protocol traces, or at least a bit more informative
debug messages than just 'Test failed' :)
With best regards,
Vadim Yanitskiy.