That function was pretty confusing since it used a "enum
gprs_rlcmac_tbf_direction dir" param (whose type is expected to describe
the data direction of a TBF) to describe the direction of the the packet
which triggered its call.
The parameter was actually always called with "GPRS_RLCMAC_UL_TBF" which
in this case meant "uplink direction" which meant "TLLI was updated from
the MS, not the SGSN".
The DL direction was only used in unit tests, which can hence be simply
replaced by ms_confirm_tlli(), which this commit does.
So this update_ms() function was actually used in practice in osmo-pcu
to trigger update of TLLI and find duplicates only when an RLCMAC block
(control or data) was received from the MS. Therefore, this function is
renamed in this patch and moved to the gprs_ms class, since it really
does nothing with the TBF.
Related: OS#5700
Change-Id: I1b7c0fde15b9bb8a973068994dbe972285ad0aff
ms_new_dl_tbf_assignment() is split into 2 functions, one to
allocate+assign on PACCH and another one for PCH.
This makes a lot clearer the aim of each caller of the function.
Once this is done, it becomes obvious tbf->establish_dl_tbf_on_pacch()
is basically doing the same as ms_new_dl_tbf_assigned_on_pacch() so drop
it.
Change-Id: I610210e3120c962d91ce8ff94c66161e086761ba
In that state (ul_tbf=TBF_ST_FINISHED), we are unable to reach the MS to
assign a new DL TBF.
* MS Is not available in CCCH because it's attached the PDCH.
* MS won't be able to PKT_CTRL_ACK a PktDlAss on PACCH, because next
thing it will do is to PKT_CTRL_ACK the UL_ACK_NACK(FINACK=1) we
already polled it for, and immediatelly after that it will release the
UL TBF on its side and go back to packet idle mode.
Hence, we must wait for MS to send the PKT_CTRL_ACK to us in order to be
able to assign the DL TBF in PCH (CCCH).
Related: OS#5700
Change-Id: I7a30db9cc7dae70e04054f1a4dba004bd1780d4a
Those power params are applied in the Pkt Ul Ass sent to the
MS.
In practice it doesn't matter much because the Pkt Ul Ass message is
created later asynchronously by the scheduler (event CREATE_RLCMAC_MSG).
Still it's much cleaner applying the information before allocating the
UL-TBF, since that's an extra independent step.
Change-Id: I63133aa42dcf27a86437b1bc8dc83c30d6718028
The LLC queue is already in the MS object. The LLC timer and most
of the logic to enqueue its data is independent from the TBF.
Change-Id: I56b89fcac838d8eb732b629734d5e458e9c806d1
That's the special value checked in the implementation of get_ms() to
skip lookups based on TLLI.
This should save some cicles trying to match TLLI 0.
Change-Id: I364d238ff8a82abb14281140fe18b273c0e8f541
I believe this may be related to sporadic failures we hit on Jenkins:
test -z "atconfig" || rm -f atconfig
../../../tests/testsuite: line 987: ./atconfig: No such file or directory
make[2]: *** [Makefile:1464: clean-local] Error 1
This dependency is present in all other Osmocom projects.
Change-Id: Id9bf06392ad31e1ecc66a5bd13069a915183a76b
This makes sure all MS and TBF objects under a bts are freed when its
underlaying storage is freed (cleanup() is called).
Related: OS#5555
Change-Id: Idf3ad8b70c97313dec38a49d48cf36d6c9b404c7
The timeout is set to a high value to avoid freeing the MS during main
loop iteration. Let's set it back to 0 to have a common free path in
test infrastructure.
Change-Id: I6dc4765163fde1a46574b49f3185aea65391e0d0
A CoDel state per prio queue is needed, otherwise the sojourn time state
is not properly reset when a high prio packet is dequeued.
If we have a global codel state shared for all prio queues of an MS, then
basically high prio (GMM) packets will "never" be dropped because they are
handled/dequeued way quicker, so it's sojourn time will be below the
threshold most probably, stopping the "dropping" state for the rest of
lower prio packets.
The handling of different codel states is moved from MS object to the
llc_queue, also offloading already loaded dl_tbf.cpp in the process.
This will also allow in the future setting different CoDel parameters
for different priority queues if needed.
Tests need to be adapted since now the CoDel and PDU lifetime are
incorporated into the llc_queue_dequeue(). Also because dequeue now also
accesses related MS fields.
Related: OS#5508
Change-Id: I2bce2e82ab6389d8a70130a5c26a966a316b0fa4
There's no real reason (other than historical) why code in llc should be
kept as c++ code. Let's rewrite it as C so that it can be included by
existing C code without having to add C->C++ shim, ifdefs all around,
etc.
This simplifies code and easies modification/improvement of the related
objects.
Change-Id: I250680ba581167d7398b2f734769c756cbb61c48
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I4a49dbeeec89b22624c968152118aecf8886dac6
We basically want to probe whether it's possible to allocate TBFs, or
whether we know it will fail due to all main resources being already in
use (TFI, USF).
Having bts_all_pdch_allocated() return false doesn't mean though that an
MS will be able to allocate a TBF for sure. That's because further
restrictions are applied based on MS: whether it was already attached to
a specific TRX, whether the ms_class allows for a certain multislot
combination, etc. However, it should provide a general idea on whether
for sure the PCU is unable to provide more allocations. More fine
grained state about failures can still be followed by looking at
tbf:alloc:failed:* rate counters.
Related: SYS#4878
Depends: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd (libosmocore)
Change-Id: Ie0f0c451558817bddc3fe1a0f0df531f14c9f1d3
The whole paging path and data structre is cleaned up.
New MS helpers ms_imsi_is_valid() and ms_paging_group() are introduced
to help in the process and keep implementation details inside GprsMs
class.
Related: OS#5303
Change-Id: I4c0838b26ede58e4b711410eee2a8e4f71e9414b
Log before the action is done ("Detaching", not "Detached"). This way,
if something crashes we see that last line.
Change-Id: I6811d3772e2ac850741d3db5ec32be5c0812e81a
This commit actually addresses 2 errors:
1- gprs_bssgp_pcu_rx_paging_ps() called gprs_rlcmac_paging_request()
with MI which can be either TMSI or IMSI, and the later always called
bts_pch_timer_start() passing mi->imsi regardless of the MI type. Hence,
trash was being accessed & stored into bts_pch_timer structures if MI
type used for paging was TMSI.
2- When the MS received the PS paging on CCCH and requests an UL TBF, it
will send some data. If one phase access is used for whatever reason,
the IMSI may not be yet available in the GprsMs object since we never
received it (and we'd only have it by means of PktResourceReq). Hence,
let's better first try to match the paging by TLLI/TMSI if set in both
places, and otherwise use the IMSI.
Related: OS#5297
Change-Id: Iedffb7c6978a3faf0fc26ce2181dde9791a8b6f4
This allows distinguishing when a TBF didn't set the TFI. Useful to
identify dummy reject TBFs, etc, and make sure a non-dummy TBF set its
TFI properly.
Change-Id: Iecf54a24041bd14f4ef5b86e57c3732e1b69d463
Let's set them to match expectancies for this type of dummy TBFs, in
order to avoid acidental use/access of other timeslots to the one where
the reject was associated to.
Also use tbf_assign_control_ts() to log the TS used for the TBF, similar
to what's used in other places where control_ts is assigned.
Related: OS#5293
Change-Id: I32dcb29ad24519082b8665921efcce0b5a16d12e
These new counters allow the user to find out which kind of access are
MS requesting.
Related: SYS#4878
Change-Id: Id87c3a53d3acee92499987c843130e358f54742c
If we decode Exist bit as "1" but we are at the end of the message, and
all the Next items we'd read are expected to be possibly NULL, then swap
the Exist bit in the decoded structure as "0" in order to tell the
decoder user that the related information structure is actually unset,
as if "0" was received.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I38602e4b680ed87297c7e440691a494c07cad446
All additional release fields are considered optional, and the
CSN_DESCR for Content_t already marks almost all as such, except
DownlinkDualCarrierCapability_r7.
It has been found that some MS transmits a MS RA Capability with a Length=61 bits
where the last bit in the buffer is setting the Exist bit for
DownlinkDualCarrierCapability_r7 as 1. Hence, the CSN1 decoder failed to
decode the whole message because it expected to keep reading there
despite there's no more bytes to read.
While this is could actually be considered an MS bug, let's relax our
expectancies and simply consider the case { 1 <end> } as it was { 0 },
and mark skip decoding DownlinkDualCarrierCapability_r7. That waht
wireshark (packet-gsm_a_gsm.c) or pycrate do for instance.
This patch itself doesn't fix the problem where actually the Exist bit
is stored as 1 in the output decoded structure, but simply allows keep
ongoing with decoding until the end. This issue will be fixed in a
follow-up patch.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I9a2541bd3544802a646890f32725201836abb0da
This RA Cap creaes a decoding error on our CSN1 decoder, but seems to be
handled properly by wireshark's own decoder as well as pycrate.
The ending bit of last byte in "MS RA capability 1" has a "1" which
according to spec should flag the existance of
DownlinkDualCarrierCapability_r7, but nothing else comes after it. This
matches the expectancies as per Length field of the first RA Cap.
Related: SYS#5552
Related: OS#4955
Related: OS#5020
Change-Id: I51235e8575f4b992b44078713ec67bbccfd13293
This helps distinguishing the case where a TBF is in the initial state
and the unexpected case where osmo_fsm_inst_state_name reports "NULL"
due to fi pointer being NULL.
Change-Id: Ieaabfc9fa0dedb299bcf4541783cf80e366a88c3
This one is larger than some of the other already available.
The decoder is wroking as expected here.
Change-Id: I5d986f68395326f894349446194090b1ddaecd69
The test uses get_poll_fn() to submit a UL ctrl block on the next
expected poll TS+FN.
During initial transmit_dl_data(), 2 POLLs for DL_ACK are set on
different TS, but the test only updates the clock for one of them in
send_ul_mac_block(). As a result, one POLL item is left in the rb_tree,
and later on, when send_control_ack() is called, get_poll_fn() will pick
that 2nd DL_ACK poll FN+TS which was left untouched (due to sending no
events to the PCU clock) instead of the FN+TS which was expected to be
allocated by PCU for DL_ASS.
Until now this was not an issue since rcv_control_ack() was not properly
veirfying what the poll scheduler was expecting and accepted it. This is
no longer the case after the follow up patch refactoring
rcv_control_ack() and improving its robustness.
Change-Id: I3a4b089fe66a99e73e07bd1c690cd4d67752fad9