This patch doesn't really tests whether osmo-pcu can work on a multi-bts
environment, but it prepares the data structures to be able to do so at
any later point in time.
Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
In [1] I restricted L1 SAPI of PH-RA.ind to PDTCH and PTCCH, and
this seems to have caused a regression reported in [2]:
DL1IF ERROR sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH
I assumed that PH-RA.ind belonging to a Control Acknowledgement
message (in format of 4 Access Bursts) would have PDTCH SAPI,
while apparently it's actually arriving on PRACH.
[1] I482d60a46b9d253dfe0b16140eac9fea6420b30c
[2] https://osmocom.org/issues/1526#note-39
Change-Id: Ib0a6da37de7a1db4cad2b96293b31b9f32e7d9eb
Related: OS#1526
This is not a functional change, just fixing misleading function
name. Access Bursts on PTCCH/U have nothing to do with PDTCH.
Change-Id: I4ab710ba026315301cc6970263967616401a9fc8
The PDCH class and corresponding functions are rather self-contained and
independent from BTS implementation. Let's move them into separate file
to make bts.cpp more manageable. As additional benefit it allow us to
somewhat untangle all the different cross-dependent includes.
Change-Id: Ie05e25361e6741a81b024679f9675c98d4923683
Related: OS#1539
Promblem:
TA provided from L1 PH-DATA-IND is a relative amount of TA adjustment to actual TA
being used for given TBF. The current TA update algorithm in PCU simply applies the relative
amount of TA to given TBF but does not take into account of current TA.
As a result, the PCU will request wrong TA jump for given TBF if the MS is moving away from
BTS more than 2 km.
Related issue: http://osmocom.org/issues/2611
Fixes:
- The PCU needs increase or decrease current TA of given TBF on receiving of relative
amount of TA adjustment provided by PH-DATA-IND from L1
- The PCU needs to set absolute TA of given TBF on receiving absolute TA provided by
PH-RA-IND from L1.
Change-Id: I65212f8203f1a35278890f51db038d689b2493d5
When looking at GSMTAP output so far, one is easily overwhelmed by way
too much information being presented. A lot of is consists of DUMMY
frames, which are probably of lowest interest, ever.
A concept similar to the "gsmtap-sapi" of OsmoBTS is introduced, by
which the user can configure which particular categories (uplink or
downlink control or data, gprs or egprs, ...) he actually wants to
see in his logs.
Change-Id: I297183690e98a7234dfc1608c18847d8981306e4
Separate qbit-TA to TA conversion into separate function and use it for
computing and updating Timing Advance.
Note: the code was tested with TA=0 only to make sure it does not
introduce regressions.
Change-Id: I96fdbb20b09fb85fdd9fb6dcf3c25f6bee7f80e4
Fixes: OS#1531
Those structs are not used anywhere (which was the case in the commit
which introduced them as well) but give false-positives while grepping
through the code. Better to just drop them.
Change-Id: I0a0bb0c641e4e081a57f72187ff96e9beef16588
Layer 1 compatibility with previous generation or NuRan GSM product,
therefore the support for the Litecell 1.5 uses its own sources instead
of using tons of ifdef/endif.
Max's amendments:
* make headers path configurable
* use configured TRX instead of hardcoded value
* split subdir-objects into separate commit
* cosmetic changes
Change-Id: Ib1287375cb10a889625bbac8528fa60deed23a2b
Fixes: SYS#2443
Reviewed-on: https://gerrit.osmocom.org/61
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
Pau Espin
Vadim Yanitskiy
Vadim Yanitskiy
Harald Welte