Age | Commit message (Collapse) | Author | Files | Lines |
|
Until now, if timeslot resources where being allocated for an MS for
which its 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 must 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.
Test output changes in MslotTest.ok are expected since some allocations
are accumulative, and ms_class=0 is called the first one.
TbfTest.err changes happen in test_ms_merge_dl_tbf_different_trx().
Change-Id: If80fdd793db7dad029faa83dbf980ffc4959e2e5
|
|
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
|
|
Change-Id: I2cfa0486a3483140ce219b4645e0544e7923870a
|
|
Change-Id: I4f8e3d0dcb721d51838b50aba5b40d0551c8d0c5
|
|
Change-Id: I402a34c62d6714f054e8a3ff9042de3d2cf30727
|
|
is raised
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
|
|
Related: OS#6097
Change-Id: I327ca0e0f53be2d9b2a0705fe4de600229bdc5f9
|
|
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: 40a297f3b0c8e1670d46a4974750dd3335bc7885
Change-Id: I3d51e909c9a9f688b7f4425a5ba319d183c71d1f
|
|
Change-Id: If37907b2f75b61b3243b9d8499bb0cf5c02c28c1
|
|
Change-Id: Ifdc46a228752452c8d403f2d49f4bac23c450b4d
|
|
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
|
|
As seen during manual testing:
20230628140439674 DTBF tbf_dl.cpp:116 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12) Allocating DL TBF
...
20230628140439674 DTBFDL tbf_dl.cpp:489 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){NEW}: Received Event ASSIGN_ADD_CCCH
20230628140439674 DTBFDL bts.cpp:1108 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} Tx CCCH (PCH) Immediate Assignment [PktDlAss=PDCH(bts=0,trx=0,ts=5)] TA=0
...
20230628140440238 DMS pdch.cpp:681 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12:DL): + rcv_resource_request: now used by 2 (tbf,rcv_resource_request)
20230628140440238 DTBFDL pdch.cpp:738 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} Got PACKET RESOURCE REQ while DL-TBF pending, killing it
20230628140440238 DTBF tbf.cpp:271 TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN} free
...
20230628140440377 DTBFUL tbf_ul_fsm.c:169 UL_TBF(UL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN}: state_chg to FLOW
20230628140440377 DTBF tbf_dl.cpp:116 MS(IMSI-901700000015256:TLLI-0xd4d57c9d:TA-0:MSCLS-12-12:UL) Allocating DL TBF
20230628140440377 DTBFDL tbf_dl.cpp:475 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){NEW}: Received Event ASSIGN_ADD_PACCH
20230628140440387 DTBF tbf_dl_ass_fsm.c:105 TBF(UL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW} start Packet Downlink Assignment (PACCH) for TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){ASSIGN}
...
20230628140440816 DTBFDL bts.cpp:737 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW}: Received Event ASSIGN_PCUIF_CNF
20230628140440816 DTBFDL bts.cpp:737 DL_TBF(DL:TFI-0-0-0:E:IMSI-901700000015256:TLLI-0xd4d57c9d){FLOW}: Event ASSIGN_PCUIF_CNF not permitted
Change-Id: I042b0117552acae25c750e762f5cc254399da64f
|
|
Change-Id: I40f93473c86500f655a0a83c7816a065707e2ed9
|
|
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
|
|
Change-Id: I1da9b665b9ed83a644ea798008d456d6298b7460
|
|
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: 40a297f3b0c8e1670d46a4974750dd3335bc7885
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
|
|
Change-Id: Iba0d438f9ce20a5a4e293b0b36565f182824a136
|
|
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
|
|
Change-Id: I8c963ba7421faf2b3dcab006ea629c4628d17b44
|
|
Change-Id: I98c59dd833b3d0ada5b1ffdba7a5fc2e8cbf6241
|
|
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
|
|
Change-Id: I1bcb199f3ba9564870b82ab67218ffbf72da4824
|
|
Change-Id: I384753234651657c890faf1a4bdc1342e23e462b
|
|
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
|
|
Change-Id: I30111989c85001b0d9b98bf6f19c2247ab144433
|
|
Change macro to LOGPTBFDL since it's assigning a DL TBF. Clarify and
join log lines.
Change-Id: Ic5e01289f97bc113ba0a376a535e0cce5bccc5d1
|
|
We are no longer making use of the 4 high bits in state_flags, so we can
safely drop masking them.
Change-Id: I1402310919578a09669530786296f34bf3b23ef2
|
|
It makes no sense to continue trying to assign the UL TBF over PACCH
after T3168 * 4 retrans time out.
This helps in releasing the TBF after we got rid of incorrect use of
N3015 in UL TBFs.
While at it, update tbf_ul_fsm to use T3168 instead of X2001, since it
really needs to match T3168. Ideally it would not even have a timer
itself and receive an event from tbf_ul_ass_fsm, but that's left as a
TODO (it was already before) and simply the timer is updated.
Change-Id: I87dff68dedd06b60501e7586d20faf02bb1f0c93
|
|
T3195 is triggered as consequence of N3105 reaching MAX, which only
occurs in DL TBFs. Hence, T3195 also only applies to DL TBFs.
The references to T3195 were there as a remains from time
where we had a single tbf_fsm for both UL and DL TBFs. It can now be
further simplified.
Change-Id: I07a43c13289d50707115187a3f22df21443a7b4a
|
|
T3169 is triggered as consequence of N3101 and N3103 reaching MAX. Those
counters are related to UL TBF only, and hence T3169 also only applies
to UL TBFs. The references to T3169 were there as a remains from time
where we had a single tbf_fsm for both UL and DL TBFs. It can now be
further simplified.
Change-Id: I02f7654518da617ce6704d807d34761dbadecf07
|