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
The function signatures l1if_open_pdch() in the code for lc15 and oc2g
differ from what is defined in pcu_l1_if_phy.h. Lets update the
signatures so that they match the prototype.
Related: OS#5198
Change-Id: If1693b1b74c1808596d7da639b860f7b226385c0
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
Problem:
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.
From-Commit: 139ad3f42193
From-Remote: https://gitlab.com/nrw_noa/osmo-pcu
Change-Id: I7665586dd5722bbe04632ee5673d3033bc082324
Philipp Maier
Pau Espin
Harald Welte
Vadim Yanitskiy
Vadim Yanitskiy
Daniel Willmann