LAC, RAC, Ura & FDH

workshop

Yves Hawa
Asiacell Iraq
Table Of Contents
1- LAC/RAC Network Status and SPLIT
2- URA and FDH Background
3- URA and FDH Description
4- URA Signaling
5- URA Planning and Dimensioning
6- Feature licenses and Parameters
7- Activation and Trial
a- Radio Network KPIs
b- RNC Load KPIs
8- Conclusion
9- Counters and KPIs
 Network LAC/RAC Status and Split

› Does Asiacell Network require a LAC/RAC Split ?

› CS paging/s = pmCnInitPagingToIdleUeLa/3600
› PS paging/s = pmCnInitPagingToIdleUeRa/3600

› A LAC or RAC split is considered when the paging/s is reaching more than 120 pages/sec

› Karbala during Arbaneeya event reached a maximum of approximately 300 PS pages/s while
the CS pages/s reached a maximum of 160 pages/s. A new LAC/RAC split or URA
implementation is required in preparation for next year event.

› However in Tikrit, the current number of pages/s is still way below the threshold and doesn’t
require a LAC/RAC split at the moment.

› How to perform a LAC/RAC Split ?

Network LAC/RAC status (1/3)
Network LAC/RAC status (2/3)
 URA Background (1/4)

› URA_PCH is a UE state which can be thought of as a “waiting state for PS

services”. Its introduction brings the total number of UE states to four:

› CELL_DCH - for CS services and high volume PS services

› CELL_FACH - for low volume PS services
› URA_PCH - a waiting state for PS services
› Idle - for inactive users.
 URA BACKGROUND (2/4)
› The introduction of URA_PCH benefits both the network and the UE.

1- The UE benefits from faster access whilst still maintaining low power
consumption.

2- The network benefits from reduced paging

load, reduced signaling interface load and reduced
processor loads in the RNCs and GSNs.
 URA Background (3/4)

› Why URA now ? 1st the PS traffic has significantly increased over the years. However, the
biggest driver for URA_PCH came with the introduction of Smartphones.

› Smartphones introduced bigger screen sizes, more powerful processors and increased
user activity. This resulted in greater power consumption and therefore shorter battery life,
which was a problem for the end users and therefore for the UE vendors too.

› Some UE vendors addressed the power consumption problem by introducing UE

Proprietary Fast Dormancy, also called Pre-Release 8 Fast Dormancy. It is a mechanism
which saves power by allowing the UE to move to Idle as soon as it judges it no longer
requires PS services. It sends an SCRI (Signaling Connection Release Indication) from the
UE to the Network, informing it that the UE is releasing itself to Idle then the network has
no other choice than to release its resources and consider the UE as being Idle.
 URA Background (4/4)

› Although UE Proprietary Fast Dormancy was successful in reducing power consumption, it

caused problems for the network. The RNC no longer had control over the timing of UE
releases. In some cases UEs were releasing every as often as every 30 seconds, causing
dramatically increased signaling loads, especially in the SGSN. Another problem was that
UE Proprietary Fast Dormancy bypasses the URA_PCH state, consequently negating the
advantages in both the RNC and the SGSN that URA_PCH might otherwise provide. In
some networks 50 % of all releases were UE Proprietary Fast Dormancy.

› This situation was addressed by the standardization of Fast Dormancy in 3GPP Release 8
(here called Release 8 Fast Dormancy). It allows the UE to request a transition to a lower
energy state, and the network can then respond by sending the UE to CELL_FACH or
URA_PCH rather than to Idle. This significantly reduces the load on the network, as there
is much less signaling involved with transitions to and from CELL_FACH and URA_PCH
than with transitions to and from Idle. Release 8 Fast Dormancy also introduced a timer
called t323 which limits how often a UE can request Fast Dormancy.
URA DESCRIPTION (1/8)
› URA-PCH is as a “waiting state for PS services”, URA_PCH can be viewed
as the ”new Idle for PS connections”. Similar to Idle, the UE does not
transmit any data and its position is known with less granularity than when
in CELL_FACH or CELL_DCH state. The radio resources in the RNC are
released even though the signaling connections over IU are kept. Thus, the
SGSN does not know that the UE has moved to URA_PCH.

› URA_PCH has an advantage over Idle in that it can be considered as

“Ready for PS activity”. For PS connections, the kept signaling connection
enables the UE to move to an active state faster, thus giving the end user a
better browsing experience.
URA DESCRIPTION (2/8)
› 1) RAB establishment is done on CELL_DCH if Transitions without URA_PCH
rateSelectionPsInteractive.channelType is set to default.

› 2) As an alternative to 1), interactive RABs may be established on

CELL_FACH rather than on CELL_DCH. This occurs if
rateSelectionPsInteractive.channelType=FACH. In this case the user
plane data is sent on FACH.

› 3) Upswitch due to UE activity beyond what can be supported on FACH.

› 4) Timeout due to inactivity or low throughput, governed by

hsdschInactivityTimer, downswitchTimer, in combination with the
throughput thresholds downswitchThreshold and
downswitchTimerThreshold

› 5) Downswitch to Idle due to inactivity, governed by inactivityTimer

› 6) Normal RAB Release

URA DESCRIPTION (3/8)
› 7) To begin data transfer, the UE must upswitch Transitions with URA_PCH
from URA_PCH to CELL_FACH

› 8) Downswitch to URA_PCH due to inactivity,

governed by inactivityTimer.

› 9) When the UE has been inactive on URA_PCH

for inactivityTimerPch, the network pages the UE,
and when it responds the network orders it to
idle.
URA DESCRIPTION (4/8)
› Transitions 10a and 10b are dotted to symbolize Transitions with UE
proprietary Fast Dormancy
that they are not controlled by the network, but
are performed autonomously by the UE.

› UE Proprietary Fast Dormancy considerably

decreased the number of UEs going to
URA_PCH.
URA DESCRIPTION (5/8)
› UE Proprietary Fast Dormancy is a problem for the network since
the benefits of URA_PCH can not be obtained if the state is never Transitions with UE Release 8
entered. To overcome this problem, Fast Dormancy was Fast Dormancy
standardized in 3GPP Release 8. It resulted in the network and the
UE sharing control of fast dormancy transitions. Two things were
added to the standards:

1- When the UE wants to release, it must first ask the network. To do this, it
uses an information Element (IE) which was added to the SCRI.
The content of the IE is a cause value saying “UE requested PS
session Data End”.

2- The timer t323 was added, which sets the minimum allowable time
between sending SCRI requests. t323 is set in the network and
broadcast in SIB 1. It is also sent in UTRAN Mobility Information to
cover the case when the UE has not yet read the system
information, for example because it has come from GSM.

› UEs performing Release 8 Fast Dormancy will do it via transitions

12 and 13 in the figure Introducing Release 8 Fast Dormancy will
significantly reduce the number of UEs doing UE Proprietary Fast
Dormancy (transitions 10a and 10b) although some of the older
UEs may still do this transition.
URA DESCRIPTION (6/8)

› A PS connection is usually first established on DCH (default of rateSelectionPsInteractive.channelType =

DCH). After the data transmission is finished an inactivity timer on DCH is started. In Figure 6 it is named
hsDschInactivityTimer, but it could as well be one of the following timers: hsDschInactivityTimerCpc,
downswitchTimer or downSwitchTimerUp. After expiry of the DCH timer, the UE is sent to CELL_FACH,
where inactivityTimer or inactivityTimerEnhUeDrx is started. Before this timer expires, a second burst is to be
sent, and the UE is switched to DCH again and the procedure from the first burst is repeated. On
CELL_FACH inactivityTimer (inactivityTimerEnhUeDrx) expires and the UE is downswitched to URA_PCH.
Finally, a third burst is to be transmitted and the UE is upswitched to CELL_DCH where the downswitch
procedure from the first two bursts is repeated.
URA DESCRIPTION (7/8)

› In the figure above, The UE decides when to switch to Idle. The state transitions for the three bursts in Figure
are identical. This is because the UE Proprietary Fast Dormancy is initiating a transition to Idle before
inactivityTimer expires. To be more precise, the UE timer is shorter than the sum of hsdDschInactivityTimer
and inactivityTimer, thus the UE is triggering Fast Dormancy. Note that the UE Proprietary Fast Dormancy
could be triggered from CELL_DCH instead. This would happen if the UE timer, which is brand specific, were
shorter than the applicable inactivity timer on CELL_DCH (e.g.hsDschInactivityTimer).
URA DESCRIPTION (8/8)

› In this figure, after the first data burst, the UE requests a downswitch and it is granted. After the second burst
the UE is inhibited from sending the request because t323 has not yet expired. Instead it has to wait till t323
expires. By the time the third burst is sent, t323 has expired again, so the UE can once again send SCRI
when it wants to. Note that if inactivityTimer on CELL_FACH expires before the UE timer it is the network
that triggers the downswitch to URA_PCH. This case is not shown in the figure. The share of network versus
UE triggered downswitches will thus depend on the relation between inactivity- and t323 timers in the RNC
and the UE timer.
 URA Signaling: Paging ues in ura_pch (1/2)

› Paging messages are either of type 2 or type 1. Type 2 paging messages are targeting
users in CELL_DCH or CELL_FACH and sent to one cell only. They constitute a negligible
part of all paging messages and are not impacted by URA_PCH. Paging messages of type
1 are addressing users in Idle or URA_PCH and may be broadcasted over many cells.
When URA_PCH is introduced, there are two impacts on type 1 paging:

- A share of pages will originate from the RNC instead of the SGSN
- A share of pages will be broadcast over a UTRAN Registration Area (URA), instead of a
Location Area (LA) or a Routing Area (RA)

› The impacts have the following reasons: When the network wishes to contact a UE, a
page is required, regardless of whether the UE is in Idle or URA_PCH. However, the page
is handled differently in the two cases. The difference lies in which node originates the
page and the area size over which it is broadcast. In idle mode, CS pages are originated in
the MSC and broadcast to the LA, and PS pages are originated in the SGSN and
broadcast over the RA. With URA_PCH, both CS and PS pages are handled differently:
 URA Signaling: Paging ues in ura_pch (2/2)

› - 1. CS pages still originate in the MSC

because from the MSC’s point of view the UE
appears to be in idle mode. However, when
the RNC receives the page from the MSC, it
knows the UE is in fact in URA_PCH state so
it broadcasts the page to the URA rather than
the LA as seen in the figure
› - 2. PS pages no longer originate in the
SGSN. This is because from the SGSN’s
point of view a UE in URA_PCH state is
already connected and does not need to be
paged. So the SGSN simply sends the user
data through to the RNC. The RNC, upon
receiving the data, knows that the UE is in
URA_PCH state and therefore broadcasts
the page to the URA.
 URA Signaling: ura updates

› A UE in Idle mode informs the MSC when it passes an LA border, and the SGSN
when it passes an RA border. It also periodically informs the MSC and SGSN
about the current LA and RA via periodic updates. The period is set by t3212 and
t3312 respectively.

› A UE in URA_PCH, on the other hand, informs the RNC when it passes a URA
border. It also sends periodic URA updates to the RNC (with periodicity t305) and
periodic LA updates to the MSC (with periodicity t3212). The reason it sends
periodic LA updates is because the MSC thinks the UE is in idle mode and is
expecting these updates.

› The URA updates do not go over Iu-CS or Iu-PS as do the LA and RA updates
respectively. This benefits the Iu-CS and Iu-PS as well as the RNC processors.
 URA Signaling: multirab signaling (1/3)

› Call Setup:
› There are two ways to create a multirab of the kind “Speech + 1xPS”:
-A Speech call is ongoing when a PS Data session is started
-A PS Data session is ongoing when a speech call is started
› The first case cannot involve URA, because the setup is done on DCH. If the
speech call later ends then the PS part may drop to URA_PCH.
› In the second case the UE can be in CELL_DCH, CELL_FACH or URA_PCH
when the Speech call is to be setup. When in URA_PCH, the UE will transition to
CELL_DCH and the network will perform a RAB reconfiguration to “Speech + PS
interactive 0/0”
› From the MSC point of view there is no difference between this case and setting
up a single speech RAB. From the SGSN point of view, it does not know about the
signaling occurring and the UE state transitions, and keeps the Iu Signaling
Bearer and Iu Bearer over Iu-PS.
 URA Signaling: multirab signaling (2/3)

› Call Release:
› We now examine what happens when one of the connections is released from a
“Speech plus 1xPS” multirab. There are two cases:

-The Speech call is released first

-The PS Data session is released first

› Let’s take the case of the speech call being released first. If there is ongoing PS
activity at the time of the CS release then the PS part will continue until it becomes
inactive and is down-switched to CELL_FACH and then potentially to URA_PCH.
In the case where the PS session is inactive before the speech call is released,
the RAB will have been reconfigured to “Speech + PS interactive 0/0”. When the
speech call is then released the connection will also be reconfigured to
CELL_FACH and then potentially to URA_PCH
 URA Signaling: multirab signaling (3/3)

› Call Release:

› Now let’s take the case of the PS data session being released first. It is
important to understand what is meant by a release here. The system will
not “release” the PS part of a multirab just because it has become inactive.
It will simply downswitch it to “Speech + PS interactive 0/0” – and this is the
case described above. A true “release” will only happen if the whole data
connection is terminated. In this case the multirab will reconfigure to
speech only, and so URA_PCH will not be involved.
 URA Planning & DimensioninG (1/2)

1. The LAC, RAC and URA planning is a tradeoff between paging load on the one hand, and LA, RA
and URA updates on the other.

2. In a network facing too high paging load, it may be easier to plan new URAs than to re-plan the
LACs and RACs, new URAs doesn’t involve any Core actions.

3. The size of the paging area decides the paging load.

4. Every release from URA_PCH to Idle is performed with a page. Such a release with a page is not
performed from any other state. Thus there is an increase in paging load if the URA is as big as the
LAs and RAs. It consequently has to be smaller. The impact from the extra page will be more
visible the shorter inactivityTimerPch is.

5. Each cell may belong to up to 4 URAs and the URAs can therefore be partly overlapping, which will
“smear out” the URA borders and mitigate large concentrations of URA updates on border cells, for
example when a URA border run through a busy traffic area.
 URA Planning & DimensioninG (2/2)

6. Aiming for as low paging load as possible brings the drawback of

more area updates. Those can however be minimized by
selecting area borders properly and by using overlapping URAs,
thus LAU, RAU and URAU are spread out geographically for
UEs in state URA_PCH and Ping-Pong is avoided for these
UEs.

7. Current situation in the network is as follows:

- Each RNC Contains one LAC except RNC KRB where 2 LACs are defined
- Each LAC contains only one RAC

8. Asiacell URA planning methodology will rely on below ideas:

- Two or Three URA per LAC/RAC
- One URA per site
- No URA overlapping as no RAC borders
 Features Licenses

FAJ 121 407 UTRAN Registration Area Handling:

This is the feature that enables URA_PCH. It is a prerequisite for other features Fast Dormancy
Handling and Faster Establishments, Direct upswitch from URA.

FAJ 121 1552 Fast Dormancy Handling:

Fast Dormancy Handling ensures that Release 8 capable UEs do fast dormancy to URA_PCH rather
than to idle. This maximizes the number of users in URA_PCH and therefore maximizes the benefits of
URA_PCH.
 parameters
Following table shows the recommended values for the parameters when
URA_PCH and Fast Dormancy Handling are activated.

Timer Recommended Value Current Value

hsdschinactivityTimer 2 sec 2 sec
downswitchTimer 1 sec 1 sec
inactivityTimer 10 sec, 8 sec 30 sec
T323 5 sec 120 sec
inactivityTimerPch 29,15 minutes 30 minutes
t305 30 minutes 30 minutes
dlRlcBufUpswitchMrab 5 0
Radio Network KPIs
Rrc success rate

90% reduction in PS Req.

RNCBIS953E

RRC CS success rate is maintained. 90% reduction in the PS RRC attempts after URA activation. Reduced from 99.8% to 99.4%

It has been commonly observed that when the absolute number of events decreases the success rate also decreases.

UEs in poor coverage will more often drop to Idle, Consequently higher share of UEs may end up performing RRC connection requests
from poor coverage, resulting in lower success rate.
RAB success rate

91% reduction in PS RAB Att.

RNCBIS953E

91% reduction in PS HS/EUL RAB

Speech RAB
the PS Interactive success rate has
success rate is
RAB attempts after reduced from
maintained.
URA activation. 99.8% to 99.2%
Speech drop rate

RNCBIS953E

Speech drop call rate is maintained.

PS r99 drop rate

RNCBIS953E

PS R99 DCR increased on the day of activation 31/Aug/2016.

PS R99 DCR came back to original trend.

Excluding 31/Aug, DCR improved from 0.17% to 0.13%

Hsdpa drop rate

RNCBIS953E

HSDPA DCR increased on the day of activation 31/Aug/2016.

After increasing the users license in SGSN, HSDPA DCR came back to original trend.

HS Drop maintained at 0.15%

Soft handover success rate

RNCBIS953E

Soft handover success rate is maintained with no major impact.

Traffic

RNCBIS953E

No major deviations in Speech traffic and Packet data traffic.

Hsdpa/EUL users – rnc953

RNCBIS953E

Reduction in HS/EUL users at the RNC level is observed due to users in URA_PCH state.
Channel switch fach_ura

RNCBIS953E

Channel switching success rate from FACH to URA is almost 100%

Channel switch ura_fach

RNCBIS953E

Channel switching success rate from URA to FACH is almost 100%

Ura update success rate

RNCBIS953E

URA update success rate is very good, above 99.8%.

Average users in ura

RNCBIS953E

Average number of URA users is around 1900 per day.

Paging attempts

-65% reduction in paging type1

RNCBIS953E

Number of paging type 1 attempts from SGSN to RNC reduced significantly by around 65%.

UTRAN initiated paging attempts forms the majority of paging traffic in the RNC.

No impact on the paging type 1 attempts from MSC to RNC.

RNC Load KPIs
CC-SP Load

Reduction in CC load is observed post URA implementation.

MP Load

Reduction in MP load is observed post URA implementation.

DC Load

No change in DC load post URA implementation.

C2 Load

Reduction in C2 load post URA implementation.

Users license

Reduction in FachDchHsUsers post URA implementation.

Conclusion
URA-PCH and FDH are very important features to be implemented in any high smartphone
penetration networks.

All Radio KPIs are following normal trend, No KPI degradation observed

Significant improvement in RNC load KPIs

Expected good improvement in Core load KPIs

Counters & KPIs
 New counters
› Ura - pmCnInitPagingToUraUe
– Number of CN-initiated pages attempted for UEs in the URA_PCH state. Incremented by one for every CN-initiated page attempted for a UE in the URA_PCH state.
› Ura - pmSamplesRabUra
– Number of samples recorded within the ROP for pmSumRabUra. Incremented by one when the value of the internal level counter is sampled, even when the sampled
value is 0. This means that the value should normally be (sampling rate * ROP length) at the end of the ROP, regardless of the value of the corresponding sum counter.
However, if the corresponding sum counter for all instances of this MO class is zero, then this counter will report zero.
› Ura - pmSumRabUra
– Sum of all sample values recorded during a ROP for the number of PS Interactive RABs in URA_PCH. Values are read periodically from an internal level counter and
added to this counter. The level counter maintains the current number of PS Interactive RABs in URA_PCH.
› Ura - pmUtranInitPagingToUraUe
– Number of UTRAN-initiated pages attempted for UEs in the URA_PCH state. Incremented by one for every UTRAN-initiated page attempted for a UE in the URA_PCH
state.
› UtranCell - pmNoUraUpdSuccess
– Number of successful URA updates. Incremented by one for each successful URA update.
› UtranCell - pmNoUraUpdAttempt
– Number of attempted URA updates. Incremented by one for each attempted URA update.
› UtranCell - pmNoSystemRabReleasePacketUra
– Number of system RAB releases for Packet RABs while in URA_PCH state. Incremented by one for each system RAB release of a Packet RAB, while in URA_PCH. A
system RAB release has 'release cause' = anything except 'Normal Release', 'Successful Relocation', 'Resource Optimization Relocation', 'User Inactivity' or 'release-due-
to-UE-generated-signaling-connection-release'.
› UtranCell - pmNoNormalRabReleasePacketUra
– Number of normal RAB releases for Packet RABs while in URA_PCH state. Incremented by one for each normal RAB release of a Packet RAB, while in URA_PCH. A
normal RAB release has 'release cause' = 'Normal Release', 'Successful Relocation', 'Resource Optimization Relocation', 'User Inactivity', or 'release-due-to-UE-generated-
signaling-connection-release'.
› UtranCell - pmChSwitchSuccFachUra
– Number of successful channel down-switching attempts from CELL_FACH to URA_PCH. Incremented by one for every successful channel downswitching attempt from
CELL_FACH to URA_PCH.
› UtranCell - pmChSwitchAttemptFachUra
– Number of channel down-switching attempts from CELL_FACH to URA_PCH. Incremented by one when a channel down-switching from CELL_FACH to URA_PCH is
attempted.
› UtranCell - pmChSwitchSuccUraFach
– Number of transitions succeeded URA_PCH -> Cell_FACH. Incremented by one for successful transition from URA_PCH to Cell_FACH.
› UtranCell - pmChSwitchAttemptUraFach
– Number of transitions attempted URA_PCH ->Cell_FACH. Incremented by one for every transition attempted from URA_PCH to Cell_FACH.
New KPIs

› New KPIs needs to be monitored:

New KPIs

› Existing KPI formulas needs to be updated:

• PS DCH/FACH drop rate=100*(pmNoSystemRabReleasePacket-pmNoSystemRabReleasePacketUra-

pmNoSystemRbReleaseHs-pmChSwitchAttemptFachUra+pmChSwitchSuccFachUra-
pmChSwitchAttemptDchUra+pmChSwitchSuccDchUra)/(pmNoNormalRabReleasePacket-
pmNoNormalRabReleasePacketUra+pmNoSystemRabReleasePacket-pmNoSystemRabReleasePacketUra-
pmNoNormalRbReleaseHs-pmNoSystemRbReleaseHs +pmNoSuccRbReconfOrigPsIntDch+
pmChSwitchSuccFachUra+pmUpSwitchFachHsSuccess+pmChSwitchSuccDchUra)

• HS drop rate=100*(pmNoSystemRbReleaseHs-
pmChSwitchAttemptHsUra+pmChSwitchSuccHsUra)/(pmNoNormalRbReleaseHs+pmNoSystemRbReleaseHs+
pmNoSuccRbReconfPsIntDch+pmPsIntHsToFachSucc+pmChSwitchSuccHsUra)

• EUL drop rate = 100*(pmNoSystemRbReleaseEul)/(pmChSwitchSuccEulUra+pmPsIntHsToFachSucc+

pmNoSuccRbReconfOrigPsIntEul+pmNoSystemRbReleaseEul+pmNoNormalRbReleaseEul)