Cellular Network Infrastructure » Radio Access Network » OsmoBSC

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

That's the sequence I had in my notes:

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

Yup working on that now.

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

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

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 )

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.

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.

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.

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.

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.