| commit | 85aa87b61ff36eb297bd3b3d5936d7270f30476c | [log] [tgz] |
|---|---|---|
| author | Pau Espin Pedrol <pespin@sysmocom.de> | Tue Oct 12 14:02:52 2021 +0200 |
| committer | Pau Espin Pedrol <pespin@sysmocom.de> | Tue Oct 12 18:57:44 2021 +0200 |
| tree | 49f026faee763e19c655f92ecc63c17ee85e6348 | |
| parent | 27a4e7371cc0cf4ed2796f7b59336b2bbf40b171 [diff] |
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
This repository contains a C/C++-language implementation of a GPRS Packet Control Unit, as specified by ETSI/3GPP. It is part of the Osmocom Open Source Mobile Communications project.
The Packet Control Unit is terminating the Layer 2 (RLC/MAC) of the GPRS radio interface and adapting it to the Gb Interface (BSSGP+NS Protocol) towards the SGSN.
The PCU interfaces with the physical layer of the radio interface. OsmoPCU is typically used co-located with the BTS, specifically OsmoBTS. For legacy BTSs that run proprietary sotware without an interface to OsmoPCU, you may also co-locate it with the BSC, specifically OsmoBSC
The official homepage of the project is https://osmocom.org/projects/osmopcu/wiki/OsmoPCU
You can clone from the official osmo-pcu.git repository using
git clone git://git.osmocom.org/osmo-pcu.git
There is a cgit interface at http://git.osmocom.org/osmo-pcu/
We provide a user manual as well as a vty reference manual
Please note that a lot of the PCU configuration actually happens inside the BSC, which passes this configuration via A-bis OML to the BTS, which then in turn passes it via the PCU socket into OsmoPCU.
Discussions related to osmo-pcu are happening on the osmocom-net-gprs@lists.osmocom.org mailing list, please see https://lists.osmocom.org/mailman/listinfo/osmocom-net-gprs for subscription options and the list archive.
Please observe the Osmocom Mailing List Rules when posting.
Our coding standards are described at https://osmocom.org/projects/cellular-infrastructure/wiki/Coding_standards
We us a gerrit based patch submission/review process for managing contributions. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for more details
The current patch queue for osmo-pcu can be seen at https://gerrit.osmocom.org/#/q/project:osmo-pcu+status:open