| commit | 677bebbe5c49d4607322e96053fe14ddd78d9549 | [log] [tgz] |
|---|---|---|
| author | Pau Espin Pedrol <pespin@sysmocom.de> | Mon Oct 31 13:56:33 2022 +0100 |
| committer | Pau Espin Pedrol <pespin@sysmocom.de> | Mon Oct 31 22:07:31 2022 +0100 |
| tree | cea8a4949c504c3081c8d1105d9a52aff567fb9e | |
| parent | 338a5ae770892d10817270b9358467212505ec53 [diff] |
Avoid losing DL-TBF during MS merge It is desired to free pending DL-TBF under some scenarios, which somehow are related to those where we call the ms_merge() procedure since it's at time an MS can be identified when coming from packet-idle state. Until now, the freeing of those DL-TBFs happen because the ms_merge() procedure doesn't migrate DL-TBF from "old_ms" to "ms". This was done manually under the cases where it was deemed necessary before calling the ms_merge() procedure 8because old_ms and its tbfs are gone after returning from it). This logic, though convinient for the specific cases at hand, is quite confusing for readers and program execution since one would expect the ms merge to, well, merge everything. Therefore, this patch changes the ms_merge() logic to always merge the DL-TBF, and only under the specific cases where it makes sense to free it, do so explicitly after MS merge, where all the info has been updated and united. 2 code paths are now explicitly freeing the existing DL-TBF when needed: - TBF_EV_FIRST_UL_DATA_RECVD: 1st data (containing TLLI) is received from MS, hence identifyng the MS and potentially having been merged with some old MS which used to have a DL-TBF, most probably in process of being assigned through CCCH (PCH). This event is triggered during MS using 1phase-access, and we should drop the exsitng DL-TBF because MS just came from packet-idle mode (CCCH). - rcv_resource_request(): PktResourceRequest is received at an scheduled SBA, meaning the MS is doing 2phase-access, meaning MS also came from packet-idle mode (CCCH), so previous DL-TBF can be dropped. Related: OS#5700 Change-Id: I29f4ffa904d79d58275c6596cc5ef6790b6e68c6
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 https://gitea.osmocom.org/cellular-infrastructure/osmo-pcu
There is a web interface at https://gitea.osmocom.org/cellular-infrastructure/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