Crash of UmTRX transceiver with dual TRX

Andreas Eversberg andreas at eversberg.eu
Mon Jul 8 19:12:06 UTC 2013


Andreas Eversberg wrote:
>   
>>>> i see no problem with that reject. i think it makes sense to reject TSC,
>>>> if it does not match the TSC of first TRX. since trx manager interface
>>>> seems to be designed to handle each TRX individually (even might be
>>>> possible to run on different transceivers for one BTS), i would think it
>>>> is a good idea to set TSC for every TRX.
>>>>       
>>>>         
>>> We can easily move to separate TSC settings be removing the static
>>> identifier. The only issue then is that OpenBTS will no longer work.
>>> Perhaps the larger limitation is that we can't set TSC dynamically
>>> after POWERON. This is because the midamble correlation sequence is
>>> regenerated and is not thread safe.
>>>     
>>>       
>> There could be two command sets - one for OpenBTS compatibility, one
>> for more advanced systems.
>>   
>>     
> i think that is not requited. TSC at openbsc is a global setting. by the
> specs, it can be set for every timeslot individualy. i think it would be
> good to keep it global, so the transceiver remains compatible to
> openbsc. i can remove the TSC command from osmo-bts. alternatively, as
> stated above, setting the same TSC, which is already running at TRX 0
> could be just acknowledged, different TSC rejected.
>   
once TSC is set, it cannot be changed, even after poweroff. i must
restart transceiver before every new start of osmo-bts. before osmo-bts
start provisioning transceiver, it sends poweroff to all trx. also if
bsc fails, transceiver is turned off and provisioned after bsc link is
restored. with the single trx version of transceiver it worked all the
time. i think there should be a solution for that problem.





More information about the UmTRX mailing list