Project

General

Profile

Feature #4514

OM2000 Support for Ericsson RBS6000 / DUG 20

Added by laforge 6 months ago. Updated 3 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Ericsson BTS
Target version:
-
Start date:
04/27/2020
Due date:
% Done:

100%

Spec Reference:

Description

This is a feature ticket about adding support for the RBS6000 family of Ericsson BTS; specifically those using the "DUG (Digital Unit GSM) 20".

tnt and laforge have protocol traces of the OM2000 setup of some of those, which has resulted in quite a bit of experimenting by tnt and the following patches:

What is needed is support in OsmoBSC to fully bring up all the required MOs inside a DUG 20 based BTS, so it can be brought up fully. Subsequently, phones should see the BTS and perform GSM signaling, such a LU, MO+MT SMS, USSD, etc. Voice will not work until #2547 (osmo-mgw E1 endpoint support) is implemented.


Related issues

Related to OsmoMGW - Feature #2547: Add E1/T1 endpoint type to osmo-mgwStalled05/06/202005/06/2020

Related to OsmoBSC - Bug #3975: osmo-bsc crash during startup with nokia insiteClosed05/04/2019

Related to OsmoBSC - Bug #4683: properly report OM2000 bring-up problemsNew07/30/2020

Precedes OsmoBSC - Feature #4682: OM2000 MCTR Support for Ericsson RBS6000 / DUG 20New07/30/2020

History

#1 Updated by laforge 6 months ago

  • Related to Feature #2547: Add E1/T1 endpoint type to osmo-mgw added

#2 Updated by tnt 6 months ago

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.

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.

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.

(As a side note for future reference, when starting over the boot sequence bringing the TF object up takes FOREVER, like 10-20 min before it considers the internal oscillator as good enough and without this it will not continue past TF).

#3 Updated by laforge 6 months ago

There is the LAPD issue causing segfault, not sure if I went far enough to hit that on the RBS or not.

But here I was thinking more of the OM2K.

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.
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.
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.

That's the sequence I had in my notes:

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

#4 Updated by laforge 6 months ago

  • Related to Bug #3975: osmo-bsc crash during startup with nokia insite added

#5 Updated by laforge 6 months ago

That's the sequence I had in my notes:

That "arbitrary" command is not in master. Mind submitting a patch?

#6 Updated by tnt 6 months ago

Yup working on that now.

#8 Updated by laforge 6 months ago

On Tue, Apr 28, 2020 at 08:30:41AM +0000, tnt [REDMINE] wrote:

See https://gerrit.osmocom.org/q/topic:%22om2k%22+(status:open%20OR%20status:merged)

thanks, merged.

#9 Updated by laforge 6 months ago

  • Assignee changed from sysmocom to tnt

tnt has indicated he would be continuing this work, thanks!

#10 Updated by tnt 6 months ago

Some log excerpt with information about some message formats :

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

Also, beware of T3105 value, needs to be valid ( 40 ms works )

#11 Updated by tnt 6 months ago

  • Status changed from New to In Progress

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:

  • 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:
    • There can be multiple TRX and their link can come up in any order
    • 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)
    • The link might even come up before we reach the TRX FSM state where we wait for it ...
    • So all in all, plenty of race condition / special case to handle ...
  • 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.

#12 Updated by tnt 6 months ago

Just a status report on the ticket:

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.

Operating it with an earlier version of the protocol (G12R12), I can bring the BTS up to the point where LU works.
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).

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).

No idea how multi radio head would work and I only have 1 radio so I can't test that.

#13 Updated by laforge 6 months ago

On Tue, May 05, 2020 at 10:13:59PM +0000, tnt [REDMINE] wrote:

No idea how multi radio head would work and I only have 1 radio so I can't test that.

As the (non-remote) RUS were relatively inexpensive (< 200 EUR), it
might be an option to simply get one more. I suppoese it would be best
to get one in the same band, as that is the most likely deployment at
this point (several sectors within one band, each driven by one RUS, all
of them together driven by one RUG and later also in parallel by one DUL)

Given the shipping costs and delays it makes most sense for you to order
directly, rather than sysmocom shipping one to you.

Don't forget to order related cables / connectors / SFPs as needed.

All in all, not urgent. Top priority is to get a single RUS working
reliably with OsmoBSC first.

#14 Updated by tnt 5 months ago

  • % Done changed from 0 to 50

All the patches required to bootstrap a single RUS RBS6k are now in gerrit for review / merge.

It works reliably for me but should be tested by others to make sure it's reproductible.
Obviously you need the BTS to have an IDB loaded that matches whatever you want to do.

You also need to limit the protocol version for OML to G12R12 using :

network
 bts N
   om2000 version-limit oml gen 12 rev 12

It's also been tested in the multi-TRX case and with frequency hopping, all seems to behave properly.

What remains :

  • Test traffic channels : Need MGW support
  • Support for multiple radio heads (MCTRs). There are two cases:
    • Multiple radio for a single BTS, just to add TRXs to the same C0.
    • Multiple C0s out of the same physical BTS. This depends on some architecture changes, see #4536
  • Support for G12R13 protocol.
    • 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.
    • 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.

#15 Updated by laforge 4 months ago

tnt wrote:

All the patches required to bootstrap a single RUS RBS6k are now in gerrit for review / merge.

for the record, the tnt/rbs branch is fully merged for quite some time now.

It works reliably for me but should be tested by others to make sure it's reproductible.

I'm currently trying to get the current master to bring up my RBS2308 before moving on to RBS6k

  • Test traffic channels : Need MGW support

That should be ready soon. Both the BSC side for MGCP E1 endpoints as well as the actual MGW are getting close.

#16 Updated by laforge 3 months ago

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

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.

I will create separate tickets for topics like MCTR support etc.

#17 Updated by laforge 3 months ago

  • Precedes Feature #4682: OM2000 MCTR Support for Ericsson RBS6000 / DUG 20 added

#18 Updated by laforge 3 months ago

  • Related to Bug #4683: properly report OM2000 bring-up problems added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)