Escolar Documentos
Profissional Documentos
Cultura Documentos
Huawei Workshop
Troubleshooting Access Failures
18. COMMON ID
RANAP RANAP
23. DT [ SETUP ]
RANAP RANAP
40. DT [ ALERTING ]
RANAP RANAP
41. ACM
ISUP
42. DCCH: ULDT [ CONNECT ] <AM>
RRC RRC
• RF Reasons
• Miscellaneous causes
When -22>EcIo>-18 ; 80%>RRC_SR>20% When -18>EcIo>-16 ; 95%>RRC_SR>80% When -16>EcIo>-2 then RRC_SR>95%
•Transmission issues (fluctuating PATH, high BER, reduced capacity, routers down in the IP
cloud).
•Planning issues: traffic not properly shared between layers and NodeB, lack of a clear best
server( no dominance), paging congestion due to LAC splitting issue.
•Radio Congestion:
• CE
• DL Power
• UL Power
• R99 Codes
• Iub bandwidth
• SPU bottleneck
• WMPT board bottleneck
Where there any alarms on investigated cells (or any of it's Every morning there should be an email with cells unavailable on previous day and
YES NO
neighbouring cells, intra or inter) ? duration of unavailability.
Is it a repetitive failure or a "one time" event? YES NO If one time event, please wait one more day before to conclude. Could be a social event
Is the SHO factor less than 50%? YES NO If not, please review its best server area, tilt, azimuth and CPICH power
Is this cell having full overlapping with other neighbouring cells? ( i.e.
there's no direction user can move without having good coverage). Is If no review your targeted coverage and accept current limitations and constraints due
YES NO
any user, in any indoor environment within the footprint of this cell, to location and/or number of Node-Bs.
able to get a decent RSCP and EcIo?
Is the height of the antenna less than 100m? YES NO If No, please do not expect a good RRC Success rate.
If no (and footprint is on a plain terrain) please take immediate actions to increase downtilt.
Is the total tilt of the cell more than 3 degree downtilt? YES NO Antenna RF pattern is hardly touching the ground, users are handled on side lobes. DL
Power issues will occur.
is the cell Idle sintrasearch=127? YES NO If no, please do not expect a good RRC Success rate.
is the cell idleQoffset1sn<4? YES NO If no, please do not expect a good RRC Success rate with idleQoffset1sn>4dB
is the cell Idle idleQoffset2sn<2? YES NO If no, please do not expect a good RRC Success rate with idleQoffset2sn>4dB
is the cell idleQhyst1<4? YES NO If no, please do not expect a good RRC Success rate with idleQhyst1>4dB
is the cell idleQhyst2<2? YES NO If no, please do not expect a good RRC Success rate with idleQhyst2>4dB
Sum of VS.RRC.Rej.ULIUBBand.Cong 0 0 0 0
Sum of VS.RRC.Rej.ULPower.Cong 14 10 0 0
Sum of VS.RRC.Rej.DLPower.Cong 135 118 1965 290
Sum of VS.RRC.Rej.DLIUBBand.Cong 0 0 0 0
SPU board is the issue when Solution: Open a ticket to TAC (should not
Identify if RRC failures for a cell are due to SPU : (check YES (VS.RRC.SuccConnEstabCPU /
ADD NODEB command to find the SPU for a cell/Node-B) . happen after SPH226)
VS.RRC.AttConnEstabCPU)
<97% (daily stats)
NO
YES
Solution: On the RNC LMT, run the PING IP command to the IP of the NodeB
VS.RRC.Rej.ULIUBBand.Cong
during failing hours. If packet loss rate is greater than 0.1% please contact
VS.RRC.Rej.DLIUBBand.Cong
transmission engineers (to troubleshoot or upgrade)
Check configuration(ULTOTALEQUSERNUM=160;
NBMULCACALGOSELSWITCH=ALGORITHM_SECOND). Solution: Increase
VS.RRC.Rej.ULPower.Cong
ULTOTALEQUSERNUM to 180. If still failing: add carrier or reduce/balance traffic to
other layers/cells.
NO
Solution per cell: ???
VS.RRC.Rej.DLCE.Cong Solution per RNC: decrease DLGBR from 64 to 32 for specific services
Identify if more than 10% of failures for a cell are due to Solution 1: If failures correlated with VS.IUB.FailRLSetup.NoReply
VS.RRC.Rej.Rl.Fail then it is WMPT board congestion( add UTRP Board)
RL.Failure :
Solution 2: run the PING IP command on the IP of the NodeB to detect congestion
on the IuB.
Solution 3: If failures correlated with RLM.FailRLSetupIub.Cong then it is WBBP
GO TO NEXT SLIDE board congestion
VS.CRNCIubBytesFACH.Tx or
VS.CRNCIubBytesPSR99.CCH.Tx Solution1: Offload traffic
are flat in time( limited)
NO
•. Data cellID=yyyyy
Sum of VS.RRC.AttConnEstab.Sum 73083
Sum of Cell.RRC.Att.Fail 17110
Sum of VS.RRC.Rej.Redir.Service 0
Sum of VS.RRC.Rej.ULIUBBand.Cong 0
Sum of VS.RRC.Rej.ULPower.Cong 0
Sum of VS.RRC.Rej.DLPower.Cong 163
Sum of VS.RRC.Rej.DLIUBBand.Cong 0
Sum of VS.RRC.Rej.ULCE.Cong 0
Sum of VS.RRC.Rej.DLCE.Cong 0
Sum of VS.RRC.Rej.Code.Cong 0
Sum of VS.RRC.Rej.RL.Fail 0
Sum of VS.RRC.Rej.TNL.Fail 0
Sum of VS.RRC.FailConnEstab.Cong 163
Sum of VS.RRC.Rej.Sum 163
Sum of VS.RRC.FailConnEstab.NoReply 16944
Sum of VS.RRC.SetupConnEstab 72920
Sum of RRC.SuccConnEstab.sum 55973
RRC_SR 76.59%
Here are most of
the RRC failures
occurring
indicating poor
UL coverage
(overshooting)
Data cellID=yyyyy
•.
Sum of VS.RRC.AttConnEstab.Sum 75048
Sum of Cell.RRC.Att.Fail 5324
Sum of VS.RRC.Rej.Redir.Service 0
Sum of VS.RRC.Rej.ULIUBBand.Cong 0
Sum of VS.RRC.Rej.ULPower.Cong 0
Sum of VS.RRC.Rej.DLPower.Cong 115
Sum of VS.RRC.Rej.DLIUBBand.Cong 0
Sum of VS.RRC.Rej.ULCE.Cong 0
Sum of VS.RRC.Rej.DLCE.Cong 0
Sum of VS.RRC.Rej.Code.Cong 0
Sum of VS.RRC.Rej.RL.Fail 0
Sum of VS.RRC.Rej.TNL.Fail 0
Sum of VS.RRC.FailConnEstab.Cong 115
Sum of VS.RRC.Rej.Sum 115
Sum of VS.RRC.FailConnEstab.NoReply 5208
Sum of VS.RRC.SetupConnEstab 74933
Sum of RRC.SuccConnEstab.sum 69724
RRC_SR 92.91%
•.
Data cellID=yyyyy
Sum of VS.RRC.AttConnEstab.Sum 39512
Sum of Cell.RRC.Att.Fail 2602
Sum of VS.RRC.Rej.Redir.Service 0
Sum of VS.RRC.Rej.ULIUBBand.Cong 0
Sum of VS.RRC.Rej.ULPower.Cong 0
Sum of VS.RRC.Rej.DLPower.Cong 0
Sum of VS.RRC.Rej.DLIUBBand.Cong 0
Sum of VS.RRC.Rej.ULCE.Cong 0
Sum of VS.RRC.Rej.DLCE.Cong 0
Sum of VS.RRC.Rej.Code.Cong 0
Sum of VS.RRC.Rej.RL.Fail 0
Sum of VS.RRC.Rej.TNL.Fail 0
Sum of VS.RRC.FailConnEstab.Cong 0
Sum of VS.RRC.Rej.Sum 0
Sum of VS.RRC.FailConnEstab.NoReply 2602
Sum of VS.RRC.SetupConnEstab 39512
Sum of RRC.SuccConnEstab.sum 36910
RRC_SR 93.41%
•.
Data cellID=yyyyy
Sum of VS.RRC.AttConnEstab.Sum 75162
Sum of Cell.RRC.Att.Fail 3583
Sum of VS.RRC.Rej.Redir.Service 0
Sum of VS.RRC.Rej.ULIUBBand.Cong 0
Sum of VS.RRC.Rej.ULPower.Cong 0
Sum of VS.RRC.Rej.DLPower.Cong 439
Sum of VS.RRC.Rej.DLIUBBand.Cong 0
Sum of VS.RRC.Rej.ULCE.Cong 0
Sum of VS.RRC.Rej.DLCE.Cong 0
Sum of VS.RRC.Rej.Code.Cong 4
Sum of VS.RRC.Rej.RL.Fail 0
Sum of VS.RRC.Rej.TNL.Fail 0
Sum of VS.RRC.FailConnEstab.Cong 443
Sum of VS.RRC.Rej.Sum 443
– SCCPCH (Secondary
Common Control
Physical Channel). It
carries paging messages
themselves as well as
packet messages for
mobiles in cell FACH.
2 Physical channels:
– PICH (Paging Indicating
Channel): This is just to
inform the UE that it
needs to initiate an RRC
Connection request.
Those are the details for 2nd SCCPCH
this channel.
Paging
ocassion
Paging
Paging message
indicator (3 IMSI or
5 TMSI)
PO= {(IMSI div K) mod (DRX cycle length div PBP)} * PBP + n * DRX cycle length + Frame Offset
Where n = 0,1,2… as long as SFN is below its maximum value ,for FDD PBP=1
•
DRXcycle=7=>128 frames
Frame offset =-7860 chips
PBP=1
K=1 (there„s only one S-CCPCH that carries PCH)
PI=Np=36
PO= (IMSI)mod128+ n* 128 -7860 chips
PI=(IMSI/8192) mod36
• More bits inside a PI means a greater probability to decode the paging indicator but less capacity of the paging channel and power
consumption for UE. Less bits means a lower probability for the UE to decode the paging indicator but longer battery life of the UE. Best
solution is a mid-way one: PI=36.
• •
HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
Paging Access Failure Troubleshooting-(VII)
From all this information what do you need to know?:
• there can be several places where paging could get congested: Iu interface, IuB
interface, RNC boards, or PCH interface . PICH channel is the only channel that
is never congested!
• Check with CN how many paging repetitions have, how do they page: by IMSI or
by TMSI. If first paging fails how many repetitions? Last paging is network wide or
LAC wide only?
• --- is currently facing PCH channel load: all smart phones are in cell PCH state. In
this state can only receive paging but can not transmit any data. Any paging for a
UE it is sent specifically to that cell. How RNC knows where is such an UE? By
cell update!. Every time UE changes the cell in cell PCH there is a cell
•
update+cellupdate confirm, utran mobility information confirm. That means that
the RNC is aware about new location of the UE.
• How much is the paging success now in --- network?
• What solutions we have to offload the PCH channel?:
• LAC split.
• Page by TMSI
• Reduce ping-pongs (and reselections)
• Improve best server area and reduce overlapping
No performance
indicators. Only
estimation by RTWP,
load of the RACH
channel etc..
Enough performance
counters
Max_TX_power_on_PRACH
NB01
Power_Ramp_Step :
Pp-m :
Message
Preamble_Initial_Power :
…. …. part
Uplink/UE/PRACH Preamble 1 Preamble n
Preamble_Retrans_Max : AICH_Transmission_Timing
•
• Missing neighbours, lack of best server area and poor UL coverage
influence a lot the RACH success rate.
• Cell radius is now at 29.000 km. Make sure there are no UE from a
larger distance(path distance) else will fail on RACH.