2g to 3g

[essalvador]

Hi all,

We have a bss system (b9) alcatel 2g , we have to install with those sites alcatel some 3g sites with Huawei equipements: 2 questions:

* which radio parameters to activate in alcatel to enable HO between alcatel 2g sites and Huawei 3g sites.

* Is true : we have to reduce the number of relationship of 2g sites to 16 relations because after the installation of 3g sites we have a HO-relations to add between 2g and 3g sites ? and this operation will affect the KPI of our system now (ho_fail and call_drop_ho) ??

thanks,

[s52d]

Hi all,

We have a bss system (b9) alcatel 2g , we have to install with those sites alcatel some 3g sites with Huawei equipements: 2 questions:

* which radio parameters to activate in alcatel to enable HO between alcatel 2g sites and Huawei 3g sites.

* Is true : we have to reduce the number of relationship of 2g sites to 16 relations because after the installation of 3g sites we have a HO-relations to add between 2g and 3g sites ? and this operation will affect the KPI of our system now (ho_fail and call_drop_ho) ??

thanks,

Hi!
With non-Alcatel BSS we can define handovers. And we do, they work.
But, most operators has no active mode handovers from 2g to 3g.
Logic is: if you are already happy on GSM, just finish the call and move to 3g in idle mode.

So, just define utran BA list and other idle mode parameters, no need or handover relations.
Then, when you are happy with it, try handovers where your 3g coverage outperforms 2g (some 3g only indoor system to motivate users to unlock "gsm only" on their terminals).
If 3g cells are defined, you can use only 31 positions in BA list for GSM cells,
as 32nd is used to report UTRAN neighbors.

On top of it, have you read my post on common LA?

BR
s52d

[essalvador]

Hi!
With non-Alcatel BSS we can define handovers. And we do, they work.
But, most operators has no active mode handovers from 2g to 3g.
Logic is: if you are already happy on GSM, just finish the call and move to 3g in idle mode.

So, just define utran BA list and other idle mode parameters, no need or handover relations.
Then, when you are happy with it, try handovers where your 3g coverage outperforms 2g (some 3g only indoor system to motivate users to unlock "gsm only" on their terminals).
If 3g cells are defined, you can use only 31 positions in BA list for GSM cells,
as 32nd is used to report UTRAN neighbors.

On top of it, have you read my post on common LA?

BR
s52d

Thanks for answer,

* in case of reselect from 2g to 3g (from egprs to umts), we are obliged to declare the relation from 2g sector and 3g sector or not ?? or the declaration in BA list of the an umts frequency is sufficient ?

* yes i have read your post about la.

[s52d]

Thanks for answer,

* in case of reselect from 2g to 3g (from egprs to umts), we are obliged to declare the relation from 2g sector and 3g sector or not ?? or the declaration in BA list of the an umts frequency is sufficient ?

* yes i have read your post about la.

Hello!

For cell reselection, idle mode parameters are fine.
(I know, PBCCH or NACC from 2g to 3g might chage this story).

You have to:
- define UMTS frequencies-code(-diversity) into idle mode list so terminals knows where to listen
- enable scanning for it during idle mode. From all the options, I prefer "allways".
- define criteria when to change (either aboslute or relative to BSS or both; EcNo or RSCP)
For E///, there is no need to define neighbor relations, as cell change is done in idle mode;
we need them for CS handovers in active mode. With another set of parameters....

We had cases of misconfiguration, and users were camping on BSS close to 3G site.
Mostly new sites, before we sync parameters.

BR
s52d

p.s. Common LA helps to minimise unnecessary signaling. For networks that can do it.