Project

General

Profile

Bug #1610

RF channel release skipping T3109

Added by laforge over 2 years ago. Updated about 1 month ago.

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

100%

Estimated time:
Spec Reference:

Description

                /* GSM 04.08 gives us two options for the abnormal
                 * chanel release. This can be either like in the non-existent
                 * sub-lcuase 3.5.1 or for the main signalling link deactivate
                 * the SACCH, start timer T3109 and consider the channel as
                 * released.
                 *
                 * This code is doing the later for all raido links and not
                 * only the main link. Right now all SAPIs are released on the
                 * local end, the SACCH will be de-activated and right now the
                 * T3111 will be started. First T3109 should be started and then
                 * the T3111.

Related issues

Related to OpenBSC - Bug #49: T3109 not implementedClosed

Related to OpenBSC - Bug #50: Abnormal channel release handling is wrongClosed

Related to OpenBSC - Bug #2380: logical channels can get stuck if BTS sends no RELEASE INDICATION for SACCH / T3109 can be disabledClosed2017-07-19

Related to OsmoBSC - Bug #2734: RF channel teradown timers (T3109) way too largeClosed2017-12-10

History

#1 Updated by laforge almost 2 years ago

  • Related to Bug #49: T3109 not implemented added

#2 Updated by laforge over 1 year ago

  • Assignee set to dexter
  • Priority changed from Normal to Low

#3 Updated by laforge about 1 year ago

  • Related to Bug #50: Abnormal channel release handling is wrong added

#4 Updated by laforge about 1 year ago

  • Related to Bug #2380: logical channels can get stuck if BTS sends no RELEASE INDICATION for SACCH / T3109 can be disabled added

#5 Updated by laforge 10 months ago

  • Related to Bug #2734: RF channel teradown timers (T3109) way too large added

#6 Updated by laforge 10 months ago

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

#7 Updated by laforge 10 months ago

  • Category set to A-bis RSL

#8 Updated by laforge 3 months ago

  • Assignee changed from dexter to neels
  • Priority changed from Low to Normal

I would suspect this is resolved with the lchan fsm?

#9 Updated by neels 3 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90

the lchan_fsm.c I have T3109 and T3111 in

        [LCHAN_ST_WAIT_SAPIS_RELEASED]  = { .T=3109 },
        [LCHAN_ST_WAIT_BEFORE_RF_RELEASE]       = { .T=3111 },
        [LCHAN_ST_WAIT_RF_RELEASE_ACK]  = { .T=3111 },
        [LCHAN_ST_WAIT_AFTER_ERROR]     = { .T=993111 },

with

        { .T=3109, .default_val=5, .desc="RSL SACCH deactivation" },
        { .T=3111, .default_val=2, .desc="Wait time before RSL RF Channel Release" },
        { .T=993111, .default_val=4, .desc="Wait time after lchan was released in error" 
                "(should be T3111 + 2s)" },

Actually I also use T3109 during normal channel release, when we sent RSL Release for the SAPIs to wait for the RLL Release CNF messages.

So, yes, T3109 is definitely implemented and there is no way around it with the lchan_fsm.c.

#10 Updated by neels about 1 month ago

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

merged.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)