Hi Sylvain, I am currently working on https://osmocom.org/issues/2988#note-21. And while reading the specifications and looking at the Calypso PHY implementation, I've got a few questions. In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH procedures", Measurement Report messages are sent at each possible occasion when nothing else has to be sent. In other words, a dummy LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here. The Calypso PHY (i.e. the firmware) is sending self-composed Measurement Reports if there is nothing in transmit queue:
static uint8_t ubMeas[23] = { /* L1 SAACH pseudo-header */ 0x0f, 0x00,
/* lapdm header */ 0x01, 0x03, 0x49,
/* Measurement report */ 0x06, 0x15, 0x36, 0x36, 0x01, 0xC0, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };
/** * Is called every time when when * a new LAPDm frame received from DSP */ void pu_update_rx_level(uint8_t rx_level) { ubMeas[7] = ubMeas[8] = rx_level; }
const uint8_t *pu_get_meas_frame(void) { if (l1s.tx_meas) { /* There is a Measurement Report in transmit queue */ return l1s.tx_meas->l3h; } else { /* Compose a Measurement Report */ /* Update L1 SAACH pseudo-header */ ubMeas[0] = l1s.tx_power; ubMeas[1] = l1s.ta;
return ubMeas; } }
I am not sure if this is the correct way. Why? - The Measurement Reports coming from the higher layers may contain additional information, such as the neighbour measurements. - The higher layers may spoof indicated TA value, while this code uses the actual one. - Measurement Reporting is already implemented in the higher layers, so this duplicates... 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. 2) Keep a last Measurement Report somewhere, and transmit it until a new one is arrived from the higher layers. But I am still unsure, is this approach correct too. Probably, some parts of the Measurement Reporting implementation should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY. This way each Measurement Report would always contain the actual measurement results at the moment of transmission... What do you think? Any ideas are welcome! With best regards, Vadim Yanitskiy.
Hi,
What do you think? Any ideas are welcome!
TBH, Andreas wrote that part AFAIR. I don't like having duplication but it might be unavoidable to have measurement reports that are not too dated and because of the osmocom-bb latency over the serial link. 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. And AFAICT, keeping the last one and sending it until a new one arrives is pretty much what's done right now. Cheers, Sylvain
Hi Vadim, following up on this as I was browsing through the list of open issues and ended up on OS#2988 and https://gerrit.osmocom.org/#/c/osmocom-bb/+/7470/ On Fri, Mar 23, 2018 at 08:20:22PM +0700, Vadim Yanitskiy wrote:
In short, according to the GSM TS 04.08, section 3.4.1.1 "SACCH procedures", Measurement Report messages are sent at each possible occasion when nothing else has to be sent. In other words, a dummy LAPDm fill frame (0x01, 0x03, 0x01, 0x2b, ...) is not applicable here.
this part is clear so far.
The Calypso PHY (i.e. the firmware) is sending self-composed Measurement Reports if there is nothing in transmit queue:
[...]
I am not sure if this is the correct way. Why?
- The Measurement Reports coming from the higher layers may contain additional information, such as the neighbour measurements.
- The higher layers may spoof indicated TA value, while this code uses the actual one.
- Measurement Reporting is already implemented in the higher layers, so this duplicates...
I agree.
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.
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.
2) Keep a 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.
Probably, some parts of the Measurement Reporting implementation should be moved to L1, i.e. to the firmware, trxcon and VIRT-PHY. This way each Measurement Report would always contain the actual measurement results at the moment of transmission...
Measurement reports are sent every SACCH multiframe (102 or 104 frames), i.e. about every 500ms. Also, the end of the measurement period is defined independently from the time at which a measurement report is being sent. There are, AFAICT, about 12 frames between the end of the measurement period and the start of the transmission of the measurement report. That's about 55ms of time. 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. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
participants (3)
-
Harald Welte -
Sylvain Munaut -
Vadim Yanitskiy