This way PCU always answers DATA.ind and the BTS can still clearly
identify idle frames. It also simplifies testing and verification of
correct behavior.
Related: SYS#4919
Change-Id: Ife718eeed2af011479c03099ea109518f04567bc
This function is expected to be used only on DL TBF so far, so let's
really assert to avoid going through if something is wrong and ending up
later with other issues.
Change-Id: If398ee48364fce5b5e38830b2b278b3bad9a48a2
Code above setting the timer in same tbf_fsm already has this kind of
assert, but it helps understanding the code having this assert here.
Change-Id: I7588deef5073694eb5fecdb516c241a04594e2b0
In that function, previous PDCHs are unlinked and then alloc_algorithm
is expected to assign new TFIs.
Change-Id: I7bcbb223ca32400bede7ab638695ba3c015c9946
Off the top of my head: The tbf_ was kept during a previous refactoring
a while ago to avoid changing lots of more lines in the same patch.
Change-Id: I8ae689a272b7c4d244576ff157f6019a87041abc
TSC is not really a property of a TBF, so let's drop it in order to avoid
confusing and possible misuse of that accessor.
Change-Id: I105eb65d507e45631faddb23420c42bc9560e580
There's no real need to pass a tlli per separate, the information is
already contained in the MS. Furthermore, when doing so, it becomes
clear the TLLI was only passed to set it again on the MS, so actually
that ms_update() can be totally dropped since it will act as a no-op.
Change-Id: Ie761c3c7c222458ab0514117ae637ad3267139a0
The situation holds true as long as the assignment is resolved. Hence,
it can also happen that the TBF is in RELEASE state, because it was
unable to do the assignment (and after retrying, MAX_N3105 moved it into
RELEASING).
Let's not explicitly check states, the other conditions should be
enough.
Related: SYS#5647
Change-Id: I05fb0ea44aeb3fbda9e8e1c449e9366efaa2c511
It doesn't make sense to keep asking the scheduler to retransmit Pkt Ul
Ass if the tbf_fsm already decided we are going to release the TBF.
It can be seen in following log extract:
"""
tbf_ul_ass_fsm.c:112 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) start Packet Uplink Assignment (PACCH)
tbf_ul_ass_fsm.c:131 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) Scheduled UL Assignment polling on PACCH (FN=612941, TS=7)
tbf_ul_ass_fsm.c:188 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: state_chg to WAIT_ACK
pdch_ul_controller.c:330 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=612937, reason=DL_ASS): TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS)
tbf.cpp:550 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) poll timeout for FN=612937, TS=7 (curr FN 612937)
tbf.cpp:392 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=ASSIGN EGPRS) N3105 exceeded MAX (8)
tbf.cpp:602 TBF(UL-TFI_1)[7bd530]{ASSIGN}: Received Event MAX_N3105
tbf_fsm.c:194 TBF(UL-TFI_1)[7bd530]{ASSIGN}: state_chg to RELEASING
pdch_ul_controller.c:330 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=612941, reason=UL_ASS): TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS)
tbf.cpp:550 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) poll timeout for FN=612941, TS=7 (curr FN 612941)
tbf.cpp:589 UL_ASS_TBF(UL-TFI_1)[849e50]{WAIT_ACK}: Received Event ASS_POLL_TIMEOUT
tbf_ul_ass_fsm.c:224 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) Timeout for polling PACKET CONTROL ACK for PACKET UPLINK ASSIGNMENT: |Assignment was on PACCH|No uplink data received yet|
tbf_ul_ass_fsm.c:226 UL_ASS_TBF(UL-TFI_1)[849e50]{WAIT_ACK}: state_chg to SEND_ASS
tbf_ul_ass_fsm.c:308 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: Received Event CREATE_RLCMAC_MSG
tbf_ul_ass_fsm.c:112 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) start Packet Uplink Assignment (PACCH)
tbf_ul_ass_fsm.c:131 TBF(TFI=1 TLLI=0xe1c12303 DIR=UL STATE=RELEASING EGPRS) Scheduled UL Assignment polling on PACCH (FN=612976, TS=7)
tbf_ul_ass_fsm.c:188 UL_ASS_TBF(UL-TFI_1)[849e50]{SEND_ASS}: state_chg to WAIT_ACK
"""
Change-Id: I94243ff99dfaf3664a1a4b3c4c87b5104ba4f7d1
When MS sends us the Packet Resource Request as RRBP from final UL ACK/NACK, we create a new TBF
with a different set of allocated TS. However, we must send the Pkt UL Assignment with information
of the new TBF using that same TS where we receive the Packet Resource Request, which happens to
be the control TS of the previous/old TBF. The original control TS of the new TBF is kept in
tbf->first_common_ts.
Hence the code does gprs_rlcmac_pdch::rcv_resource_request():
"""
ul_tbf->control_ts = ts_no;
"""
And later, when we receive a CTRL ACK answering the Pkt UL Assigment, we change the control TS of
the new TBF back to the new one, by calling tbf_assign_control_ts(), which basically does:
"""
tbf->control_ts = tbf->first_common_ts;
"""
So, for instance we have a TBF which was allocated with tbf->control_ts=4 and hence is only attached
to PDCH 4 (tbf->pdch[]), but for which is temporarily applied tbf->control_ts=7. Hence, when a poll
is requested, it is done in control_ts, aka 7, which is not in the array of attached PDCH.
The problem is of course if we never reach the point where the final control_ts is set, due to never
receiving the CTRL ACK. If the TBF is freed (due to timer X2001) before receiving the CTRL ACK and
hence tbf_assign_control_ts() is called, a crash may occur, because potentially a poll for the TBF is
left in TS 7 because it's not a PDCH attached to the TBF and hence poll
entries on that TS are not released, hence keeping a pointer to the
freed TBF.
Related: SYS#5647
Change-Id: I0c49f2695e0d932d956c01976c9458eebee63cd4
Seen on a runnig osmo-pcu against real MS:
"""
pdch_ul_controller.c:329 PDCH(bts=0,trx=1,ts=7) Timeout for registered POLL (FN=751140): TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS)
tbf.cpp:542 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) poll timeout for FN=751140, TS=7 (curr FN 751140)
tbf.cpp:384 TBF(TFI=0 TLLI=0xe8c12143 DIR=UL STATE=ASSIGN EGPRS) N3105 exceeded MAX (8)
tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Received Event MAX_N3105
tbf.cpp:594 TBF(UL-TFI_0)[9bc050]{ASSIGN}: Event MAX_N3105 not permitted
"""
It was first though when FSMs where introduced that an FSM in ASSIGN
state could not receive this kind of event because it was believed to be
sending no CTRL blocks at all until flow state. That's because the
believe was that Assignment over PACCH was done by another existing TBF.
It turns out this is usually the case, but not in all cases. In at least
one case, the tbf object (and tbf_fsm/tbf_{ul,dl}_ass_fsm) itself is
handling its own assignment (hence eg. sending the UL assignment and waiting
response through tbf_ul_ass_fsm. This happens if a UL TBF sends a Pkt
Resource Req as a response to RRBP of final UL ACK/NACK in order to
request a new TBF, where it temporarily uses the control_ts of the
previous TBF to get a new Pkt UL Assignment over PACCH.
If Pkt Ul Assignment doesn't receive a CTRL ACK, tbf_ul_ass_fsm will
retrnamist it, until MAX_N3015 is reached (the event we failed to
handle until now). At this point, we really want to transition to
RELEASING in order to avoid keeping the TBF allocating resources (until
X2001 times out).
Related: SYS#5647
Change-Id: I86d5c1bbccd06673d08451b812d149e727404733
Move the required conditions to generate a message to the rts()
function, this way the scheduler knows this TBF cannot yet attempt the
procedure and hence will not request it to create a message which will
fail.
This way the scheduler will schedule other itneresting messages instead
of failing and scheduling a dummy block as a result.
Change-Id: Idbe4f9bbd23005a43c586b737cf9adc2114287e2
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
Let's only release PDCH ULC entry if it was indeed what we expected.
In other case, time it out.
Move the case in the switch statement to the start to easy function
readibility (early return style).
Change-Id: I3d8749acca8e7859295d73cce556b2083169f726
If we didn't expect this kind of UL messages according to pdch ULC, then
we shouldn't allow going forward and releasing the ULC entry: let it
time out instead so that TBF runs whatever appopiate action is needed in
this case, be it retransamission, releasing itself, etc.
Change-Id: I8ab3f5e4f2f802944269453db13a80c9ede67714
If it doesn't match out expectancies, it means we early return and hence
don't push forward / update whatever state was requested upon receival
of the UL message for the expected TBF. Hence, we shall not remove the
allocated ULC entry: in this scenario we need to keep it so that timeout
procedure times out and the tbf applies whatever measures are required,
be it retransmission, releasing itself, etc.
Change-Id: Ia69a7d92c4b5c98ec71a75605c8dc3a755e63a35
Fixes following error log line:
"{RELEASING}: Event DL_ACKNACK_MISS not permitted"
Rationale: We may move to RELEASING state at some point, for instance
due to MAX_N3101/MAX_N3105 while still having some active poll
registered in some PDCH ulc. Upon that poll (most probably) timing out,
it will send a DL_ACKNACK_MISS event to us. Since we are already
determined to release the TBF (waiting for T3195 or T3169 to trigger),
simply ignore the event and avoid logging an error.
Fixes: OS#5240
Change-Id: Ibfb49356d2b3b5fccb6d59db8593b2256e5c51fb
This clarifies the different paths and uniforms them. Makes code far
easier to read and debug.
New improved verification already found some misehavior in some tests.
Change-Id: I7e4a88d6e004bbb7974595320ed73742162c7ad7
Move FSM internal state checks to its own file. Re-use the helper
function in the 2 places where same stuff is checked.
Change-Id: I9ded6e1c80e6cd7bcf6883bc2e853b6dafb33f7c
As seen operating PCU after BTS restart, lots of following message
sequences due to FSM kept in same state (hence scheduler retyring every
time):
"""
DTBF tbf_ul_ass_fsm.c:306 UL_ASS_TBF(DL-TFI_0){SEND_ASS}: Received Event CREATE_RLCMAC_MSG
DTBF tbf_ul_ass_fsm.c:95 TBF(TFI=0 TLLI=0xf80bd801 DIR=DL STATE=RELEASING EGPRS) We have a schedule for uplink assignment, but there is no uplink TBF
DTBF tbf_ul_ass_fsm.c:97 UL_ASS_TBF(DL-TFI_0){SEND_ASS}: transition to state NONE not permitted!
DTBF tbf_ul_ass_fsm.c:306 UL_ASS_TBF(DL-TFI_0){SEND_ASS}: Received Event CREATE_RLCMAC_MSG
"""
Change-Id: I91d74f70a9106ccbf0c137b6e713877f9ea8f59d
Make use of the separate GPRS counters added in previous patch
I0c0a1121b4ae5f031782e7e63a0c28eb0b6c8b42 to shorten
has_gprs_only_tb_attached.
Related: SYS#4878
Change-Id: I1dd7df2c740ea604f07c65bebcb7c0051aebf9ae
Same was already done for PDTCH in previous commits. Let's now apply
same bits to PTCCH.
Related: SYS#4919
Change-Id: If6617964e67fc35eeee1791b06e13bf63ac88f73
We also want to avoid sending idle blocs in TRX0 to the BTS, so that the
BTS can be aware of blocks being idle and then submitting dummy blokcs
by itself applying required BCCH Carrier power reduction.
Related: SYS#4919
Change-Id: Idd58d2a09c3947098b960cfcb5cd1b7b7bca3d84
Add stats needed for performance measurements in
3GPP TS 52.402 § B.2.1.54-55.
Split m_num_tbfs to count GPRS and EGPRS TBFs separately. Move the code
that updates m_num_tbfs and sets the PDCH_OCCUPIED stats to a separate
function, as it's mostly the same in the TBF attach and detach.
Related: SYS#4878
Change-Id: I0c0a1121b4ae5f031782e7e63a0c28eb0b6c8b42
We already have a similar function for Neighbor Address Resolution.
This way we keep as much as possible internal state related logic into
the nacc_fsm.c file.
Change-Id: I7378939825cc3ec3280f76bc51233c0a172d8a27
While NACC was initially developed, it became clear there was need for
a way to interact PCU<->BSC in order resolve ARFCN+BSIC into CGI-PS
for later RIM usage.
Hence, this resolution was first (until today) implemented using an out
of bands RPC system using the CTRL interface, which required specific
config to be written and matches in osmo-pcu and osmo-bsc VTY (ip+port
of the CTRL interface to use).
However, this has several shortcomings:
* As explained above, specific configuration is required
* Since recently, we do support BSC redundancy in osmo-bts. Hence the BTS
may switch to a BSC other than first one. If that happened, that'd mean
the CTRL interface would still point to the initially configured one,
which may not be the same currently serving the PCU.
During recent development of ANR related features, a similar need for
PCU<->BSC was required, but this time it was decided to extend the IPA
multiplex of the Abis OML connection to pass PCUIF messages,
transparently forwarded to each side by the BTS.
This has the advantage that connection PCU<->BTS is handled by BTS and
both sides send messages transparently.
Let's switch by default to using this new interface, while still
maintaing the old way for a while (announcing them as deprecated) to
avoid breaking existing deployments until they are upgraded to new
versions of osmo-pcu and osmo-bsc.
Related: SYS#4971
Change-Id: I6ad33c7ab10202840cf804dea9ba595978d0e920
Count available PDCHs (3GPP TS 52.402 § B.2.1.38) as well as occupied
PDCHs (§ B.2.1.42-44).
Related: SYS#4878
Change-Id: I74760a68ee055510a79e80854ec7bf1521669119
When a PDCH TS becomes disabled (eg due to dyn TS being used for a
call), we are currently freeing all attached PDCHs in order to avoid
further use of it. However, pdch_free_all_tbf() was only freeing TBFs
attached to the PDCH, that is, TBFs having a valid TFI assigned.
There are some cases where temporary dummy TBFs are created which have
no TFI assigned, such as when creating an ImmAssReject. Let's take those
into account too, and make sure they are freed.
Related: OS#5226
Change-Id: Ibfe78448ebdedc8b049c80664711e166d910f9b7
These messages are expected under some circumstances, such as when
direct phy is used and a chan is disabled (eg. dyn TS). This happens
because PCU asks for chan de-activation through PCUIF while at the same
time marking the PDCH locally as disabled. Hence, in the time the BTS
manages to disable it on the lower layers, the phy still sends us
RTS indications.
Let's keep it under NOTICE to avoid clogging the logs in production
setups which are usually using global level of NOTICE or ERROR.
Related: OS#5222
Change-Id: Iab9e1590b504bf05dc693e27550b30db0dffcbc7