This fixes TBF objects leaking and ending up alive when the MS object is
explicitly freed through talloc_free (and sporadically
crashing TbfTest once a timeout for them occur).
This mostly affects unit tests, where most of the explicit free()
happens.
In osmo-pcu, in general, the GprsMs object only gets _free() called when
its resource count reaches 0, aka no more TBFs are attached to it. Hence
in general GprsMs object is freed() only when no TBFs (to be leaked) are
present.
However, in the unit tests it's usual that we want to wipe the entire
context by eg. feeing the PCU, the BTS or MS object, which should also
free the related TBFs.
When running osmo-pcu this may only be an issue when the MS object is
freed explicitly, which could happen for instance when a BTS is torn down,
ie. PCUIF going down, moment at which all GprsMs of that BTS are freed.
But in there actually it iterates over PDCHs to free all TBFs, so it's
fine.
If we iterated over MS, this could have ended up in a crash, like
it happened in TbfTest sporadically, but it's not a bit problem if we
crash + restart at that time since anyway the BTS is gone ore just
getting up around that time.
Related: OS#6359
Change-Id: Ibbdec94acb8132be20508d3178d88da44bfaf91d
We should have introduced this documentation snipped years ago, when
first introducing IP-SNS support in libosmogb/osmo-pcu.
Change-Id: I83709b7231c2a3930e1b3f09b737319fb7d7e741
I'm not sure why some files did contain an AGPLv3+ header, instead of
the GPLv2+ which is the actual overall project license. I consider it a
mistake.
In any case, any copyrightable contribution to those files was done by
sysmocom employees, so I as managing directory can legally make a
license change, whther or not it was a mistake early on or not.
The only remaining AGPLv3+ files are those implementing the "direct
PHY" interface for osmo-bts-{symo,lc15,oc2g}. That is als
unintentional, but more complex to resolve as they were copied from
osmo-bts, which is indeed an AGPLv3+ project.
Change-Id: I52533193de0ec7e24bf7c5bb035589ba5b9419e4
Now that 1.4.0 is released, bring back the patch that was temporarily
reverted to avoid the need for a new libosmocore.
This reverts commit 16729ba727.
Change-Id: Idd113e328a693df2e8f2f5d172eaf5bf2bfcf009
In preparation for an 1.4.0 osmo-pcu release that should not require a
new libosmocore, revert this patch.
This reverts commit a155fe85de.
Change-Id: I714efdc9c9403d3ff74e18df1629e2de6876e9d7
The struct member gen_idle_blocks controls whether the the PCU has to
generate dummy blocks to fill idle periods or if this task is left to
the BTS hardware.
Since idle dummy blocks only have to be transmitted on the C0 carrier,
we should rename the gen_idle_blocks struct member to
gen_idle_blocks_C0.
Related: OS#6198
Change-Id: If9511ed911f9c5d6d463881a387a9e7d11a15465
When a PDCH is idle, then the gaps are filled with dummy blocks. OsmoPCU
supports generating the dummy blocks locally, so that a continous stream of
PDCH blocks is sent to L1. However, some BTS models (the OsmoTRX based models
in particular) are able to generate the idle blocks locally. In this case the
PCU should leave the genration of the dummy blocks to the BTS in order to
save processing time and load on the PCUIF interface.
In gprs_rlcmac_sched we already have a flag to skip idle frames in case we do
not use the so called "direct phy access". A similar mechanism also exists in
pcu_l1_if.cpp in function pcu_rx_rts_req_ptcch().
Unfortunately this check is not implemented correctly. The flag gets set when
the ENABLE_DIRECT_PHY define constant is set. However, this does not say
anything about whether the BTS model supports the generation of idle blocks or
not. The define constant is intended to be used to disable direct phy related
code in on platforms where no direct phy code is used or cannot be used. We
must instead check the BTS model (bts->bts_model) in order to decide whether
this particular BTS type requires the generation of dummy blocks or not.
Related: OS#6191
Change-Id: I7a08d8cc670fa14f7206ffffdbc22351f3668a17
At the moment the PCU has no way of knowing with which BTS model it is
used with. However, some BTS models may require slightly different
behaviour by the PCU, depending on which BTS model is used. So, lets add
an additional bts_model field to struct gsm_pcu_if_info_ind in order to
convey the exact BTS model to the PCU and store this information in
struct gprs_rlcmac_bts
Related: OS#6191
Change-Id: I48eb75f65ab54fdec41ef913e24c1f18cd4a4047
We now use PCUIF v11 in the TTCN3 tests exclusively and also osmo-bts
and osmo-bsc only support PCUIF v11. There is no longer a need to
maintain a backward compatibility to PCUIF v10 in osmo-pcu.
Related: OS#5927
Change-Id: I68a3f59d5c960ae3a4fbd74f9d4a894295cb9ed8
This has been fixed in osmo-bts too.
If frames are not deliverd fast enough to the DSP, bursts will get
dropped. The osmo-bts-sysmo process must have priority over other
processes, so it can deliver frames fast enough.
Related: OS#6199
Change-Id: Ifa2c36bc0975e89d21b6fb2fc49db6077e5207da
The PCUIF flag PCU_IF_FLAG_SYSMO was originally used by osmo-bts-sysmo
to signal to the PCU that the direct PHY access for the sysmo-bts DSP
should be enabled. With time, support for other BTS models was added and
the flag became a synonym for "direct PHY access", so it makes sense to
rename it to "PCU_IF_FLAG_DIRECT_PHY"
Related: OS#6191
Change-Id: I29b7b78a3a91d062b9ea3cd72623d30618cd3f0b
Fix OsmoPCU not restarting if e.g. an external gsmtap IP is configured
that is currently not available. Also make the service files more
consistent with other Osmocom projects.
Revert f81e2f76 ("systemd: Do not re-start in case of exit(1) (e.g. a
config issue)").
Related: SYS#6581
Change-Id: I061206a6f61abddfa698a4ce809afcbdf0cbce9c
We cannot see how uninitialized access is possible, but gcc v13.2.1
does complain about it. Let's work this around by assigning an
invalid value, like trx_count_free_tfi() does.
src/bts.cpp: In function 'int bts_tfi_find_free(const gprs_rlcmac_bts*,
gprs_rlcmac_tbf_direction,
uint8_t*, int8_t)':
warning: 'tmp_first_tfi' may be used uninitialized [-Wmaybe-uninitialized]
Change-Id: Ia446cdf573ee25e6da6b4aa917972c63472229bb
Fixes: OS#6190
This function is also needed in osmocom-bb.git, so it becomes
a library function (part of libosmogsm).
Change-Id: I6a8502c2b2015ca7d0452ab9f5da0484a03ce91e
Depends: libosmocore.git I9590f2e836fc48650decf1564b6ab46306c4fe2d
Depends: libosmocore.git Ie8bb9c49c6f81b8f4a1766547d6943f9880d1186
When printing the PCUIF protocol version, we only mention OsmoBTS, but
since OsmoPCU can also be used in co-location with OsmoBSC, we should
also mention OsmoBSC here. Let's write "OsmoBTS/OsmoBSC"
Related: OS#5927
Change-Id: Ibe49064d04dff0617357e3e0b00fea961b657784
since OsmoPCU is no longer exclusively used in co-location to OsmoBTS
the module osmobts_sock (PCUIF) should get a more generic name.
Related: OS#5927
Change-Id: Ic7f6246265fa31be189e4aea36dfaa89bd0eeddd
When a downlink IMMEDIATE ASSIGNMENT message is sent through the PCH,
an IMSI is always required in order to be able to calculate the paging
group. However, when the downlink IMMEDIATE ASSIGNMENT has to be sent
before the MS has completed the GMM ATTACH REQUEST, the IMSI is still
unknown. In this case we may assume that the MS is still in non-DRX
mode, which means it listens on all CCCH blocks (PCH and AGCH).
This means we may send the IMMEDIATE ASSIGNMENT through the AGCH in this
situation. This will also have the advantage that the scheduling through
the AGCH will have less latency than the paging queue.
Unfortunately the SAPI PCU_IF_SAPI_AGCH only supports sending whole MAC
blocks, so it won't be possible to attach a TLLI that can be used for
confirmation. To fix this, let's add a new SAPI_PCUI_IF_AGCH_2, that
works similar as SAPI PCU_IF_SAPI_PCH_2 and use it to send the
IMMEDIATE ASSIGNMENT through the AGCH.
CAUTION: This patch breaks compatibility with current master osmo-bts
and osmo-bsc (see "Depends")
Related: OS#5927
Depends: osmo-bts.git I29858fa20ad8bd0aefe81a5c40ad77a2559a8c10
Change-Id: I9effdcec1da91a6e2e7a7c41f95d3300ad1bb292
At the moment we let OsmoBTS (or OsmoBSC) look into the MAC block we
send and in case it is an IMMEDIATE ASSIGNMENT message, a confirmation
would be sent back. Unfortunately, this method is not very practical,
lets add a flag to struct gsm_pcu_if_pch to tell the receiving end that
the MAC block (data) needs to be confirmed when it is sent.
Related: OS#5927
Change-Id: Ia202862aafc1f0cb6601574ef61eb9155de11f04
Until now, if timeslot resources where being allocated for an MS
whose msclass is not known, msclass=12 was being selected.
While it's true that msclass=12 is quite a usual one implemented by
phones (Rx=4, Rx=4, Sum=5), some MS implementations may not support such
modes.
As a result, if the PCU allocates a TBF for an MS which its msclass is
not known (eg. because it used 1-phase access aka no Pkt Res Req), then
a minimal msclass=1 should be assumed. Otherwise, it may assign more
multislots than the MS can handle, and will work incorrectly since an
amount of RLC/MAC blocks won't be sent/received properly.
With the existing code base, changing the default MSCLASS to 1 would,
however, create a worse user experiencie for the vast majority of devices
(which are msclass >= 12). The code should be improved to first use only
1 TS until the MS CLASS is known, and at that point reallocate resources
and re-assign them (eg. RECONFIGURE TBF rlc/mac ctrl blk).
So, for now, simply add a hidden VTY config to allow changing the
default assumed MS Class, so that operators wishing to support all
devices can eg. set it to 1.
Change-Id: If80fdd793db7dad029faa83dbf980ffc4959e2e5
Since we now no longer refer to TLLI when we mean "message ID" (msg_id),
we should also remove the "_DT" / "_dt" suffix from structs and define
constants and replace it with "_2" if required.
Change-Id: If641b507dcb6b176109c99dce7cff2a7561364b0
Related: OS#5927
The struct gsm_pcu_if_data_cnf_dt was added when the first experiments
mit Ericsson RBS base stations were made. It is essentially a copy of
gsm_pcu_if_data, where the mamber "data" was replaced with a member
"msg_id" (which was originally called "tlli"). Since we didn't know
back then which parameters we would still need at some later point we
kept all the other parameters. However, to this day we never used the
parameters below fn. Even fn was only used for logging purposes, but is
now also unused.
Let's remove all those unused members.
(Since all removed members are at the tail of the struct,
compatibility with other programs that use the PCUIF should not break.)
Change-Id: Id6109264e4144c2ab7b8410d4087705d857cd4c9
Related: OS#5927
The function bts_rcv_imm_ass_cnf, which processes the confirmation
message from osmo-bts or osmo-bsc has an fn (frame number) parameter.
This parameter not used for anything other than logging. The source of
this frame number parameter is the conformation message that comes from
osmo-pcu or osmo-bsc. In the case of osmo-bsc the frame number is always
0, since osmo-bsc uses RSL and can not know the exact frame numbers.
since we do not really need the frame number for the confirmation, lets
remove the fn parameter entirely.
Related: OS#5927
Change-Id: I35bc99eaec5d0287ae3916bc668f0babaddfd6ce
To confirm downlink IMMEDIATE ASSIGNMENT messages, we use the TLLI as an
identifier and the related struct member is also called "tlli".
Unfortunately this is misleading since the message identifier does not
necessarly have to be a TLLI. It is just an implementation detail that
osmo-pcu uses the TLLI as a message identifier.
To make that clear, lets rename the tlli member (and variable and
parameter names where it is passed on) to "msg_id".
(Since this change only renames variables and struct members it will not
break compatibility with other programs that use the PCUIF)
Related: OS#5927
Change-Id: I4a25039dfe329e68879bc68936e49c4b190625e6
This is a port of libosmo-gprs.git commit 49535bec37caddcea5718ed4e526c477c71f1b3a applied to osmo-pcu.
Problem this patch is fixing:
The current RLCMAC code is never invalidating the BSNs which have
been received after they are not needed.
This is somehow workaround by the following check when eg BSN wraps
around 127->0 and the BSN=0 is received:
""""
rcv_data_block_acknowledged()
m_window.m_v_n.is_received(rdbi->bsn)
/* Offset to the end of the received window */
offset_v_r = (m_v_r - 1 - bsn) & mod_sns();
return m_v_n.is_received(bsn) && offset_v_r < ws();
"""
The first m_v_n_is_received() would return true because the BSN has
never been invalidated, which is wrong, but fortunately the extra check
"offset_v_r < ws()" returns > ws() since:
v_r=0, bsn=0: "(0 - 1 - 0) & 127" ----> 0xffff & 0x007f ---> 0x007f > 64
So thanks to the above the BSN is considered not received, but looking
at the V(N) array would say the opposite. Hence, this commit aims at
fixing the V(N) array to contain proper values (marked "invalid") for
BSNs becoming out of the window when it rolls forward.
Explanation of the solution:
The V(N) array contains the status of the previous WS (64 in GPRS) data
blocks. This array is used to construct the RRB signaled to the peer
during PKT UL ACK/NACK messages together with the SSN (start sequence
number), which in our case is mainly V(R), aka one block higher than the
highest received block in the rx window.
Hence, whenever PKT UL ACK/NACK is transmitted, it contains an RRB
ranging [V(R)-1,...V(R)-WS)] mod SNS (SNS=128 in GPRS).
The receive window is basically [V(Q) <= BSN < V(R)] mod SNS, as is of
size 64.
The V(R) is increased whenever a highest new block arrives which is in the
receive window (guaranteeing it will be increased to at most V(Q)+64.
Since we are only announcing state of blocks from V(R)..V(R)-WS, and
blocks received which are before that BSN are dropped since don't fall
inside the rx window, we can securely mark as invalid those blocks
falling behind V(R)-WS whenever we increase V(R).
Related: OS#6102
Change-Id: I5ef4dcb0c5eac07a892114897f9e4f565b1dcc2c
This new structure was already used when porting existing osmo-pcu code
to libosmo-gprs-rlcmac, and proved to be much more clear.
It makes no sense to keep both ul and dl window code mixed, since the
code base is mostly different between them, and the developer usually is
only interested in reading/debugging one side at a time.
Change-Id: If21b6f48ef190a718502389cbfde8cbdfc8d7f7a
Otherwise unit tests (the only real used of that API so far) would end
up with v_r and v_q variables reset, but with previous state in v_n
array, which is not good.
Let's make sure everything is reset in
gprs_rlc_ul_window::reset_state(), and simply call that method during
constructor time.
Change-Id: I007b672527664b05353077b9208722056799f43f
in handle_retrans_pkt_cell_chg_notif, the variable neigh_key is used
uninitialized at end of the function. This has been introduced with
Change I96280f0ec5955ed3cb17641bf4118496c929bdac, where we modified
fill_neigh_key_from_bts_pkt_cell_chg()_not so that it write directly
at the ctx variable. This works in st_initial but not in
handle_retrans_pkt_cell_chg_notif(), so let's have neigh_key and
neigh_key_present as a parameter so that the caller can decide where
the result is stored.
Fixes: CID#322150
Related: OS#6100
Change-Id: I7e74beda03829d909b6542659316241c275a36b3
The NACC procedure in OsmoPCU currently only supports NACC with GERAN
cells. When an UTRAN or E-UTRAN cell is proposed in the
PacketCellChangeNotification, then the FSM is immediately terminated,
meaning that the NACC procedure can not commence.
When the NACC procedure is carried out for UTRAN or E-UTRAN cells, the
PCU will not send any system information to the UE. Instead it
immediately sends a PacketCellChangeContinue message. This also means
that we do not carry out any RAN Information Requests in the background.
This patch adds logic to detect if the proprosed cell is an UTRAN or
E-UTRAN cell and the adds a new transition to the FSM so that a short
route to NACC_ST_TX_CELL_CHG_CONTINUE can be taken.
Related: OS#6044
Change-Id: I96280f0ec5955ed3cb17641bf4118496c929bdac
These errors started appearing lately when upgrading builders to
debian12, with a newer gcc version.
Change-Id: I0046a6f4fb3979710b4cd5222de599d9aaac227b
A recent commit adding TBF_ST_WAIT_REUSE_TFI state updated
ms_append_llc_dl_data() to attempt creating a new DL TBF while in that
state, but forgot to update the assert checking for the conditions in
ms_is_reachable_for_dl_ass().
Related: OS#6084
Fixes: 40a297f3b0
Change-Id: I3d51e909c9a9f688b7f4425a5ba319d183c71d1f
Pau Espin
Harald Welte
Oliver Smith
Philipp Maier
Andreas Eversberg
Keith Whyte
Vadim Yanitskiy