Project

General

Profile

Actions

Bug #5227

open

osmo-pcu: Attempt recovery of TBF when one of its assigned PDCH TS becomes disabled

Added by pespin over 2 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
-
Start date:
09/03/2021
Due date:
% Done:

0%

Spec Reference:

Description

Currently, when a PDCH TS becomes disabled (eg: dynamic TS is required for a voice call), we are currently freeing immediately all existing TBFs which were attached to that TBF.

This looks really rude and simple way to overcome the scenario. By doing so, it means all ongoing TBFs cease to transmit or receive data, hence breaking all connections and keeping them broken for a while.
Even worse: The MS with active TBF will stay listening on that TS and trying to decode whatever is sent to another MS (be it TCH, SDCCH, etc.).

Hence, we should try to find a way to attempt some sort of recovery for as many MS as possible, by telling the MS that PDCH is no longer available and it shouldn't listen on it. Even better, we should try to relocate the MS to a potential better set of PDCH TS.

That probably involves sending some RLCMAC DL Control Block to the MS. Hence, we should check during pdch disable:
  • If MS has only 1 PDCH TS assigned and it's the one we are disabling, we can do nothing, keep the tbf_free().
  • If MS has more than 1 PDCH TS assigned and the PDCH being disabled is its control_ts, change the control_ts to another PDCH TS.
  • Internally mark to avoid RX/TX on the PDCH being disabled, and do all the process to change the active PDCH set.

Related code in osmo-pcu which may be of interest:

gprs_rlcmac_pdch::disable()
  gprs_rlcmac_pdch::free_resources()
    pdch_free_all_tbf()
       tbf_free()

handle_timeout_X2002()
  tbf_assign_control_ts()
  tbf_update()
    gprs_rlcmac_tbf::update()
  tbf_dl_trigger_ass()

tbf_assign_control_ts()

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)