Handover and load balancing on SysmoBTS 2050

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.org
Mon Feb 20 17:06:39 UTC 2017


Hi list, Hi all.

This is quite Rhizomatica, or at least litecel 2050 specific, please
excuse me for that. I also don't know, maybe it applies to other use cases.

Rhizomatica has one community where an attempt was made to increase
coverage at the same time as capacity, by installing two 2050s with a
somewhat overlapping coverage area. We have currently plans to do the
same in other places.

The goal of this email is to try to establish the work needed to be done
in order to fix what I outline below, I may just be lacking knowledge in
some cases, in other It seems we need to implement some things.

I have grabbed fairwaves' meas_json and meas_web and modified a little
to give me a visualisation of the neighbour meas reports.

So my first doubt is about idle cell reselection on the part of the MS.
It doesn't seem to be operating quite as I would imagine it should and I
am wondering is there any parameter that might make a difference, such
as cell_identity? Is cell reselection hysteresis/offset relevant when
handover is disabled? These parameters are not described in the manual.
If I understood them I could update that. In the meantime, we seem to be
getting reports from users that "the signal is weak" near what I might
call the secondary BTS. At the same time, user reports are not terribly
reliable. However what seems to be happening is that the MS is camped on
the primary BTS, subsequently they have moved away so their handset is
showing less 'bars'. I'm sometimes seeing TCH in use on the primary BTS
that are showing neighbour measurements from the secondary that are more
favourable.

Of course, I am often seeing messages such as:

handover_decision.c:203 (bts=3,trx=0,ts=2): Cell on ARFCN 242 is better:
Skipping, Handover disabled

Obviously, this makes sense, and I am not sure why historically we have
handover disabled, I presume it is issues with rtp, although we are
using the rtp_proxy. I don't have two BTS so I can't test locally here.
Could anybody comment on the state of that?

I am assuming that there is no way we can do load balancing unless we
first have handover enabled, at the same time it is unclear to me if it
will even work with handover.  I believe this is called "Traffic
Handover" Is this already implemented in the BSC? As in, can the BSC
assign a channel on another ARFCN to the MS if the current ARFCN (the
one the MS makes the access request on) has no TCH available?

I also have a doubt about operation with a Litecel/2050. Obviously you
don't really want rescue handover operating between the two BTS that are
present in the Litecel as it is the same antenna, and this shouldn't
happen anyway as the signal levels should never be sufficiently
different, but we do want load balancing handover. I do see "no
resources available" log messages, (especially related to the BROKEN
channels issue) when one BTS in a litecel has no more capacity but the
other does, so it would seem that the BSC is not managing this. Is that
correct?

Would it be correct to assume that maybe some handover rules are
required that would specify: Handover from BTS 0 to BTS 3 but not from
BTS 0 to BTS 1?

Finally, I have a doubt about the rtp proxy mode. Was it ever discussed
to implement SIP Mobility aka re-Invite in order to be able to do
BTS-MGW rtp and also handover? This would seem to me to be a good thing
to have?


k/








More information about the OpenBSC mailing list