Picked code from the Decoder function. I gave it a try
callback_init_Cell_Selection_Params_FREQUENCY_DIFF and looks
like working fine.
Change-Id: Iac962ae3e9f52f417f394060b64fc4d0ebf3d0bf
Other callback functions are properly specified as per what's in
"typedef CSN_CallBackStatus_t". However, these two were wrong.
Change-Id: I280b51d4c8c38c76cc1ccd49656b6b7bbe769760
This is only an initial implementation, where all state changes are
still done outside the FSM itself.
The idea is to do the move in several commits so that they can be
digested better in logical steps and avoid major break up.
Related: OS#2709
Change-Id: I6bb4baea2dee191ba5bbcbec2ea9dcf681aa1237
The ul_tbfs/dl_tbfs lists will become per-trx. Since in this case we
want to operate on the BTS globally, let's iterate over MS objects
instead. This makes more sense too since here we really aim at reaching
a MS (subscriber) instead of specific TBFs. Later on the code can be
optimized easily to schedule a Pkt Paging Request for only 1 of the TBFs
of each MS instad of scheduling it for each TBFs in the MS.
Change-Id: I671e531921bbea2f5cc0f2bfcb8a39ea5c6673b8
Before this patch, when a PAGING-GS was received in PCU from SGSN, it
would always forward the paging request to all PDCHs in all TRXs of all
BTS (well, it did some heuristics to avoid sending it in some PDCHs
where onyl repeated TBFs would be listening).
The previous behavior, didn't make much sense in the case where the PCU
is asked to page an MS which it knows (ie in which PDCHs is listening
to). Hence, in that case it makes sense to simply send the paging
request on 1 PDCH where the MS is listening, instead of sending it in a
big set of different PDCHs.
This commit also splits the old get_paging_mi() helper which was
erroneously created to parseboth CS/PS-PAGING requesst, since they
actually use a different set of target subscriber information (for
instance, CS-PAGING provides optionally a TLLI, and one provides P-TMSI
while the other provides TMSI).
In this patch, the handling of CS paging request is split into 2 parts:
1- A new helper "struct paging_req_cs" is introduced, where incoming
CS-PAGING requests (from both SGSN over BSSGP and BTS/BSC over PCUIF)
are parsed and information stored. Then, from available information, it
tries to find a target MS if avaialable
2- bts_add_paging() is called from both BSSGP and PCUIF paths with the
helper struct and the target MS (NULL if not found). If MS exists,
paging is forwarding only on 1 PDCH that MS is attached to. If no MS
exists, then the old heursitics are used to forward the request to all
MS.
Change-Id: Iea46d5321a29d800813b1aa2bf4ce175ce45e2cf
Got this today with newer gcc (11.1.0) after system upgrade:
egprs_rlc_compression.cpp:693:9: error: this ‘else’ clause does not guard... [-Werror=misleading-indentation]
The indentation was indeed wrong, provoking a warning in GCC. From code
flow point of view, however, the previous state was fine too, so no
logical change is involved in this commit.
Change-Id: I37bfc8e85daaabbbf10dfd907b305e3e0ec31863
Previous implementation of the Rx path was first checking the APP ID
before checking the lower layer (container type), which was confusing
because the information is then not verified in ascending order in the
protocol stack.
Let's instead, first, pass the pdu to the correct container type
handler, and only once there, let each container type handler verify the
available applications.
Change-Id: Ibe017c1a6e789f45d74c4a5f5f4608298c8c9f91
The logic checking whether the UL TBF had already been sent all the data
(and hence was marked as finished and requesting UL ACK to be sent) was
not taking into account the case where there was still no valid block
stored, ie. when the first received UL data block was discarded for some
reason (ex: because TLLI was not set during content resolution).
Related: OS#1940
Change-Id: I739e67ae1bb40555a362170f26fb98ac69caabb2
Let's avoid different code paths in the loop based on is_tlli_invalid.
Instead, always do the proper storing of the block, and if later on the
corner case is found (no TLLI received while in Content Resolution
process) when checking tlli related stuff, then simply invalidate the
block.
Related: OS#1940
Change-Id: I77afaa617d7ce045c0f6d994fc0d8e03fe69de53
Since a while ago, tbf should always have an MS attached since its
creation, so there's no sense to check for it here.
Change-Id: If056a3fb83b43a48c2a6382fc30c6c81fe2b2651
It could happen that if MS sends first UL blocks without TLLI (wrongly,
due to being in contention resolution), the submitted UL ACK/NACK would
contain an invalid TLLI.
Related: OS#1940
Change-Id: Ibae5df6cfbb56f8f8007cb9fec9c29006d673b72
This allows more easily finding when this specific scenario happens, and
can easily be compared against the PACCH one.
Change-Id: I609792a40fda2a798ca71a0e9f5639d0a0f011d7
Untangle variable assignment at the start of the function. Changes end
up in same kind of assignment, but are far easier to understand based on
the variable use later on.
* reserved_{dl,ul}_slots contain mask of TS either "previously-reserved" or
"intended to be reserved now" based on MS's ms_class.
* {dl,ul}_slots contain a derived mask from the one above, filtered
further based on more factors like type of allocation requested (multi
vs single), available USFs (UL), etc.
Change-Id: If3cfa82f8b793a87e97145ee8a6fc0fe1a61add6
Store direction check to simplify the code.
Get rid of 2-step LOGP to avoid multi-row logs in gsmtap log.
Change-Id: Ia2e061da82ddce564b2d768d8ade1672c22934e2
While libosmogb / ns2 supports that natively in the VTY, the PCU
doesn't want to use the complexities of the full NS2 vty.
Change-Id: I7bfbad46582e65e5ad2ac0cc66545538bc632df8
Related: SYS#5427
The code path running into first call of "create_packet_access_reject()"
is a superset condition of the second one, so the second one will never
be hit.
As a result first, this block:
"""
else if (tbf == tbfs->ul_ass && tbf->direction == GPRS_RLCMAC_DL_TBF)
if (tbf->ul_ass_state_is(GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ))
msg = tbfs->ul_ass->create_packet_access_reject();
else
msg = tbfs->ul_ass->create_ul_ass(fn, ts);
"""
Can be simplified into:
"""
else if (tbf == tbfs->ul_ass && tbf->direction == GPRS_RLCMAC_DL_TBF &&
!tbf->ul_ass_state_is(GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ))
msg = tbfs->ul_ass->create_ul_ass(fn, ts);
"""
Next, one can see that previous condition still forces
!tbf->ul_ass_state_is(GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ) to be always true
if we ever reach that code, so it can be dropped.
Change-Id: I62e2255e28fc4f43fe0a31259ebf18ad00e7e357
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
During RELEASING state the TFI, USFs, etc. are still reserved and
assigned to the TBF, and hence the TBF may still use it.
If callers of this function rely on not taking TBFs under RELEASING
state, they should check that explicitly.
It still makes sense being to operate on RELEASING TBFs, since under
some circumstances the TBF may go under a previous state. See for
instance 3GPP TS 44.060 sec 8.1.1.3a.2:
"""
If N3101 reaches the value N3101max, the network shall stop sending
PACKET UPLINK ACK/NACK messages to the mobile station for that TBF
and shall start timer T3169 for the TBF. If an RLC/MAC block is received
from the TBF when timer T3169 is running, the network shall stop timer
T3169 and resume sending PACKET UPLINK ACK/NACK messages to the TBF.
When T3169 expires, the network may consider the TBF as released and
reuse the TFI value.
"""
Change-Id: Ibb471e727388512d42794d3faa26597e2545b852
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
The related ul_ass_state already implies polling is ongoing since we are
waiting for an ACK to be received from MS. Hence there's no need to
check poll_state there.
Change-Id: I5e12280a6835407fa452bd4d5df799d2672790ec
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
When the scheduler detects it's time to receive a UL block due to a
scheduled poll, if that polling is done on a UL TBF, then use its USF if
available instead of using USF_UNUSED (=7) when sending a DL block on
that same FN.
This is not really needed for correct work, since MS take care
themselves of scheduling a UL block when they receive the poll (RRBP)
some time before, and don't check the USF at the time of transmitting.
In any case, it helps understand better when looking at pcap traces that
indeed it a UL block from that MS was requested, instead of setting USF
to 7.
Related: OS#5033
Change-Id: I2ad9d8ea6afc8f83192033470bd27010a7474430
Simply use the UL TBF pointer all along until the end, instead of setting
both the UL TBF pointer plus the usf var.
This commit is also a preparation for next commit which also selects UL
TBF when a poll is available, to set its USF in the DL message instead
of "USF_UNUSED".
Change-Id: I3aa3886932ef87db18ed7ff6991ea315f481990b
With previous code, a skipped TBF could be returned despite not matching
the conditions, since at the end of the loop the tbf pointer was
returned.
Related: OS#5020
Change-Id: If6dccec86c7a655bf1c62f333cfbc8d2c507c94f
pdch_ul_controller.c: In function ‘pdch_ulc_release_tbf’:
pdch_ul_controller.c:217:7: error: ‘item_tbf’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
217 | if (item_tbf != tbf)
| ^
Change-Id: I42120fdf23753945ebc16bb5469d9fd253c3da37
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
Take the time to also do small refactorings to clarify and simplify the
function, by using rts_next_fn() already available in pcu_utils.h and
getting rid of poll_tbf from tbf_candidates, which clearly follows
another objective.
Using PDCH UL Controller has the advantage that we don't need to check
poll_scheduled() on each TBF, but only do the query once.
Related: OS#5020
Change-Id: Ia60bb5249a9837dec1f42180e44d9848334d86d6
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
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).
This patch does the same for direct phy feature, where the osmo-pcu
process receives the DATA.ind directly from the DSP.
Depends: osmo-bts.git Change-Id I343c7a721dab72411edbca816c8864926bc329fb
Related: OS#5033
Change-Id: I9a835e16ef0e5a68c003a93d1a33233aa43464ae
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: I17c28abf63b153448b533971ac5cf2e48daadea8
Use primitives instead of parsing the message a second time.
Set bctx->is_sgsn to false to allow the BSSGP layer to send back a
RESET_ACK with cell information.
Related: OS#3879
Depends: Ibcbaffa94cbdc4296a8a7c372304ac11d50d9559 (libosmocore)
Change-Id: I3afaf826798e362270ffa622c24bfd124ef25cd1
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
This is specially useful to detect for instance if a cell is handling
too many users, ending up in TFI or USF exhaustions. This information
can be later in the future used to tune TBF allocation algorithm behavior
(either manually/statially through config file, or
automatically/dynamically in code based on some thresholds).
Related: OS#5042
Change-Id: I5402e937ff8d800684655e500ef8e5c867141dc3
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
The gprs_ns2 now requires to specify every bind which should be used by the NSE for IP-SNS
Related: SYS#5354
Depends: I9ab8092bf286e7d90e92f5702a5404425e959c84 (libosmocore)
Change-Id: I35c987224ce098f7ee9f189ce0fce9e68ad3feac
The DL NACC related message (PKT Cell Neighbor Data/Change Continue)
are filled with the TFI of the target TBF. Hence, only select the tbf
for NACC transmission if the related TBF already has a TFI assigned.
Otherwise, "OSMO_ASSERT(tbf_is_tfi_assigned(tbf));" in nacc_fsm.c when
generating messages may be hit.
Related: SYS#4909
Change-Id: I72b2dff28aacdb04909c098c94834ff79f55b31d
Add support for multiple SNS endpoints.
Move the NSE allocation to the top in preparation of IP-SNS binds.
The future gprs_ns2 library will require to manual add every bind to the NSE for IP-SNS.
Rename the function to match more it's purpose.
Related: SYS#5354
Change-Id: I69cf48ab168a6dca4f649157bf6556d7cd27d4fb
Similar to what's done in the previous commit, but this time when we are
further forward in the resolution process.
This can be triggered for instance because we are taking too much time
to resolve and MS has timer to retransmit the Pkt cell Change Notify in
case no response was received in time.
This commit fixes osmo-pcu exiting due to ASSERT(0) since the event was
already accepted but not being handled in the state function.
Related: SYS#4909
Change-Id: I0c29e5979fec6eebe9dfb151907a4cd2f5e4a737
If the message is a duplicate (same tgt cell), simply ignore it.
If the message contains a different tgt cell, restart the resolution:
* Avoid re-creating the socket in that case
* Avoid potentially picking a CTRL response for an older request
Related: SYS#4909
Change-Id: Ia2ed2580bbbdd6d3464833257b0dcb8ec6f8d699
We don't care about those messages anymore if we already transitioned
further than NACC_ST_WAIT_REQUEST_SI. Furthermore, RIM code dispatching
the event to the FSM is only doing it in the mentioned state above.
Related: SYS#4909
Change-Id: If420b49e437ff02073669522408763e5e84fe477
Same filler will be needed in different places since that message can
arrive at different points of time (different states).
It also helps supporting newer key types in the future.
Change-Id: Idfd4db8408f767b1847b04c88047a1c4996e543e
Now that we have the required System Information in osmo-pcu to craft
the Packet Neigbour Cell Change packet for cells it controls, let's
avoid starting a RIM procedure to gather the SI info, since the SGSN
would end up routing the RIM request back at us and we'd answer back to
ourselves.
This same optimization cannot be done on the first step (CTRL Neighbor
Resolution against BSC), because the PCU cannot know if the target
ARFCN+BSIC requested by the MS is actually managed by a cell under the
PCU or it's another cell managed by another external PCU, because
ARFCN+BSIC keys can be resued among non-neighbor cells. Hence, it shall
always ask the BSC since only it holds the information about neighboring
cells.
Related: OS#4909
Change-Id: I928875b6b66dff55fc12f51b6b1ad919fef7d03b
Use the fact that the MS must answer the RRBP of the Pkt Cell Change
Continue with a CTRL ACK to find out whether the message was received
successfuly or a retransmission is potentially required.
3GPP TS 44.060:
"""
When the mobile station receives the PACKET CELL CHANGE ORDER or
the PACKET CELL CHANGE CONTINUE message the mobile station shall
transmit a PACKET CONTROL ACKNOWLEDGMENT message in the specified
uplink radio block if a valid RRBP field is received as part of the
message; the mobile station may then switch to a new cell.
"""
Related: SYS#4909
Change-Id: I7cc28922e71699598da0ef6eb90136a47d3c002f
Answer an incoming RAN INFORMATION REQUEST RIM PDU with RAN INFORMATION
PDU that contains system information type 1, 3 and 13
Depends: osmo-bts I5138ab183793e7eee4dc494318d984e9f1f56932
Change-Id: Id72118120c14984d2fb1b918b41fac4868150d41
Related: SYS#5103
Those fields were ment to be 0 (non-valid), just the comments were
copied over from somewhere else, and they are misleading.
Change-Id: Ic95853e115f60c65f7f11187d49d6e870d08c7bb
If fore some reason we fail to fetch SI of target cell, we move
directly to NACC_ST_TX_CELL_CHG_CONTINUE in order to submit a Cell
Change Continue against the MS without providing any Packet Neighbor
Cell Data beforehand, as per spec that's probably the best we can do
in this scenario (TS 44.060):
"""
1) The network responds with a PACKET CELL CHANGE CONTINUE message.
If a mobile station as response to a PACKET CELL CHANGE NOTIFICATION
message receives a PACKET CELL CHANGE CONTINUE message without receiving
any neighbour cell system information, the mobile station shall stop timer
T3208, stop timer T3210 if still running, leave CCN mode and continue cell
reselection in NC0/NC1 mode.
"""
This commit also fixes a use-after-free triggered by TTCN3 test
TC_nacc_outbound_rac_ci-resolve_fail_parse_response, where the "cmd"
pointer passed to nacc_fsm_ctrl_reply_cb() was freed during FSM
termination (its talloc ctx was under ctx->neigh_ctrl_conn) and the
libosmocore code calling that callback was later on accessing
cmd->defer.
Since due to this change the FSM is no longer syncrhonously freed, the
issue is gone.
Related: SYS#4909
Change-Id: Ie3f12a08ad611b1086d3f4ab7c3d34af43c07961
Upon timeout, we move directly to NACC_ST_TX_CELL_CHG_CONTINUE in order
to submit a Cell Change Continue against the MS without providing any
Packet Neighbor Cell Data beforehand, as per spec that's probably the
best we can do in this scenario (TS 44.060):
"""
1) The network responds with a PACKET CELL CHANGE CONTINUE message.
If a mobile station as response to a PACKET CELL CHANGE NOTIFICATION
message receives a PACKET CELL CHANGE CONTINUE message without receiving
any neighbour cell system information, the mobile station shall stop timer
T3208, stop timer T3210 if still running, leave CCN mode and continue cell
reselection in NC0/NC1 mode.
"""
Related: SYS#4909
Change-Id: Ia9932ab082ec095294e85dc4d532046970e17986
This way, we don't open a socket and do the IPA handshake in the event
the request is already cached.
Related: SYS#4909
Change-Id: Ib1ea85e1196c8b9dc40c8837ab5d4a54f2a1f2d4
Older versions of osmo_ctrl_conn_alloc() may not properly initialize
write_queue.bfd.fd to -1, which means if osmo_sock_init2_ofd() failed
during nacc_fsm_alloc(), the destructor would wrongly enter the conditon
where the whole structure is set and unregister the unregistered fd.
Related: libosmocore Change-Id I98f744d2880fbb883719cdf1d3eb31f2b22a13b6
Related: SYS#4909
Change-Id: I253bd9087b1f7ab039aa1127e9dc586f5106905a
A new nacc_fsm is introduced per MS object, with its partner priv
structure struct nacc_fsm_ctx, which exists and is available in the MS
object only during the duration of the NACC procedure.
The NACC context is created on an MS whenever a Pkt Cell Change
Notification is received on Uplink RLCMAC, which asks for neighbor
information of a given ARFCN+BSIC.
First, the target ARFCN+BSIC needs to be translated into a CGI-PS
(RAC+CI) address. That's done by asking the BSC through the Neighbour
Resolution Service available in osmo-bsc using the CTRL interface.
Once the CGI-PS of the target cell is known, PCU starts a RIM RAN-INFO
request against the SGSN (which will route the request as needed), and
wait for a response containing the SI bits from the target cell.
After the SI are received, the scheduler is instructed to eventually
poll a TBF for the MS originating the CCN, so that we can send the SI
encapsulated into multiple Packet Neighbor Cell Data messages on the
downlink.
One all the SI bits are sent, the scheduler is instructed to send a
Packet Cell Change Continue message.
Once the message above has been sent, the FSM autodestroys itself.
Caches are also introduced in this patch which allows for re-using
recently known translations ARFCN+BSIC -> CGI-PS and CGI-PS -> SI_INFO
respectively.
Change-Id: Id35f40d05f3e081f32fddbf1fa34cb338db452ca
This also changes the vty configuration. If only timeout has been
configured for ns the new configuration is compatible.
For further information see:
https://osmocom.org/projects/libosmocore/wiki/Network_service_(NS)
Depends-on: I8c3f2afecc74b78f7f914f7dce166cbcb63444eb (libosmocore)
Change-Id: I14af821a8d1fda670643c3d5f81299a3abf3c583
All gprs_ns2 enums have now GPRS_NS2 as prefix.
Depends-on: I548ff12f7277cbb7e1a630a3dc02b738ce89be72 (libosmocore)
Change-Id: Ifdc7956318c07d680feab33c22bc2c6f20927bf9
Sine we don't yet implement properly all resegmentation of blocks from
same MCS family type, when requiring a GMSK DL block (due to GPRS+EGPRS
multiplexing limitations) we need to skip retransmitions, otherwise we'd
be incorrectly picking a DL block which was already built with a
potentially higher MCS value.
The "DL_PRIO_NEW_DATA" prio serves two purposes:
* There's new data to send
* There's some nacked data to be retransmitted
The 2nd purpose has, later on, more priority over the 1st one when the tbf
is selected (see gprs_rlcmac_dl_tbf::take_next_bsn()).
Until now we were handling correctly the case where the tbf was skipped
in case the prio was to resend unacked data (DL_PRIO_SENT_DATA), but
was incorrectly selected when it'd send nacked data. Let's fix it by
specifically checking w->resend_needed() < 0.
Change-Id: I253de8e1a190a9adb56160f38892c9e43e2c0272
Under some circumstances, it could happen that a DL TBF is created as a
GPRS TBF due to not yet having enough information of the MS, and only
after the TBF is created the PCU gains that information and upgrades the
MS mode to "EGPRS". Hence, there's the possibility to run into a
situation where a GPRS TBF is attached to a EGPRS MS.
It may also happen sometimes that despite the TBF and the MS be EGPRS,
there's need to further limit the DL MCS to use, eg. MCS1-4 (GMSK).
As a result, when asking for the current DL (M)CS to use, we must tell
the MS which kind of limitations we want to apply. The later reasoning
was already implemented when GPRS+EGPRS multiplexing was added, but the
former was not being checked. Hence, by further spreading through the
call stack the "req_kind_mode" we match both cases.
Related: OS#4973
Change-Id: Ic0276ce045660713129f0c72f1158a3321c5977f
The TBF can sometimes be detached from an MS, for eg. when switching
from one MS object to another due to them being merged after we found
duplicate objects upon receiving new information from it, but that
change is instantaneous so it shouldn't be a problem. The only other way
where an MS can be detached from an MS is during the end of its (or the
MS) life, where it is not sending data anymore.
Hence, it is safe to drop those checks for MS not being null. Those
being trigger, it should be considered a bug.
Change-Id: If292a53a09a64664031e756bff4735b9c6ee8651
It could happen as of current implementation that a TBF was created as
GPRS due to the MS being non-egprs, and later on the MS was upgraded to
EGPRS due to newly received information from the MS.
Hence, in order to infer if the data block is EGPRS or GPRS, let's
better check for the TBF info, which is the one really mandating the
kind of dl block to generate.
Change-Id: I49720fb3a69ca972cd1973de937ac8ee77615431
MS is always assigned to a BTS, since it's set during MS constructor.
Hence, the check removed in this patch would never hold true (and if it
did, it'd be a bug).
Change-Id: I86a71c64623f7bec031226938a54306148370ffb
it was noticed that gprs_pcu_get_bts_by_cgi_ps() sometimes failed to
return the BTS even if the CGI-PS fields matched, probably due to memcmp
checking too padding bytes which may not be zero-initialized in one of
the two memory regions being checked. Let's be on the safe side and use
libosmocore APIs to check them.
Depends: libosmocore.git Change-Id I00e329bc5be8674b30267dec238e7656ddfc21db
Change-Id: I7c8ee2c447634e45b367bb8f84adf0140ae48591
This code doesn't do anything yet app-related with the received RIM
messages, but already provides the initial infrastructure to handle them
in the future, and does first checkings.
Related: SYS#5103
Change-Id: Ia0ade0e97ea781ec655439c008b6cefaf3e90dec
This patch doesn't really tests whether osmo-pcu can work on a multi-bts
environment, but it prepares the data structures to be able to do so at
any later point in time.
Change-Id: I6b10913f46c19d438c4e250a436a7446694b725a
There's no real point in using C++ there, and using C++ makes the
compiler fail to use llist_head in multi-bts patches added later due to:
"""
'offsetof' within non-standard-layout type is conditionally-supported
"""
Change-Id: I8965b5cc5a713e64788b5b6aa183d3035341ddbb
There's no real use of C++ in that file, and it causes problems when
using llist_head entry macros in future patches adding initial support
for multiple BTS in PCU object, so let's move it to plain C.
Change-Id: Ic771a89fd78b5e66151a5384f0ff6a8895589466
Those files are not really being used other than for calling
get_current_fn() which is just a placeholder to call
bts_current_frame_number on the global bts object.
Change-Id: I6d50a8c15c1de5e2a308a24b313a7776f94ae54f
The bts_init/cleanup functions were kept during the C and C++ structure
merge process to make the patch simpler. It's not needed anymore,
let's move all the destructor logic into one function and keep that
together.
Change-Id: I73a9457d5c92f62261561ef6afe392953576aec4
Before, we used tho have a BTs object split into 2 parts, a C
gprs_rlcmac_bts struct and a C++ BTS struct, and "bts_data" naming was
used to distinguish them in variable names. Nowadays the struct is
finally combined into one, so there's no point in using this "bts_data"
terminology, we use always "bts".
Change-Id: I9852bf439292d1abc70711bea65698b21bde0ee8
There's no BTS single global object anymore, get rid of those APIs. Move
users to use "pcu->bts", which will evolve to a linked list in the
future.
Change-Id: I9cf762b0d3cb9e2cc3582727e07fa82c8e183ec5
Previous work on BTS class started to get stuff out of the C++ struct
into a C struct (BTS -> struct gprs_glcmac_bts) so that some parts of
it were accessible from C code. Doing so, however, ended up being messy
too, since all code needs to be switching from one object to another,
which actually refer to the same logical component.
Let's instead rejoin the structures and make sure the struct is
accessible and usable from both C and C++ code by rewriting all methods
to be C compatible and converting 3 allocated suboject as pointers.
This way BTS can internally still use those C++ objects while providing
a clean APi to both C and C++ code.
Change-Id: I7d12c896c5ded659ca9d3bff4cf3a3fc857db9dd
Both values (optionally) set (forced) by VTY and the values received
from PCUIF were stored in the same variable, meaning that for instance
the PCUIF values wouldn't really be used if someone applied eg "no cs"
during runtime.
This commit does something similar to what was already done for the
max_(m)cs fields. We store PCUIF values in one place and VTY ones in
another place, and then trigger a bts object internal process to find
out exactly which initial CS should it be using.
Change-Id: I80a6ba401f9c0c85bdf6e0cc99a9d2008d31e1b0
Currently the BTS object (and gprs_rlcmac_bts struct) are used to hold
both PCU global fields and BTS specific fields, all mangled together.
The BTS is even accessed in lots of places by means of a singleton.
This patch introduces a new struct gprs_pcu object aimed at holding all
global state, and several fields are already moved from BTS to it. The
new object can be accessed as global variable "the_pcu", reusing and
including an already exisitng "the_pcu" global variable only used for
bssgp related purposes so far.
This is only a first step towards having a complete split global pcu and
BTS, some fields are still kept in BTS and will be moved over follow-up
smaller patches in the future (since this patch is already quite big).
So far, the code still only supports one BTS, which can be accessed
using the_pcu->bts. In the future that field will be replaced with a
list, and the BTS singletons will be removed.
The cur_fn output changes in TbfTest are actually a side effect fix,
since the singleton main_bts() now points internally to the_pcu->bts,
hence the same we allocate and assign in the test. Beforehand, "the_bts"
was allocated in the stack while main_bts() still returned an unrelated
singleton BTS object instance.
Related: OS#4935
Change-Id: I88e3c6471b80245ce3798223f1a61190f14aa840
When allocating multiple slots for a UE the following example
is not allowed 'UU----UU' for a UE class 12.
The time slot number can not roll over 7 and move to 0.
44.060 or 45.002 only specifies contigous however it was unclear
it this is an allowed pattern.
Only the example 45.002 B.3 in release 12 cleared this up.
It gives an example for a multi slot class 5 UE which has 7 possible
configuration this means the rolled over is not allowed.
Multislot class type 2 UE doesn't have this limitation.
Further if a UE supports 8 time slots this is not a limitation because
the window size (45.002 B.1) can include all time slots.
Releated: SYS#5073
Change-Id: I16019bdbe741b37b83b62749b840a3b7f4ddc6c7
Under some platforms (RPI4, ARM) container older ASan, it will log false
positive log errors which will make unit test fail because then output
changes:
"""
pcu_l1_if.cpp:847:2: runtime error: member access within misaligned address 0xb3f0b78c for type 'struct GprsMs', which requires 8 byte alignment
"""
The pointer is indeed misaligned, but it's not actually a bug, because
the pointer is never derreferenced. That happens during
llist_for_each_entry operation where it does cast the pointer but it
only checks if the list has actually reached the end.
To workaround the issue, simply defer casting it by using llist_for_each
instead, where the pointer is assigned only in the case it really points
to a GprsMS struct.
Change-Id: I149fb42706501eb33f9c6fe48f76a03ddee5954a
Unfortunately, RACH.ind on the PCU interface contains no Uplink
measurements: neiter RSSI nor C/I. In order to avoid sending
garbage, let's zero-initialize 'struct pcu_l1_meas'.
Change-Id: I8c3210c428da17d23d798f3ef9df941ded6e162a
Fixes: CID#216512
Let's use usual osmocom rate_ctr instead of having one variable +
setter/getter functions, so we can easily add new counters and also
because it makes code more clear (no need to look at what the "update"
function is doing).
Using rate counter also provides info about how recently the MS has been
interacting with the network.
Related: OS#4907
Change-Id: I744507fde4291955c1dbbb9739b18a12a80145b1
It is expected that the tbf object is freed at any moment in time, for
instance if osmo-pcu drops PCUIF connection with osmo-bts. I couldn't
find any reason why it would e dangerous to free the tbf, so let's
remove this message.
related: OS#4779
Change-Id: I4ab5ccaa5bf6257b18d8fd5ba06baab083821817
This ensures spec compliance, because currently the base class
destructor would be called through a base class pointer to derived
class instead of the most derived one, which ist unexpected and actually
undefined behavior in c++11 and beyond.
Change-Id: Ic4abde1658a983bb0ccf9a526177dce50ff6dc23
There is a big difference between:
if ((a = foo() != 0xffffffff)) { ... }
and
if ((a = foo()) != 0xffffffff) { ... }
In the first case, 'a' is the result of '!=' operation, i.e. either
0 (false) or 1 (true). In the second case, 'a' will hold the value
returned by foo(), and this is exactly what must have been used in
gprs_rlcmac_rcv_rts_block().
The bug was there since SBA allocation feature was added in 2012.
Change-Id: Ifd607ae8a33382e48f9d9e50a28a4bdf4eaf73a2
Fixes: 07e97cf8a5
Related: CID#215835
As we integrate osmo-pcu more and more with libosmocore features, it
becomes really hard to use them since libosmocore relies heavily on C
specific compilation features, which are not available in old C++
compilers (such as designated initializers for complex types in FSMs).
GprsMs is right now a quite simple object since initial design of
osmo-pcu made it optional and most of the logic was placed and stored
duplicated in TBF objects. However, that's changing as we introduce more
features, with the GprsMS class getting more weight. Hence, let's move
it now to be a C struct in order to be able to easily use libosmocore
features there, such as FSMs.
Some helper classes which GprsMs uses are also mostly move to C since
they are mostly structs with methods, so there's no point in having
duplicated APIs for C++ and C for such simple cases.
For some more complex classes, like (ul_,dl_)tbf, C API bindings are
added where needed so that GprsMs can use functionalitites from that
class. Most of those APIs can be kept afterwards and drop the C++ ones
since they provide no benefit in general.
Change-Id: I0b50e3367aaad9dcada76da97b438e452c8b230c
The resulting code is cleaner since it becomes clear the relation
between all those pointers, which are set in one function and used in
another one, passed through the caller of the former two.
Moreover, if more tbf candidates are to be added for other type of
actions, having them in a struct is much easier since only one pointer
is passed.
Change-Id: I55482aa5af7be5a176a7b4879a672ad37e618020
NS2 introduce a ns dialect to differentiate
between the 4 possible dialects.
Related: OS#4472, OS#4890
Depends: libosmocore.git Ia118bb6f994845d84db09de7a94856f5ca573404
Change-Id: I16dc82c38eb75c2b9d1197640a955fec7df84efc
According to:
* 3GPP TS 44.060 version 16.0.0 "9.3.1a Delayed release of downlink Temporary Block Flow"
* 3GPP TS 44.064 version 16.0.0 "6.4.2.2 Unconfirmed Information (UI) Dummy command"
LLC UI Dummy frames are to be used when there no more data to send, only
in order to delay the release of a TBF. Hence, while not incorrect per
se, makes no sense to send those LLC UI Dummy frames inserted into
rlcmac blocks which already contain other LLC frames, since the MS in
that case is already being kept active.
It only makes sense to send those LLC UI Dummy frames when we have
nothing else to send, that is, alone inside a RLCMAC block without other
LLC frames.
Related: OS#4849
Change-Id: Ifae1a7b2b3dfad8df19585063088ba0df2749c8f
Pau Espin
Harald Welte
Alexander Couzens
Vadim Yanitskiy
Philipp Maier
Eric Wild