https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-04-27T17:42:17ZOpen Source Mobile CommunicationsOsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180882020-04-27T17:42:17Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-3 priority-high3 closed behind-schedule" href="/issues/2547">Feature #2547</a>: Add E1/T1 endpoint type to osmo-mgw</i> added</li></ul> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180912020-04-27T19:47:02Ztnt
<ul></ul><p>I never wrote any code for this, I was doing it manually in the console, manually setting up the objects. However I never got it to boot fully.</p>
<p>The timeslot configuration never worked, it always got rejected and I never figured out why. Looking into what the unknown IE were, we manage to uncover the meaning for most of them, unfortunately none really gave a clue as to why the TS configuration could have been rejected. The best guess so far was some error when configuring the E1 <-> timeslot mapping through the MCTR but that was never tested.</p>
<p>Because testing with the console was tedious the plan was to fixup E1 in osmo-bsc so that this could be done automatically and continue the testing / reversing to see if we can bring it up.</p>
<p>(As a side note for future reference, when starting over the boot sequence bringing the TF object up takes <em>FOREVER</em>, like 10-20 min before it considers the internal oscillator as good enough and without this it will not continue past TF).</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180922020-04-27T20:09:22Zlaforge
<ul></ul><p>There is the LAPD issue causing segfault, not sure if I went far enough to hit that on the RBS or not.</p>
<p>But here I was thinking more of the OM2K.</p>
<p>First it's missing the setup for some of the objects, like the MCTR which prevents the "per trx" OM2k/RSL links from starting at all.<br />And then from what I remember the dependencies between object in which order they were brought up (or trying to be) was not the same as in the captures.<br />I didn't dig into really what was wrong with it or what was important or not, all I know is it wasn't working out of the box.</p>
<p>That's the sequence I had in my notes:</p>
<pre>
bts 0 om2000 class cf 0 255 0
start-request
operational-info 1
exit
bts 0 om2000 class is 0 255 0
connect-command
reset-command
start-request
configuration-request
enable-request
operational-info 1
exit
bts 0 om2000 class tf 0 255 0
connect-command
reset-command
start-request
configuration-request
enable-request
operational-info 1
exit
bts 0 om2000 class mctr 0 255 0
connect-command
reset-command
start-request
operational-info 1
arbitrary 300 a80300a932aa06ab0100
arbitrary 304
enable-request
bts 0 om2000 class trxc 0 255 0
reset-command
start-request
operational-info 1
bts 0 om2000 class tx 0 255 0
connect-command
reset-command
start-request
operational-info 0
configuration-request
enable-request
operational-info 1
bts 0 om2000 class rx 0 255 0
connect-command
reset-command
start-request
operational-info 0
configuration-request
enable-request
operational-info 1
bts 0 om2000 class ts 0 0 0
connect-command
reset-command
start-request
operational-info 0
configuration-request
enable-request
operational-info 1
</pre> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180952020-04-27T20:24:28Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-2 priority-default closed" href="/issues/3975">Bug #3975</a>: osmo-bsc crash during startup with nokia insite</i> added</li></ul> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180962020-04-27T20:33:27Zlaforge
<ul></ul><blockquote>
<p>That's the sequence I had in my notes:</p>
</blockquote>
<p>That "arbitrary" command is not in master. Mind submitting a patch?</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180972020-04-28T07:17:52Ztnt
<ul></ul><p>Yup working on that now.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180982020-04-28T08:30:41Ztnt
<ul></ul><p>See <a class="external" href="https://gerrit.osmocom.org/q/topic:%22om2k%22+(status:open%20OR%20status:merged)">https://gerrit.osmocom.org/q/topic:%22om2k%22+(status:open%20OR%20status:merged)</a></p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=180992020-04-28T08:59:45Zlaforge
<ul></ul><p>On Tue, Apr 28, 2020 at 08:30:41AM +0000, tnt [REDMINE] wrote:</p>
<blockquote>
<p>See <a class="external" href="https://gerrit.osmocom.org/q/topic:%22om2k%22+(status:open%20OR%20status:merged)">https://gerrit.osmocom.org/q/topic:%22om2k%22+(status:open%20OR%20status:merged)</a></p>
</blockquote>
<p>thanks, merged.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=181242020-05-01T08:14:52Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>4368</i> to <i>tnt</i></li></ul><p><a class="user active" href="https://osmocom.org/users/12">tnt</a> has indicated he would be continuing this work, thanks!</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=181252020-05-01T09:02:46Ztnt
<ul></ul><p>Some log excerpt with information about some message formats :</p>
<pre>
08:17 < tnt> DEI a8 is "TRXC list" single little endian u16 (yeah, little endian seems weird ...)
08:17 < tnt> DEI a9 is "maximum_allowed_power" in dBm
08:19 < tnt> DEI aa is "Maximum_allowed_number_of_TRXCs"
08:22 < tnt> DEI ab is "MCTR_feature_status_bit_map". And it's actually variable length with the first byte being the lenght ( must be < 11 to validate )
08:34 < tnt> So a8 is probably a bitmap
08:42 < tnt> yup, confirmed if you look at the TRXC object instance number in the trace. The first one has TRXC 0,1,6,7,8 0 & 1 = 0x0003 config from MCTR0, 6,7,8 = 0x01c0 config from MCTR1. And in the second trace you get TRXC 0,1,2,3 = 0x000f MCTR config.
08:04 < tnt> DEI 9e "Configuration Type" : Single bit, only LSB is read. Can be optional or mandatory depending on ... something (maybe a protocol version ?)
08:04 < tnt> DEI 9f "Jitter Size"
08:04 < tnt> DEI a0 "Packing Algorithm"
08:05 < tnt> Depending on some parameter, either 9e is optional and 9f/a0 are not allowed. Or alternatively 9e/9f/a0 are all 3 mandatory.
08:05 < tnt> (those are the 3 unknowns that are at the end of TS config for traffic channels)
10:15 < tnt> But at least I can now explain my "msg_length" issue when trying to set the timeslot configuration for TCH channels. It's probably that mysterious parameter that makes 9e optional and 9f/a0 disallowed. Not really sure what configured that "mode" though ...
10:25 <@LaF0rge> tnt: it's probably super channel or not?
10:26 <@LaF0rge> tnt: on a classic channelized E1 you don't have jitter
10:26 <@LaF0rge> tnt: so the jitter size parameter only makes sense in a packetized environment, i.e. superchannel
10:26 <@LaF0rge> tnt: aka 'packet abis over TDM'
09:42 < tnt> Message 0x138 to CF
09:42 < tnt> DEI ae (1 byte length) power_back_off_channel_type_map
09:42 < tnt> DEI af (1 byte length) power_back_off_priority
09:42 < tnt> DEI b0 (1 byte length) power_back_off_value
</pre>
<p>Also, beware of T3105 value, needs to be valid ( 40 ms works )</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=181472020-05-04T17:33:15Ztnt
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>I've been working on this, sometime in a bit hackish way just to try and get it up. But I'll keep a log here os the issues that will need to be figured out later:</p>
<ul>
<li>The OM2K link "per-trx" only comes up after MCTR is setup. So that means we need to wait for it before trying to boot the TRX itself. Now we get notified of a TRX link coming up in bootstrap_om_trx() but it's not that easy:
<ul>
<li>There can be multiple TRX and their link can come up in any order</li>
<li>They also come up / then down / then up during boot if the BTS happens to be already configured when startin osmo-bsc (because it was configured already and it will go down during the reconfig)</li>
<li>The link might even come up <em>before</em> we reach the TRX FSM state where we wait for it ...</li>
<li>So all in all, plenty of race condition / special case to handle ...</li>
</ul>
</li>
<li>The pchan_is / pchan_on_init get screwed up because the timeslot fsm gets TS_EV_RSL_DOWN events during the startup. This happens because the link might be up on start (because you restart osmo-bsc but not the bts) and it will go down and up during the init and this invalidates the timeslot settings. And it seems that TS_EV_RSL_READY doesn't actually set thos up again, only TS_EV_OML_READY does and that's only sent once in abis_om2k_trx_init during the bootup and then never again.</li>
</ul> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=181712020-05-05T22:13:59Ztnt
<ul></ul><p>Just a status report on the ticket:</p>
<p>When operating the BTS at the latest protocol revision (G12R13), the TS objects refuse to come up, the conf req result shows "Data not according to request" which of course means the "Enable" fails.</p>
<p>Operating it with an earlier version of the protocol (G12R12), I can bring the BTS up to the point where LU works.<br />Looking at the logs, in that mode the MCTR is in "BTS controlled mode" (vs BSC controlled mode). Downside is that then I have no idea how we can tweak the radio head power and how to map TRXs to MCTRs (radio heads).</p>
<p>At least multi trx seem to work with a single radio head. I was able to get TRX 1 configured (there seem to be a bug preventing channel on it from working but I got it up from OM2k point of view). So I'm assuming TRX0-7 are just mapped linearely. Or maybe just 0-2 (since I only have 3 TRX configured in the IDB).</p>
<p>No idea how multi radio head would work and I only have 1 radio so I can't test that.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=181782020-05-06T08:40:28Zlaforge
<ul></ul><p>On Tue, May 05, 2020 at 10:13:59PM +0000, tnt [REDMINE] wrote:</p>
<blockquote>
<p>No idea how multi radio head would work and I only have 1 radio so I can't test that.</p>
</blockquote>
<p>As the (non-remote) RUS were relatively inexpensive (< 200 EUR), it<br />might be an option to simply get one more. I suppoese it would be best<br />to get one in the same band, as that is the most likely deployment at<br />this point (several sectors within one band, each driven by one RUS, all<br />of them together driven by one RUG and later also in parallel by one DUL)</p>
<p>Given the shipping costs and delays it makes most sense for you to order<br />directly, rather than sysmocom shipping one to you.</p>
<p>Don't forget to order related cables / connectors / SFPs as needed.</p>
<p>All in all, not urgent. Top priority is to get a single RUS working<br />reliably with OsmoBSC first.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=182002020-05-08T13:56:21Ztnt
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>50</i></li></ul><p>All the patches required to bootstrap a single RUS RBS6k are now in gerrit for review / merge.</p>
<p>It works reliably for me but should be tested by others to make sure it's reproductible.<br />Obviously you need the BTS to have an IDB loaded that matches whatever you want to do.</p>
<p>You also need to limit the protocol version for OML to G12R12 using :</p>
<pre>
network
bts N
om2000 version-limit oml gen 12 rev 12
</pre>
<p>It's also been tested in the multi-TRX case and with frequency hopping, all seems to behave properly.</p>
<p>What remains :</p>
<ul>
<li>Test traffic channels : Need MGW support</li>
<li>Support for multiple radio heads (MCTRs). There are two cases:
<ul>
<li>Multiple radio for a single BTS, just to add TRXs to the same C0.</li>
<li>Multiple C0s out of the same physical BTS. This depends on some architecture changes, see <a class="issue tracker-2 status-1 priority-2 priority-default" title="Feature: Multi BTS support within a single physical device (New)" href="https://osmocom.org/issues/4536">#4536</a></li>
</ul>
</li>
<li>Support for G12R13 protocol.
<ul>
<li>This seems required for mixed radio mode (LTE+GSM) operation, when that's in the IDB then the BTS only advertises G12R13 and nothing else.</li>
<li>Currently the MCTR config is implemented (and is accepted) but the timeslot don't load their config. Config is acknowledge but configuration results are "Not According to request". No idea why ... No errors or info in the logs. Tried a lot of things, none of them worked. Last ditch effort is try to switch to "super channel mode". Yet to be done.</li>
</ul></li>
</ul> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=190102020-07-03T19:56:51Zlaforge
<ul></ul><p>tnt wrote:</p>
<blockquote>
<p>All the patches required to bootstrap a single RUS RBS6k are now in gerrit for review / merge.</p>
</blockquote>
<p>for the record, the <code>tnt/rbs</code> branch is fully merged for quite some time now.</p>
<blockquote>
<p>It works reliably for me but should be tested by others to make sure it's reproductible.</p>
</blockquote>
<p>I'm currently trying to get the current master to bring up my RBS2308 before moving on to RBS6k</p>
<blockquote>
<ul>
<li>Test traffic channels : Need MGW support</li>
</ul>
</blockquote>
<p>That should be ready soon. Both the BSC side for MGCP E1 endpoints as well as the actual MGW are getting close.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=192092020-07-30T06:24:40Zlaforge
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>50</i> to <i>100</i></li></ul><p>OM2000 bring-up of RBS6K with at total of 3 differen setups of DUG20+RUS01 and DUG20+RUS02 is working from 1TRX to 8TRX. I've even used different software buils on the RBS, whatever was in the flash when it shipped.</p>
<p>I will create separate tickets for topics like MCTR support etc.</p> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=192112020-07-30T06:33:04Zlaforge
<ul><li><strong>Precedes</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/4682">Feature #4682</a>: OM2000 MCTR Support for Ericsson RBS6000 / DUG 20</i> added</li></ul> OsmoBSC - Feature #4514: OM2000 Support for Ericsson RBS6000 / DUG 20https://osmocom.org/issues/4514?journal_id=192122020-07-30T06:51:09Zlaforge
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-1 priority-2 priority-default" href="/issues/4683">Bug #4683</a>: properly report OM2000 bring-up problems</i> added</li></ul>