Project

General

Profile

Actions

Feature #1902

open

unify/refactor dynamic timeslot code

Added by neels over 7 years ago. Updated over 4 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
01/05/2017
Due date:
% Done:

0%

Spec Reference:

Description

The two kinds of dynamic timeslots could use the same data structures.

The IPAC style TCH/F_PDCH was implemented first, using ts->flags.
The Osmo style TCH/F_TCH/H_PDCH needed more detailed state, so ts->dyn was added.

The TCH/F_PDCH could also use ts->dyn.

Also, we had neverending bugs of places that forgot to check for dyn ts.
The code would be less fragile if we kept the actual current mode the
timeslot is in in the actual ts->pchan field, where all the code expects it.
Currently we keep "TCH_F_TCH_H_PDCH" in pchan and store the current real
mode in dyn->pchan_is. So all code needs to be aware of dynamic channels
and has to add checks to find out the current mode.

I assume it would be nicer if the fact that a channel is dynamic is kept
in ts->dyn, and the ts->pchan can be evaluated like with static channels.
ts->pchan should probably also reflect switchover as an invalid pchan.
This way all code can just directly use ts->pchan, and the places that
are concerned with switchover can look it up in ts->dyn.*.


Related issues

Related to OsmoBTS - Bug #3131: dynamic timeslots not tested by BTS_Tests.ttcnResolvedlaforge04/04/2018

Actions
Related to OsmoBSC - Bug #3099: dynamic timeslots not tested by BSC_Tests.ttcnResolvedlaforge03/22/2018

Actions
Actions #1

Updated by neels over 7 years ago

  • Description updated (diff)
  • Priority changed from Normal to Low

(accidentally hit enter when there was no description yet, adding description now)

Actions #2

Updated by neels over 7 years ago

  • Assignee set to 118
Actions #3

Updated by laforge over 6 years ago

  • Project changed from OpenBSC to OsmoBSC
Actions #4

Updated by laforge over 6 years ago

  • Assignee changed from 118 to 4368
  • Priority changed from Low to Normal

I think this should be done together with the introduction of osmo_fsm for handling a lchan, i.e. one FSM per lchan whihc then tracks all of it's activation/deactivation state.

Actions #5

Updated by laforge about 6 years ago

  • Related to Bug #3131: dynamic timeslots not tested by BTS_Tests.ttcn added
Actions #6

Updated by laforge about 6 years ago

  • Related to Bug #3099: dynamic timeslots not tested by BSC_Tests.ttcn added
Actions #7

Updated by laforge about 6 years ago

I think this should wait until we have proper test cases, e.g. #3099

Actions #8

Updated by laforge about 6 years ago

  • Category set to A-bis RSL
Actions #9

Updated by neels over 5 years ago

  • Status changed from New to Resolved

In the course introducing the new timeslot FSM in osmo-bsc, the dynamic timeslot handling has been overhauled, and both dyn ts kinds now use the same data structures, namely

  • ts.pchan_from_config = vty config setting,
  • .pchan_on_init = same as pchan_from_config but is not affected by telnet vty changes, and
  • .pchan_is = the current actual pchan.
  • For static timeslots, pchan_is = pchan_on_init,
  • for dynamic ones,
    • pchan_on_init = {TCH_F_TCH_H_PDCH, TCH_F_PDCH}
    • pchan_is = {TCH_F, TCH_H, PDCH, NONE}

However, the osmo-bts code base still employs the old separate data structures to track the dynamic timeslot status.

Actions #10

Updated by neels over 5 years ago

  • Project changed from OsmoBSC to OsmoBTS
  • Category deleted (A-bis RSL)
  • Status changed from Resolved to New

ok, let me just re-open this in the OsmoBTS project, then.

Actions #11

Updated by laforge almost 5 years ago

  • Priority changed from Normal to Low
Actions #12

Updated by laforge over 4 years ago

  • Assignee deleted (4368)
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)