Handover and load balancing on SysmoBTS 2050

historical

Dear Harald,

I noticed this part:

> Even PCU integration for GRPS support is coming up.

Can I ask how specific will that part be to the RBS2000?

I have Nokia Ultra and MetroSite sets (both with EDGE capability), the EDAP part is accessbile, but I was not able to find a lot of details about the Nokia Abis implementation, especially of the PCU part.

Thanks!

Csaba

----- Eredeti üzenet -----
Feladó: "Harald Welte" <laforge at gnumonks.org>
Címzett: "Keith" <keith at rhizomatica.org>
Másolatot kap: "OpenBSC Mailing List" <openbsc at lists.osmocom.org>
Elküldött üzenetek: Kedd, 2017. Február 21. 16:14:05
Tárgy: Re: Handover and load balancing on SysmoBTS 2050

Hi Keith,

On Tue, Feb 21, 2017 at 03:40:54PM +0100, Keith wrote:
> 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.

this is expected, as per GSM architecture such as system should operate
as two TRXs of one BTS and not as two BTSs.  No "normal" operator would
put two BTSs with same transmit power and same coverage in place.

> Increasing handover power budget hysteresis a lot, >=15dB  of course
> tames that, but surprisingly does not eliminate it. 

This might relate to the fact that the power control loop algorithm is
very simplistic and has a tendency to oscillate.  It has been a
long-time TODO item to avoid the algorithm in the PHY and use a more
dampened algorithm with a PID or kalman filter in OsmoBTS.  But then,
there are so many open TODO items for so many years :/

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

Just a quick response: jolly implemented "traffic handover" aka "load
balancing" 3 years ago as part of a branch (I believe for a customer),
but unfortunately this never was merged back to master.

Meanwhile, we already have all the code for execution of hand-overs in
place.  We also have dynamic timeslots in place.  So the "mechanics"
should all be there to add the two missing features from those old
branches:
a) de-fragmenting of channels (i.e. merging two separate TCH/H into one
   timeslot, so the other timeslot can be switched to TCH/F or PDCH on
   demand
b) load/traffic based hand-over

see jolly/new_handover and jolly/dyn_pdch branches.

> Or what is the intended strategy for increasing channel capacity at a site? 

The general strategy I would normally assume is to
* switch to half-rate channels with AMR whenever possible
* use dynamic channel switching to switch between TCH/H (default) and
  TCH/F (if neded)
* use BTSs with more TRX.  Even high-end Ericsson equipment supporting
  up to 3 sectors of 4 TRX each (12 TRX) is actaully available
  surprisingly inexpensive these days.  We've recently done some
  improvements in Ericsson RBS2000 support.  Even PCU integration for
  GRPS support is coming up.
-- 
- 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)