Crash of UmTRX transceiver with dual TRX

Andreas Eversberg andreas at eversberg.eu
Mon Jul 8 17:04:03 UTC 2013


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




More information about the UmTRX mailing list