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
Show replies by date