Access Failures Troubleshooting Workshop

(1)

Security Level:

47pt 30pt Color::white : FrutigerNext LT Medium Font to be used by customers and

: Arial

www.huawei.com

Huawei Workshop

Troubleshooting Access Failures

(2)

35pt

Font to be used by customers and partners :

18pt

• Call Setup Procedure (step by step & all protocols)

• General Causes of failures

• How to chase and to solve specific access failures:

 RRC Access Failure Troubleshooting.

 Paging Access Failure Troubleshooting

 RACH Access Failure Troubleshooting

(3)

35pt

18pt

Mobile Terminated Call Setup Procedure (I)

UE Node B RNC MSC / VLR MGW RRC 3. PCH: PCCH: PAGING TYPE 1 <TM> RRC 2. PAGING RANAP RANAP RRC

4. RACH: CCCH: RRC CONNECTION REQUEST <TM>

RRC

1. IAM ISUP

5. RADIO LINK SETUP REQUEST

6. RADIO LINK SETUP RESPONSE

9. DOWNLINK SYNCHRONISATION

12. SYNCH IND

7. ESTABLISHMENT REQUEST (AAL2)

8. ESTABLISHMENT CONFIRM (AAL2) Start RX NBAP NBAP NBAP NBAP ALCAP ALCAP ALCAP ALCAP DCH-FP DCH-FP L1 L1 Start TX

11. FACH: CCCH: RRC CONNECTION SETUP <UM>

RRC RRC

14. DCCH: RRC CONNECTION SETUP COMPLETE <AM>

RRC RRC

10. UPLINK SYNCHRONISATION

DCH-FP DCH-FP

13. RADIO LINK RESTORE INDICATION

NBAP NBAP

Can be either RRC Connection setup (to this cell

and or inter freq to another one when DRD) or Reject.

Here the Node-B will start RL with DL transmission

Here the UE will start to send the PRACH and wait for AICH and then send RACH message

Here the UE will do DL synchronization (using N312=1, T312=1, N313=20 andT313=3) . Then the UE will start UL TX transmission and the Node-B will detect UL SYNCH (based on N_INSYNCIND=8, N_OUTOFSYNCIND=8,TRLFAILURE=20)

Here the RNC will perform a DRD decision

and CAC decision for RRC

(4)

35pt

18pt

Mobile Terminated Call Setup Procedure (II)

UE Node B RNC MSC / VLR MGW

28. RAB ASSIGNMENT REQUEST

RANAP RANAP

26. DT [ CALL CONFIRMED]

RANAP RANAP

25. DCCH: ULDT [ CALL CONFIRMED ] <AM>

RRC RRC 24. DCCH: DLDT [ SETUP ] <AM> RRC RRC RANAP RANAP

15. DCCH: INITIAL DT [ PAGING RESPONSE ] <AM>

RRC RRC RANAP RANAP RRC RRC RRC RRC

19. SECURITY MODE COMMAND

RANAP RANAP

20. SECURITY MODE COMMAND

21. SECURITY MODE COMPLETE

22. SECURITY MODE COMPLETE 16. SCCP CONNECTION RQ [

INITIAL UE MESSAGE [PAGING RESPONSE ] ]

27. BINDING ID, SPEECH CODE TYPE, B PARTY

ROUTE RANAP RANAP 18. COMMON ID 23. DT [ SETUP] 17. SCCP CONNECTION CONFIRM SCCP SCCP SCCP SCCP

Here the RNC will perform a DRD decision

(5)

35pt

18pt

Mobile Terminated Call Setup Procedure (III)

UE Node B RNC MSC / VLR MGW

46. DT [ CONNECT ACK] 46. DCCH: DLDT [ CONNECT ACK ] <AM>

RANAP RANAP

RRC RRC

39. DCCH: ULDT [ ALERTING ] <AM>

40. DT [ ALERTING]

RANAP RANAP

RRC RRC

42. DCCH: ULDT [ CONNECT ] <AM>

43. DT [ CONNECT]

RANAP RANAP

RRC RRC

37. RAB ASSIGNMENT RESPONSE

RANAP RANAP

41. ACM ISUP

47. ANS (CONNECT) ISUP

36. DCCH: RADIO BEARER SETUP <AM>

38. DCCH: RADIO BEARER SETUP COMPLETE <AM>

RRC

RRC RRC

RRC

29. ESTABLISHMENT REQUEST ( AAL2 )

30. ESTABLISHMENT CONFIRM ( AAL2 ) ALCAP

ALCAP ALCAP

ALCAP

33. ESTABLISHMENT REQUEST (AAL2)

34. ESTABLISHMENT CONFIRM (AAL2)

ALCAP

ALCAP ALCAP

ALCAP

31. RADIO LINK RECONFIG PREPARE

32. RADIO LINK RECONFIG READY

NBAP NBAP

44. OPEN CONNECTION 35. RADIO LINK RECONFIG COMMIT

NBAP NBAP Terminating UEs are considered to be in a call after CC Connect ACK

Originating UEs are considered to be in a call after CC Connect message

(6)

35pt

18pt

General Causes of failures (I)

• RF Reasons

• Radio Parameter Problems

(7)

35pt

18pt

General Causes of failures - RF reasons (II)

 Poor DL coverage.

The “fake coverage” phenomenon (the user sees the 3G icon on the screen in

idle but cannot connect to any service). The cause could be overshooting cells but also excessive

values of Qqualmin like -22 dB. Solution: Adjust the antenna azimuth and down tilt, add repeaters and

RRUs, add micro cells. Any user should get a better signal than EcIo = -18 dB.

 Lack of Dominance (no clear Best server

): Continuous change of best server leads to

RRC failures and RAB failures.Solution: Establish a best server everywhere. Clear dominance.

 Poor UL coverage:

The UE has not enough TX power to communicate with Node-B (even when

there is low UL traffic on the cell). Solution: Adjust the antenna azimuth and down tilt, add repeaters,

reduce CPICH power.

 Strong UL interference:

Due to external interference or high UL traffic (the cell shrinking

phenomenon). The UE will not be able to increase to more than 21 dBm for the preamble power and the

RACH will fail - or synch will fail later. Solution: Up to operator‟s decision (implement more tilt ,CPICH

power reduction, chase external source of interference or increase the number of Node-Bs to cope with

traffic)

 Strong DL interference:

Usually due to overshooting cell, external interference, high DL traffic

on this cell and surrounding cells. The UE will miss the AI message for RACH and will fail to establish a

call - or will fail to get synch in DL. Solution: Improve best server area (strong dominance)

 RF radiating system problems:

 Antenna‟s footprint not touching the ground properly: sites with over 120 m height and tilts around 3 degrees. More than 3/4 of the

antenna pattern will not be touching the ground with a decent level of signal. Most calls are handled on side lobes.

 RF jumpers (feeding the antennas with RRU signal) are too long (should be no more than 3 meters, we‟ve seen cases in --- with 10

meters of ½” jumpers). This definitely leads to high noise factors and call setup failures. Also UL and DL coverage is very much limited.

(8)

35pt

18pt

Poor DL coverage.



The “Fake coverage” phenomenon (user gets the 3G icon on his screen in idle but either cannot pass an RRC or a

RAB). Cause is overshooting cells but also excessive values of Qqualmin like -22 dB. Solution: Adjust the antenna

azimuth and down tilt, add repeaters and RRUs, add micro cells, improve best server, change Qqualmin. Any user

should get a better signal than EcIo=-18 dB. If this level cannot be achieved it is better to display ” no service” on.

user screen.

When -16>EcIo>-2 then RRC_SR>95% When -18>EcIo>-16 ; 95%>RRC_SR>80%

When -22>EcIo>-18 ; 80%>RRC_SR>20%

User experience: 3G icon,3G signal

bars, great service accessibility. User „s

perception: Very Positive. User experience: 3G icon,3G signal

bar, good service accessibility. User „s

perception: Positive. User experience: 3G icon, no 3G bar, no

service accessibility. User „s perception:

Very negative.

Qqualmin

PRO

CONS

Comments

-22 dB

• User always see the 3G icon

on his phone‟s screen (although

it‟s a “fake” coverage the user

does not always attempt to use

the service)

•Maximum traffic possible

• Bad customer experience but less

NW signalling.

•Not all call attempts are counted

(not a clear perception of

accessibility).

Will grab all extreme

traffic leading quickly into

DL Power congestion and

accessibility issues.

-18 dB

• The user will not always have

the 3G

Icon on his phone‟s

screen (but when icon is

present service is 100%

accessible)

• Potential traffic decrease

• Great and real customer

experience but increased signalling

(coverage lost);

• All “Call attempts” are counted

(better performance perception of

accessibility) due to this RRC_SR

KPI may (or may not) be

improved.

No more “fake coverage”.

Decrease in DL Power

Congestion.

(9)

35pt

18pt

General Causes of failures – Radio Parameter Problems(II)

• Excessive values in object UCELLSELRESEL: Examples:

Qqualmin<-18

,

IDLESINTRASEARCH ≠ 127,

IDLEQHYST2S>1, IDLEQHYST1S>3.

• Improper settings of access parameters

:

No discrepancies found in UCELLACCESSRESTRICT

• Inappropriate settings of preamble power ramp step and retransmission times

:

Current set of

parameters is NOK (PREAMBLERETRANSMAX=20, CONSTANTVALUE-20, PowerRampStep=2, Mmax=8).

• Inappropriate setting of adjacent cells for UINTRAFREQNCELL

:

Qoffset1sn, Qoofset2sn out of the

range (-4dB;+4dB). Wrong settings for Sintra (like 0 dB), Sinter( also like 0 dB).

• Inappropriate settings of synchronization parameters

:

Synch and Out-Of-Synch parameters for UL

(N_INSYNC_IND=8, N_OUTSYNC_IND=8,and T_RLFAILURE=20), DL (T312=1, N312=1, N313=D20 ,T313=3 and

N315=D20). Please remember that call re-establishment is activated for both UL and DL (great KPIs but

acceptable user

perception

)

• Unsuitable power allocation rate for DL common channel

:

No discrepancies found (PSCHPower,

SSCHPower, BCHPower , MaxFachPower, PCHPower, AICHPowerOffset, PICHPowerOffset)

• Unsuitable initial power of uplink and downlink dedicated channel

:

No discrepancies found for UL

(DPCCH_Initial_Power = PCPICHPower - CPICH_RSCP + Uplink interference + DefaultConstantValue) and DL initial SIR

target

• Unsuitable setting of uplink Initial SIR target value of dedicated channel:

No discrepancies found for

DL initial SIR Target

• Inappropriate setting of adjacent cells for UINTERFREQNCELL:

• When 1900 and 850 MHz have significant azimuth difference why there is DRD just towards one 1900 cell and

not for the other 1900 cell as well?

(10)

35pt

18pt

General Causes of failures –Miscellaneous causes(II)

•Transmission issues (fluctuating PATH, high BER, reduced capacity, routers down in the IP

cloud).

•Alarms on cells, on Node-Bs, on RNC, on transmission

•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

(11)

35pt

18pt

(12)

35pt

18pt

RRC Access Failure Troubleshooting (I)

Is cell/NodeB/RNC configuration the correct one? YES NO Should be done daily (automatically and network wide) based on a defined template.

Where there any alarms on investigated cells (or any of it's

neighbouring cells, intra or inter) ? YES NO

Every morning there should be an email with cells unavailable on previous day and 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

If a repetitive failure (according to KPI values in the past) is it a slowly degradation (with traffic increase) or an event one (degraded

seriously from a specific moment)?

YES NO If event one, go back to that day and see what was changed at that time and reconsider that change

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 any user, in any indoor environment within the footprint of this cell,

able to get a decent RSCP and EcIo?

YES NO If no review your targeted coverage and accept current limitations and constraints due

to location and/or number of Node-Bs.

Is the height of the antenna less than 100m? YES NO If No, please do not expect a good RRC Success rate.

Is the total tilt of the cell more than 3 degree downtilt? YES NO

If no (and footprint is on a plain terrain) please take immediate actions to increase downtilt. 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

(13)

35pt

18pt

Font to be used by customers and partners : Date---- RNC1 RNC2 RNC3 RNC4 Sum of VS.RRC.AttConnEstab.Sum 6154003 7115377 5397822 1920647 Sum of Cell.RRC.Att.Fail 46702 73768 87275 12471 Sum of VS.RRC.Rej.Redir.Service 0 0 0 0 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 Sum of VS.RRC.Rej.ULCE.Cong 1144 1352 721 507 Sum of VS.RRC.Rej.DLCE.Cong 822 11 0 0 Sum of VS.RRC.Rej.Code.Cong 12 41 372 0 Sum of VS.RRC.Rej.RL.Fail 30 50 419 0 Sum of VS.RRC.Rej.TNL.Fail 0 0 0 0 Sum of VS.RRC.FailConnEstab.Cong 2343 1552 3070 802 Sum of VS.RRC.Rej.Sum 2373 1602 3489 802 Sum of VS.RRC.SetupConnEstab 6151630 7113775 5394333 1919845 Sum of VS.RRC.FailConnEstab.NoReply 44006 71818 83566 11667 Sum of RRC.SuccConnEstab.sum 6107301 7041609 5310547 1908176

Conclusion: Most RRC failures (over 90%) are due to RRC no reply. For RRC issues, focus on overshooting cells first (to solve No reply), second

on congested cells.

Here are most of the RRC failures

occurring indicating poor

UL coverage (overshooting)

(14)

35pt

18pt

RRC Access Failure Troubleshooting (III)

Identify if RRC failures for a cell are due to SPU : (check ADD NODEB command to find the SPU for a cell/Node-B) .

Identify top N cells (more than 2000 RRC attempts per day and success rate is less

than 98%)

SPU board is the issue when (VS.RRC.SuccConnEstabCPU /

VS.RRC.AttConnEstabCPU) <97% (daily stats)

Solution: Open a ticket to TAC (should not happen after SPH226)

Identify if more than 10% of the failures for a cell are due to congestion :

YES NO

YES

Solution: On the RNC LMT, run the PING IP command to the IP of the NodeB

during failing hours. If packet loss rate is greater than 0.1% please contact transmission engineers (to troubleshoot or upgrade)

VS.RRC.Rej.ULIUBBand.Cong VS.RRC.Rej.DLIUBBand.Cong

VS.RRC.Rej.ULPower.Cong

Check configuration(ULTOTALEQUSERNUM=160;

NBMULCACALGOSELSWITCH=ALGORITHM_SECOND). Solution: Increase

ULTOTALEQUSERNUM to 180. If still failing: add carrier or reduce/balance traffic to

other layers/cells.

VS.RRC.Rej.DLPower.Cong

Check configuration :UPCPICH and MAXTXPOWER should be at least 10 dB between the 2 values. DLOLCTRIGTHD=95.DL_UU_OLC=0.

Solution1:add carrier or reduce/balance traffic to other layers/cells Solution2: change NBMDLCACALGOSELSWITCH=ALGORITHM_THIRD

VS.RRC.Rej.ULCE.Cong

Solution per cell: change ULTTICREDITSFRESTHD from SF8 to 4SF4.

CE resources for admission is in congestion status the new admitted 2ms HSUPA terminals will be mapped onto the 10ms TTI radio bearer. 2ms TTI HSUPA users whose bit rate is below the threshold of TTI reconfiguration(800Kbps) will be reconfigured to 10ms TTI

Solution per RNC: decrease ULGBR from 32 to 16 for specific services VS.RRC.Rej.DLCE.Cong Solution per cell: ???_{Solution per RNC: decrease DLGBR from 64 to 32 for specific services}

VS.RRC.Rej.Code.Cong Solution per cell is to activate Code reshuffling algo: in object

UCELLALGOSWITCH change CELL_CODE_LDR to 1

Identify if more than 10% of failures for a cell are due to

RL.Failure : VS.RRC.Rej.Rl.Fail

Solution 1: If failures correlated with VS.IUB.FailRLSetup.NoReply

then it is WMPT board congestion( add UTRP Board)

Solution 2: run the PING IP command on the IP of the NodeB to detect congestion

on the IuB.

(15)

35pt

18pt

RRC Access Failure Troubleshooting (IV)

Identify if more than 10% of failures for a cell are due to

TNL (Transport Network Layer) : VS.RRC.Rej.TNL.Cong

Solution 1: Recheck configuration( IPPATHs of Nodeb has same capacity

of transmission one;same for pair one)

Solution 2: Run the PING IP command on the IP of the NodeB to detect

congestion on the IuB.

Identify if more than 10% of failures for a cell are due to FACH congestion :

YES NO

YES

Solution 1: (After SPH226) MOD UCELLALGOSWITCH: CellId=xxxxx,

RsvdPara1=RSVDBIT5-1; (will improve CS success rate, will degrade PS success rate)

Solution 2: Offload traffic

VS.RRC.AttConnEstab.Msg >>

VS.RRC.AttConnEstab.Sum

VS.CellFACHUEs>25 Solution: Offload traffic VS.CRNCIubBytesFACH.Tx or

VS.CRNCIubBytesPSR99.CCH.Tx are flat in time( limited)

Solution1: Offload traffic

VS.MaxRTWP - VS.MeanRTWP > 10 dB

Solution 1: reduce HSUPA traffic Solution 2: Offload traffic

Solution 3: Check external interference

Check missing neighbours Solution 1: Add important Neighbours_{Solution 2: Increase tilt to avoid risky overlaping footprints}

If RRC Estab SR for whole RNC<99% and UU no reply is

major cause

Solution 1 per RNC : modify RRC estab type to be on DCH

SET URRCESTCAUSE:RRCCAUSE=TERMCAUSEUNKNOWN, SIGCHTYPE=DCH_3.4K_SIGNALLING, EFACHSWITCH=OFF; Take care as this will improve the RRC SR but will increase DL Power

Solution 2 per RNC : stop SRB over HSDPA when DRD could be

present SET UFRCCHLTYPEPARA, SRBCHLTYPE=HSUPA, SRBCHLTYPERRCEFFECTFLAG=TRUE

Identify if more than 10% of failures for a cell are due to VS.RRC.FailConnEstab.NoReply :

NO FROM PREVIOUS SLIDE

YES

Please ask for HUAWEI support if after all those steps a cause for poor RRC failure could not be found

NO

(16)

35pt

18pt

•.

Top offending cell in xxx area with more than 10.000 RRC

attempts per day: cell yyyyy

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%

(17)

35pt

18pt

•.

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%

2

nd

_{offending cell in xxx area with more than 10.000 RRC}

(18)

35pt

18pt

•.

Here are most of the RRC failures occurring indicating poor UL coverage (overshooting) 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%

3

rd

_{offending cell in xxx area with more than}

(19)

35pt

18pt

•.

4

th

_{offending cell in xxxx area with more than}

10.000 RRC attempts per day: cell yyyyy

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 Sum of VS.RRC.FailConnEstab.NoReply 3137 Sum of VS.RRC.SetupConnEstab 74719 Sum of RRC.SuccConnEstab.sum 71579 RRC_SR 95.23%

(20)

35pt

18pt

Paging Access Failure

Troubleshooting-(I)-case of one SCCPCH

 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

this channel.

– SCCPCH (Secondary

Common Control

Physical Channel). It

carries paging messages

themselves as well as

packet messages for

mobiles in cell FACH.

(21)

35pt

18pt

Paging Access Failure Troubleshooting-(II)

-case of two SCCPCH

 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

this channel.

– 2

nd

_{SCCPCH (Second}

Secondary Common

Control Physical

Channel). It carries only

paging messages

themselves.

(22)

35pt

18pt

Paging Access Failure Troubleshooting-(III)

PICH timing in relation to P-CCPCH and S-CCPCH (extras from 3GPP 25.211-700) :

Paging

indicator

Paging

message

(3 IMSI or

5 TMSI)

Paging

ocassion

(23)

35pt

18pt

Paging Access Failure Troubleshooting-(IV)

PICH channel parameters:

• SF 256 used all the time.Each UE looks for a particular PICH timeslot according to several parameters broadcasted on SIBs :

• PI number of paging indicators per radio frame. 3GPP allows values 18,38,72,144. It is broadcasted in Sysinfo5: PI-countperframe

• SFN of the P-CCPCH where the PICH frame started. The SFN is known by UE immediately after synchronization with P-CCPCH. SFN range is from 0 to 4096.

• K number of S-CCPCH and can be found in Sysinfo5 . Usually 1 or 2 ( same like in GSM combined or non-combined BCCH).

• DRX cycle. UE will use the DRX=min (DRXPS,DRXCS). DRX cycle is broadcasted in Sysinfo1: cn-DRX-CycleLengthCoefficient (2 values broadcasted, one for each CN domain)

• IMSI known from U-SIM.

• Frame offset =Ts-ccpch,k–Tpich (see previous slide). Ts-ccpch,k = Tk256 chip, Tk{0, 1, …, 149} and can be found in Sysinfo5: and it is called timming offset. For particular UTRAN timming offset=0(S-CCPCH and P-CCPCH are time aligned). Tpich = 7680 chips as a fix value forced by 3GPP. • A paging indicator set to “1” indicates that the UE should read the S-CCPCH of the corresponding frame.

• Total number of chips in one 10msec radio frame is 38400. PICH channel can transmit (38400/256) 150 indicator modulation symbols or (150X2) 300 bits. Only the first 288 of these are used, leaving the last 12 bits undefined

• More details in 3GPP specs: 25.211-700 and in 25.331-710 RRC protocol specification

•

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

PI = DRX Index mod Np Where DRX Index = IMSI div 8192 If we consider particular settings:

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

(24)

35pt

18pt

Paging Access Failure Troubleshooting-(V)

•

PICH frame structure :

• A group of bi=1 means there‟s a paging and UE should read it‟s very first paging occasion. • A group of bi=0 means there‟s no paging and UE could go back to idle till next paging indicators.

• 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.

(25)

35pt

18pt

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)

(26)

35pt

18pt

•Why are RACH parameter VERY important? Because it impacts strongly user experience (also

called E2E=end-to-end user experience)

RACH Access Failure Troubleshooting (I)

Enough performance counters No performance

indicators. Only estimation by RTWP,

load of the RACH channel etc..

(27)

35pt

18pt

RACH Access Failure Troubleshooting (II)

Uplink/UE/PRACH

_{Preamble 1}

Message

part

….

Max_TX_power_on_PRACH Preamble n Preamble_Retrans_Max : MMax

The answer on AICH must be a specific positive response for the specific

RACH sent

Parameters for RACH/PRACH:

•NBO1( 0NBO1min NBO1 NBO1max ) is the time between 2 ramping power of the preamble within the same preamble cycle. •Preamble_Retrans_Max is the maximum number of preamble that can be sent in a cycle.

•Mmax is the maximum number of preamble cycles.

•Preamble_Initial_Power = Primary CPICH TX power – CPICH_RSCP + UL interference + Constant Value •Constant value is an initial value to start the first preamble power usually is -24.

•UL interference is the latest value broadcasted by the NodeB in SIB7. Ue needs to decode this value before being able to transmit RACH. •Power_Ramp_Step is the how much the preamble power should be increased after each No ack received on AICH.

•Power offset P p-m = Pmessage-control – Ppreamble, measured in dB, between the power of the last transmitted preamble and the control part of the random-access message.

•AICH_Transmission_Timing is the time when the RACH message must be transmitted after positive AICH was received( there are other parameters too)

RACH is a common type transport channel in the uplink. RACHs are always mapped one-to-one onto physical channels (PRACHs), i.e. there is no physical layer multiplexing of RACHs, and there can only be one RACH TrCH and no other TrCH in a RACH CCTrCH. Service multiplexing is handled by the MAC layer. In one cell several RACHs/PRACHs may be configured. If more than one PRACH is configured in a cell, the UE performs PRACH selection

NB01

Preamble_Initial_Power :

Power_Ramp_Step :

Pp-m :

AICH_Transmission_Timing

RACH message mandatory parameters:

-UE identity( IMSI,IMSI+LAI, TMSI, IMEI-when no USIM is inserted) -RRC establishment cause (31 causes)

Access Failures Troubleshooting Workshop

Security Level:

www.huawei.com

Huawei Workshop

Troubleshooting Access Failures

Contents

•

Call Setup Procedure (step by step & all protocols)

•

General Causes of failures

•

How to chase and to solve specific access failures:

 RRC Access Failure Troubleshooting.

 Paging Access Failure Troubleshooting

 RACH Access Failure Troubleshooting

Mobile Terminated Call Setup Procedure (I)

Mobile Terminated Call Setup Procedure (II)

Mobile Terminated Call Setup Procedure (III)

General Causes of failures (I)

•

RF Reasons

•

Radio Parameter Problems

General Causes of failures - RF reasons (II)

 Poor DL coverage.

The “fake coverage” phenomenon (the user sees the 3G icon on the screen in

idle but cannot connect to any service). The cause could be overshooting cells but also excessive

values of Qqualmin like -22 dB. Solution: Adjust the antenna azimuth and down tilt, add repeaters and

RRUs, add micro cells. Any user should get a better signal than EcIo = -18 dB.

 Lack of Dominance (no clear Best server

): Continuous change of best server leads to

RRC failures and RAB failures.Solution: Establish a best server everywhere. Clear dominance.

 Poor UL coverage:

The UE has not enough TX power to communicate with Node-B (even when

there is low UL traffic on the cell). Solution: Adjust the antenna azimuth and down tilt, add repeaters,

reduce CPICH power.

 Strong UL interference:

Due to external interference or high UL traffic (the cell shrinking

phenomenon). The UE will not be able to increase to more than 21 dBm for the preamble power and the

RACH will fail - or synch will fail later. Solution: Up to operator‟s decision (implement more tilt ,CPICH

power reduction, chase external source of interference or increase the number of Node-Bs to cope with

traffic)

 Strong DL interference:

Usually due to overshooting cell, external interference, high DL traffic

on this cell and surrounding cells. The UE will miss the AI message for RACH and will fail to establish a

call - or will fail to get synch in DL. Solution: Improve best server area (strong dominance)

 RF radiating system problems:

Poor DL coverage.



The “Fake coverage” phenomenon (user gets the 3G icon on his screen in idle but either cannot pass an RRC or a

RAB). Cause is overshooting cells but also excessive values of Qqualmin like -22 dB. Solution: Adjust the antenna

azimuth and down tilt, add repeaters and RRUs, add micro cells, improve best server, change Qqualmin. Any user

should get a better signal than EcIo=-18 dB. If this level cannot be achieved it is better to display ” no service” on.

user screen.

Qqualmin

PRO

CONS

Comments

-22 dB

• User always see the 3G icon

on his phone‟s screen (although

it‟s a “fake” coverage the user

does not always attempt to use

the service)

•Maximum traffic possible

• Bad customer experience but less

NW signalling.

•Not all call attempts are counted

(not a clear perception of

accessibility).

Will grab all extreme

traffic leading quickly into

DL Power congestion and

accessibility issues.

-18 dB

• The user will not always have

the 3G

Icon on his phone‟s

screen (but when icon is

present service is 100%