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/baseband-devel@lists.osmocom.org/.
Vadim Yanitskiy axilirator at gmail.comHi 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.