Sunteți pe pagina 1din 3

Hello friends, Can anybody suggest to me how to improve Irat PS, my CS Irats is very good but my PS Irat is poor.

I will appreciate your suggestions.


Check the Gb link utilization,RPP /Garb card utilization.In 2G end check FPDCH there any soft blocking.. For Improving the PS IRAT you can enable the BSIC verification for PS calls as well. Since GSM radio network planning, that is, overlapping GSM frequencies and missing ADJG definitions, can cause unsuccessful handovers from WCDMA to GSM if BSIC of target cell is not verified before triggering the handover which can cause a decrease of the success rate in ISHO 3G to 2G for PS calls (in case of this kind of network configuration). So This problem of GSM Radio Network planning can be avoided with a new RNC implementation,where BSIC is always verified also in case of PS NRT calls. As suggested above by both experts we need to check if there is Execution failure Rate on 2G , If it is really high then need to check the 2G Frequency plan and also if ther is mismatch of 2G Parameters configured on 3G ( BCCH,BSIC( BCC,NCC) Normally if we have mistmatch of values configured on 3G, then duirng the compressed mode UE Will not report the right besterver of 2g which means that it might report far off 2G Cell which migh lead to Handover failures later if there are no enough GPRS Timeslots configured on 2G Side, there will be failures due to congestion Aapart from these factors, we need to chekc for PS at what threshold we are trigeering Handovers. If threshold is too low, then in very bad radio conditions before triggering the Handovers to 2G we might drop the call( Case of Indoors fro instance) This threshodl depends on the Operator as some operators try to configure paramters from user point of view as they will keep the thrshold too low sacrificing the PS drops rate and ISHO NRT Rate If your CS IRAT HO is good then you should have no problems with 2G parameters because you have successful IRAT HOs...but then you need to qualify this...check how many attempts you have for CS and PS....then check your compressed mode thresholds in PS as compared to CS....you can start from there... Usually the PS IRAT is worse than CS, it is normal, because CS IRAT threshold is lower than PS threshold, this is to decrease the CS call drop and improve the user feeling. But for PS, it is different, we try to make user stay in 3G, because 2G data rate is very low, and they are not so sensitive to call drop, they care more about data rate. Pls confirm if it's reasonable. You have Huawei vedor or any other. check the failure is due to Phyical channel failure, Cfg unspported, UE No reply, or failing in relocation. BTW your CS IRAT is blind HO or coverage level? To improve IRAT CC you may increase IuPs timing offset.

Hi Experts, Can u share your knowledge on how HS-DSCH in HSDPA are shared among different users, and how many uses can simultaneously occupy the channel???
HSDPA is a 'shared' concept. It means that the resources such as codes and power are shared among users. The scheduler will schedule each user in each TTI according to algorithm (licensed and/or parameter controlled). As for the max sinultaneous users, it depends on parameter to control the number of HS-SCCH codes per TTI which can be set up to a maximum of 4. This means that 4 users are able to be scheduled in one TTI(sharing a total of 15 codes). Max users are also vendor specific. As far as I know, NSN supports up to 72 max users while Huawei supports up to 96 users per cell. NSN support up to 128 users per cell. Another questions - recommendation for number HS-SCCH codes in cell parameters -3 or 4 - what is the optimal value? Max 4? Max 4 when you have a low value of measurement power offset ( like 4-5 dB). When you have a high value (like 6-7 dB) it is better to keep it to 3 the number of H-SCCH. You will see from stats that less than 3-4% of the time scheduler will schedule 4 users in the same TTI. It also depends on reported CQI distribution and available power on cell. I would say it is cell by cell decision. On cells with low traffic you can even have it to 2. It depends on traffic per cell. Huawei only supports up to 64 HSDPA User per cell, there are a feature that increase to 96 users, BUT only to VoIP traffic (Very low traffic demand). Well, max number of users in HSDPA is related with max num of users in one TTI( 2ms) which is HS-SCCH. It will be more better when you have code multiplexing rather than time multiplexing. If there is 15 codes and HS-SCCH is 3; users are allocated accordingly with 5/5/5 codes in shared environment.

Please a question, what do you mean with "measurement power offset"?, I'm a little bit confuse. Could you explain me please? Please see explanation below for parameter " HS-PDSCH MPO Constant" This parameter named Measure Power Offset Constant is used to compute measurement power offset. Measurement power offset is used by UE to obtain total received HS-PDSCH power. The calculation for Measure Power Offset is as shown below: Measure Power Offset = Max(-6, Min(13,CellMaxPower - PcpichPower - Measure Power OffsetConstant)). For details of the IE "Measure Power Offset", refer to 3GPP TS 25.214. In RAN13 there can be up to 128 users per cell. This is decided in object UCELLCAC parameter MAXHSDPAUSERNUM. Usually there are other limitations and this number is really hard to achieve. What is the optimal value for Tx & Rx Power in UMTS Network. There's no optimal power; it is rather an operating range in both UL and DL adjusted by power

control in uplink and downlink. dynamic range for NodeB : TX power for a RL (radiolink) can go as much as +8dB more than CPICH channel and as low as -15 dB than CPICH. Typical value of CPICH is 33 dBm RX power for a RL can go as much as UL interference( that could be even -90 or -80 dBm) and as low as -110dBm (nodeB sensitivity varies up to +/- 4dB from a value of -106 dBm ) dynamic range for UE: TX power can be as much as 24 dBm( depending on UE class type) and as low as -50 dBm RX power can be as low as -125dBm (UE sensitivity dependant) and as much as -45 dBm( more or less depending on UE class) Those are all relative values. It depends much on DL and UL synchronization timers and constants ( all values in SIB1 in UMTS) that will decide when to interrupt power control on a radio link (when out of sync and RL failure is triggered). It also depends on specific UE and NodeB sensitivities and power classes. What is the most important thing to check if I want to provide HSDPA throughput comparatively higher. Actually, some situations seen like it has lots of variations( between 4mbps to 200kbps) when I check DL from FTP. Hi Ranjit, very few basic rules : establish a clear and steady best server everywhere with good RF( EcIo>-9 dB, RSCP>-90 dBm), reduce SHO as much as possible, make sure there is no bottleneck( codes, power, users, licenses, IuB, flow control, no external interference), make sure default parameters are not messed up, activate all features ( 16 QAM, 64 QAM, MIMO, DCHSDPA when/where available) and all will be great. As long as you have good coverage all will be ok

In cell breathing, does the actual received level decreases at the edge of cell????
RSSI will be the same but RSCP and EcIo will degrade according to traffic increase. The answer is yes, both RSCP and EcIo will degrade with 2 up to 5 dB. For example with no HSDPA traffic RSSI=-90 dBm, RSCP=-93 dBm, EcIo=-3 dB. With light HSDPA traffic( that means not all codes used, not all TTis, not all power, not 100% usage of 16 QAM, not 100% usage of 2msec TTI) new values will be RSSI=-90 dBm, RSCP=-95 dBm, EcIo=- 5dB.With heavy HSDPA traffic( all 16 codes used,all TTis used, more than 70%of the power used,100% usage of 16 QAM, 100% usage of 2msec TTI) new values will be RSSI=-90 dBm, RSCP=-98 dBm, EcIo=- 8dB. This is why cell breath phenomenon occurs. One mobile that used to have EcIo=-17 dB ( cell having Qqualmin=18dB) cannot make calls anymore since his new EcIo will be EcIo=-19 dB so current cell will not be eligible anymore and UE will forcily reselect another cell or another RAT

S-ar putea să vă placă și