Handover and load balancing on SysmoBTS 2050

historical

Hi Keith,

we have had hand-over between BTSs working back in 2009, it is for sure
not a new feature at all.  This was working long before Abis/IP was
implemented, and yes, it is also working with Abis/IP.  I don't know why
Rhizomatica has it disabled.  Maybe you were seeing a particular bug or
incompatibility at the time?

Regarding cell reselection offset / cell reselection hysteresis: We
generally try to not document parameters which are taken 1:1 from the
specifications, as there are plenty of textbooks on the subject of GSM
network planning and optimization.  From our point of view we just
provide the operator a way to specify a parameter which is then
broadcast to the mobile phones.  It is nothing that OpenBSC/OsmoBTS act
upon or treat in any way.  You simply specify what you want and we pass
it through.

And yes, the "cell reselection" parameters effect excatly
cell-reselection in idle mode.  This is completely unrelated to
hand-over which happens in dedicated mode.  Whether you have hand-over
enabled or how it is configured thus has no influence on cell
reselection and its parameters.

I don't understand your question regarding SIP or re-invite.  If you're
using the rtp_proxy, any hand-overs are completely transparent to MNCC.
You don't even have a way to know a hand-over has happened behind the
MNCC interface.

The proper solution for the two BTSs inside a LiteCell or sysmoBTS 2050
is to run them as one BTS with two TRX.  This way you gain one timeslot,
and you avoid any discussion about unwanted hand-over betwen those two
transceivers.

At sysmocom we never implemented support for this, as there was and
still is insufficient customer interest in the sysmoBTS 2050 to rectify
spending any resources on developing this.

What would be needed is roughly:
* OsmoBTS which can run on a single TRX without assuming that that TRX
  is C0 and transmits a BCCH/CCCH.
* An OML proxy that terminates the OML connection to the BSC and which
  routes messages based on their TRX number to either of the two (or
  "N") instances of OsmoBTS.

At that point, one board in the 2050 runs OsmoBTS for C0, and the OML
proxy.  The other board runs OsmoBTS for C1.  Both OsmoBTS connect to
the OML proxy on C0, and the OML proxy establishes OML to the BSC.  Each
OsmoBTS establishes a separate RSL connection (each from its own IP
address) towards the BSC.

On the BSC side we handle this since 2010 or 2011, as this is also how a
multi-trx setup with nanoBTSs looks like on the Abis side.

All other OsmoBTS-supported Multi-TRX hardware runs all transceivers
with a single OsmoBTS instance, so they don't need the kind of support
required for the 2050.  Hence, we are back to step one:  Somebody would
have to spend some time on the required code.  I'd be more than happy to
review and/or merge any related changes.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)