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
The function neigh_cache_lookup_entry() is only used from within
neigh_cache.c. Let's make it static and move it, so that we do not need
the prototype declaration.
Change-Id: I1ea72ad9c79bfeaa06391cf8f62b284fbfea8efc
Scenario: A DL TBF is assigned over PCH (CCCH) and we start transmitting
DL data blocks blindly after X2002, but at the same time the MS start
packet-access-procedure to request an UL TBF.
Right now osmo-pcu correctly detects the MS is available in PDCH and
re-assigns a DL TBF using PACCH, but the LLC frames it transmitted in
the old PCH-assigned DL TBF get lost when that older TBF is freed
(because the DL blocks were removed from the GprsMs llc_queue).
This issue is now more frequent since X2002 timer was added recently to
delay starting requesting USF for a UL TBF, hence the contention
resolution in general takes more time and hence the PACCH assignment of
the DL TBF takes more time too, so more DL data blocks are transmitted
to the DL TBF assigned over PCH during that time.
This patch improves the situation to at least recover the DL blocks
transmitted if the DL TBF is freed (due to MS merge trigger by scenario
mentioned above), where no DL ACK/NACK was ever received by the MS.
Ideal solution would be to have complete tracking of which LLC PDUs from
the llc_queues were completely ACKed at RLC/MAC level, but that really
requires a lot of work and major refactoring, which are left as a future
improvement.
Change-Id: I9be4035fb2cf2b3ee56e91dcc12cc8c24028b4aa
If in those states, we already left the FINISHED step which means we
already received a FinalACk previously, hence it means we are missing
requested retransmissions of the last DL ACK/NACK due to fn-advance
(several DL blocks in transit before receiving UL response).
Change-Id: Ib0f23a9cc3c614fe428b682e01502930cd2e478f
Due to the fn-advance feature, we schedule DL blocks in advance, which
may make several retransmitted DL ACK/NACK [RRBP] be in flight, and
hence several of them may be answered by the MS.
When the first one is received, we attempt to initiate a PktDlAss over
PACCH if new DL data was received meanwhile from SGSN.
However, if we receive duplicates of that final PKT CTRL ACK, we don't
want to re-initiate it again, since it is already ongoing.
Related: OS#5471
Change-Id: Idc204aba61ad98f75853dcd46200f5dcc4139203
In RELEASE state, the UL TBF is considered not available anymore, and we
are simply waiting in order to be able to reuse the allocated resources
(just in case it was still around). Hence, a UL TBF in that state should
not be selectable to initiate a DL TBF assignment over PACCH.
Related: OS#5472
Change-Id: Ia11f7802779cfeea15a71bddad9f7e0c6c1afb11
Otherwise the scheduler selects the UL TBF for USF during that time, and
of course no one has that USF assigned yet, so no answer and that ends
up triggering MAX_N3101 on the UL TBF.
This is specially important when PCU is connected to the BSC, since the
amount of time for the ImmAss to be scheduled on the BTS and reach the
MS can be bigger.
Change-Id: I48babd70ca44f11110240cbcfbab43d0e3a0fb59
A new state TBF_ST_WAIT_REUSE_TFI was added lately in dl_tbf_fsm, which
allows differentiating the time where the MS is listening on PACCH
after having sent last DL ACK/NACK, and time where it should already be
in idle mode.
In the former, the ms_need_dl_tbf() should return false since the MS is
still ongoing in packet-active mode (and new data incoming from SGSN
will trigger new DL TBF assignment over PACCH as needed), while in the
later we want to start a new PCH assignment.
Fixes: 40a297f3b0
Change-Id: I96f311480d036859511c6ba825ccd36bdc71190b
T3192 on the MS side (boadcasted by the network on SI13) is used for the
MS to stay monitoring the PDCH of a DL TBF after sending PKT DL ACK/NACK
for the last DL data block (FinalAck=1).
T3193 is the counterpart in the network, defined as >T3192, which is
used to make sure the TFI is no longer used by the MS and hence can be
reused/re-assigned again.
Hence, we want to differentiate between those 2 timers, since the first
one gives us information on how late can we still tx PktDlAss on PACCH
on that DL TBF, while the later only provides info on when to free the
DL TBF in order to reuse the TFI.
Change-Id: I7421342461bf159d945651037e6fe690f88c6fae
In that code path, new_tbf is an UPLINK_TBF. Uplink TBFs (tbf_ul_fsm.c)
don't use state TBF_ST_WAIT_RELEASE, hence that condition cannot ever be
true.
Change-Id: I379d4140326a46e94914152fe9b735de852ceda0
When sending the last DL block, the FSM moves FLOW->FINISHED. Hence, it
is impossible to receive the FINAL_ACK in state flow, when we didn't yet
sent the last DL block (it's only possible if there's a bug in the MS).
TbfTest need to be adapted since they where acting wrong.
Change-Id: I3288743ff01ff84c3d345b6efb7c3fb6ca934791
Timer T3192 may be used in the future to know wheter a DL TBF assignment
can be sent on PACCH after the last DL TBF has finished (final ACK).
Change-Id: Ie5f6251ee773f56771f9a9507711a20e6282aac6
That timer is configured by value sent over PCUIF, hence better have it
to the same default value in osmo-bsc/osmo-bts.
Change-Id: I498f05ff4d232164690d177430e90eb99b4eea9d
Dispatching TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS means the UL TBF is
able to be used to assign DL TBFs over PACCH.
However, there's an extra implicit restriction: if the PCU already sent
the final UL ACK/NACK to that UL TBF, then whatever message sent
after it cannot be reliably answered, since the MS will go back to idle
state after issues the PKT CTRL ACK for that final UL ACK/NACK.
This condition is already being checked in
contention_resolution_success():
"""
if (ms_need_dl_tbf(ms()) && !tbf_ul_ack_waiting_cnf_final_ack(this))
ms_new_dl_tbf_assigned_on_pacch(ms(), this);
"""
Since we are considering the UL TBF to have done contention resolution
when we transmit the *first* UL ACK/NACK, it mans we are doing both things
on the same code path iif the *first* UL ACK/NACK is at the same time
the *final* UL ACK for that UL TBF. This can happen if the UL TBF is
only sending 1 block, which will have CV=0. This can usually happen
during GMM Attach Request.
In this scenario, with current code goes into a situation where first
the TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS is triggered and *afterwards*
the UL_ACK/NACK state is updated. As a result, the code snippet check
above (!tbf_ul_ack_waiting_cnf_final_ack()) will be true and the DL TBF
be assigned, but afterwards in the same code path it figures out the
final ack happens.
In order to fix this, first update the ACK/NACK state and only
afterwards trigger the Contention Resolution Success event.
Change-Id: I62ae91b494e4fd0ade3f4a3ba3817bcaedbdebf5
When we receive PCU_IF_MSG_DATA_CNF_DT, we check on PCU_IF_SAPI_PCH.
This is formally not correct, we should check on PCU_IF_SAPI_PCH_DT
instead.
(This patch will only affect osmo-bsc but not osmo-bts. The reason for
this is that osmo-bts still uses the older PCUIF v.10)
Depends: osmo-bsc.git Id5c799e625c56e57f7b51cd4fb57f5bea9c973d2
Change-Id: I0883b51fc232ec0267f1511c3a37c0bcd0967a08
It makes more sense to have it there, where it is transmitted with more
control depending on current state. Furthermore, it's
counterpart/continuation TBF_EV_ASSIGN_PCUIF_CNF logic is already there,
so it makes sense to have the whole logic together.
Change-Id: I8af39d3087ccf197321f0c71cb29b67adbe1f36e
That flag was still in state_fsm for historical reasons (refactoring
steps), but it's not really the best place for it, since it's really
specific to dl_tbf and to transmit of data and DL ACK/NACK not the
overall state of the TBF.
Change-Id: I12c28c1a52f363f2d17a8bc24bbdf379543fc7a6
That flag was still in state_fsm for historical reasons (refactoring
steps), but it's not really the best place for it, since it's really
specific to dl_tbf and to transmit of data and DL ACK/NACK not the
overall state of the TBF.
Change-Id: I6b44121bbe185b58f3a77be8c12b4ef1f3180a30
First print what is going to be attempted, later alarm about the
possible error, finally early return.
Change-Id: I417e9689f60e7f5d3c8ef67543e56fea87c8eebd
That path should not really happen. It happening would mean a totally wrong
code being used. Hence, just abort() to simplify the code.
Change-Id: Iaf65e909e45cc279e5be4b045c15174f910ffc12
Pau Espin
Philipp Maier