Proper measurement reporting

[Vadim Yanitskiy]

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.