Commit Graph

5 Commits

Author SHA1 Message Date
Pau Espin 8971d6b98f Use new stat item/ctr getter APIs
Generated with  following and similar spatch snippets:
"""
@@
expression E1, E2;
@@
- &E2->ctr[E1]
+ rate_ctr_group_get_ctr(E2, E1)
"""

Change-Id: I0b43f922a595d694ac0aeda80107ef9bf4e755e7
2021-06-04 17:48:43 +02:00
Neels Hofmeyr c33eb8d569 allow explixit TSC Set and TSC on chan activ / modif / assignment
Activating / modifying to a VAMOS mode will require picking specific TSC
Set / TSC. It is a bad idea to pick the TSC in each message encoding
function, rather make this choice centrally.

So far we pick the training sequence code to use based on the timeslot
configuration, and this TSC is determined only upon encoding the RSL
messages.

Instead, pick the TSC to use upon the initial lchan activation /
modification request; store this in the request structs and pass through
the activation / modification code paths.

For VAMOS modes, we also need to pick a TSC Set. Do so also upon activ /
modif request. Note that the TSC Set is not yet applied in this patch,
it will be applied in upcoming VAMOS patches.

The activ / modif request may pass -1 for tsc_set and/or tsc to indicate
no specific choice of TSC Set and TSC, resulting in the same behavior as
before this patch.

For example, lchan->activate.info.tsc* may be passed as -1. The exact
choice for tsc_set and tsc is then stored in lchan->activate.tsc*, i.e.
one level up (the .info sub-struct is considered as immutable input
args). The lchan->activate.tsc* are the values actually encoded in RSL
messages. After the ACK, the lchan->activate.tsc* is stored in
lchan->tsc* to indicate the TSC actually in use. Same for modif.

Note that in 3GPP TS 45.002, the TSC Set are numbered 1 to 4, while the
TSC are numbered 0 to 7. On the wire, though, TSC Set is sent as 0 to 3
value. This is a weird discrepancy, odd choice made by the spec authors.
For conformance with the spec wording, I decided to pass the TSC Set
number as a 1-4 ranged value, and only convert it to the 0-3 on-the-wire
format upon message encoding. So log messages and VTY output will
indicate the first TSC Set as "1", but the first TSC as "0", as defined
in 3GPP TS 45.002, even if that is somewhat weird.

Related: SYS#5315 OS#4940
Change-Id: Ic665125255d7354f5499d10dda1dd866ab243d24
2021-05-31 05:20:02 +00:00
Neels Hofmeyr 5df7e771a8 gsm48_lchan2chan_desc(): expose TSC as param
Expose the training sequence code used in the RSL Channel Description IE
as an input parameter.

So far the Channel Description IE is always composed with a training
sequence code from gsm_ts_tsc(). For RSL commands enabling VAMOS mode,
specific training sequence codes are required.

So far, all callers still use gsm_ts_tsc(), making this a patch without
any functional change. Upcoming patches will pass specific TSC as
configured for VAMOS instead, in specific places.

Related: SYS#5315 OS#4940
Change-Id: I49503a6f5d25bb3bc9a0505bd79ed1d5c4f50577
2021-05-28 17:22:59 +00:00
Neels Hofmeyr 980a28fdcb rename lchan->rqd_ta to last_ta
Originally, the lchan stored only the Timing Advance from the initial
channel request, hence it was called rqd_ta.

Since quite a while now, rqd_ta also stores the most recent Timing
Advance from each received Measurement Report. So rename to last_ta.

This is cosmetic preparation for an upcoming patch that clarifies
whether the Timing Advance is already known for Channel Activation.

Change-Id: I1049526a173819baeb4978db5bf018ba3f1006a0
2021-02-05 20:24:43 +01:00
Neels Hofmeyr 4ae338d5b6 LCS: implement the bulk of Location Services
Depends: I4d7302a4853518916b6b425e710c10568eb2ffe5 (libosmocore)
Change-Id: I28314ba97df86a118497e9b2770e2e6e2484e872
2020-10-09 00:26:02 +02:00