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
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
This counter is only used in DL TBFs as per TS 44.060.
section 13.4 "N3105":
"When the network after sending a RRBP field in the _downlink RLC data block_ ..."
(DL data blocks are only sent in DL TBFs).
section 8.1.2.1:
"If N3105 = N3105max, the network shall release the downlink TBF internally
and start timer T3195 for that TBF. When T3195 expires, the network may reuse
the TFI"
Change-Id: I4d4f4d4d3e6e0539ea8ec2395bed00d059b84e04
N3103 counts retransmits of PACKET UPLINK ACK/NACK with FinalACK=1. As a
consequence, this counter only applies to UL TBFs.
Current code is only using it in UL TBF, but add an assert to clarify
and make sure it is not used unproperly in the future.
Change-Id: I026d6145249ef19694f673ec7b4928af9d401dd6
TS 44.060 13.4 "N3101" clearly states this counter relates to UL TBFs,
since it only applies to TBFs for which USFs are set:
"When the network after setting USF for a given TBF, receives a valid data block of this TBF from
the mobile station in a block assigned for this USF, it will reset
counter N3101. If PS Handover is not ongoing, the network will increment counter N3101 for each
USF for which no data is received for this TBF."
Furthermore, N3101 must only be reset for data blocks, so drop all rx
CTRL block patches on UL TBF resetting the counter.
Change-Id: I207f3906d13fc6feea2282e261f468a09db37d86
While at it, fix a typo in the test output.
This function is nowadays only used in ms_current_pacch_slots(), which
is used only to print the PACCH TS (the first common UL & DL TS).
Change-Id: Id1d0b681f6866618f9f3a8c64d6a6c809ca50ea7
The cast for different types it's not really needed, simply use the
unsigned long long version to make sure we don't drop 1s, in any case
__builtin_popcountll() will be quicker than what we used to have.
Change-Id: I80ae72d34d53564fc3da1601ee48c8b2ffe79735
That case should only happen under really rare conditions, like
receiving a RACH.ind before having received any DATA.ind.
Change-Id: I4c71f3481764b501a4441bc735a87725884a3e75
The FN time counter is not really PDCH specific, but to the whole BTS,
and all other calls t the bts_set_current_frame_number() are already
laced in pcu_l1_if.cpp; move it there.
Change-Id: If36f22a1067c904fa7fda87bed5062b6738f0dd1
Those function don't really require the full FN, hence let's pass only
the required information.
This makes the implementation here less dependent on how/if we are able to calculate
full FNs based on RFN: We get an RFN, and we have to encode so that the RFN can be
derived again, so feels less cumbersome having to go through RFN->FN->RFN which may
only cause possible issues if there's some FN timing bug.
3GPP TS 44.018 10.5.2.30 Request Reference:
"The purpose of the Request Reference information element is to provide the random
access information used in the channel request and the frame number, FN modulo 42432"
3GPP TS 44.018 10.5.2.38 Starting Time:
"The purpose of the Starting Time information element is to provide the start TDMA
frame number, FN modulo 42432."
Change-Id: If9b758434c00f2a3868534d5be84946809c989a9
RFN_MODULUS (42432) used to calculate is a multiple of 416:
416 * 102 = 42432
Hence, (X % 42432) % 416 == X % 416.
So, there's no need to derive the full FN.
Change-Id: If7a6a15c373a068bcc757d27937dd6eeac2e0bae
This may happen if a RACH.ind is received before any DATA.ind has been
received.
With usual osmo-bts-trx or osmo-bts-sysmo, this shouldn't happen
nowadays, but it is still a problem with osmo-bts-virtual, where lower
layers don't submit NOPE.ind in the absence of data, and hence it won't
sent DATA.ind to osmo-pcu all the time.
This change helps in showcasing confusing scenarios where the RFN
generated in the Imm Ass was wrong.
Change-Id: I29b7ba828fe890f90e35686bbb04d4abfe56b955
The previous code was really confusing, passing full FNs as RFNs under
certain external conditions, and then assuming the RFN input of
rfn_to_fn() function could actually be a FN.
As a result, we had a lot of code behaving slightly different depending
on whether the incomding FN from pcuif was filled in by a BSC or a BTS.
Avoid this b ehavior differentiation and always assume the most
restricted one, aka RFN.
Change-Id: Ib3b5702168195b595711cd0ff32c211b9aba429d
Change format to print the state at the end, to resemble more the same
format used by FSMs.
Furthermore, by moving it at the end, print it only when "enclousure" is
requested, aka when not requested by FSM to update its internal name.
The consequence of this logc is that log lines printed from FSM don't
end up with the same state string printed twice in different places.
While at it, shorten the EGPRS/GPRS indicator to one character, which
should be understandable enough since it matches what's usually seen in
mobile phones to signal one or another.
Change-Id: I86b5f042fae77721b22fc026228677bd56768ba9
In the current code we still send PAGING COMMAND MAC blocks via SAPI
PCU_IF_SAPI_PCH, which technically belongs to the older PCUIF version
(v.10), which we are going to deprecate soon.
Let's change this so that PAGING COMMAND MAC blocks will also be sent
through PCU_IF_SAPI_PCH_DT. Since PAGING COMMAND messages require no
confirmation by the receiving end we may set the TLLI field to
GSM_RESERVED_TMSI.
Depends: osmo-bsc.git I82443f2b402aa2416469c8c50b1c050323ef3b8f
Related: OS#5927
Change-Id: I99cfe373fa157cfb32b74c113ad9935347653a71
we have defined IMSI_DIGITS_FOR_PAGING but some parts of the code still
use magic numbers (3), let's replace those as well.
Change-Id: I9a1b6ba4578e2a8875d8d1a9e56c36dc2b33fe0d
The functions l1if_open_pdch and l1if_close_pdch have a misleading
naming since what they actually do is opening and closing the TRX since
they return and accept a context (obj) that is valid for a whole TRX.
This also explains why the other functions accept a timeslot as
parameter in addition to the context. Let's rename those functions so
that it is clear what they do.
Related: OS#6022
Change-Id: I395a60b2fba39bac4facec78989bac20f0cef0d3
At the moment only allocate one CCU descriptor and use it as context for
the whole TRX. This is fine when running with one PDCH only but as soon
as multiple PDCHs are used the CCU descriptor gets messed up. Let's fix
this by introducing a TRX descriptor that contains an array of 8 CCU
descriptors, one for each timeslot.
Related: OS#6022
Change-Id: I09a51f34ce0edef79a797c4686c7b1d27c376e49
Pau Espin
Philipp Maier
Oliver Smith
Vadim Yanitskiy
Max