This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Keith keith at rhizomatica.orgHi Harald. I appreciate the clarification on things that are pure GSM spec, I know where to look now. :) I tried activating handover this morning very briefly on that site and it started a ping-pong game between the two bts/trx in the LiteCell. Increasing handover power budget hysteresis a lot, >=15dB of course tames that, but surprisingly does not eliminate it. I thought to increase then the neighbour averaging, but 10 is the maximum. It seems it would be difficult to tune that for permanent operation. Notwithstanding what you said about the solution for the LiteCell, which is noted, it still suggests to me some kind of simpler solution such as a ruleset about which BTSs to use for rescue HO. On the question about SIP re-invite, I am talking about operating without rtp_proxy, so that one can have the advantage of BTS<->BTS RTP streams at the same time as handover. From what I've read, this is quite feasable, as part of the SIP spec. I think this is already considered as part of the development of the osmo-sip-connector, which is a project I really want to see moving forward and hope to find time to contribute to over the next few months. However, and again notwithstanding your suggesting for how to resolve the LiteCell issue of the two BTS/TRX, I understand that load balancing (aka traffic handover?) is not implemented in OpenBSC. I am certainly seeing this, for example in the case where all available TCH are in use, a call cannot be established, even though another BTS has resources available. Is this not something that is desirable to implement? Regardless of whether it were a LiteCell, or two or more other types of BTS such as SysmoBTS 1020? Or what is the intended strategy for increasing channel capacity at a site?