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 about 1 year ago. Updated 12 months 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 #1

Updated by pespin 12 months ago

TS 44.060 8.1.1 Uplink RLC data block transfer:

The network may, at any time during uplink packet transfer, change the TTI configuration or USF mode (BTTI USF 
mode or RTTI USF mode) as well as the corresponding downlink PDCH-pairs of an already established uplink TBF by 
sending on the downlink PACCH, an uplink TBF assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION). The mobile station shall begin using the new parameters 
within the reaction time defined in 3GPP TS 45.010.

8.1.1.1.2 Resource Reallocation for Uplink:

The network may at any time during uplink packet transfer initiate a change of resources by sending on the downlink 
PACCH monitored by the MS, an unsolicited uplink assignment message (e.g. PACKET UPLINK ASSIGNMENT, 
MULTIPLE TBF UPLINK ASSIGNMENT, PACKET TIMESLOT RECONFIGURE, MULTIPLE TBF TIMESLOT 
RECONFIGURE or PACKET CS RELEASE INDICATION message) to the mobile station. During the reallocation, 
TFI is allowed to be changed. A mobile station that supports multiple TBF procedures shall act on the uplink 
assignment message as defined in sub-clause 8.1.2.5.

Check whole section "8.1.1.3a.5 Resource Reallocation for Uplink" and "8.1.2.4 Resource Reassignment for Downlink".

Also, have a look at message "PACKET TIMESLOT RECONFIGURE" and "PACKET CS RELEASE INDICATION"

We should at least notify the related MS that the TBF is freed, see "8.1.1.4 Network initiated release of uplink TBF":

The network may initiate release of an uplink TBF by transmitting a PACKET TBF RELEASE message to the mobile 
station on the PACCH.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)