Hi Harald,

I tested and can confirm that the Nokia code cannot handle a situation when the first TRX is not the first physical TRX in the cabinet. This affects MetroSite and UltraSite and all other variants that can handle more than one TRX. Given the fact these units are getting 20+ years old, backplane or other HW issues can force a user to not start with the first physical TRX and in that case the RSL bootstrap fails as the BTS receives a config starting with trx1 while the unit may has trx2 or trx3 etc.

Question is how to handle this?

One option is that on Nokia, each TRX has its own RSL TEI, and that is a 1:1 match as much as I know. Physical TRX1 has TEI1, TRX2 has TEI2 etc. So we can make a check during fu_config to first determine the first physical TRX based on the RSL TEI, and then check at each iteration which is the next one. For example you can have trx2 and trx4 as well, so we cannot expect that the TRX-es are in a continuous order nor that they always start with trx1.

Another option is to introduce a new Nokia specific TRX variable that describes the physical location of the TRX inside the cabinet and do the above mentioned checks with that.

Or there is a 3rd option I am not thinking about :-)

Any and all opinions are welcome.

Regards, Csaba