Project

General

Profile

Actions

Bug #1841

closed

Dynamic PDCH / TCH switching assumes RSL link is up

Added by laforge over 7 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
A-bis RSL
Target version:
-
Start date:
11/16/2016
Due date:
% Done:

100%

Spec Reference:

Description

It seems the existing code has the assumption that the RSL link is up at the time the OML MO for the timeslot is enabled.

This might be the case, but might also not be the case.

Also, the RSL link might get lost and get re-established. In that case, all ts/lchan are again in intial state and the PDCH will need to be activated. This should be fairly simple to simulate with dropping the RSL link from either BTS or BSC point of view.

From my point of view, it might make sense to have an (explicit or implicit) FSM with time-outs. So whenver a dynamic timeslot is currently not used for TCH but the PDCH is not active either, we should re-attempt to activate the PDCH after some time out, again and again.

In the Ericsson case, also if the PCU looses sync with the CCU, the BTS releases the PDCH timeslot/lchan after some time with an error - similar to the case where no TRAU/RTP connection can be established for voice on a voice channel. For that reason, too, the PDCH will need to be periodically re-activated if for some reason it gets deactivated.

Furthermore, in the abis/ip case, the RSL CHAN ACT (PDCH) seems to be sent before the OPSTART of the TS is acknowledged by the BTS.


Related issues

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

what scale of timeout would make sense for PDCH reactivation? Is 10 seconds too frequent?

Actions #2

Updated by laforge over 7 years ago

On Thu, Nov 24, 2016 at 04:07:54PM +0000, neels [REDMINE] wrote:

what scale of timeout would make sense for PDCH reactivation? Is 10 seconds too frequent?

I think it would be OK, but 30s or 60s would be equally fine.

Actions #3

Updated by laforge over 6 years ago

  • Project changed from OpenBSC to OsmoBSC
  • Category deleted (libbsc)
Actions #4

Updated by laforge almost 6 years ago

This should be tested for in #3099 to better reproduce the situation and then fix it.

Actions #5

Updated by laforge almost 6 years ago

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

Updated by laforge almost 6 years ago

  • Category set to A-bis RSL
Actions #7

Updated by laforge almost 6 years ago

  • Status changed from New to In Progress
  • Assignee changed from neels to laforge
  • % Done changed from 0 to 10
Actions #8

Updated by laforge almost 6 years ago

  • % Done changed from 10 to 80
Actions #9

Updated by laforge almost 6 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

patch merged

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)