30C3 aftermath

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/osmocom-event-orga@lists.osmocom.org/.

Alexander Chemeris alexander.chemeris at gmail.com
Thu Jan 2 12:48:58 UTC 2014


On Thu, Jan 2, 2014 at 4:32 AM, Sylvain Munaut <246tnt at gmail.com> wrote:
> Hi,
>
>>>> It would be nice if we could sync the L1 of the BTS and use "shared
>>>> ARFCN" where for eg one TS is used by one BTS and another for another
>>>> BTS (dynamically of course so the capacity self-adapts).
>>>
>>> I think that's unrealistic and requires a lot of effort on all layers,
>>> including the BSC who currently has no view at all about that.
>
> The BSC part is almost trivial.
>
> Syncing the L1 is the nearly impossible part ...

This can be done when a GPS signal is available, but we're
in-building, so I tend to agree that this is too hard to do.

>> But I don't see how this could increase capacity, as number of
>> available TSs will stay the same.
>
> It doesn't increase it in absolute terms, but allows to dynamically
> allocate the capacity.
> And it's definitely used in real networks, because my local network
> does it ... with 16 ARFCNs shared for traffic between all the local
> BTSs.
>
> Like, as soon as there is a talk in german in one of the hall, the bts
> serving that hall gets a lot more traffic than when
> If the allocation of TCH is static, then each hall needs the capacity
> to handle peak traffic, which may mean 2 ARFCN for each hall (and
> being right next to each other, you'd need at least 4 ARFCN to cover
> the 3 halls, assuming re-use between the two most distant ones). Now
> if you go with a 1 ARFCN + 1 shared ARFCN per hall, you can handle the
> same peaks in each hall with (2 + 1 ARFCN) ...

For this usecase I think we're fine with the rough granularity
sharing, i.e. sharing on ARFCN level instead of TS level.

Btw, one thing we'll have to take care is to "pack" existing calls
into the non-shared ARFCNs when a shared ARFCN is to be moved to
another BTS. Should not be a big problem, though - just a bunch of
intra-BTS handovers.

>> OTOH, similar balancing can be achieved with the frequency hopping.
>
> ??? What does frequency hopping do for load balancing ???

This is a poor man's load balancing solution. Supposedly it's used in
real life network planning.

The idea is that we can deliberately share some ARFCN between two
closely located frequency-hopping cells. Then, if both cells are
loaded and use those ARFCNs, signal will be degraded due to
interference. But if one cell is under-loaded and other is fully
loaded, then those ARFCNs will be used by the loaded cell with little
to no quality degradation.

This is based on the fact, that frequency hopping is following a
pseudo-random pattern. Thus if two calls share 1 ARFCN out of N, it'll
lead to "some" degradation of quality, which might be tolerable, as we
have good quality coverage at the CCH.

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru




More information about the osmocom-event-orga mailing list