Project

General

Profile

Bug #1574

Include MS TIMING OFFSET in RSL MEASUREMENT RESULT

Added by laforge almost 4 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
02/23/2016
Due date:
% Done:

100%

Spec Reference:

Description

We are missing this parameter

meas_sysmo.pcapng.gz meas_sysmo.pcapng.gz 15.9 KB msuraev, 01/26/2017 11:10 AM
meas_nano.pcapng.gz meas_nano.pcapng.gz 7.63 KB msuraev, 01/26/2017 11:10 AM

History

#1 Updated by laforge about 3 years ago

  • Assignee set to msuraev
  • Priority changed from Low to Normal

#2 Updated by msuraev almost 3 years ago

  • Status changed from New to In Progress

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).

#3 Updated by msuraev almost 3 years ago

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.

#4 Updated by msuraev almost 3 years ago

  • Status changed from In Progress to Stalled

Current implementation published in gerrit 1699 and 1700.

#5 Updated by msuraev almost 3 years ago

  • % Done changed from 10 to 20

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?

#6 Updated by laforge almost 3 years ago

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.

I don't understand you here:
  • 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?

#7 Updated by laforge almost 3 years ago

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.

#8 Updated by laforge over 2 years ago

  • Priority changed from Normal to Low

#9 Updated by msuraev over 2 years ago

  • % Done changed from 20 to 30

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

#10 Updated by msuraev over 2 years ago

  • % Done changed from 30 to 40

Gerrit 2391 is merged, 1700 is under review.

#11 Updated by msuraev over 2 years ago

  • Status changed from Stalled to Resolved
  • Assignee changed from msuraev to laforge
  • % Done changed from 40 to 100

All patches are merged.

#12 Updated by laforge over 2 years ago

  • Assignee changed from laforge to msuraev

#13 Updated by laforge over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)