- This topic has 11 replies, 1 voice, and was last updated 9 years, 7 months ago by pix.
21st February 2011 at 02:40 #65819MKTGuest
I read sometime back that if BCCH periphery is more than the TCH then some problems can come in call setups, and drops may be high.
Then in case of 900/1800 cells the situation is always like this coz coverage of 1800 is less compared to 900.
Yet, we assigned first priority to 1800 in TCH assignment.
I want to know, when we put 1800 on priority, do some calculations are done by BSC prior to assignment or
it( BSC) will simply check the pool, if 1800 TCH’s are available in the cell, and 900 TCH’s are also available then as per the priorty settings it will allot the 1800 blindly. Of course intracell handovers can occur later on between 1800 and 900.
But, the question is
do the priority works on
AVAILABILITY or some calculations such as distance or TA etc.
MKT21st February 2011 at 19:35 #65820pixGuest
your 1st sentence is confusing. “bcch periphery is more than tCH”. What does it mean ?
BSC will allocate the MS on a 1800 TCH based on rxlev of 1800, traffic_load of 900 and traffic_load of 1800.
Timing advance is usually not taken into account for multiband networks.
Other parameters include “time” during which the MS is around a 1800 cell. If too short, then Ms stays in 900. If longer than a threshold, then it is handover to 1800 cell.
pix22nd February 2011 at 11:08 #65821MKTGuest
Let us take a case when BCCH TRX is serving to a longer distance in comparison to the TCH TRX. In this case when MS initiates a call on BCCH TRX, a situation might occur when there is no TCH free on the BCCH TRX and the BSC allot a TCH on TCH TRX. But the MS is not in the coverage of TCH TRX so hhhhhhjkhsha will happen.
Now in case of 900/1800 cells where the BCCH is on 900 and TCH is on 1800 as well as 900.
I assume the coverage circle of 1800 will be less than the coverage circle of 900 BCCH as well as 900 TCH TRX’s.
Under this scenario,
if the MS who is actually in the coverage circle of 900 BCCH or 900 TCH gets allotted an TCH of 1800 by BSC
then the case i want to discuss will come into effect.
Now, before allotting the TCH of 1800 how can BSC know its RXLEVEL?
It will be only after the MS is allotted the TCH of 1800, the MS measures the RXLEVEL and send it back the BSC will come to know the RXLEVEL.
Regards22nd February 2011 at 12:44 #65822ATTOGuest
For allocation on 1800 band, calculations are done by BSC to see however or not the MS is receiving sufficient level on 1800 band for allocation (others calculations are done too). This is done by appliyng an offset to the rxlev received on 900 band like this:
Rxlev900 band = (approximately) Rxlev1800 + Offset.
This offset is theoriticaly 10 dB but it could be in reality greater or smaller than this value. Optimizations guys have to tune this parameters to better fit the environnement and traffic balancing purposes.
Thanks22nd February 2011 at 14:32 #65823MKTGuest
That’s what i am supposing about the behavior of BSC. BSC can “estimate” about the rxlevel of 1800 based on the rxlevel of 900.
Of course this guess is based on calculations but still it is a guess.
Actually i am thinking of doing one change in few of my cells, where I have more traffic load in the near zone of cell, then comes the fields in between, and then comes a village( i.e. population again)
That is if traverse from BTS to one direction we have
The configuration of cell is 6 TRX( 4 of 900 and 2 of 1800)
Tx pwr of TRX900 is 47 dBm
Tx pwr of TRX1800 is 45 dBm
The 1800 is combiner bypass while 900 is with combiner.
I want to make it as 2 +4 ( 2 TRX of 900 and 4 TRX of 1800)
The picture will be reverse now i.e.
900 without combiner and 1800 with combiner.
This will yield a picture( i can’t draw here) where we will be having 900 coverage circle more than the 1800 coverage circle.
I wish if i can force the traffic in the inner circle( the overlapping zone of 1800 & 900) to 1800 while the traffic on the outer circle to 900.
In this way i will have the advantage of capacity plus coverage both.
But the thought of mind is
Do we have such type of feature in BSC’s where we can make the BSC to allot a preferred TCH on the basis of TA computed from RACH?
If at all, no such parameter exists with any vendor as of now, then
What do you suggest as an alternate.
MKT22nd February 2011 at 14:52 #65824ATTOGuest
No such parameter exist within Alcatel & Ericsson. Not explicitly .
What i’ll suggest to you is to upgrade your 1800 band to 4 TRX. Then make this band as the prefered band for traffic what i mean is to put more load on this band. Then do drive test from near the cell till the village to see if sufficient level is received from 1800 band, if not normally a handover from 1800 to 900 band will be done.
If the level (1800 band) in the village is sufficient enough then you could downgrade the 900 band in order to have this configuration 2 TRX in 900 band and 4 TRX in 1800 band.
The reason why to do this is that 1800 band suffer more from path loss than 900 band.
Regards.22nd February 2011 at 19:49 #65825pixGuest
just to add some info
with your current situation, you can already simulate how good will be your 1800 coverage after the extra-loss.
Do a drive test, located in the 1800 zone.
Remove 5dB from the results.
Are you happy with this reduced coverage ? Can you still cover the 1st village ? Can you also cover part of the 2nd village ?
If yes : go on, add 2 1800MHz trx.
Now, does the second village connect on the 900 TRX or on the 1800 TRX ?
If 900 TRX : can you ensure that only 2 TRX for this village will be enough ?
If yes : downgrade the 900 zone to 2 trx only.
Also, yes you are right : when MS is doing the call setup, it is located on the 900 TRX. The BSC cannot know what will be the exact rxlev in the 1800 trx. Atto explained it well 🙂
pix23rd February 2011 at 15:04 #65826MKTGuest
Thanks Atto & Pix..
One more thing i would like to ask is
if a TCH is occupied by GPRS user(s) will that “use” is reflected as “erlang” in traffic report or is it excluded in the erlang carried by the cell as being a packet traffic and is a part of some other counter in BSC.
MKT24th February 2011 at 07:28 #65827ATTOGuest
I think that GPRS traffic is not counted as “Erlang” in CS traffic report due to this argumentation based on Alcatel Stats:
1) Fixed PDCH timeslots are never taken into account for allocation for voice traffic.
So Max Busy TCH in One Hour = Always Number TCH defined (including PDCH timeslots) – Number fixed PDCH.
2) On A interface, Reports on CS traffic always shows GPRS CIC (s) as Idle even when GPRS traffic was done.
3) When evalutating interference with Idle channel Measurements,idle PDCH timeslots are never taken into account.
regards4th March 2011 at 13:14 #65828babiGuest
Will anyone explain causes of tch unavailability please ?7th March 2011 at 06:44 #65829ManiaGuest
Sorry for being late to post. but you can try having a seperate BCCH for DCS coolocated with the GSM and prefer DCS calls by using C2, CRO and disabling PBGT handovers. Also if you are using SIEMENS then I think there can be allocation to DCS based on TA. similar to TA basedHO for extended cells. Also adding a combine to the DCS would only reduce its coverage pattern.8th March 2011 at 16:26 #65830pixGuest
regarding your “erlang” question:
GPRS users are not included in the RTCH_Erlang_total.
You’ll have to look at the number of busy PDCH to know how many TS are used by GPRS users.