21 Feb
2017
21 Feb
'17
10:08 p.m.
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(a)gnumonks.org>
Címzett: "Keith" <keith(a)rhizomatica.org>
Másolatot kap: "OpenBSC Mailing List" <openbsc(a)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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)