https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-05-12T13:25:44ZOpen Source Mobile CommunicationsOsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=182942020-05-12T13:25:44Zpespin
<ul></ul><a name="3GPP-TS-1221-V800-OML"></a>
<h1 >3GPP TS 12.21 V8.0.0 (OML)<a href="#3GPP-TS-1221-V800-OML" class="wiki-anchor">¶</a></h1>
<p>8.6.2 Set Radio Carrier Attribute -> contains ARFCN list (param info forwarded to TS 05.05)<br />8.6.3 Set Channel Attributes -> contains HSN + MAIO + ARFCN list (param info forwarded to TS 05.02)</p>
<a name="3GPP-TS-0502-V8110"></a>
<h2 >3GPP TS 05.02 V8.11.0<a href="#3GPP-TS-0502-V8110" class="wiki-anchor">¶</a></h2>
<p>Most related required information can be found in this document.</p>
<a name="54-Radio-frequency-channel-sequence"></a>
<h2 >5.4 Radio frequency channel sequence<a href="#54-Radio-frequency-channel-sequence" class="wiki-anchor">¶</a></h2>
<pre>
The radio frequency channel sequence is determined by a function that, in a given cell, with a given set of general
parameters, (see subclause 5.6.2), with a given timeslot number (TN), a given mobile radio frequency channel
allocation (MA) and a given mobile allocation index offset (MAIO), maps the TDMA frame number (FN) to a radio
frequency channel.
In a given cell there is therefore, for a physical channel assigned to a particular mobile, a unique correspondence
between radio frequency channel and TDMA frame number.
The detailed hopping generation algorithm is given in subclause 6.2.
</pre>
<a name="56-Parameters-for-channel-definition-and-assignment"></a>
<h2 >5.6 Parameters for channel definition and assignment<a href="#56-Parameters-for-channel-definition-and-assignment" class="wiki-anchor">¶</a></h2>
summary: Per TimeSlot we need to add this information (Already in osmo-bsc VTY. it goes BSC->BTS through OML):
<ul>
<li>TSC (we already have it, "training_sequence_code")</li>
<li>MA (mobile radio frequency channel allocation) (the ARFCN list afaiu, TS 05.02 "6.2.2 Parameters" says "The MA contains N radio frequency channels, where 1<=N<=64". "hopping arfcn add" </li>
<li>MAIO (mobile allocation index offset) "hopping maio" </li>
<li>HSN (hopping sequence number) "hopping sequence-number"</li>
</ul>
<a name="6-Mapping-of-logical-channels-onto-physical-channels"></a>
<h2 >6 Mapping of logical channels onto physical channels<a href="#6-Mapping-of-logical-channels-onto-physical-channels" class="wiki-anchor">¶</a></h2>
<p>This explains all the mappings that we need to add to osmo-bts scheduler as a new abstraction layer level.</p>
<a name="623-Hopping-sequence-generation"></a>
<h2 >6.2.3 "Hopping sequence generation"<a href="#623-Hopping-sequence-generation" class="wiki-anchor">¶</a></h2>
<p>This section explains how to get the ARFCN based on input params (MAI, N=len(MA), FN, MAIO, HSN. (see "Figure 6" for graphical input/output params).</p>
<a name="624-Specific-cases"></a>
<h2 >6.2.4 Specific cases<a href="#624-Specific-cases" class="wiki-anchor">¶</a></h2>
<pre>
frequency hopping is not permitted on any timeslot supporting a BCCH
according to table 3 of clause 7. A non-hopping radio frequency channel sequence is characterized by a mobile
allocation consisting of only one radio frequency channel, i.e. with N=1, MAIO=0. In this instance sequence generation
is unaffected by the value of the value HSN.
</pre>
<p>"Figure 1" is quite useful to understand the mapping in different layer levels.<br />"Figure 4", "Figure 5", "Figure 6" shows hoping in action.</p>
<a name="Current-Status-Summary"></a>
<h1 >Current Status Summary:<a href="#Current-Status-Summary" class="wiki-anchor">¶</a></h1>
<ul>
<li>Configuration of hopping params supported in osmo-bsc, as well as sending values over OML (afaiu because we supported that in the past with an older non-osmo-bts BTS)</li>
<li>Only initial minimal retrieiving implemented in osmo-bts (oml.c), but hopping not supported in general.</li>
</ul>
<a name="Steps"></a>
<h1 >Steps:<a href="#Steps" class="wiki-anchor">¶</a></h1>
<ul>
<li>osmo-bts:
<ul>
<li>It lacks most of the hopping support. OML messages take the params but do nothing (eg oml.c oml_rx_set_radio_attr and oml_rx_set_chan_attr). Right now osmo-bts expectes arfcn-list to be len()=1.</li>
<li>Towards osmo-trx, we probably need to enable HANDOVER on all ARFCNs in MA group (ARFCN list) for that TS? it also means we need some ref counting structure since several channels may require it to be set.</li>
<li>Also in osmo-trx, we specifically set each TS with its type. TODO: checked what needs to be done there regarding this.</li>
<li>Update in lots of placed (grep "hopping") that hopping is not implemented in osmo-bts.</li>
</ul></li>
</ul>
<ul>
<li>scheduler:
<ul>
<li>Downlink (Tx): trx_sched_fn in scheduler_trx.c calls _sched_rts() and _sched_dl_burst() for each timeslot, but when using frequency hoping then this would be <br />wrong, we need to somehow convert arfcn + fn => ts, and so far AFAIU the spec only provides functions to go the opposite path...<br />We could perhaps go this way and simply end up sending on a different arfcn for which it was polled?</li>
</ul></li>
</ul>
<a name="TODO"></a>
<h2 >TODO:<a href="#TODO" class="wiki-anchor">¶</a></h2>
<ul>
<li>Channel assignment parameters (RSL? 08.58? already done by BSC?)</li>
<li>Find out how to infer TS from arfcn + fn (UL or RTS), and other scheduler required changes.</li>
<li>Pass information to PCU</li>
</ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=182952020-05-12T13:26:26Zpespin
<ul></ul><a name="Regarding-operational-sample-configuration"></a>
<h2 >Regarding operational sample configuration:<a href="#Regarding-operational-sample-configuration" class="wiki-anchor">¶</a></h2>
<p>The idea is to set, for the same TS number on all TRXs [len(TRXs)=N], the same HSN (Hoppping sequence Number) and a different MAIO (0..N-1)<br />So for instance this would be possible:<br /><pre>
trx 0
timeslot 0
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 1
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 1
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 2
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 2
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 3
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 3
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 4
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 4
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 5
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 5
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 6
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 6
phys_chan_config PDCH
hopping enabled 1
hopping sequence-number 7
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
timeslot 7
phys_chan_config PDCH
hopping enabled 1
hopping sequence-number 8
hopping maio 1
hopping arfcn add 870
hopping arfcn add 872
trx 1
timeslot 0
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 1
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 1
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 2
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 2
phys_chan_config TCH/H
hopping enabled 1
hopping sequence-number 3
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 3
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 4
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 4
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 5
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 5
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 6
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 6
phys_chan_config PDCH
hopping enabled 1
hopping sequence-number 7
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
timeslot 7
phys_chan_config PDCH
hopping enabled 1
hopping sequence-number 8
hopping maio 2
hopping arfcn add 870
hopping arfcn add 872
</pre></p>
<a name="Regarding-RSL-CHan-ACT"></a>
<h2 >Regarding RSL CHan ACT<a href="#Regarding-RSL-CHan-ACT" class="wiki-anchor">¶</a></h2>
<p>Check TS 08.58 sec "9.3.5 Channel Identification" IE, where it points to TS 0408:<br /><pre>
04.08 "Channel Description" *
04.08 "Mobile Allocation" *
A * denotes that the whole of the 04.08 element including the element identifier and length should be included. The 04.08 "Mobile Allocation" shall for compatibility reasons be included but empty, i.e. the length shall be zero.
</pre></p>
<p>From there, TS 04.08 sec "10.5.2.5 Channel Description" explains how to either encode the ARFCN or the MAIO + HSN<br />Similarly, "10.5.2.21 Mobile Allocation" IE encodes an ARFCN List as a bitmap of 1 and 0. It, however, must be always empty according to spec TS 08.58.</p>
<p>This is already implemented in osmo-bsc.git abis_rsl.c rsl_tx_chan_activ() as pointed out by Harald. On the oher hand, in osmo-bts.git, we are not even parsing RSL_IE_CHAN_IDENT in rsl.c rsl_rx_chan_activ(), which means nowadays we are not even verifying that the ARFCN in there fine (we probably assume the ARFCN for the trx associated to the rsl connection is used).</p>
<p>We also need to make sure we send the CA (list of arfcns) in BCCH in the BTS:<br /><pre>
f frequency hopping is applied, the cell allocation if present in the message is used to decode the mobile allocation. If the cell allocation is not included, the mobile station uses its current cell allocation, the current CA is the last CA received on the BCCH. Afterward, the current CA may be changed by some messages sent on the main signalling link containing a CA (the possible messages are: ASSIGNMENT COMMAND, HANDOVER COMMAND and FREQUENCY REDEFINITION). Note that there are cases in which the current CA is undefined, see sub-clause 3.4.3.3.
</pre></p>
<a name="Regarding-PCU"></a>
<h2 >Regarding PCU<a href="#Regarding-PCU" class="wiki-anchor">¶</a></h2>
<p>Taking over from what Harald did look at, on osmo-pcu.git we need to:</p>
<ul>
<li>pass Mobile Allocation bitmap over the PCU socket (only if it turns out we need to implement "Frequency Parameters" for indirect mode in "Immediate assignment", see further below). We actually don't need to add this anyway because it's already being sent to BSC->BTS->PCU through System Ifnormation 13 element "GPRS Mobile Allocation : GPRS Mobile Allocation IE > } -- Defined in 3GPP TS 04.6012.10a GPRS Mobile Allocation" </li>
<li>Pass per-pdch TS (MAIO, HSN) parameters over the PCU socket so the PCU knows about them: MAIO, HSN. We could try encoding it inside 16bit arfcn (we need 6 bit for MAIO and 6 bit for HSN, so 12 of 16 total, plus some way to differentiate between hopping enabled or disabled). It needs to be done at least for info_ind, when in osmo-pcu arfcn is copied and later used. Other usages look more like gsmtap related.</li>
<li>encode the hopping parameters in any kind of RLC/MAC messages, specifically
<ul>
<li>Encoding::write_immediate_assignment()</li>
<li>Encoding::write_packet_uplink_assignment()</li>
<li>Encoding::write_packet_downlink_assignment()</li>
</ul></li>
</ul>
<p>TS 04.08:</p>
<ul>
<li>"10.5.2.16 IA Rest Octet" Included in "IMMEDIATE ASSIGNMENT". Contains struct "Frequency Parameters", which in turn contains MAIO and Mobile Allocation. We don't seem to need this though, since we only send Downlink and Uplink options which doesn't contain those.</li>
</ul>
<ul>
<li>"10.5.2.25a Packet Channel Description": Included in "IMMEDIATE ASSIGNMENT". It has a bit to encode either ARFCN or MAIO + HSN. In there, there seems to be "Direct" vs "Indirect" "encoding of hopping RF channel configuration", the first providing MAIO+HSN and the other one MAIO+MA_NUMBER_IND. We probably want to use direct since we have MAIO + HSN from the BTS anyway).</li>
</ul>
<a name="Summary-of-steps"></a>
<h2 >Summary of steps:<a href="#Summary-of-steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>Move osmocom-bb hopping functions to libosmocore</li>
<li>osmo-bts.git: Rework scheduler-trx (plus generic scheduler structures) to decouple 1 trx = 1 specific rfch. Use libosmocore rfch functions in in scheudler-trxto convert rfch<->trx and pass logical trx to generic scheduler. (we may want to add some generic code in the scheduler to do so).</li>
<li>pcuif: Find way to include MAIO+HSN (12bit) into uint16_t to avoid changing protocol. Otherwise, change structs to accomodate MAIO+HSN. TRX in pcuinf continues to work the same since they are considered logical TRXs.</li>
<li>osmo-pcu.git: Write MAIO+HSN in write_assignment if hopping is enabled</li>
<li>faketrx: We may have to add support for hopping in faketrx to test with TTCN3</li>
</ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=182962020-05-12T13:26:58Zlaforge
<ul></ul><p><a class="user active" href="https://osmocom.org/users/30187">pespin</a>: Let me illustrate what happens in the following tables.</p>
Assumptions:
<ul>
<li>5-TRX BTS (C0..C4 each represent one ARFCN)</li>
<li>BCCH on TRX0/TS0</li>
<li>sequential hopping sequence (for illustration, works for any other seuqence)</li>
<li>b = BCCH/CCCH</li>
<li>A..E = logical timeslots (think of TCH/F or PDCH)</li>
</ul>
<a name="TS0"></a>
<h2 >TS0<a href="#TS0" class="wiki-anchor">¶</a></h2>
<table>
<tr>
<td>TRX </td>
<td>C0</td>
<td>C1</td>
<td>C2</td>
<td>C3</td>
<td>C4</td>
</tr>
<tr>
<td>fn=0</td>
<td>b </td>
<td> A</td>
<td> B</td>
<td> C</td>
<td> D</td>
</tr>
<tr>
<td>fn=1</td>
<td>b </td>
<td> D</td>
<td> A</td>
<td> B</td>
<td> C</td>
</tr>
<tr>
<td>fn=2</td>
<td>b </td>
<td> C</td>
<td> D</td>
<td> A</td>
<td> B</td>
</tr>
<tr>
<td>fn=3</td>
<td>b </td>
<td> B</td>
<td> C</td>
<td> D</td>
<td> A</td>
</tr>
<tr>
<td>fn=4</td>
<td>b </td>
<td> A</td>
<td> B</td>
<td> C</td>
<td> D</td>
</tr>
</table>
<p>=> BCCH + 4 dedicated timeslots (A..D)</p>
<a name="TS17"></a>
<h2 >TS1..7<a href="#TS17" class="wiki-anchor">¶</a></h2>
<table>
<tr>
<td>TRX </td>
<td>C0</td>
<td>C1</td>
<td>C2</td>
<td>C3</td>
<td>C4</td>
</tr>
<tr>
<td>fn=0</td>
<td>A </td>
<td> B</td>
<td> C</td>
<td> D</td>
<td> E</td>
</tr>
<tr>
<td>fn=1</td>
<td>E </td>
<td> A</td>
<td> B</td>
<td> C</td>
<td> D</td>
</tr>
<tr>
<td>fn=2</td>
<td>D </td>
<td> E</td>
<td> A</td>
<td> B</td>
<td> C</td>
</tr>
<tr>
<td>fn=3</td>
<td>C </td>
<td> D</td>
<td> E</td>
<td> A</td>
<td> B</td>
</tr>
<tr>
<td>fn=4</td>
<td>B </td>
<td> C</td>
<td> D</td>
<td> E</td>
<td> A</td>
</tr>
<tr>
<td>fn=5</td>
<td>A </td>
<td> B</td>
<td> C</td>
<td> D</td>
<td> E</td>
</tr>
</table>
<p>=> 5 dedicated timeslots (A..E)</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=182982020-05-12T13:29:27Zlaforge
<ul><li><strong>Precedes</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/4547">Feature #4547</a>: support for frequency hopping in osmo-pcu</i> added</li></ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183182020-05-12T19:50:55Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>I would like to follow test-driven development approach here, so my current plan is:</p>
<ul>
<li>1. Implement freq. hopping support for the MS side of ttcn3-bts-test:
<ul>
<li>trxcon remains unchanged and still maintains a single TRXC/TRXD connection
<ul>
<li>on TRXC we already have an MS specific command: <em>SETFH <HSN> <MAIO> <CH1> <CH2> [... <CHN>]</em></li>
</ul>
</li>
<li>fake_trx.py gets the actual implementation of freq. hopping
<ul>
<li>hopping sequence is generated from parameters indicated by <em>SETFH</em></li>
<li>in Transceiver/FakeTRX every burst coming from the BurstForwarder triggers freq. change</li>
<li>unit tests!</li>
</ul>
</li>
<li>BTS_Tests.f_est_dchan() must be extended:
<ul>
<li>to be able to send <em>RSL MT_IMMEDIATE_ASSIGN_CMD</em> with hopping parameters</li>
<li>to be able to send <em>L1CTL DM_EST.req</em> with hopping parameters</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>2. Implement test cases as a part of ttcn3-bts-test:
<ul>
<li>2.0. Investigate what needs to be changed or refactored in order to indicate freq. hopping parameters to osmo-bts-trx (IUT)
<ul>
<li>osmo-bts.cfg in docker-playground needs to be changed, so osmo-bts-trx knows about all additional transceivers</li>
<li>osmo-bsc.cfg in docker-playground needs to be changed, so osmo-bsc can OML-bootstrap all transceivers for us</li>
<li>fake_trx.py needs to know about all additional transceivers too (by default we have 1 MS + 1 BTS only)</li>
</ul>
</li>
<li>2.1. Make sure that L2 frames on different kinds of logical channel (SDCCH, TCH, PDCH) can be sent and received when freq. hopping is in use</li>
<li>2.2. Make sure that several channels with and without freq. hopping can co-exist together, not interfering with each other</li>
<li>2.3. Make sure that BCCH on C0/TRX0 can still be decoded when at least one dedicated channel is hopping</li>
<li>2.4. Make sure that CBCH on SDCCH/8 can still be decoded when SI4 indicates that it </li>
<li>FIXME: record <em>GSM_RR_Types.MaioHsn</em> is empty o_O</li>
</ul></li>
</ul>
<ul>
<li>3. Finally, implement baseband freq. hopping support in osmo-bts-trx:
<ul>
<li>3.0. Illustrate the current bts/trx/ts/lchan dependency diagram, investigate what needs to be changed
<ul>
<li>obviously we need to decouple both logical channel state and trx/ts state</li>
<li>logical channel handlers (rx_data_fn, rx_tchf_fn, etc.) shall have no access to anything else than their associated state
<ul>
<li>this is how it's (almost) done in trxcon, but still: *trx is needed to know TSC for Tx bursts, *ts provides multiframe layout info...</li>
<li>we can just store what's needed in the logical channel state</li>
</ul>
</li>
</ul>
</li>
<li>3.2. Implement handling of the hopping related parameters in the OML messages</li>
<li>3.3. Implement the actual code for dispatching bursts to and from the transceivers</li>
<li>3.4. Indicate support of freq. hopping to the BSC among with the other features</li>
</ul></li>
</ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183192020-05-12T20:07:38Zfixeria
<ul></ul><p>Some more additional notes:</p>
<ul>
<li>1. Implement freq. hopping support for the MS side of ttcn3-bts-test:
<ul>
<li>Calypso PHY does not require any changes and can be also used in the testing setup</li>
</ul></li>
</ul>
<ul>
<li>3. Finally, implement baseband freq. hopping support in osmo-bts-trx:
<ul>
<li>3.5. We already have hopping sequence generation code in OsmocomBB, makes sense to move it to libosmocore</li>
</ul></li>
</ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183292020-05-13T20:55:47Zfixeria
<ul></ul><blockquote>
<p>3.5. We already have hopping sequence generation code in OsmocomBB, makes sense to move it to libosmocore</p>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/18244">https://gerrit.osmocom.org/c/libosmocore/+/18244</a> libosmogsm: import hopping sequence generation code<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/18245">https://gerrit.osmocom.org/c/libosmocore/+/18245</a> libosmogsm: add Doxygen docs for gsm0502_hop_seq_gen()</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183472020-05-15T17:42:59Zfixeria
<ul></ul><blockquote>
<p>fake_trx.py gets the actual implementation of freq. hopping</p>
</blockquote>
<p>This part is pretty much done, but unit tests are still missing (low priority).</p>
<blockquote>
<p>hopping sequence is generated from parameters indicated by SETFH</p>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/18261/">https://gerrit.osmocom.org/c/osmocom-bb/+/18261/</a> trx_toolkit/gsm_shared.py: implement hopping sequence generation</p>
<blockquote>
<p>on TRXC we already have an MS specific command: SETFH <HSN> <MAIO> <CH1> <CH2> [... <CHN>]</p>
</blockquote>
<p>I had to change the format of this command, so we send a list of frequencies instead of ARFCNs:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/18319/">https://gerrit.osmocom.org/c/osmocom-bb/+/18319/</a> trxcon: refactor trx_if_cmd_setfh(): send Rx/Tx frequencies</p>
<blockquote>
<p>in Transceiver/FakeTRX every burst coming from the BurstForwarder triggers freq. change</p>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/18262/">https://gerrit.osmocom.org/c/osmocom-bb/+/18262/</a> trx_toolkit/transceiver.py: add frequency hopping support</p>
<p>I am starting to work on TTCN-3 test cases now.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183672020-05-18T09:33:12Zfixeria
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>10</i></li></ul><p>All changes mentioned above have been merged.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=183682020-05-18T09:53:17Zfixeria
<ul></ul><blockquote>
<p>I am starting to work on TTCN-3 test cases now.</p>
</blockquote>
<p>I have prepared a multi-TRX configuration for ttcn3-bts-test: <a class="external" href="https://git.osmocom.org/docker-playground/commit/?h=fixeria/mtrx&id=8dd2bf5cdeab3d1f9c35388918bf1eba8136ef41">https://git.osmocom.org/docker-playground/commit/?h=fixeria/mtrx&id=8dd2bf5cdeab3d1f9c35388918bf1eba8136ef41</a>. Unfortunately, the existing test cases fail when running against the new setup.</p>
<p>The problem is that in the new multi-TRX setup we have more than one IPA/RSL connection, because every transceiver establishes it's own RSL link to the same IP address / port of the test case (virtual BSC). This works with osmo-bsc, but not with our IPA/RSL emulation components. As it turns out, <em>IPA_Emulation_CT</em> was not designed to serve more than one IPA connection, so <strong>it overwrites its <em>g_ipa_conn_id</em></strong> on every incoming connection. In the end, <strong>all messages are getting sent to TRX3 instead of TRX0</strong>, because it was the last connection :/</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=184102020-05-22T15:41:51Zfixeria
<ul></ul><pre>
22:24 < fixeria> The main question is how do we map one of multiple IPA/RSL connections to the exact trx number? Some options: a) the transceivers always connect one
after another, starting from trx#0, so we can assume that every new connection belongs to trx#(N+1)
22:26 < fixeria> b) the RSL_Emulation component can be modified to ask IPA UnitID of each transceiver, so we can parse trx#N from response: _/_/N
22:28 < fixeria> c) get rid of osmo-bsc and do the OML bootstrapping from the test case (probably, a lot of work)
22:28 < fixeria> c) ... so we can instruct osmo-bts-trx to establish transceiver connections on different TCP addr/port pairs
22:32 <@LaF0rge> fixeria: 'b' sounds like the cleanest approach, as that's what the BSC is doing
22:32 <@LaF0rge> 'c' is really a separate topic (I want to do that at some point, but not now)
22:33 <@LaF0rge> 'd' (your second 'c') would be an acceptable workaround if 'b' is not really an option
</pre> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=184322020-05-26T14:25:27Zfixeria
<ul><li><strong>% Done</strong> changed from <i>10</i> to <i>20</i></li></ul><blockquote>
<p>22:26 < fixeria> b) the RSL_Emulation component can be modified to ask IPA UnitID of each transceiver<br />22:32 <@LaF0rge> fixeria: 'b' sounds like the cleanest approach, as that's what the BSC is doing</p>
</blockquote>
<p>So I implemented b), and finally got the existing TTCN-3 test cases working against a multi-trx setup. Yay \o/. All changes have been submitted to Gerrit, some of them have already been merged. The most important ones are:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18486/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18486/</a> library/RSL_Emulation: fixup: handle RSL messages from any TRX<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18357/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18357/</a> library/IPA_Emulation: server mode: handle multiple client connections<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18462/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18462/</a> library/IPA_Emulation: handle optional conn_id in ASP_RSL_Unitdata<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18463/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18463/</a> library/IPA_Emulation: server mode: also request IPA UnitID<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18464/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18464/</a> library/IPA_Emulation: server mode: expose IPA IDENTITY RESPONSE<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18465/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18465/</a> library/RSL_Emulation: server mode: handle multiple transceivers</p>
<p>P.S. This also means that we can write test cases for multi-trx setup, not only for frequency hopping.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=184522020-05-27T16:19:20Zfixeria
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>30</i></li></ul><blockquote>
<p>FIXME: record GSM_RR_Types.MaioHsn is empty o_O</p>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18521/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18521/</a> library/GSM_RR_Types: fix MaioHsn: add missing MAIO and HSN fields</p>
<blockquote>
BTS_Tests.f_est_dchan() must be extended:
<ul>
<li>to be able to send RSL MT_IMMEDIATE_ASSIGN_CMD with hopping parameters</li>
<li>to be able to send L1CTL DM_EST.req with hopping parameters</li>
</ul>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18523/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18523/</a> bts/BTS_Tests: derive ts_ChanDesc{H0,H1} from ts_ChanDesc<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18526/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18526/</a> library/L1CTL_PortType: refactor L1CTL channel establishment<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18527/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18527/</a> library/L1CTL_Types: fix definition of L1ctlH1 (hopping parameters)<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18528/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18528/</a> library/L1CTL_Types: introduce ts_L1CTL_DM_EST_REQ_H1<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18529/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18529/</a> library/L1CTL_PortType: f_L1CTL_DM_EST_REQ_IA(): handle hopping params<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18530/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18530/</a> bts/BTS_Tests: add frequency hopping parameters</p>
<blockquote>
2.0. Investigate what needs to be changed or refactored in order to indicate freq. hopping parameters to osmo-bts-trx (IUT)
<ul>
<li>osmo-bts.cfg in docker-playground needs to be changed, so osmo-bts-trx knows about all additional transceivers</li>
<li>osmo-bsc.cfg in docker-playground needs to be changed, so osmo-bsc can OML-bootstrap all transceivers for us</li>
<li>fake_trx.py needs to know about all additional transceivers too (by default we have 1 MS + 1 BTS only)</li>
</ul>
</blockquote>
<p><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/18487/">https://gerrit.osmocom.org/c/docker-playground/+/18487/</a> ttcn3-bts-test: enable 3 additional transceivers for BTS#0</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=184532020-05-27T16:27:19Zfixeria
<ul></ul><p>While working on the first test case, I found and fixed a bug in trxcon:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/18519/">https://gerrit.osmocom.org/c/osmocom-bb/+/18519/</a> trxcon: fix l1ctl_proc_est_req_h0(): convert to host byte order</p>
<p>so here is a "demo" test case, and of course it fails at the moment (as expected):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18531/">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18531/</a> WIP: bts/BTS_Tests: add sample test case using frequency hopping</p>
<p>In general, I think we can introduce "hopping" variants of the existing test cases, at least some of them.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=184762020-05-29T18:30:45Zfixeria
<ul></ul><p>I just noticed that osmo-bsc does not actually distinguish different osmo-bts-{trx,sysmo,...} variants. Instead, they all are treated as "sysmobts", so they all share same set of features in osmo-bsc. We're about to introduce frequency hopping support to osmo-bts-trx, but the other variants will unlikely get it any time soon, probably never. I think we need to implement a proper handling of osmo-bts-{trx,sysmo,...} variants in osmo-bsc, so they all can have separate feature vectors.</p>
<p>While reading the code, I also discovered that the "public" osmo-bts features that are reported via OML were mixed together with the internal implementation specific features, so they are reported to the BSC all together. This is definitely a bad idea, so I decided to separate both feature sets:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/18591">https://gerrit.osmocom.org/c/osmo-bts/+/18591</a> Do not mix public and private BTS features, use libosmocore's API</p>
<p>and found a minor bug:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/18592">https://gerrit.osmocom.org/c/osmo-bts/+/18592</a> oml: fix TL16V length calculation in add_bts_feat()</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=185692020-06-06T12:14:03Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/4194">osmo-bts-trx.dot</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/4194/osmo-bts-trx.dot">osmo-bts-trx.dot</a> added</li></ul><p>So this is the actual dependency diagram for the current code:</p>
<p><div class="flash error">Error executing the <strong>graphviz_link</strong> macro (Missing template wiki_graphviz/macro with {:locale=>[:en], :formats=>[:xml, :atom], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby, :rsb]}. Searched in:
* "/usr/src/redmine/plugins/wiki_mscgen_plugin/app/views"
* "/usr/src/redmine/plugins/wiki_graphviz_plugin/app/views"
* "/usr/src/redmine/plugins/redmine_tags/app/views"
* "/usr/src/redmine/plugins/redmine_openid_provider/app/views"
* "/usr/src/redmine/plugins/redmine_mentions/app/views"
* "/usr/src/redmine/plugins/redmine_lightbox2/app/views"
* "/usr/src/redmine/plugins/redmine_checklists/app/views"
* "/usr/src/redmine/plugins/redmine_banner/app/views"
* "/usr/src/redmine/plugins/clipboard_image_paste/app/views"
* "/usr/src/redmine/app/views"
* "/usr/local/bundle/gems/redmine_crm-0.0.61/app/views"
)</div></p>
<p>As can be seen, osmo-bts-trx specific structures live separately from generic osmo-bts structures. Only <em>l1sched_trx</em> has a pointer to <em>gsm_bts_trx</em>. Another important point is that <strong>osmo-bts-trx maintains individual schedulers for each transceiver</strong>. This is critical for the upcoming frequency hopping implementation. Ideally we should have one scheduler per <em>gsm_bts</em> that would serve all child transceivers. I'll propose another graph for the new architecture soon.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=185722020-06-06T19:36:12Zlaforge
<ul></ul><p>Thanks for the diagram!</p>
<p>My naive thought would have been that all of this can stay the same? After all, the state, including the burst bufefrs and the scheduler are referring to a <strong>logical</strong> TRX. The actual permutation of bursts between radio carriers and logical TRX would have to be even one level lower, right?</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=185892020-06-07T18:52:30Zpespin
<ul></ul><p>Agree with <a class="user active" href="https://osmocom.org/users/7">laforge</a> , that was also my conclusion after looking at the code.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=186852020-06-11T17:16:00Zfixeria
<ul></ul><blockquote>
<p>My naive thought would have been that all of this can stay the same?</p>
</blockquote>
<p>Mostly, yes, I am not planning to refactor everything ;) However we still need some important changes:</p>
<ul>
<li>There should be one scheduler per BTS, not per TRX. All child transceivers of a BTS share the same clock source anyway. Otherwise every 'per TRX scheduler' would try to dequeue packets from per timeslot Downlink queues.</li>
<li>Logical channel handlers should not operate on TRX (<em>struct l1sched_trx</em>), but on the associated logical channel state (<em>struct l1sched_chan_state</em>).</li>
</ul>
<p>I am also splitting logical channel handlers into separate files, because currently it's hard to find e.g. xCCH handler in a huge file.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=189722020-06-29T05:46:39Zfixeria
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>handle/parse hopping channels on A-bis OML + RSL (common part)</i> set to Done</li><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>commutator between "gsm_bts_trx" and "radio carrier" doing the actual hopping</i> set to Done</li><li><strong>% Done</strong> changed from <i>30</i> to <i>80</i></li></ul><p>During the last couple of weeks I was distracted by some unrelated tasks (see <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: ttcn3-bsc-test: all LCLS test cases broken since build #987 (Resolved)" href="https://osmocom.org/issues/4619">#4619</a>, <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: (Wrong?) measurement of both RSSI and ToA on TCH channels (Resolved)" href="https://osmocom.org/issues/3032">#3032</a>, <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoBTS rxlev/rxqual SUB computation completely broken [AMR DTX] (Resolved)" href="https://osmocom.org/issues/2978">#2978</a>), but now I finally got enough time to move on.</p>
<blockquote>
<p>There should be one scheduler per BTS, not per TRX. All child transceivers of a BTS share the same clock source anyway. Otherwise every 'per TRX scheduler' would try to dequeue packets from per timeslot Downlink queues.</p>
</blockquote>
<p>As it turned out, I was wrong. Sorry for confusion. We actually have one scheduler per BTS instance.</p>
<blockquote>
<p>Logical channel handlers should not operate on TRX (struct l1sched_trx), but on the associated logical channel state (struct l1sched_chan_state).</p>
</blockquote>
<p>I decided to keep this as is. Having access to <em>struct l1sched_trx</em> in the logical channel handlers allows them to print more context information in the logging messages.</p>
<p>Last week I continued to work on this task, found an interesting problem in the scheduler (already merged):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19009">https://gerrit.osmocom.org/c/osmo-bts/+/19009</a> osmo-bts-trx: fix trx_sched_fn(): properly advance frame number</p>
<p>and finally submitted the actual frequency hopping implementation to Gerrit:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19028">https://gerrit.osmocom.org/c/osmo-bts/+/19028</a> osmo-bts-trx/scheduler: cosmetic: move trx_if_powered() check<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19029">https://gerrit.osmocom.org/c/osmo-bts/+/19029</a> osmo-bts-trx/scheduler: refactor dummy burst scheduling<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19030">https://gerrit.osmocom.org/c/osmo-bts/+/19030</a> osmo-bts-trx/scheduler: implement baseband frequency hopping</p>
<p>I did some testing with the real hardware (USRP B210 in multi-AFCN mode, 2 TRX) and a Nokia phone:</p>
<pre>
trx 0
arfcn 801
...
timeslot 0
phys_chan_config CCCH
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 1
hopping sequence-number 1
hopping maio 0
hopping arfcn add 801
hopping arfcn add 805
timeslot 2
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 0
hopping maio 0
hopping arfcn add 801
hopping arfcn add 805
timeslot 3
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 0
hopping maio 0
hopping arfcn add 801
hopping arfcn add 805
...
trx 1
arfcn 805
...
timeslot 0
phys_chan_config TCH/H
hopping enabled 0
timeslot 1
phys_chan_config SDCCH8
hopping enabled 1
hopping sequence-number 1
hopping maio 1
hopping arfcn add 801
hopping arfcn add 805
timeslot 2
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 0
hopping maio 1
hopping arfcn add 801
hopping arfcn add 805
timeslot 3
phys_chan_config TCH/F
hopping enabled 1
hopping sequence-number 0
hopping maio 1
hopping arfcn add 801
hopping arfcn add 805
...
</pre>
<p>Hopping SDCCH/8 on TS1 works fine (tested Location Updating, USSD, SMS, Silent Call). Hopping TCH/F and TCH/H on TS2..7 still to be tested. Unfortunately, OsmoBSC fails to encode <em>RR Channel Assignment</em> properly, so the phone rejects this message by sending <em>RR Status (cause=Conditional IE Error)</em>.</p>
<p>Since TRX0 is C0 (ARFCN 801), I also checked the spectrum to make sure that dummy bursts are sent as expected and there are no gaps. Everything looks fine.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=189732020-06-29T05:55:30Zfixeria
<ul><li><b>Checklist item</b> deleted (<strike><i>separate logical TRX from "radio carriers" in our data structures</i></strike>)</li></ul><blockquote>
<p>[ ] separate logical TRX from "radio carriers" in our data structures</p>
</blockquote>
<p>I don't think we really need this. The existing object hierarchy in osmo-bts-trx is flexible enough.<br />Burst "routing" in the proposed implementation is done by the scheduler itself.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=190752020-07-08T11:50:12Zfixeria
<ul><li><strong>Blocked by</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/4658">Bug #4658</a>: Wrong burst order in a multi-trx setup</i> added</li></ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=191202020-07-14T10:51:54Zfixeria
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>automatic TTCN3 testing of frequency hopping configurations</i> set to Done</li><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>I have submitted a set of changes:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19159">https://gerrit.osmocom.org/c/docker-playground/+/19159</a> ttcn3-bts-test/osmo-bsc.cfg: change pchan config for TRX#1..3<br /><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19160">https://gerrit.osmocom.org/c/docker-playground/+/19160</a> ttcn3-bts-test: add configuration with frequency hopping parameters</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19243">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19243</a> library/GSM_RR_Types: add ts/tr templates for MaioHsn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19244">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19244</a> BTS_Tests: introduce and use helper f_l1ctl_est_dchan()<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19245">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19245</a> BTS_Tests: implement optional frequency hopping support</p>
<p>The existing test cases implicitly cover the following scenarios:</p>
<blockquote>
<p>2.1. Make sure that L2 frames on different kinds of logical channel (SDCCH, TCH, PDCH) can be sent and received when freq. hopping is in use<br />2.2. Make sure that several channels with and without freq. hopping can co-exist together, not interfering with each other<br />2.3. Make sure that BCCH on C0/TRX0 can still be decoded when at least one dedicated channel is hopping</p>
</blockquote>
<p>excluding this one (we don't seems to have any test cases for SDCCH8+CBCH at all):</p>
<blockquote>
<p>2.4. Make sure that CBCH on SDCCH/8 can still be decoded when SI4 indicates that it</p>
</blockquote> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=191212020-07-14T11:16:18Zfixeria
<ul></ul><p>Running the existing test cases against a multi-trx setup with frequency hopping enabled locally shows the following regressions:</p>
<pre>
pass->FAIL BTS_Tests.TC_meas_res_sign_tchf
pass->FAIL BTS_Tests.TC_meas_res_sign_sdcch8
pass->FAIL BTS_Tests.TC_rsl_ms_pwr_ctrl
pass->FAIL BTS_Tests.TC_rsl_ms_pwr_dyn_up
pass->FAIL BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown
pass->FAIL BTS_Tests.TC_paging_imsi_200percent
pass->FAIL BTS_Tests.TC_paging_tmsi_200percent
pass->FAIL BTS_Tests.TC_si_sched_2quater
pass->FAIL BTS_Tests.TC_si_sched_13_2bis_2ter_2quater
pass->FAIL BTS_Tests.TC_pcu_ptcch
pass->FAIL BTS_Tests.TC_pcu_time_ind
pass->FAIL BTS_Tests.TC_pcu_rts_req
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_1block
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_2block
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_3block
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_4block
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_multi
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_schedule
pass->FAIL BTS_Tests_SMSCB.TC_sms_cb_cmd_sdcch4_default_and_normal
pass->FAIL BTS_Tests_SMSCB.TC_cbc_sdcch4_load_overload
pass->FAIL BTS_Tests_LAPDm.TC_sabm_ua_dcch_sapi0
pass->FAIL BTS_Tests_LAPDm.TC_sabm_retransmit
pass->FAIL BTS_Tests_LAPDm.TC_sabm_invalid_resp
pass->FAIL BTS_Tests_LAPDm.TC_sabm_dm
pass->FAIL BTS_Tests_LAPDm.TC_establish_ign_first_sabm
pass->FAIL BTS_Tests_LAPDm.TC_iframe_seq_and_ack
pass->FAIL BTS_Tests_LAPDm.TC_iframe_timer_recovery
pass->FAIL BTS_Tests_LAPDm.TC_rec_invalid_frame
pass->FAIL BTS_Tests_LAPDm.TC_segm_concat_dcch
pass->FAIL BTS_Tests_LAPDm.TC_segm_concat_sacch
pass->FAIL BTS_Tests_LAPDm.TC_rr_response_frame_loss
pass->FAIL BTS_Tests_LAPDm.TC_incorrect_cr
pass->FAIL BTS_Tests_LAPDm.TC_sabm_incorrect_c
</pre>
<p>some of them related to the recent changes to fake_trx.py (see <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: Wrong burst order in a multi-trx setup (Stalled)" href="https://osmocom.org/issues/4658">#4658</a>), so let's filter them out:</p>
<pre>
pass->FAIL BTS_Tests.TC_meas_res_sign_tchf
pass->FAIL BTS_Tests.TC_meas_res_sign_sdcch8
pass->FAIL BTS_Tests.TC_si_sched_2quater <-- unrelated regression (see OS#4662)
pass->FAIL BTS_Tests.TC_si_sched_13_2bis_2ter_2quater <-- unrelated regression (see OS#4662)
pass->FAIL BTS_Tests.TC_pcu_ptcch
pass->FAIL BTS_Tests_LAPDm.TC_sabm_ua_dcch_sapi0
pass->FAIL BTS_Tests_LAPDm.TC_sabm_retransmit
pass->FAIL BTS_Tests_LAPDm.TC_sabm_invalid_resp
pass->FAIL BTS_Tests_LAPDm.TC_sabm_dm
pass->FAIL BTS_Tests_LAPDm.TC_establish_ign_first_sabm
pass->FAIL BTS_Tests_LAPDm.TC_iframe_timer_recovery
pass->FAIL BTS_Tests_LAPDm.TC_segm_concat_dcch
pass->FAIL BTS_Tests_LAPDm.TC_rr_response_frame_loss
pass->FAIL BTS_Tests_LAPDm.TC_incorrect_cr
pass->FAIL BTS_Tests_LAPDm.TC_sabm_incorrect_c
</pre>
<p>Both measurement related test case failures (TC_meas_res_sign_tchf and TC_meas_res_sign_sdcch8) seem to be caused by the fact that in fake_trx.py both FAKE_TOA and FAKE_RSSI commands apply to a transceiver they are sent to, while in this setup we deal with several transceivers. The easiest approach would be to send FAKE_* commands to all transceivers.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=191222020-07-14T13:40:04Zfixeria
<ul></ul><p>This change solves the LAPDm test case failures:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19253">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19253</a> BTS_Tests_LAPDm: consider frequency hopping parameters</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=191232020-07-14T14:21:15Zfixeria
<ul></ul><p>This change makes <em>BTS_Tests.TC_pcu_ptcch</em> pass:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19254">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19254</a> BTS_Tests: fix PDCH tests: consider frequency hopping</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=192542020-08-02T19:54:02Zfixeria
<ul><li><b>Checklist item</b> <input type='checkbox' class='checklist-checkbox' checked disabled> <i>pass the hopping parameters (MAIO, HSN, ...) over the PCU socket so the PCU knows about them (common part)</i> set to Done</li><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19510">https://gerrit.osmocom.org/c/osmo-bts/+/19510</a> pcu_sock: warn about maximum transceiver number constraints<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19511">https://gerrit.osmocom.org/c/osmo-bts/+/19511</a> pcu_sock: separate trx / ts filling from pcu_tx_info_ind()<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/19513">https://gerrit.osmocom.org/c/osmo-bts/+/19513</a> pcuif_proto: version 10: add frequency hopping parameters</p>
<p>All changes submitted to Gerrit, waiting for code review.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=192572020-08-03T09:04:44Zfixeria
<ul></ul><p>I also submitted a TTCN-3 test case:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19517">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19517</a> BTS_Tests: compose the MA bitmask in f_resolve_fh_params()<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19518">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19518</a> BTS_Tests: verify hopping parameters in the INFO.ind message</p>
<p>and it reveals a problem with the Mobile Allocation bitmask sent by osmo-bts-trx. To be fixed.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=192982020-08-11T06:42:05Zfixeria
<ul><li><strong>Blocked by</strong> deleted (<i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/4658">Bug #4658</a>: Wrong burst order in a multi-trx setup</i>)</li></ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=192992020-08-11T06:42:15Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-7 priority-3 priority-high3" href="/issues/4658">Bug #4658</a>: Wrong burst order in a multi-trx setup</i> added</li></ul> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=193032020-08-11T11:37:12Zfixeria
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Resolved</i></li></ul><p>All changes have been merged.</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=193482020-08-13T11:38:06Zfixeria
<ul></ul><p>All hopping test cases were failing on Jenkins two times in a row. I found and fixed the problems causing this:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19622">https://gerrit.osmocom.org/c/docker-playground/+/19622</a> ttcn3-bts-test/jenkins.sh: do not create unused directory<br /><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19623">https://gerrit.osmocom.org/c/docker-playground/+/19623</a> ttcn3-bts-test/jenkins.sh: use bts-tester-{generic,oml,virtphy,hopping}<br /><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/19624">https://gerrit.osmocom.org/c/docker-playground/+/19624</a> fixup ttcn3-bts-test/jenkins.sh: enable frequency hopping test cases</p> OsmoBTS - Feature #4546: baseband frequency hopping support for osmo-bts-trxhttps://osmocom.org/issues/4546?journal_id=193602020-08-15T12:07:00Zfixeria
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/4708">Bug #4708</a>: Various SMSCB test cases fail with frequency hopping enabled</i> added</li></ul>