This allows more easily finding when this specific scenario happens, and
can easily be compared against the PACCH one.
Change-Id: I609792a40fda2a798ca71a0e9f5639d0a0f011d7
Store direction check to simplify the code.
Get rid of 2-step LOGP to avoid multi-row logs in gsmtap log.
Change-Id: Ia2e061da82ddce564b2d768d8ade1672c22934e2
Tbftest expectatins need to change because 5000/20 = 250 < 255, hence
the message is now sent as units of 20ms instead of seconds.
Related: OS#3928
Change-Id: I48b34b94b1a5dfb046a3a6cf8a0d944a7c9b6754
Document the function, make it look similar to usual TBF creation path
tbf_alloc_ul()->tbf_alloc_ul_tbf->tbf::setup(), which it mimics with
some differences.
Get rid of unneeded stuff like creating MS and settings its TLLI (that's
already done in only caller of the function). There's no need for
calling update_ms() either.
Change-Id: I61df2e4f0f0df1f8db941741a2d35a2319252c5e
Now that we finally handle N3101 and N3103 correctly, we can fix abuse
of T3169 we were doing to make sure TBFs were freed.
According to 3GPP TS 44.060, T3169 should be armed:
* N3101_MAX reached
* N3103_MAX reached
Furthermore, when T3169 is enabled, the tbf should be in state
RELEASING so that its USF is not used.
See full description: https://osmocom.org/issues/5033#note-2
Related: OS#5033
Change-Id: I2cec531e2633281b88f69ba065c0105580c81076
Use recently added PDCH UL Controller to verify expectancies.
Test test_packet_access_rej_prr is rewritten since it didn't make sense
as it was before, since it relied on osmo-pcu not checking stuff
properly to trigger the reject. The RACH requests are changed to
allocate 8 SBAs (maximum of 7 concurrent USFs). Allocating the SBA
doesn't reserve a USF, that happens at PKT RESOURCE REQUEST, hence we
end up exhausting resources there and triggering the REJECT at that
point.
Previous version of the patch allocated TBFs directly through RACH req,
and then submitted an extra PKT RESOURCE REQUEST which PCU didn't expect
to trigger the reject.
Change-Id: I157e72160317340ee7742c78c62a25d3d98fc01e
That field is not needed anymore, and it works only under the assumption
that only 1 poll request can be active at a time per TBF, which is not
true.
Change-Id: I9b8bed7741d385bab4cd8c64b841a78a02a05fe1
That field is not needed anymore, and it works only under the assumption
that only 1 poll request can be active at a time per TBF, which is not
true.
Change-Id: I63a34a702f028b871530fb7caeb13e8ea1cc78ac
Value 'false' is always passed by all callers of the function, so
there's no need to pass it. Furthermore, since it's false, there's no
need to access poll_fn since RRBP will always be invalid.
Change-Id: Ia48ce2a021865e76e813dedb22aca9c2522c5693
The poll_state logic was part of previous implementation (prior to pdch
ul controller) where the ssumption was that TBF could only had 1 POLL
request in transit, which is really not true. With current
infrastructure we don't need this state tracking at all.
Change-Id: Ie5b807ccd38aa736ae11b3310ca61ad0156ca4d4
There's no good reason to allow only for 1 concurrent POLL requested to
a TBF, it was onyl done this was as an implementation limitation factor.
It can well happen that several multiple POLLs may be in transit at the
same time, eg to get DL ACK/NACK as well as to get a CTRL ACK for a Pkt
Cell Change Continue (NACC).
Change-Id: Ic4080db684a4626cae90dd574d123081981284ca
This API is not really needed anymore, since anyway it works under the
assumption there can only be 1 POLL in transit per TBF, which isn't
necessarily true.
Change-Id: I875f51cade95faeb2d79dcebfead4c83e23a731b
This allows easily checking the initial reason to trigger the poll when
either it is received or times out.
Later on this reason can be transformed into an FSM event and sent to
the related FSM.
Related: OS#5020
Change-Id: Ie8fefd1f47ad674ce597a8065b15284088956bde
Make sure an unreserved FN is picked and reserved when allocating and
scheduling an SBA.
In practice this has no change in behavior right now, since anyway using
an offset of 52 FNs ensure no USF or POLL has alredy been scheduled that
far in the future. Since it's also impossible to allocate more than 1
SBA per PDCH and RTS FN, we are also safe about multiple SBAs being
allocated, because we use a hardcoded offset of 52.
However, that could change in the future, when we dynamically tweak the
current offset of 52 FN based on information from BTS about its AGCH
queue load:
* If load is high, we may need to increase the offset since it
will take more time for the BTS to transmit the TBF and hence we must
reserve a TBF starting time further in the future (higher FN).
* If load turns low, we may schedule next SBA a bit more nearby in time
than the previously allocated SBA, hence here there could be a
collision.
Related: OS#5020
Change-Id: I2d4e21e2307de6c17748e8da5c7e149c947a7eb9
This way PCU can now detect whether scheduled UL blocks through USF
were never received. This allows in a follow-up patch to start
increasing N3101 properly.
Related: OS#5033
Change-Id: Ia99c9edad6e5bd837e9baeb4fb2683b227887957
There's no need for setting the FN in RA.ind since we anyway already
receive a DATA.ind beforehand.
Furthermore, the applied delay of 5 in the call is not really used at
all.
Change-Id: I437f4f95d054aea96bec3b9343e495451020ff3c
Issue will be fixed in next commit. Leaving ASSERTs disabled so that
test passes in jenkins.
Related: OS#5020
Change-Id: I657db6b300363f8f3a9e4cfaf7a7f49e361a0512
TbfTest is updated to submit empty blocks to have somehow meaningful
output (at least as meaningful test results as before, not much). That's
because we must update bts->curr_fn to have polls expire.
Related: OS#5020
Change-Id: I683ca738ce5a133c49c36a1d94439a942d64a831
Right now we handle different types of UL allocations in different
classes like PollAllocator and SBAllocator, and they usually don't take
into account the other one in most cases. Furthermore, those objects are
usually per-BTS object, instead of per PDCH object.
This is a first step towards having a unified per-PDCH controller which
takes care of controlling what is scheduled and hence expected on the
uplink. Each PDCH has a UL Controller which keeps track of all reserved
uplink frame, be it SB, RRBP poll or USF assigned, all under the same
API.
As a first step, only the SBA part is fully implemented and used (being
it the easiest part to replace); TBF poll+usf will come in follow-up
patches later on. As a result, the SBAllocator per-BTS class dissappears
but some of its code is refactored/reused to provide more features to the
gprs_rlcmac_sba object, which is also further integrated into the new UL
Controller.
Related: OS#5020
Change-Id: I84b24beea4a1aa2c1528f41435f77bd16df2b947
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).
Depends: osmo-bts.git Change-Id I343c7a721dab72411edbca816c8864926bc329fb
Related: OS#5020
Change-Id: Ibc495173119465e74f726ddc36e312334e6dc0fd
If Idle TBF timer (X2031) is set to 0, it means the TBF release is
immediately started once all queued data has been scheduled. In that
case, we must set FBI=1 (by setting cv=0) and move to FINISH state.
This used to work over the usual path where X2031 != 0, because release
start will alays happen at a later sched poll time where a dummy LLC
frame is sent and FBI set accordingly.
Change-Id: Ib20602936ae084c413f6bfe14eea33b602020be0
Old commit getting rid of LLC UI dummy and updating create_new_bsn()
function introduced a bug by not moving update of value m_last_dl_drained_fn
prior to a new break introduced.
As a result, the value is not updated in the case LLC queue becomes
drained but last few bytes are drained at exactly that moment.
Furthermore, then the IDLE tbf timer (X2031, keep_open())) returns always
true since according to it the drain never happened.
The impact of the bug is basically delaying a bit more than expected the
time the TBF stays in IDLE state with the TBF release process yet
to be started.
Related: OS#4849
Fixes: 7d0f9a0ec3
Change-Id: I7420aeffda3500bcdc990291e4a56511af433ff9
Since a while ago, the data architecture was changed so that TBF is
guaranteed to always have a MS object associated. Hence, it makes no
sense to pass the MS object as a separate param as we can take it from
tbf object and makes code less confusing.
Change-Id: Idc0c76cf6f007afa4236480cdad0d8e99dabec5f
Before this patch, allocate_usf() was implemented to only allocate 1 USF
per TBF, regardless of the available ul_slot mask.
As a result, only 1 slot at max was allocated to any TBF. That's a pity
because usual multislot classes like 12 support up to 2 UL slots per TBF
(in common TS with DL).
This patch reworks allocate_usf() to allocate as many UL multislots as
possible (given mslot class, current USF availability, TFI availability,
related DL TBF slots for the same MS, etc.).
As a result, it can be seen that AllocTest results change substantially
and maximum concurrent TBF allocation drops under some conditions.
That happens due to more USFs being reserved (because each TBF has now
more UL slots reserved). Hence now USF exhaustion becomes the usual
limitation factor as per the number of concurrent TBFs than can be
handled per TRX (as opposed to TFIs previously).
Some of the biggest limitations in test appear though because really
high end multislot classes are used, which can consume high volumes of
UL slots (USFs), and which are probably not the most extended devices in
the field.
Moreover, in general the curren timeslot allocator for a given
multislot class will in general try to optimize the DL side gathering
most of the possible timeslots there. That means, for instance on ms
class 12 (4 Tx, 4Rx, 5 Sum), 4 DL slots and 1 UL slot will still be
selected. But in the case where only 3 PDCHs are available, then with
this new multi-slot UL support a TBF will reserve 3 DL slots and 2 UL
slots, while before this patch it would only taken 1 UL slot instead of
2.
This USF exhaustion situation can be improved in the future by
parametrizing (VTY command?) the maximum amount of UL slots that a TBF
can reserve, making for instance a default value of 2, meaning usual
classes can gather up 2 UL timelosts at a time while forbidding high-end
hungry classes to gather up to 8 UL timeslots.
Another approach would be to dynamically limit the amount of allowed
reservable UL timeslots based on current USF reservation load.
Related: OS#2282
Change-Id: Id97cc6e3b769511b591b1694549e0dac55227c43
The old VTY command is marked as deprecated and still overrides the use
in case it's used.
Related: SYS#5358
Depends: libosmocore.git Change-Id I74fb0a3afc1ac4aadbfc609b882d929401f790eb
Depends: osmo-bsc.git Change-Id I8b97ea11bad5fe05f2f634945b5703ee9abde81d
Change-Id: I46f2a955b157a409055fca7fb917dc4f75482426
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I7f9c56313cfaa74ebe666f44763a83d8102f5484
Related: OS#5034
All vectors should be valid, since they were generated by an MS.
As can be seen, osmo-pcu fails to decode one of the vectors.
Change-Id: I37a2ddd394eeffa1cae0f3e419eeee0200a57fcf
OS#4955
Change-Id: Ib5677048f5668185ffe752f97c97d5612eee4d72
Pau Espin
Pau Espin Pedrol
Vadim Yanitskiy