Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Ref: 3GPP TS 48.058 § 8.4.8
The value range is [-63; 192] but manually setting it to -3 causes wireshark to display 253. That's because gsm_abis_rsl.timing_offset in packet-rsl.c is marked as FT_UINT8. Note: that marking it as FT_INT8 would result in values above 127 displaying incorrectly so I'm not sure if this should be corrected.

According to 3GPP TS 45.010 § 1.2:
MS_TO = P - T quantized to the nearest symbol, where T is TA set for MS (can be obtained from lapdm_entity) and P is round trip propagation delay in symbols (shall be somehow set by BTS' L1 to gsm_lchan).

The implementation which acc_delay and ta_offs_qb to compute ms_to always report -1 or 0 in tests based on sysmobts. When using nanobts the results vary significantly (36-94): see attached files. Note that some measurements are marked as malformed by wireshark so I'm not sure yet if it's a bug in nanobts or in my interpretation of the spec. Also, actual TA sometimes reported as 8 and sometimes 0 with no obvious connection to ms_to.

Current implementation published in gerrit 1699 and 1700.

Gerrit 1699 has been merged, gerrit 1700 is under review. Is there a way to verify that we're sending the right thing besides relying on nanobts?

msuraev wrote:

Ref: 3GPP TS 48.058 § 8.4.8
The value range is [-63; 192] but manually setting it to -3 causes wireshark to display 253. That's because gsm_abis_rsl.timing_offset in packet-rsl.c is marked as FT_UINT8. Note: that marking it as FT_INT8 would result in values above 127 displaying incorrectly so I'm not sure if this should be corrected.

• the "RSL MS Timing Offset" IE Value is an uint8_t with range from 0..255
• the actual offset (in symbol periods) is computed as that uint8_t field - 63.

So a difference of '0' symbol periods offset would be encoded as "IE Value 63, resulting in 63-63 = 0.

I don't really see this reflected in your implementation, as the 'raw/absolute' value from the DSP/PHY is taken 1:1 and put in the RSL IE?

msuraev wrote:

The implementation which acc_delay and ta_offs_qb to compute ms_to always report -1 or 0 in tests based on sysmobts.

How did you test? I mean, without a physically large distance between MS and BTS, or the capability to delay the RF signal somehow, how was this tested? If you're next to the BTS, I'm not surprised there's no timing offset ;)

OsmocomBB has the capability to pre-empt or delay its transmissions to fool the BTS about a smaller or larger distance to the BTS. This should make it possible to simulate?

When using nanobts the results vary significantly (36-94): see attached files.

36-63 = -27
94-63 = +32

The values are incredibly high, almost as if they're quantized not to symbol periods but a much higher resolution clock? At least they seem to center around the nominal zero value.

Note that some measurements are marked as malformed by wireshark so I'm not sure yet if it's a bug in nanobts or in my interpretation of the spec. Also, actual TA sometimes reported as 8 and sometimes 0 with no obvious connection to ms_to.

I wouldn't worry too much about what a nanoBTS or other device does, as long as we are convinced that we're doing what the relevant 3GPP spec says.

Gerrit 2391 was sent with fixes to displaying MS TO and clarifications related to MS TO vs TO field confusion.

Gerrit 2391 is merged, 1700 is under review.

All patches are merged.