https://osmocom.org/https://osmocom.org/favicon.ico?16647414092016-10-11T10:00:17ZOpen Source Mobile CommunicationsOsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=21982016-10-11T10:00:17Zlaforge
<ul><li><strong>Assignee</strong> set to <i>msuraev</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=22272016-10-12T15:49:07Zmsuraev
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>Should I implement static or dynamic variant? What should happen if new value for "channel-descrption bs-ag-blks-res" is entered in OpenBSC vty?</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=22322016-10-12T16:05:16Zmsuraev
<ul></ul><p>Static variant sent for review as gerrit #1047. Not strictly speaking required, but handy for debugging is extended logging from gerrit #1043.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=22612016-10-17T14:47:09Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>20</i></li></ul><p>Preliminary variant sent for review in gerrit #1099. Missing bits:<br />- it's unclear how/if octphy support different number of AGCH (equivalent of lch_par->agch.u8NbrOfAgch)<br />- it's unclear if/how we have to activate/deactivate lchan for osmo-trx (equivalent of sapi_deactivate_cb())</p>
<p>Current implementation is somewhat ugly because we 1st unconditionally activate CCCH before knowing SI3 with proper number of AGCH. When we finally receive AGCH value from SI3 we deactivate channel and than activate it again. osmo-bts-trx seems to be different in this regard - maybe we do not have to use reactivation hack in there. Also, once this early auto-activation hack is removed we can streamline this code.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=23542016-11-08T17:37:23Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=25152016-12-01T17:16:20Zmsuraev
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>50</i></li></ul><p>Support for lc15 and sysmo has been merged.<br />Octphy: waiting for vendor response.<br />Osmo-trx: waiting for vendor response.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=33742017-03-14T14:23:40Zlaforge
<ul></ul><p>I guess you need to follow-up with Octphy and Osmo-TRX folks regularly to make sure this doesn't stay stalled forever.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=43652017-06-27T13:22:59Zmsuraev
<ul></ul><p>Related gerrit 3067 has been sent for review.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=45632017-07-15T10:42:20Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/2366">Feature #2366</a>: OsmoBTS lacks EXTENDED BCCH support</i> added</li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=52402017-08-29T15:24:53Zlaforge
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul><p>patches in gerrit under review, not stalled.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=53042017-09-04T16:10:31Zmsuraev
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>support in osmo-bts-litecell15</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>support in osmo-bts-octphy</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>support in osmo-bts-sysmo</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>support in osmo-bts-trx</i> added</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' disabled> <i>support in osmo-bts-virtual</i> added</li><li><strong>% Done</strong> changed from <i>50</i> to <i>60</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=54522017-09-22T10:51:42Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p>The octphy support requires vendor cooperation.<br />The virtphy support is planned. Might make sense to add corresponding TTCN-3 test if time permits.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=57542017-10-11T08:32:04Zlaforge
<ul><li><b>Checklist item</b> deleted (<strike><i>support in osmo-bts-octphy</i></strike>)</li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>High</i></li></ul><p>please add it to -virtual and extend the TTCN-3 test to cover it.</p>
<p>I've dropped the OCTPHY topic. I presume you had inquired them regarding this at the time you were working on the code? If not, please make sure they are aware we're waiting for them to add support to the PHY.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=57662017-10-11T11:59:12Zmsuraev
<ul></ul><blockquote>
<p>I presume you had inquired them regarding this at the time you were working on the code?</p>
</blockquote>
<p>Yes, twice actually. Although it's been a while ago so I'm pretty sure they forgot about it by now. Dexter, can you please ping them again? The question is basically "how do we instruct octphy l1 that it should use X AGCH channels (as in 3GPP TS 45.002 ยง3.3.2.3 a)BS_AG_BLKS_RES)?" or "is that supported by some fw version already?".</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=57692017-10-11T13:34:50Zdexter
<ul></ul><p>I wrote Jason an email, maybe he can give us more information about this or even point us to the right places in the documentaion/header files.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=59142017-10-23T21:00:02Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-2 priority-default closed" href="/issues/1611">Feature #1611</a>: be more efficient in batching IMMEDIATE ASSIGN REJECT messages</i> added</li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=64802017-12-03T09:57:37Zlaforge
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>support in osmo-bts-octphy</i> added</li><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul><p>Regarding Octphy: The response was that there is no different L1 SAPI between AGCH and PCH, so we don't ned to inform/instruct the PHY about where higher layers put the split.</p>
<p>Instead, both AGCH and PCH are leading to PH-RTS.ind of type cOCTVC1_GSM_SAPI_ENUM_PCH_AGCH. AFAICT, in osmo-bts-octphy/l1_if.c:chan_nr_by_sapi() we map this to cbits=0x12 which is "Downlink CCCH (AGCH/PCH)". So it "should simply work".</p>
<p>I've pushed a change Ic1038b8dc57bdaf05493cd8479355b960275ea41 that simply removes the related warning, see <a class="external" href="https://gerrit.osmocom.org/5148">https://gerrit.osmocom.org/5148</a></p>
<p>osmo-bts-virtual (and related test case) thus remains the only open tasks here. Please get that done.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=67582017-12-11T14:56:44Zmsuraev
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=79532018-03-01T23:14:00Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>msuraev</i> to <i>4368</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=102402018-07-04T13:07:51Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>dexter</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=109952018-08-27T15:32:21Zdexter
<ul></ul><p>I have figured out how the paging and access grant channels should be laid out. I hope my understanding is correct here:</p>
<pre>
=====================================================
== TDMA frame mapping for FCCH + SCH + BCCH + CCCH ==
=====================================================
F = FCCH
H = SCH
B = BCCH
C = CCCH
D = SDCCH
S = SACCH
I = Idle
A = AGCH
P = PCH
1 2 3 4 5
012345678901234567890123456789012345678901234567890
v v v
FHBBBBCCCCFHCCCCCCCCFHCCCCCCCCFHCCCCCCCCFHCCCCCCCCI
0000 11112222 33334444 55556666 77778888 (B0 ... B8)
PPPP PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 0
AAAA PPPPPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 1
AAAA AAAAPPPP PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 2
AAAA AAAAAAAA PPPPPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 3
AAAA AAAAAAAA AAAAPPPP PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 4
AAAA AAAAAAAA AAAAAAAA PPPPPPPP PPPPPPPP BS_AG_BLKS_RES = 5
AAAA AAAAAAAA AAAAAAAA AAAAPPPP PPPPPPPP BS_AG_BLKS_RES = 6
AAAA AAAAAAAA AAAAAAAA AAAAAAAA PPPPPPPP BS_AG_BLKS_RES = 7
=======================================================================================
== TDMA frame mapping for FCCH + SCH + BCCH + CCCH + SDCCH/4(0...3) + SACCH/4(0...3) ==
=======================================================================================
F = FCCH
H = SCH
B = BCCH
C = CCCH
D = SDCCH
S = SACCH
I = Idle
A = AGCH
P = PCH
1 2 3 4 5 6 7 8 9 0
012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901
v v v v v v v
FHBBBBCCCCFHCCCCCCCCFHDDDDDDDDFHDDDDDDDDFHDDDDDDDDIFHBBBBCCCCFHCCCCCCCCFHDDDDDDDDFHDDDDDDDDFHDDDDDDDDI
0000 11112222 0000 11112222 (B0 ... B2)
PPPP PPPPPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 0
AAAA PPPPPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 1
AAAA AAAAPPPP PPPP PPPPPPPP BS_AG_BLKS_RES = 2
Example #1:
FN: MOD102: BLOCK:
165 63 B1
216 12 B1
220 16 B2
267 63 B1
271 67 B2
318 12 B1
322 16 B2
369 63 B1
372 66 B2
420 12 B1
424 16 B2
==> B0 is never used for paging ==> BS_AG_BLKS_RES = 1
Example #2:
FN: MOD102: BLOCK:
573 63 B1
577 67 B2
624 12 B1
628 16 B2
675 63 B1
679 67 B2
726 12 B1
730 16 B2
777 63 B1
828 12 B1
832 16 B2
==> B0 is never used for paging ==> BS_AG_BLKS_RES = 1
</pre>
<p>I did an experiment. I have set BS_AG_BLKS_RES = 2 via the osmo-bsc VTY and ran BTS_Tests.TC_paging_imsi_200percent. The result looks like BS_AG_BLKS_RES = 1, so there is indeed something wrong here.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=110842018-08-30T14:41:00Zdexter
<ul></ul><p>At least for the osmo-bts-trx/faketrx/trxcon case I can say that it works now. The reason why it did not work last time is that the setting for bs_ag_blks_res is quite confusing. It is not set via OML, so setting it via osmo-bsc.cfg does not change anything. The parameter must be changed in BTS_tests.ttcn as well at two places (for the test and for the SI3). Once this is changed correctly osmo-bts receives the parameter correctly and behaves accordingly.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=110852018-08-30T14:42:33Zdexter
<ul></ul><p>For the ttcn3 test I have simplified the things a bit: <a class="external" href="https://gerrit.osmocom.org/10707">https://gerrit.osmocom.org/10707</a></p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=110892018-08-31T10:12:40Zdexter
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>80</i></li></ul><p>I have added now a unit-test. We see the expected behavior for all possible bs_ag_blks_res settings, which is very good.</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bts/+/10724">https://gerrit.osmocom.org/#/c/osmo-bts/+/10724</a> paging: add unit-test to check different bs_ag_blks_res settings</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=110902018-08-31T13:32:09Zdexter
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>support in osmo-bts-virtual</i> set to Done</li><li><strong>% Done</strong> changed from <i>80</i> to <i>100</i></li></ul><p>I have also checked the support for osmo-bts-virtual with an experiment. I have set different values for bs_ag_blks_res, started osmo-bts-virtual and observed the frame number of the emitted GSMTAP frames. The frame numbers of the paging channel (dummy pagings) all fell into the correct range. I have tested with bs_ag_blks_res=1 and bs_ag_blks_res=2.</p>
<p>Since the decision when to send pagings to the phy is made in l1sap.c:l1sap_ph_rts_ind() it is common code we can be very sure that the behavior of osmo-bts-virtual will not be different from other BTS. So I think we can conclude that bs_ag_blks_res is correctly handled in osmo-bts-virtual.</p>
<p>To increase the test coverage a bit I have added a check to BTS_Tests.ttcn that checks if the pagings on L1CTL actually fall into the PCH and not in the AGCH or even BCCH. We currently only check with bs_ag_blks_res=1. See also:</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10726">https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/10726</a> BTS_Tests: check paging channel fn (bs_ag_blks_res)</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=110922018-08-31T16:04:01Zdexter
<ul><li><strong>% Done</strong> changed from <i>100</i> to <i>90</i></li></ul><p>While osmo-bts-trx seems to work just fine inside the TTCN3 tests we still have problems. When I set</p>
<pre>
bts 1
channel-descrption bs-ag-blks-res 2
</pre>
<p>The phone does not register anymore. So I think we have another problem that is related to bs-ag-blks-res. Here is a sample from the log:</p>
<pre>
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802121/1359/09/36/33 Too many contiguous elapsed fn, dropping 297
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802142/1359/04/06/02 Too many contiguous elapsed fn, dropping 49
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802144/1359/06/08/04 Too many contiguous elapsed fn, dropping 420
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802175/1359/11/39/35 Too many contiguous elapsed fn, dropping 31
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802205/1359/15/18/13 Too many contiguous elapsed fn, dropping 596
Fri Aug 31 17:43:58 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message.
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802207/1359/17/20/15 Too many contiguous elapsed fn, dropping 32
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802225/1359/09/38/33 Too many contiguous elapsed fn, dropping 584
Fri Aug 31 17:43:58 2018 <0007> scheduler.c:877 1802285/1359/17/47/45 Too many contiguous elapsed fn, dropping 143
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802337/1359/17/48/45 Too many contiguous elapsed fn, dropping 130
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802339/1359/19/50/47 Too many contiguous elapsed fn, dropping 984
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802352/1359/06/12/08 Too many contiguous elapsed fn, dropping 231
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802426/1359/02/35/30 Too many contiguous elapsed fn, dropping 74
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802446/1359/22/04/50 Too many contiguous elapsed fn, dropping 447
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802460/1359/10/18/12 Too many contiguous elapsed fn, dropping 255
Fri Aug 31 17:43:59 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message.
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802533/1359/05/40/37 Too many contiguous elapsed fn, dropping 87
Fri Aug 31 17:43:59 2018 <0007> scheduler.c:877 1802535/1359/07/42/39 Too many contiguous elapsed fn, dropping 109
Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802621/1359/15/26/21 Too many contiguous elapsed fn, dropping 747
Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802655/1359/23/09/03 Too many contiguous elapsed fn, dropping 195
Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802712/1359/02/15/08 Too many contiguous elapsed fn, dropping 57
Fri Aug 31 17:44:00 2018 <0000> rsl.c:2672 (bts=0,trx=0,ts=0,ss=4)(NONE) is not active . Dropping message.
Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802744/1359/08/47/40 Too many contiguous elapsed fn, dropping 459
Fri Aug 31 17:44:00 2018 <0007> scheduler.c:877 1802748/1359/12/00/44 Too many contiguous elapsed fn, dropping 411
Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802787/1359/25/39/35 Too many contiguous elapsed fn, dropping 75
Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802828/1359/14/29/24 Too many contiguous elapsed fn, dropping 80
Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802902/1359/10/01/46 Too many contiguous elapsed fn, dropping 677
Fri Aug 31 17:44:01 2018 <0007> scheduler.c:877 1802938/1359/20/37/30 Too many contiguous elapsed fn, dropping 194
</pre>
<p>I run the following channel combinations:</p>
<pre>
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 0
timeslot 2
</pre>
<p>bs-ag-blks-res = 2 should be a legal setting, even if I would only use CCCH+SDCCH4 with no SDCCH8. I have tested on a sysmobts as well, there it worked, but the image on that BTS is not very recent.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=124172018-10-29T13:28:43Zdexter
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=158142019-09-04T09:15:29Zlaforge
<ul><li><strong>Assignee</strong> deleted (<del><i>dexter</i></del>)</li><li><strong>Priority</strong> changed from <i>High</i> to <i>Normal</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=226432021-10-06T16:18:39Zpespin
<ul></ul><p>This should be fixable now that we have proper OMl NM FSMs in osmo-bts. AFAIu we can then get rid of LCHAN_REL_ACT_REACT.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=226442021-10-06T16:22:48Zpespin
<ul><li><strong>Assignee</strong> set to <i>pespin</i></li></ul> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=277962023-09-06T16:02:19Zpespin
<ul></ul><p>I confirm changing "channel-descrption bs-ag-blks-res 1" to "channel-descrption bs-ag-blks-res 2" for a BTS in osmo-bsc makes phones unable to see the network.</p>
<p>Tested with current osmo-bts-trx + osmo-pcu + osmo-trx master, Using only CCCH+SDCCH4 on TS0, no SDCCH8.</p>
<p>SI3 properly announces "BS_AG_BLKS_RES: 2". <br /><pre>
Control Channel Description
1... .... = MSCR: MSC is Release '99 onwards (1)
.1.. .... = ATT: MSs in the cell shall apply IMSI attach and detach procedure (1)
..01 0... = BS_AG_BLKS_RES: 2
.... .001 = CCCH-CONF: 1 basic physical channel used for CCCH, combined with SDCCHs (1)
.00. .... = CBQ3: Iu mode not supported (0)
.... .101 = BS-PA-MFRMS: 5
T3212: 5
</pre></p>
<p>According to bootstrap_bts(), using 2 is allowed with CCCH+SDCH4:<br /><pre>
/* Limit reserved block to 2 on combined channel according to
3GPP TS 44.018 Table 10.5.2.11.1 */
if (bts->si_common.chan_desc.bs_ag_blks_res > 2) {
LOGP(DNM, LOGL_NOTICE, "CCCH is combined with SDCCHs, "
"reducing BS-AG-BLKS-RES value %d -> 2\n",
bts->si_common.chan_desc.bs_ag_blks_res);
bts->si_common.chan_desc.bs_ag_blks_res = 2;
}
</pre></p>
<p>However, after the OML bringup happens, when using AG_BLKS_RES=2 it seems the BTs is not transmitting on BCCH (no SIs show in GSMTAP). So presumably something ends up wrong at osmo-bts during setup.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=277972023-09-06T16:28:59Zpespin
<ul></ul><p>The "bs_ag_blks_res" received from BSc in osmo-bts is basically only accessed through API "num_agch()".</p>
<p>In rsl_rx_bcch_info() (src(common/rsl.c), some logic seems to do stuff differently based on whether num_agch() returns != -1:<br /><pre>
case SYSINFO_TYPE_3:
if (trx->nr == 0 && num_agch(trx, "RSL") != 1) {
lchan_deactivate(&trx->bts->c0->ts[0].lchan[CCCH_LCHAN]);
/* will be reactivated by sapi_deactivate_cb() */
trx->bts->c0->ts[0].lchan[CCCH_LCHAN].rel_act_kind =
LCHAN_REL_ACT_REACT;
}
</pre></p>
<p>This seems to have some relation with <a class="user active" href="https://osmocom.org/users/119">msuraev</a> comment (<a class="external" href="https://osmocom.org/issues/1575?issue_count=102&issue_position=95&next_issue_id=1573&prev_issue_id=1576#note-4">https://osmocom.org/issues/1575?issue_count=102&issue_position=95&next_issue_id=1573&prev_issue_id=1576#note-4</a>) from 7 years ago, and my enigmatic comment from 2 years ago I cannot decode nowadays ;) (<a class="external" href="https://osmocom.org/issues/1575?issue_count=102&issue_position=95&next_issue_id=1573&prev_issue_id=1576#note-29">https://osmocom.org/issues/1575?issue_count=102&issue_position=95&next_issue_id=1573&prev_issue_id=1576#note-29</a>)</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=277982023-09-06T16:42:46Zpespin
<ul></ul><p>In src/osmo-bts-trx/l1_if.c we seem to be missing some part of the implementation according to this comment:<br /><pre>
int bts_model_lchan_deactivate(struct gsm_lchan *lchan)
{
if (lchan->rel_act_kind == LCHAN_REL_ACT_REACT) {
lchan->rel_act_kind = LCHAN_REL_ACT_RSL;
/* FIXME: perform whatever is needed (if any) to set proper PCH/AGCH allocation according to
3GPP TS 44.018 Table 10.5.2.11.1 using num_agch(lchan->ts->trx, "TRX L1"); function */
return 0;
}
/* set lchan inactive */
lchan_set_state(lchan, LCHAN_S_NONE);
return trx_sched_set_lchan(lchan, gsm_lchan2chan_nr(lchan), LID_DEDIC, false);
}
</pre></p>
<p>Again, related to LCHAN_REL_ACT_REACT.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=277992023-09-06T16:57:15Zpespin
<ul></ul><p>Also related. include/osmo-bts/lchan.h:<br /><pre>
LCHAN_REL_ACT_REACT, /* FIXME: remove once auto-activation hack is removed from opstart_compl() (OS#1575) */
</pre></p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278012023-09-06T17:04:02Zpespin
<ul></ul><p>If we send AG_BLKS_RES=2, the path mentioned above in rsl.c is entered (<code>if (trx->nr == 0 && num_agch(trx, "RSL") != 1) {</code>), and CCCH_LCHAN is deactivated.</p>
<p>sysmo, lc15 and oc2g seem to have a hack in opstart_compl() to re-enable it, but osmo-bts-trx DOES NOT HAVE IT:<br /><pre>
static int opstart_compl(struct gsm_abis_mo *mo, struct msgb *l1_msg)
{
...
switch (mo->obj_class) {
...
case NM_OC_CHANNEL:
/* ugly hack to auto-activate all SAPIs for the BCCH/CCCH on TS0 */
if (mo->obj_inst.trx_nr == 0 &&
mo->obj_inst.ts_nr == 0) {
struct gsm_lchan *cbch = gsm_bts_get_cbch(mo->bts);
DEBUGP(DL1C, "====> trying to activate lchans of BCCH\n");
mo->bts->c0->ts[0].lchan[CCCH_LCHAN].rel_act_kind =
LCHAN_REL_ACT_OML;
lchan_activate(&mo->bts->c0->ts[0].lchan[CCCH_LCHAN]);
if (cbch) {
cbch->rel_act_kind = LCHAN_REL_ACT_OML;
lchan_activate(cbch);
}
}
</pre></p>
<p>So all this needs to be cleaned up somehow.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278132023-09-07T15:20:10Zpespin
<ul></ul><p>At the BSC, BCCH_INFO is sent only normally during RSL bootstrap of the TRX:<br /><pre>
bootstrap_rsl
gsm_bts_trx_set_system_infos
rsl_si
rsl_sacch_filling
rsl_bcch_info
</pre></p>
<p>It can also be triggered more time through: ACC (ramping/subset), CTRL ("send-new-system-informations"), VTY ("bts <0-255> resend-system-information")<br /><pre>
gsm_bts_set_system_infos
gsm_bts_trx_set_system_infos
</pre></p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278142023-09-07T16:01:53Zpespin
<ul></ul><p>The process for sysmo,oc2g,clc15 goes like this:<br /><pre>
rsl_rx_bcch_info
lchan_deactivate(&trx->bts->c0->ts[0].lchan[CCCH_LCHAN]);
bts_model_lchan_deactivate
lchan_set_state(lchan, LCHAN_S_REL_REQ);
enqueue_rel_marker(lchan);
queue_sapi_command(SAPI_CMD_REL_MARKER)
sapi_queue_exeute(SAPI_CMD_REL_MARKER) // Around here this happens async..
lchan_deactivate_sapis
check_sapi_release
enqueue_sapi_deact_cmd
sapi_deactivate_cb
/* Reactivate CCCH due to SI3 update in RSL */
if (lchan->rel_act_kind == LCHAN_REL_ACT_REACT) {
lchan->rel_act_kind = LCHAN_REL_ACT_RSL;
lchan_activate(lchan);
}
trx->bts->c0->ts[0].lchan[CCCH_LCHAN].rel_act_kind = LCHAN_REL_ACT_REACT;
</pre></p>
<p>Please notice how that due the fact that the entire deep code stack happens asynchronously, "rel_act_kind = LCHAN_REL_ACT_REACT" is applied before sapi_deactivate_cb() is called despite being afterwards in the caller code path.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278152023-09-07T16:20:13Zpespin
<ul></ul><p>Initial fix here:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34340">https://gerrit.osmocom.org/c/osmo-bts/+/34340</a> bts-trx: Fix CCCH not enabled if BS_AG_BLKS_RES!=1 is provided by BSC</p>
<p>However, the logic "if (trx->nr == 0 && num_agch(trx, "RSL") != 1) {" in rsl.c rsl_rx_bcch_info() still looks wrong.</p>
<p>One should really not check if "num_agch(trx, "RSL") != 1", but if the value from previous SI3 and new SI3 actually changed.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278172023-09-07T16:43:52Zpespin
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>Feedback</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34341">https://gerrit.osmocom.org/c/osmo-bts/+/34341</a> rsl: Improve logic reactivating CCCH upon SI3 BS_AG_BLKS_RES change</p>
<p>I think it would still be nice to maybe keep TS0 (NMChannel-0-0-0) as NM state "Disabled Dependency" until initial BCCH_INFO SI3 (or all required ones?) are received on the RSL link from the BSC. Only then transition to "Disabled Off-line" and let the BSC OPSTART the channel.</p> OsmoBTS - Bug #1575: Correctly handle BS_AG_BLKS_RES (AGCH/PCH split in DL CCCH)https://osmocom.org/issues/1575?journal_id=278732023-09-15T10:49:02Zpespin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>I decided to leave it as is it for now, it's fine enough.</p>