This document provides information on troubleshooting access failures in mobile networks, including:
1. It describes the general call setup procedure and potential points of failure, such as RRC, paging, and RACH access failures.
2. Common causes of access failures are discussed, like RF issues, radio parameter problems, and other miscellaneous causes.
3. Guidance is given on how to identify and resolve different types of failures, including steps to troubleshoot RRC access failures through analyzing configuration, alarms, traffic patterns, and radio parameters.
For RF Optimisation and neighbour verification both Scanner and UE measurements are required simultaneously
Post-Processing tool is required for data analysis
Individual call failures or drops can be analysed with Drive test tools (e.g. Nemo Outdoor) but to get bigger picture, a proper analysis tool is required
Actix or Nemo Analyser can be used for
Data analysis
Create Maps
Create KPI reports
This presentation will show you how to right size customer networks, take advantage of ARM, Band steering and Client Match. Check out the webinar recording where this presentation was used. https://attendee.gotowebinar.com/recording/4688596131469180162
Register for the upcoming webinars: https://community.arubanetworks.com/t5/Training-Certification-Career/EMEA-Airheads-Webinars-Jul-Dec-2017/td-p/271908
This presentation will show you how to optimize IAPās traffic prioritization features for Voice and Video deployments and relative best practice solutions widely practiced across multiple verticals. Check out the webinar recording where this presentation was used. https://attendee.gotowebinar.com/recording/3338982991176626689
Register for the upcoming webinars: https://community.arubanetworks.com/t5/Training-Certification-Career/EMEA-Airheads-Webinars-Jul-Dec-2017/td-p/271908
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Ā
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Ā
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
Ā
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Ā
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
Ā
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Ā
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
DevOps and Testing slides at DASA ConnectKari Kakkonen
Ā
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
Ā
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Ā
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
2. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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
Page 2
3. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
Mobile Terminated Call Setup Procedure (I)
Page 3
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
NBAPNBAP
NBAPNBAP
ALCAP
ALCAP
ALCAP
ALCAP
DCH-FPDCH-FP
L1 L1
Start TX
11. FACH: CCCH: RRC CONNECTION SETUP <UM>
RRCRRC
14. DCCH: RRC CONNECTION SETUP COMPLETE <AM>
RRCRRC
10. UPLINK SYNCHRONISATION
DCH-FP DCH-FP
13. RADIO LINK RESTORE INDICATION
NBAPNBAP
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
5. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
Mobile Terminated Call Setup Procedure (III)
Page 5
UE Node B RNC MSC / VLR MGW
46. DT [ CONNECT ACK ]
46. DCCH: DLDT [ CONNECT ACK ] <AM>
RANAPRANAP
RRCRRC
39. DCCH: ULDT [ ALERTING ] <AM>
40. DT [ ALERTING ]
RANAP RANAP
RRCRRC
42. DCCH: ULDT [ CONNECT ] <AM>
43. DT [ CONNECT ]
RANAP RANAP
RRCRRC
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
RRCRRC
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
NBAPNBAP
NBAPNBAP
44. OPEN CONNECTION
35. RADIO LINK RECONFIG COMMIT
NBAPNBAP
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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
General Causes of failures (I)
ā¢ RF Reasons
ā¢ Radio Parameter Problems
ā¢ Miscellaneous causes
Page 6
7. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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.
ļ§ Missing neighbours: Leads to call setup failures due to poor signal.
Page 7
8. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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.
Page 8
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.
-20 dB Qqualmin=-20dB is suggested as a trade-off solution by Huawei.
9. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
General Causes of failures ā Radio Parameter Problems(II)
Page 9
ā¢ 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?
ā¢ Why Qoffset1sn, Qoofset2sn are out of the range (-4;+4) on top of the IdleQhyst1s >2?
10. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
General Causes of failures āMiscellaneous causes(II)
Page 10
ā¢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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
How to identify and solve different issues?
Page 11
12. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 12
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
is the cell idleQhyst2<2? YES NO If no, please do not expect a good RRC Success rate with idleQhyst2>4dB
13. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 13
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)
RRC Access Failure Troubleshooting (II)
14. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 14
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.
Solution 3: If failures correlated with RLM.FailRLSetupIub.Cong then it is WBBP
board congestion
GO TO NEXT SLIDE
NO
15. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 15
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
FACH Channel utilisation>80% Solution1: Offload traffic
16. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 16
ā¢.
Here are most of
the RRC failures
occurring
indicating poor
UL coverage
(overshooting)
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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 17
ā¢.
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%
2nd offending cell in xxx area with more than 10.000 RRC
attempts per day: cell yyyyy
18. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 18
ā¢.
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%
3rd offending cell in xxx area with more than
10.000 RRC attempts per day: cell yyyyy
19. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 19
ā¢.
Here are most of
the RRC failures
occurring
indicating poor
UL coverage
(overshooting)
4th 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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 20
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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 21
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.
ā 2nd SCCPCH (Second
Secondary Common
Control Physical
Channel). It carries only
paging messages
themselves.
2nd SCCPCH
22. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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
PI=(IMSI/8192) mod36
24. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
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. 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
26. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 26
ā¢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. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential Page 27
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)
-radio bearer ID( AS or NAS, UM or TM or AM)
-release5 indicator
-measurements results on RACH(like EcNo of the serving cell).
28. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
RACH Access Failure Troubleshooting-(III)
ā¢
From all this information what do you need to know?:
ā¢ Current RACH parameters are not optimal: allows the UE to increase
the power 20 dBm more than the RTWP(CONSTANTVALUE=-20,
PREAMBLERETRANSMAX=20, POWERRAMPSTEP=2). Due to this
RTWP increase, due to this RACH increases and so on(it creates an
avalanche effect). Better have longer call setup time for one UE (RACH
failures due to missing NB relations of overshooting cells) instead of
having entire cell shrinked due to one UE not being able to transmit
RACH message.
ā¢ 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.
ā¢ Spreaders inside the Node-B are limited. Multipath ( long distance) is
not good for resource consumptions and so RACH messages might be
missed.
29. HUAWEI TECHNOLOGIES CO., LTD. Huawei Confidential
Preliminary conclusions
ā¢ Most attempt failures are related to planning
ā¢ Plenty of attempts failures not recorded within the performance
file (When EcIo is worse than -18 very few RACH āreachā the
Node-Bs)
Page 29