RAB drop rate improvement - L1,L2,L3 TIMERS TUNING

Radio LINK SUPERVISION TIMER Trials – L1 Timers

UE SIDE L1 TIMERS

›T313 (Proposing changes from 3 to 10)

›N313 (Proposing changes from 100 to 200)

RNC SIDE L1 TIMERS

›rlFailureT (proposing changes from 10 to 20)

›DCHRCLostT (proposing changes from 50 to 90)

›ninsyncind/noutsyncind (proposing changes to 1 and 256 respectively)

BACKGROUND

• Radio connection supervision (RCS) strategy contains some system constant ruling the algorithm to supervise the connection at L1 (phisycal), L2 (RLC) and L3 (RRC) level in order to understand the best moment to release the connection

• Those system constant were originally configured for a certain traffic profile and certain kind of mobiles, and they are not fitting anymore for the current advanced mobiles (tipically Smartphones) and their traffic profile (tipically MultiRabs)

• A new RCS strategy has been considered for better handling the current 3G traffic

L1 Timer (UE side) N313 : number of consecutive “out of sync” after that Ue starts t313“Out of sync” generation is Ue dependant, generally when the Ue measures a SIR < target SIR.(the SIR is measured according to a sliding window of 160 ms  according to motorola information)According to specification Ues switches off the transmitter when is “out of Sync”.T313: After n313 consecutive “out of service”, the UE starts T313 and doesn’t  stop it until it Measures an “in Sync” that is SiR> SIR TargetN315: number of consecutive “in Sync” for the Ue to stop T313  and the Radio Link FailureProcedureTimer for Radio Link Failure in DL = n313*10 (ms)+ t313 . After this timer expiry the call is
droppedL1 Timer (proposed value)It is recommended to align themProposed valuesDchRcsLostT = 90 (9 sec) / rlFailureT = 20 (2 sec)T313 = 10 sec / N313 = 200UL RLS (DchRcLostT+ rlFailureT+(noutsyncind*10ms)) = 9 +2+2.56 = 13.56 secDL RLS (T313 + N313*10ms) = 10 + 200*10ms = 12 secimproved rlc settings             
Involved Parameters›The parameters involved in the change are listed below:–UeMaxDat – the parameter determines the number of transmissions of a PDU before a SDU is discarded or reset procedure is initiated. The number of transmissions is equal to MaxDat - 1.–UeTimerPoll – the parameter defines the maximum time for the transmitter to receive a STATUS PDU corresponding to a poll that it has sent before polling again. It is started when the poll is transmitted. A new poll is sent when this timer expires and no status is received.–UeMaxRst – the parameter determines the maximum number of transmissions of reset PDU equals MaxRst-1.

–UeTimerRst – the parameter defines the timer used for retransmission of reset PDU.–RncMaxDat – the parameter determines the number of transmissions of a PDU before a SDU is discarded or reset procedure is initiated. The maximum number of transmissions of a PDU equals MaxDat-1.–RncTimerPoll – the parameter defines.the maximum time for the transmitter to receive a STATUS PDU corresponding to a poll that it has sent before polling again. It is started when the poll is transmitted. A new poll is sent when this timer expires and no status is received.–RncMaxRst – the parameter determines the maximum number of transmissions of a reset PDU. The maximum number of transmissions of a reset PDU equals MaxRst-1.All parameters are system constants and may only be changed by Ericsson personnel.›Note that the parameter values for UeMaxDat, UeTimerRst and UeMaxRst are coded, for example setting parameter UeMaxRst = 4 means that that the UE will use UeMaxRst = 12. •Current TELECOM settings for SRB:Timerpoll (both sides RNC and Ue)=160MaxDat(both sides RNC and Ue)= 40rncMaxRST = 1UeMaxRST= 0 (means 1)rncTimerRST=550UeTimerRST= 10 (means 550)Total L2 timer (both UL or DL)= Timerpoll*(MaxDat-1)+TimerRST*(MaxRST-1)
= 160*(39)+ (1-1)(550) = 6,24sec = 160*(39)+ (1-1)(550) = 6,24sec = 160*(39)+ (1-1)(550) = 6,24sec = 160*(39)+ (1-1)(550) = 6,24secIn our opinion L2 supervision timers need to be made more robust (longer timeouts) to handle temporary bad radio, and it is suggested to align them with L3 supervision timersL2 Timers : proposed valuesOn RNC side there is no limit on maxDat, so use that to increase the timeout- On UE side maxDat is limited, set it to the max value (15) and then increase timerPoll to get the timeout length wanted.UeRC=2 / UeRcRb=2,3,4 (UeRc=speech and DCH 2,3,4 associated with speech)rncMaxDat  proposed = 50  ueMaxDat  proposed = 15(40)rncMaxRST proposed = 3  ueMaxRST proposed =4(12)rncTimerPoll  proposed = 270  ueTimerPoll  proposed = 200In this case the RLC supervision timing will lastIn RNC (270*49) + (3-1)*550 = 14.33 secondsIn Ue (39* 200)+(12-1)*550 = 13.85 secondsWe’re proposing to change them on pure speech (uerc=2, ueRcRb=2,3,4), and on Speech + Ps 0/0, and to all active multiRab associated with Speech.After looking at the performances, we would like to extend to all PS RABs as wellL3 Timers•L3 Timers start when a rrc procedure takes place (i.e. Radio Bearer / Radio Bearer Setup complete  -  active set / active set update complete)•The more classical example is L3 soft handover procedureAfter sending an rrc active set update, if the RNC doesn’t receive an active set update complete by the UE within timer: tRrcActiveSetUpdate the call is dropped , even if the Ue should recover the L1 or the L2  levels. So L3 timers (in particular the soft handover)  should expiry only after the L1 and L2 timers have expiried (Ue / RNC has had all time considered useful to recover The connection)•Actual value of  tRrcActiveSetUpdate in network = 5 seconds•Proposed value= 10 seconds.rab setup/release  

tRrcRABEst & tRrcRABRel timers›Background–Timers for RB setup and RB release are suggested to be increased. That way, more time is allowed for RAB reconfigurations, such as switch from single-RAB to multi-RAB or vice versa, and the risk for drops during RAB reconfiguration is reduced.–RAB setup and release is supervised by the following timers:›tRrcRABEst for RAB setup›tRrcRABRel for RAB release–The timers set the time for RRC RESPONSE. It has been seen in field trials that retainability can be improved by increasing the timer values.
–Both timers are system constants and may only be changed by Ericsson personnel.›In order to align all L3 timers, we propose the following changes–Change tRrcRABEst from 5 to 10 (5s à 10s)–Change tRrcRABRel from 6 to 12 (6s à 12s)››Connection to other improvements:After the RB setup/release (supervised by timer tRrcRABEst  or tRrcRABRel) an RB reconfiguration is done if RLC parameters need to be changed between UeRc:s. This procedure is supervised by hardcoded timers (establish: 5s, release 6s). To avoid this timer supervised RRC procedure it is recommended to align RLC settings for UeRc as much as possible. This minimizes the risk for dropped call. See section 

UMTS RRC STATES

INTRODUCTION

User Equipment (UE) that is powered on, but does not have a connection to the Radio Network is defined as being in Idle Mode. A UE in Idle Mode can both access and be reached by the system.
A UE that has an RRC connection is defined as being in Connected Mode. A UE in Connected Mode using the common channels RACH (or E-DCH if Enhanced Uplink for FACH feature (FAJ 121 1652) is activated) in the UL and FACH (or HS-DSCH if Enhanced Uplink for FACH is activated) in the DL is defined as being in CELL_FACH state. A UE in Connected Mode monitoring the paging channel is defined as being in URA_PCH state. The location of a UE in URA_PCH is known by the WCDMA RAN on a UTRAN Registration area (URA) level.

Before we understand different RRC States it i important to know various RNTI used in UMTS Network

What are the different RNTI used in UTRAN …

RNTI -(Radio Network Temporary Identities) are used as UE identities within the UTRAN and in signalling messages between UE and UTRAN.
RNTI is used , so that UE original identity can be hide , so that no one can detect the UE , but as a identity UE can also send IMSI or IMEI , in which we try to avoid sending the MEI number to the network, except in the case , when UE does not have the SIM or it is not properly camped to a cell and user wants to make the “Emergency call”.

These RNTI are,
SRNC RNTI (S-RNTI)
Drift RNC RNTI(D-RNTI)
Cell RNTI(C-RNTI)
UTRAN RNTI(U-RNTI)

S-RNTI is allocated in association with RRC connection setup by the SRNC to which the UE has the RRC connection, so that both can identify each other.

D-RNTI is allocated by a DRNC in association with context establishment and is used to handle the UE connection and context over the Iur interface.

C-RNTI is allocated when the UE accesses a new cell , so that we can say that it identifies the UE when UE is in common channels ( when UE is in cell FACH), i.e. with in a cell. By this CRNC and UE communicate each other.(in most cases CRNC and SRNC are incorporated in a single RNC )

But, now the most important RNTI comes into the picture, and its the URNTI, it identifies the UE , uniquely within UTRAN. URNTI is used as a UE identifier for the first cell access , and it generated by the combination of SRNC identity and SRNTI. It is an unique one in UTRAN.

Apart from them , we also have E-RNTI and H-RNTI , used in HSUPA and HSDPA respectively, which also have the same use as the above ones.
we will explore all these more in a later post.

The U-RNTI is assigned by the SRNC and uniquely identifies the UE within the UTRAN.

It is used when a UE cannot be identified in the UTRAN, e.g.,

first access after a UE did cell change (cell update or URA update) or for UTRAN originated paging.

U-RNTI: RNC id + S-RNTI

32 bits

Why is it required to have CHANNEL SWITCHING (DIFFERENT RRC STATES)

Traffic on the Interactive Radio Access Bearer (RAB) causes large variations in offered traffic over time for a particular user. The packet-switched (PS) Interactive RAB traffic transferred through the WCDMA Radio Access Network (RAN) is generated mainly by web browsing, e-mail and file transfer. Especially web browsing causes large variations in the traffic stream. After a web page is downloaded and the user is reading the page, there is very little data to transfer. This changes when the user requests a new web page. Consequently, reserving resources for a dedicated channel continuously is not efficient.

The purpose of the Channel Switching feature is to dynamically change the physical resources allocated to a User Equipment (UE) based on the amount of data that has to be transmitted in the Uplink (UL) and in the Downlink (DL). This is achieved by switching the Interactive RAB of the UE between transport channels of different rates. When an Interactive RAB has only a small amount of data to send and receive, it is switched to common transport channels mapped onto the Random Access Channel (RACH) or E-DCH (if Enhanced Uplink for FACH is activated) in UL and Forward Access Channel (FACH) or High Speed Downlink Shared Channel (HS-DSCH) in DL. This allows more users to share the radio resources than in a circuit-switched scenario. When the traffic increases, the UE is switched back to one of the following transport channels: Dedicated Channel (DCH), Enhanced Dedicated Channel (E-DCH) or HS-DSCH , if there are resources available.

The Channel Switching feature applies only to packet traffic on the Interactive RAB, which has little or no Quality of Service (QoS) attributes that apply. It belongs to the Interactive and Background QoS classes, which have no guaranteed bit rates and no packet delay requirements. When sufficient resources are available, the Interactive RAB receives high bit rates, but when the system is heavily loaded and not many resources are available, the offered bit rates can be low. In a situation of heavy load, it can be refused any bandwidth, since there are no reserved resources for the Interactive RAB.

The Channel Switching feature switches only between transport channels. The logical channels are not affected. When large amounts of data are being sent or received, the DCH transport channel with various rates is available on both the UL and the DL. In addition, the HS-DSCH is available on the DL and E-DCH is available on the UL, both depending on UE and cell capability.

For small amounts of data, the RACH and FACH common transport channels are used. In this case, for DL, a maximum of 32 kbps is shared between all users in a cell. Alternatively, HS-DSCH without associated Uplink HS-DPCCH can be activated instead of FACH and enable bit rates higher than 32 kbps, and E-DCH can be activated instead of RACH.
For no data activity, the Interactive RAB is switched to URA_PCH state, where no transport channels are allocated and no data transmission is possible.
The Channel Switching feature works both on a Single RAB and on a Multi-RAB combination.

PROCESSES IN UE MODES/STATES

UE Idle mode -The UE shall perform a periodic search for higher priority PLMNs

UTRA RRC Connected mode :

1)URA_PCH or CELL_PCH state

In the URA_PCH or CELL_PCH state the UE shall perform the following actions:
NOTE: Neither DCCH nor DTCH are available in these states.

1> if the UE is "in service area": 

•  maintain up-to-date system information as broadcast by the serving cell
• cell reselection
• Periodic search for high priority PLMN's
• Monitoring the Paging occasions and PICH and receive paging information on PCH mapped on the S-CCPCH selected by the UE
• act on RRC Messages received on PCCH and BCCH
• perform measurment process
• maintain up to date BMC Data if it supports CBS
• act in RRC Messages received on MCCH
• run timer T305 for periodical URA update if the UE is in URA_PCH state and periodic cell update if the UE is in Cell_PCH state

2) If the UE is Out of Service area

• Perform Cell selection
• Run timer T316
• Run time T305
• if the cell selection process fails to find a suitable cell after a complete scan of all RATs and all frequency
  bands supported by the UE, the UE shall after a minimum of TimerOutOfService time (default value 30 s) of being "out of service area"
• indicate all available PLMNs to NAS to enable the selection of a new PLMN
• if an acceptable cell is found then the UE shall camp on that cell to obtain limited service
•  else if no acceptable cell is found, the UE shall continue looking for an acceptable cell

CELL_FACH State

In the CELL_FACH state the UE shall perform the following actions:
NOTE: DCCH and, if configured, DTCH are available in this state.

1> if the UE is "in service area":

• maintain up-to-date system information as broadcast by the serving cell
• Cell Reselection
• Perform Meausrement process
• Run Timer T305
• Select and Configure the RB Multiplexing option applicable for the transport channels to be used in RRC states
• listen to all FACH transport channels mapped on the S-CCPCH selected by the UE
•  act on RRC messages received on BCCH, CCCH and DCCH
•  act on RRC messages received on MCCH if it supports MBMS and has activated

2> if the UE is "out of service area":

• perform cell selection process
• run timers T305 (periodical cell update), and T317 (cell update when re-entering "in service") or T307 (transition to Idle mode), if started
• run timers T314 and/or T315, if started
• if the cell selection process fails to find a suitable cell after a complete scan of all RATs and all frequency
  bands supported by the UE, the UE shall after a minimum of TimerOutOfService time (default value 30
  seconds) of being "out of service area":
  3> indicate all available PLMNs to NAS to enable the selection of a new PLMN;
  3> if an acceptable cell is found then the UE shall camp on that cell to obtain limited service

CELL_DCH state
In the CELL_DCH state the UE shall perform the following actions:
NOTE: DCCH and, if configured, DTCH are available in this state.
1> read the system information as specified in subclause 8.1.1 (for UEs in TDD mode);
1> perform measurements process
1> select and configure the RB multiplexing options applicable for the transport channels to be used in this RRC
state;
1> act on RRC messages received on DCCH;
1> act on RRC messages received on BCCH (applicable only to UEs with certain capabilities and in FDD mode);
1> act on RRC messages received on MCCH if it supports MBMS and has activated an MBMS service as 1> act on RRC messages received on BCCH (TDD only) and, if available, SHCCH (TDD only)

What is URA and URA_PCH state?

URA or UTRAN Registration Area is a colection of cells that are used for fast moving UE's in Connected mode when they are not transferring any data. In this case the UE is in CELL_PCH state. Everytime a fast moving UE in CELL_PCH state changes the cell, a CELL UPDATE needs to be performed to let the UTRAN know of the new position of the UE. This is done because in the connected mode (CELL_PCH), UE is known at cell level rather than UTRAN level as in IDLE state. If too many CELL UPDATES are performed, it defeats the purpose of UE being in CELL_PCH. Hence in this case the UE is put in URA_PCH state. Now the UE will perform CELL UPDATE only when the URA is changed for a UE. The drawback is that when UE needs to be paged the paging area is now extended to many cells belonging to the URA. 

Also Note that the CELL_PCH state is actually a subset of the URA_PCH state. It is possible to define overlapping URAs to be used in the URA_PCH state. Thus, the UTRAN operator could define that each cell is a separate URA in addition to other larger URAs. Then the operator could assign small one-cell URAs for slow-moving mobiles, and larger URAs for mobiles with greater mobility. The small URAs could nicely perform the task of the CELL_PCH state. However, it has been decided to keep these states separate. 



The URAs can be overlapping or even hierarchical. The same cell may belong to several different URAs, and the UEs in that cell may have been registered to different URAs. SIB 2 contains a list of URA identities indicating which URAs this cell belongs to. This arrangement is done to further reduce the amount of location update signaling because now the UEs moving back and forth in the boundary area of two URAs do not have to update their URA location information if the boundary cells do belong to both URAs.

WCDMA PARAMETER SETTINGS

ACCESS PARAMETERS IN IDLE MODE

Initial PRACH (The first PRACH that UE transmit) is determined by the following formula.

Initial RACH Preamble Power = Primary CPICH TX Power – CPICH_RSCP + UL_Interference + Constant Value

CPICH_RSCP is the power directly measured by UE and all other parameters are calculated (obtained) from system information. The related parameter and system information is as follows.

System Information	Information Element	Example Value
SIB3	Maximum Allowed UL Tx Power	21 dBm
SIB5	Primary CPICH Power	-8 dBm
	Power Ramp Step	3 dB
	Mmax	2
	NB01min	10
	NB02max	10
SIB7	UL Interference	-92

If UE fail to get AICH for the PRACH, it increment the PRACH power by Power Ramp Step (SIB5) and transmit the PRACH again. UE repeat this process until it gets AICH or it retried the specific number specified in SIB5.

Following screenshot is an example of PRACH transmission and retransmission. This is from a test resultl of 34.121 8.4.2.1. In this test case, Network intentionally does not send AICH so that UE keep sending PRACH with specified power increment in the specified number of times.

AICH POWER OFFEST - Power level of the AICH relative to that of the primary CPICH.

Definition: Power level of the AICH relative to that of the primary CPICH.

IE Value Engineering Units

Allowed Range [-22 … +5] -22 … +5 dB

Recommended -7 to -5 -7 to -5 dB

Setting Tradeoff: If parameter is too small, the probability of acquisition indicator

misdetection and false alarm increase. Indicator misdetection leads to increased access time

and to increased uplink interference caused by the access attempt. A false alarm causes the

UE to send a RACH message packet (e.g., RRC connection setup) which is not expected and

not detected by the Node B, thus making the UE wait for a response. Higher layers have to

recover from this phenomenon resulting in increased access delay.

If parameter is too large, downlink capacity is unnecessarily consumed.

Dependencies/Constraints: None.

Traceability: TS25.331 [35] Sect. 10.3.6.3.

RRC Message Structure: SIB5/SIB6 􀃆 FDD 􀃆 AICH Power offset

Power Ramp Step

Definition: UE transmit power increase between subsequent transmissions on the RACH

when no acquisition indicator is received.

Setting Tradeoff: If parameter is too small, the number of RACH preambles and the access

latency increase. If parameter is too large, the uplink interference increases.

Dependencies/Constraints: This parameter should be set to relatively small value if the

Preamble Retrans Max IE is set to a relatively large value, and vice versa, as their effect on

access latency and uplink interference is compounded.

Preamble Retrans Max

Definition: Maximum number of preamble transmissions in one preamble ramping cycle.

IE Value Engineering Units

Allowed Range [1…64] 1…64

Recommended 6 to 10 6 to 10

Setting Tradeoff: If parameter is too small, the probability of successful preamble ramping

cycle decreases. If parameter is too large, the uplink interference increases.

Mmax

Definition: Maximum number of preamble ramping cycles.

IE Value Engineering Units

Allowed Range [1…32] 1…32

Recommended 3 to 6 3 to 6

Setting Tradeoff: If parameter is too small, the RACH access may not take full advantage of

the time diversity provided by preamble ramping cycle repetition. If parameter is too large,

the uplink capacity consumption may unnecessarily increase.