Bug #1796
closedPTCCH activation breaks dyn TS
0%
Description
As discussed in https://gerrit.osmocom.org/#/c/671/ activating PTCCH causes error which breaks dynamic channels.
I've tested it with sysmoBTS and the reason seems to be "double activation" of channels which works for PDTCH but fails 2nd time for PTCCH - see below.
<0006> oml.c:511 activating (bts=0,trx=0,ts=0,ss=0) pchan=CCCH+SDCCH4 ts_connect_as(CCCH+SDCCH4) logChComb=ccch_sdcch4
<0006> oml.c:808 Successful activation of L1 SAPI FCCH on TS 0
<0006> oml.c:808 Successful activation of L1 SAPI SCH on TS 0
<0006> oml.c:808 Successful activation of L1 SAPI BCCH on TS 0
<0006> oml.c:808 Successful activation of L1 SAPI AGCH on TS 0
<0006> oml.c:808 Successful activation of L1 SAPI PCH on TS 0
<0006> oml.c:808 Successful activation of L1 SAPI RACH on TS 0
<0006> oml.c:511 activating (bts=0,trx=0,ts=1,ss=0) pchan=SDCCH8 ts_connect_as(SDCCH8) logChComb=sdcch8
<0006> oml.c:511 activating (bts=0,trx=0,ts=2,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:511 activating (bts=0,trx=0,ts=3,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:511 activating (bts=0,trx=0,ts=4,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:511 activating (bts=0,trx=0,ts=5,ss=0) pchan=TCH/F ts_connect_as(TCH/F) logChComb=tch_f
<0006> oml.c:511 activating (bts=0,trx=0,ts=6,ss=0) pchan=TCH/F ts_connect_as(TCH/F) logChComb=tch_f
<0006> oml.c:511 activating (bts=0,trx=0,ts=7,ss=0) pchan=PDCH ts_connect_as(PDCH) logChComb=pdtch
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 2
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 3
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 2
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 4
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 3
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 2
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 4
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 3
<0006> oml.c:808 Successful activation of L1 SAPI PDTCH on TS 7
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 2
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 4
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 3
<0006> oml.c:808 Successful activation of L1 SAPI PTCCH on TS 7
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 2: Invalid parameter
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 4
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 3: Invalid parameter
<0006> oml.c:808 Successful activation of L1 SAPI PRACH on TS 7
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 4: Invalid parameter
<0006> oml.c:813 Error activating L1 SAPI PTCCH on TS 7: Invalid parameter
Related issues
Updated by msuraev over 7 years ago
- Related to Feature #1545: continuous timing advance loop using PTCCH added
Updated by neels over 7 years ago
This error is due to osmo-bts commit 53d792c3b027bfb42d77804e3e687a287e122ef3
"Activate PTCCH UL"
the reason seems to be "double activation"
This is no double activation: the first is PTCCH DL, the second is PTCCH UL.
Let's have a look at the struct in form of the actual commit diff:
diff --git a/src/osmo-bts-sysmo/oml.c b/src/osmo-bts-sysmo/oml.c index 585e6d0..e9a4794 100644 --- a/src/osmo-bts-sysmo/oml.c +++ b/src/osmo-bts-sysmo/oml.c @@ -617,8 +617,9 @@ static const struct sapi_dir pdtch_sapis[] = { { GsmL1_Sapi_Pdtch, GsmL1_Dir_RxUplink }, { GsmL1_Sapi_Ptcch, GsmL1_Dir_TxDownlink }, { GsmL1_Sapi_Prach, GsmL1_Dir_RxUplink }, -#if 0 { GsmL1_Sapi_Ptcch, GsmL1_Dir_RxUplink }, + /* FIXME: do we still need this if? */ +#if 0 { GsmL1_Sapi_Pacch, GsmL1_Dir_TxDownlink }, #endif };
So Ptcch TxDownlink was present before and is working well,
while the patch adds Ptcch RxUplink which consistently fails to work.
Since this failure to activate PTCCH UL on PDCH TS has a side effect of breaking
the operation of dynamic timeslots, I have a strong opinion towards reverting
this commit right now, and coming back with a properly tested patch later.
My opinion is also well fed with detail in the gerrit patch review discussion of
https://gerrit.osmocom.org/671.
- The commit is immature (all it does is add an error message, and it also is
implemented only for sysmobts while lc15 would "need" the same change as well) - The commit introduces a regression
- The commit has no benefit
I would appreciate anyone else seeing the sanity of my request to revert this now ;)
Updated by neels over 7 years ago
- Related to Feature #1776: Implement fully dynamic TCH/F + TCH/H + PDCH switching added
Updated by neels over 7 years ago
- Related to Feature #1565: Dynamic PDCH / TCH switching: BTS part added
Updated by msuraev over 7 years ago
- Related to deleted (Feature #1545: continuous timing advance loop using PTCCH)
Updated by msuraev over 7 years ago
- Blocks Feature #1545: continuous timing advance loop using PTCCH added
Updated by neels over 7 years ago
- Status changed from New to Resolved
The patch that broke dyn TS has been reverted in osmo-bts 55c46022e1a5f1cbe51c96566e38ff110e4a3092.
This issue seems to be only about the dyn TS breakage, not PTCCH UL per se, so closing this.
Updated by fixeria almost 4 years ago
- Related to Bug #4500: osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH timeslots added