Change in osmo-pcu[master]: tbf_fsm: Handle MAX_N3105 in state ASSIGN

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

pespin gerrit-no-reply at lists.osmocom.org
Wed Oct 13 03:45:19 UTC 2021


pespin has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-pcu/+/25769 )


Change subject: tbf_fsm: Handle MAX_N3105 in state ASSIGN
......................................................................

tbf_fsm: Handle MAX_N3105 in state ASSIGN

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
---
M src/tbf_fsm.c
1 file changed, 6 insertions(+), 1 deletion(-)



  git pull ssh://gerrit.osmocom.org:29418/osmo-pcu refs/changes/69/25769/1

diff --git a/src/tbf_fsm.c b/src/tbf_fsm.c
index d1d4668..84d5bcc 100644
--- a/src/tbf_fsm.c
+++ b/src/tbf_fsm.c
@@ -188,6 +188,10 @@
 		/* change state to FLOW, so scheduler will start transmission */
 		tbf_fsm_state_chg(fi, TBF_ST_FLOW);
 		break;
+	case TBF_EV_MAX_N3105:
+		ctx->T_release = 3195;
+		tbf_fsm_state_chg(fi, TBF_ST_RELEASING);
+		break;
 	default:
 		OSMO_ASSERT(0);
 	}
@@ -409,7 +413,8 @@
 			X(TBF_EV_ASSIGN_ADD_PACCH) |
 			X(TBF_EV_ASSIGN_ACK_PACCH) |
 			X(TBF_EV_ASSIGN_PCUIF_CNF) |
-			X(TBF_EV_ASSIGN_READY_CCCH),
+			X(TBF_EV_ASSIGN_READY_CCCH) |
+			X(TBF_EV_MAX_N3105),
 		.out_state_mask =
 			X(TBF_ST_FLOW) |
 			X(TBF_ST_FINISHED) |

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-pcu/+/25769
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-pcu
Gerrit-Branch: master
Gerrit-Change-Id: I86d5c1bbccd06673d08451b812d149e727404733
Gerrit-Change-Number: 25769
Gerrit-PatchSet: 1
Gerrit-Owner: pespin <pespin at sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: dexter <pmaier at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20211013/ba55d4e2/attachment.htm>


More information about the gerrit-log mailing list