The functions l1if_open_pdch and l1if_close_pdch have a misleading
naming since what they actually do is opening and closing the TRX since
they return and accept a context (obj) that is valid for a whole TRX.
This also explains why the other functions accept a timeslot as
parameter in addition to the context. Let's rename those functions so
that it is clear what they do.
Related: OS#6022
Change-Id: I395a60b2fba39bac4facec78989bac20f0cef0d3
The PCU already has a list that can hold multiple BTS objects but the
API for the direct PHY access has no way to associate a PHY with a
certain BTS object. Lets update the API so that we can associate a BTS
object when opening a PDCH.
Unfortunately OsmoPCU has never been tested with more than one BTS so it
is very likely that there are still shortcomings that prevent OsmoPCU to
work properly when more then one BTS is attached. To make users aware of
this, also print a warning as soon as more than one BTS object exists.
Related: OS#5198
Related: OS#5930
Change-Id: I33518cbbe83f7f8c071afa5e995d30930099ba92
The PHY implementations we currently have do not require any
initialization that has to run directly on startup. This will change
when we introduce support for the E1 based Ericsson RBS CCU. Then we
will have to perform at least one elarly initialization (VTY config
file). So lets add an API function for PHY initialization now.
Related: OS#5198
Change-Id: Ibf2a3a058c826f6ee5b740eee72d5be94d460517
There is a function l1if_connect_pdch, but no complementary function
like we have it with l1if_open_pdch and l1if_close_pdch. The reason for
this is that the PHY implementations that rely on a femtocell DSP do not
need to disconnect the pdch explcitly. However, the planned support for
the E1 based Ercisson RBS CCU will require an explicit disconnect. So
lets add a function call for this.
Change-Id: Ied88f3289bda87c48f5f9255c4591470633cc805
Related: OS#5198
The file pcu_l1_if_phy.h contains the function prototypes for the
implementations found in xyz_l1_if.c. Lets also include pcu_l1_if_phy.h
in the related .c files.
Change-Id: Id35ba473973108da4e36d5c6f2ca78da1225ae8b
Related: OS#5198
There's no need for setting the FN in RA.ind since we anyway already
receive a DATA.ind beforehand.
Furthermore, the applied delay of 5 in the call is not really used at
all.
Change-Id: I437f4f95d054aea96bec3b9343e495451020ff3c
Since recently (see Depends below), BTS side submits DATA.ind with len=0
to announce nothing was received on that UL block FN. This will allow
osmo-pcu track time more accurately, and use this information to quickly
find out if a UL block was expected as requested by RRBP or USF poll and
increment counters such as N3101 (finally being able to properly
implement timers such as T3619).
This patch does the same for direct phy feature, where the osmo-pcu
process receives the DATA.ind directly from the DSP.
Depends: osmo-bts.git Change-Id I343c7a721dab72411edbca816c8864926bc329fb
Related: OS#5033
Change-Id: I9a835e16ef0e5a68c003a93d1a33233aa43464ae
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
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ida8fd3bd7347163567acde34ad67aefee913b0ea
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
ARFCN is already part of TRX struct so there's no need to supply it
explicitly in a separate parameter. I've tested and those are the same
anyway.
Change-Id: I8e975c52cbc819427880093b1e5371fe1f8ce460
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
Make TRX API (void *) consistent with the way it's used (integer). Use
uint8_t for TRX numbering everywhere (we don't expect hardware with
more than 256 transceivers in the near future). This change helps to
avoid unnecessary casts and make API much clearer.
Change-Id: Ic584611184b0c8b5417ecff0ddae3d526b55a079
Related: SYS#2443
Reviewed-on: https://gerrit.osmocom.org/59
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Move hardware-spicefic files into subdirectory similar to the way it's
done in OsmoBTS to make adding new hardware support easier.
Change-Id: I05004ad9032759a5dbfa57290ed1df83e89d5cb8
Related: SYS#2443
Reviewed-on: https://gerrit.osmocom.org/58
Tested-by: Jenkins Builder
Reviewed-by: Holger Freyther <holger@freyther.de>
Philipp Maier
Pau Espin
Harald Welte
Vadim Yanitskiy
Vadim Yanitskiy