RRE over IUR

RRC Connection Re-Establishment

over IUR
What is RRE and why it is needed?
 What is RRE and why it is needed?

• Call Reestablishment is possible for both Circuit Switched (CS) and Packet
Switched (PS) RABs.
• There are dedicated timers that govern the establishment of CS and PS
RABs. The timers are broadcasted in System Information (SIB1) from the
Network to the UEs.
• If the Network does not support Call reestablishment, it would set the
timer values to 0. The UE in this case will not send cell Update to the
Network requesting for reestablishing the call.
• When the Network supports the Call Reestablishment, the default value of
the timer is typically 8 sec for CS RAB and 30 sec for PS RAB.
• The UE stores these timer values and when it encounters the failure it
down-switches from DCH to FACH.
• The UE would then indicate in cell Update message whether the CS and PS
RAB timers have expired or not. When the timers have not expired the
network will initiate the call Reestablishment.
 What is RRE and why it is needed?

The sequence of Call reestablishment flow is as follows:

• Delete all old Radio Links

• Setup New Radio Link in the cell where the cell Update has originated
from
• Send CellUpdateConfirm Message to the UE.
• UE replies with one of the response message (Transport Channel/Radio
Bearer Setup/RadioBearer Release/Physical Channel Reconfiguration
Complete)

 The CellUpdateConfirm Message will contain the information about the

RABs that has been restored. In case of Multi-RAB, if only the CS or if only
the PS could be restored, then the CellUpdateConfirm message has also
the release information for the RAB that could not be restored or has been
lost. The UE in this case should reply with RadioBearer Release
Reconfiguration Complete.
 What is RRE and why it is needed?
• The primary benefit of RRE is to re-establish RRC connection of UEs that temporarily go out of
coverage (or travelling through tunnels etc), so the call will not drop.
• The user will not have to explicitly re-establish the session.
• When a UE detects a Radio Link Failure or an AM RLC unrecoverable error, the UE goes to
CELL_FACH state, performs a cell reselection and starts a Cell Update procedure. The RNC
determines the failure in one of the following ways:
• The RNC is informed of the failure and of the UE state change when it receives the Cell
Update message with cause “Radio Link Failure” or “RLC unrecoverable error”.
• The RNC detects RLC unrecoverable error before a Cell Update message is received.
• The Node B indicates a Radio Link Failure to the RNC before a Cell Update message is
received.
• In the mRAB case RRE is not attempted if the UE is in bad radio conditions (i.e. CPICH Ec/N0
below a configurable threshold)
• T314 & T315 are guard timers during which the UE keeps the RABs following radio link failure
until they expire or the cell update procedure has been completed.
• During this time, the RNC can try to re-establish the UE so that the user traffic can
resume. When T314 and / or T315 expire, the UE releases the associated RABs.
• T314 = 8s and T315 = 30s in AT&T network.
• The 9370 is configured with the same values via separate parameters
(rrcReestCSMaxAllowedTimer and rrcReestPSMaxAllowedTimer
RRE Typical flow
 What is RRE and why it is needed?

 RRE is RRC Connection Re-establishment and this feature intends to make

the Alcatel-Lucent UTRAN capable of re-establishing RRC connection due
to cell update with radio link failure or RLC unrecoverable error when PS
RAB, CS+PS RAB, PS + PS RAB, CS + PS + PS RAB are mapped to FACH, DCH
or HS-DSCH or E-DCH.
 Reduces the possibility to drop the call due to radio link failure, AM RLC
unrecoverable error.
 Earlier PM33821 feature consists in re-establishing the PS domain of a UE
that temporarily goes out of coverage with PS RAB established, ie PS RABs
of the following RAB combinations: PS, CS+PS IB, PS IB+PS IB, PS
Streaming+PS IB, or CS+PS IB+PS IB, or CS+PS Streaming+PS IB.
 Later PM34290 feature was introduced to take care of CS calls re-
establishments as well.
PM33821: For PS call re-establishment only
 For multi–service calls, only PS is re-established, CS is released.
 When UE detects a RL Failure or an AM RLC unrecoverable error on CELL_DCH,
the UE goes to Cell FACH state and performs a cell reselection and starts a Cell
Update procedure. The RNC is informed of the failure and the state change of
the UE when it receives the RRC Cell Update message and UE waits for RRC
Cell Update Confirm message to resume Data transfer.
 At the beginning of Cell Update procedure it starts T314 and / or T315
according to established RABs. On expiration of timer T314 and / or T315 the
UE releases the associated RABs, but PS Rab is preserved.
 The Cell Update message may be sent for a new cell by the UE repeatedly.
 Upon detecting Radio Link Failure or RLC unrecoverable Error from Node B or
Uplane, the RNC releases the old Node B resources and waits a Cell Update
Message from UE and after RNC receives the Cell Update Message, at first,
RNC suspends the RLC and performs the RRC Connection Re-establishment
procedure. Before sending Cell Update Confirm message, RNC resumes the
RLC.
PM33821: For PS call re-establishment only
 In Iur case, a release of the RRC connection shall be used so that the UE
re-initiates the RRC connection on the new RNC: when the Cell Update is
received from a UE served by another SRNC, RRC Connection Release
message is sent with the cause Directed Signalling Connection Re-
establishment (DSCR).
 W.r.t. OAM, following are the feature activation flags which needs to be
enabled: isRrcReEstablishAllowed, RrcReEstablishThreshold,
rrcReestMaxAllowedTimer.
 Upon detect of Radio Link Failure or RLC unrecoverable Error from Node B
or Uplane, the RNC releases the old Node B resources and wait a Cell
Update Message from UE after RNC receives the Cell Update Message,
RNC suspends and resume the RLC when RRC Connection Re-
establishment is triggered
PM33821: For PS call re-establishment only
 Prior to trying a RRC connection establishment, RNC shall check whether
CPICH_Ec/N0 of Cell Update Message is better than RrcReThreshold value.
If it is good, RRC Connection Re-establishment procedure is performed
else RRC Connection Re-establishment procedure is not performed and
RNC shall check RANAP state. If a RANAP procedure is on-going, the RRC
connection re-establishment shall not occur.

 The Rb Mapping Infomations for DCH and FACH states have to be provided
to the UE at RRC CONNECTION SETUP (for SRB) and RADIO BEARER
RECONFIGURATION (for incoming Relocation, AlwaysOnUpsize) because
RRC CELL UPDATE CONFIRM message has to be sent on the DCCH.
 PM33821:Sample scenario (NBAP Radio Link
Failure Indicator to RNC)
• ACTION:
•
– PS RAB is established on DCH
– Node-B sends the NBAP Radio Link Failure Indicator to RNC
– UE sends CELL UPDATE message with RL Failure cause to RNC

• EXPECTED BEHAVIOUR:

1. CELL FACH Reconfiguration of SRB

2. Old RL is released
3. CELL UPDATE message is received
4. New RL is established
5. CELL DCH Reconfiguration of SRB
6. Reconfiguration of TRB
7. CELL UPDATE CONFIRM is sent to UE
8. RNC receives the RRC RB Reconfiguration Complete message
9. CCCH Resource is released.
10. RRC Measurement Control is sent to UE.
11. Measurement Control is sent to I-Node
12. COMMIT_CIPHERING_CHANGE_REQ is sent to I-Node
 PM33821:Sample scenario: RRC CELL UPDATE Message(cause :
RLC Unrecoverable Error, SRB Reset Ind : FALSE, TRB Reset Ind:
TRUE) from UE
ACTION:

1. PS RAB is established on DCH

2. UE sends CELL UPDATE message with TRB RLC Unrecoverable Error cause to RNC

EXPECTED BEHAVIOUR:

1. CELL UPDATE Message is received.

2. CELL FACH Reconfiguration of SRB
3. Old RL is released
4. New RL is established
5. CELL DCH Reconfiguration of SRB
6. Reconfiguration of TRB
7. CELL UPDATE CONFIRM is sent to UE
8. RNC receives the RRC RB Reconfiguration Complete message
9. CCCH Resource is released.
10. RRC Measurement Control is sent to UE.
11. Measurement Control is sent to I-Node
12. COMMIT_CIPHERING_CHANGE_REQ is sent to I-Node
PM34290: RRC Connection Re-establishment for
CS calls.
 This feature provides the CS RAB support to the feature PM33821(UA06.0
version) RRC Reestablishment for PS.
 This feature intends to make the Alcatel-Lucent UTRAN capable of re-
establishing RRC connection for CS RAB due to the Cell Update with Radio Link
(RL) Failure or RLC Unrecoverable Error when CS RAB, CS+PS RAB, CS + PS + PS
RAB are mapped to DCH or HS-DSCH or E-DCH.
 Re-establishes the CS domain of a UE that temporarily goes out of coverage
with CS RAB established. It reduces the possibility of dropped call due to RL
Failure or AM RLC Unrecoverable Error.
 When UE detects a RL Failure or an AM RLC Unrecoverable Error (on TRB, and
PS+CS call) on CELL_DCH and if timer T314 value is set (i.e. non-zero), the UE
goes to Cell FACH state, and starts a Cell Update procedure. The RNC is
informed of the failure when it receives the RRC Cell Update message. UE
waits for RRC Cell Update Confirm message to resume data transfer. But if UE
detects RLC Unrecoverable Error on SRB, the call is simply dropped.
PM34290: RRC Connection Re-establishment for
CS calls.
 Upon detecting RL Failure from Node B or UPlane, the RNC releases the old
Node B resources and waits for a Cell Update Message from UE. When RNC
receives the Cell Update message, at first, RNC suspends the RLC/MAC and
performs the RRC Connection Re-establishment procedure. Before sending
Cell Update Confirm message, RNC resumes SRB1, so that Cell Update Confirm
can be sent out. After that, upon receiving the 1st UL data, the rest of SRBs(2-
4) and PS TRB are resumed, RNC resumes the RLC/MAC.

 Upon receiving Cell Update message from UE, if it is CS call with standalone CS
RAB, this feature shall re-establish CS, while PM33821 releases CS RAB and the
RRC connection. In the case of multi-service calls, PM33821 releases CS and
re-establishes PS only, this feature shall re-establish CS on top of it.

 The message RRC CELL UPDATE CONFIRM has to be sent on the DCCH/FACH,
implying that the INODE shall establish & support the multiple paths
(DCCH/FACH (RACH), DCCH/DCH).
 The message RRC CELL UPDATE CONFIRM has to be sent on the
DCCH/FACH, implying that the INODE shall establish & support the
multiple paths (DCCH/FACH (RACH), DCCH/DCH).
 For CS RAB, when getting the new radio resource parameters for UE,. RAB
matching algorithm is enhanced so that CS RAB retains the same rate
(same CS UL/DL RbSets) as prior to the failure.
 OAM SPECIFIC CONFIGURATION: isCSRrcReestablishAllowed,
sPSRrcReestablishforICFailureAllowed, rrcReestCSMaxAllowedTimer,
rrcReestablishCSThreshold
 PM132010: RRE over IUR
 PM33821 is V6 feature which introduced RRC connection re-establishment
to recover PS call only; CS call is released during RRE procedure.
 PM34290 is the following feature to do RRC connection re-establishment
to recover both CS and PS call.
 Both features only support cell update received in SRNC, for cell update
received in DRNC, RRC Connection Release message is sent with the cause
Directed Signalling Connection Re-establishment (DSCR) and call is
released. UE will then re-initiate RRC connection to new SRNC.
 PM132010 removed the Iur limitation set by PM33821 and PM34290, it
perform RRC connection re-establishment over Iur and recover the call
with RL in DRNC
 PM132010: RRE over IUR
 Due to UE mobility, RRC Cell Update including RRE failure causes (Radio
link failure or RLC unrecoverable error) could be sent to a cell in DRNC,
instead of performing RRC release, DRNC forward cell update through
Uplink Signalling Transfer Indication on CCCH to SRNC. SRNC interpret cell
update cause and initiate RRE by setting up RNSAP RL and Transport
bearer Over Iur. The RRC Cell Update Confirm is enclosed in RNSAP
Downlink Signalling Transfer Indication and sent over CCCH to DRNC,
which then sends RRC Cell Update Confirm to UE over CCCH.

 The call configuration eligible to RRE over Iur is max 3PDP in combination
with CS thanks to feature PM81449 RAB combination – Multiple PDP
enhancement.
 RRC state prior to RRE can be CELL_DCH or CELL_FACH. The transport
channel type for TRB can be DCH, HSDPA and EDCH, and for SRB, it can be
DCH, SRB over EDCH and SRB over F-DPCH.
 PM132010: RRE over IUR
 New feature flag: IsRreOverIurAllowed is introduced.
 The feature flag interact with existing flag
rrcReestablishForSingleOrMultiServiceMode to re-establish RRC
connection for PS only or CS and PS over Iur.
PM132010 –RRC Connection Re-establishment over
Iur support
•Description
– Extends current RRE capability to additional scenarios involving Iur.
– Specifically this provides two key capabilities:
1. DRNC can now convey a received Cell Update (CU) across the Iur to the SRNC.
– Currently the DRNC will reject the CU, forcing a UE re-registration.
2. SRNC can now trigger the existing RRE paradigm from a CU received via the Iur.
– Currently the SRNC will reject the CU, forcing a UE re-registration.
•Benefits
– Improves KPI11(Iur), by avoiding a deterministic class of avoidable call drops.
•Activation/Configuration
– Activation: Feature flags on both SRNC and DRNC.
• SRNC: RNC/RAS/IsRreOverIurAllowed set to True.
• DRNC: RNC/NeighbouringRNC/IsRreOverIurAllowed set to True.
– Control: N/A (no additional behavioral controlling parameters).

All Rights Reserved Alcatel-Lucent 2013 19

 PM132010 – Overview
• Currently RRE is either not triggered (i.e. immediate call drop) or it is triggered but fails for scenarios
related to Iur.
• Fundamental to PM132010 is the necessity for the 9370 to be able to transfer (and appropriately
receive/process) a Cell Update (CU) over the Iur
• This applies to cases where the SRNC is identified in the CU.
• The general intention is to now trigger and/or support RRE for these Iur-related scenarios in order to
enhance the user experience, and improve the associated KPIs.
• The system reaction triggered by RRE/Iur will be similar to the case of non-Iur RRE processing on the
SRNC, referred to as “Traditional-RRE”.
• With “Traditional-RRE” the approach is to release old RL and re-establish the RL upon
reception of the CU from the UE.
• RRE/Iur provides consistency wrt current non-Iur RRE handling, and increases the opportunity
for seamless IOT support with E///.
• Multiple scenarios (12 identified) initially considered for inclusion in PM132010 (with differing value
statements and technical risk), but after analysis and discussion with AT&T:
• 5 key scenarios chosen for inclusion in LR14, based on their anticipated KPI11 and KPI11-Iur
projected benefits.
• Other scenarios excluded from LR14, due to complexity, value, or non-KPI11 benefits.
 Unaffected Behaviour
Scenario 3 flow: UE Detected failure – non-mobility Iur
Pre-PM132010 UA08
behaviour.

1) Precondition: UE is in CELL_DCH on cell2 under DRNC, with PRL on PM132010 behaviour.

this Iur link. Either CS-only, PS-only or PS+CS mRAB call.

UE NODEB DRNC SRNC Core

1) CS, PS or PS+CS RAB established (CELL_DCH) via PRL on Iur

2) UE detects a
RL failure and 2) Cell Update (RL failure)
3a-UA08) DRNC responds to CU with RRC Release
sends a CU to (DSCR) and UE re-attaches to DRNC (i.e. starts over).
DRNC. Starts 3a-UA08) RRC Connection Release (DSCR)
T314/15,
guarding T314/15 3b-UA08) Iu-Release-Command
3b-UA08) KPI11-Iur impacted (via
completion of CU
VS.RAB.Drop.CN.Init.CSV <DRNC>) upon
procedure.
reception of unsolicited Iu-Release-Command.

4-UA08) SRNC responds

3) RNSAP: Uplink Signalling Direct
3) DRNC sends CU to SRNC to CU with RRC Release
Transfer Indication/Forwarded Cell Update
identified in the CU. (DSCR) via RNSAP.

4) RNSAP (RRC Connection Release (DSCR))

5) Reception of CU across Iur
triggers “Traditional-RRE” on
“Traditional RRE” Procedure SRNC (i.e. RL deletion followed by
re-establishment, not shown).
7-8) Normal 7) Cell Update Confirm 6) RNSAP: DL Sig Transf Req (CUC)
completion of
Traditional-RRE 8) Radio Configuration Complete 6) RRE sends CUC across Iur, a
new/key behavioural aspect of RRE/Iur

New 9370 behaviour

Scenario 4 flow: NodeB/SRNC-RLC Detected failure – non-mobility Unaffected Behaviour
Iur Pre-PM132010 UA08
behaviour.
1) Precondition: UE is in CELL_DCH on cell2 under DRNC, with PRL on
this Iur link. Either CS-only, PS-only or PS+CS mRAB call. PM132010 behaviour.

UE NODEB DRNC SRNC Core

1) CS, PS or PS+CS RAB established (CELL_DCH) via PRL on Iur 4-UA08) SRNC drops call upon
reception of RNSAP failure
2) NBAP (RLF) message. K11-Iur impacted (via
2) NodeB detects/reports RLF failure, 3) RNSAP (RLF) VS.RAB.Drop.CSV<.NeighbRn>)
which DRNC sends to SRNC.

4) SRNC starts normal RRE

5) UE detects a RL
failure and sends a
CU to DRNC. Starts
T314/15, guarding
completion of CU
procedure.
processing, which means deleting old
RL and waiting for the CU to arrive
rrcReestCSMaxAllowedTimer/ before re-establishing the new RL
“Traditional RRE” rrcReestPSMaxAllowedTimer (guarded by
Procedure rrcReestCSMaxAllowedTimer/rrcReest
PSMaxAllowedTimer).
5) Cell Update (RL failure) 6) RNSAP: Uplink Signalling Direct
Transfer Indication/Forwarded Cell Update

6-UA08) DRNC responds to

T314/15 CU with RRC Release (DSCR) 6) DRNC sends CU to SRNC
identified in the CU.

8-9) Normal 7) RNSAP: DL Sig Trans Req (CUC)

8) Cell Update Confirm
completion of
Traditional-RRE 7) Sending CUC across Iur
9) Radio Configuration Complete
a new/key behavioural
aspect of RRE/Iur

New 9370 behaviour

Scenario 12 flow: UE wanders back to SRNC cell after the DRNC failure Unaffected Behaviour
detected (NodeB/RNC detected failure) Pre-PM132010 UA08
behaviour.

1) Precondition: UE is in CELL_DCH on cell2 under DRNC, with PRL on PM132010 behaviour.

this Iur link. Either CS-only, PS-only or PS+CS mRAB call.

UE NODEB DRNC SRNC Core

2) UE loses
coverage under
cell2 and moves 1) CS, PS or PS+CS RAB established (CELL_DCH) via PRL on Iur 4-UA08) SRNC drops call upon
into cell1
2) NBAP (RLF) reception of RNSAP failure
controlled under 3) RNSAP (RLF)
message. K11-Iur impacted (via
SRNC, resulting
VS.RAB.Drop.CSV<.NeighbRn>)
in NodeB RLF
detection under rrcReestCSMaxAllowedTimer/
DRNC. rrcReestPSMaxAllowedTimer 4) SRNC starts normal RRE processing,
which means deleting old RL and
“Traditional RRE” waiting for the CU to arrive (guarded by
5) UE sends
CU (RL failure) Procedure rrcReestCSMaxAllowedTimer/rrcReestP
to SRNC, and SMaxAllowedTimer).
starts T314/15, 5) Cell Update (RL failure)
guarding
completion of 6) RRE continues after reception
CU procedure. of CU on new cell under SRNC. In
T314/15
7) Cell Update Confirm this case the re-establishment is
8) Radio Configuration Complete a new RL setup, not present prior
7-8) Normal to the failure.
completion of
Traditional-RRE

New 9370 behaviour

 Scenario 1 flow: UE Detected failure - mobility Unaffected Behaviour

Pre-PM132010 UA08
behaviour.
1) Precondition: UE is in CELL_DCH on cell1 under SRNC.
PM132010 behaviour.
Either CS-only, PS-only or PS+CS mRAB call.

UE NODEB DRNC SRNC Core

1) CS, PS or PS+CS RAB established (CELL_DCH), no Iur

2) Cell Update (RL failure)
3a-UA08) DRNC responds to CU with RRC Release
2) UE loses 3a-UA08) RRC Connection Release (DSCR) (DSCR) and UE re-attaches to DRNC (i.e. starts over).
coverage under
cell1 and moves 3b-UA08) Iu-Release-Command
T314/15
into cell2 3b-UA08) KPI11 impacted (via
controlled by VS.RAB.Drop.CN.Init.CSV) upon reception of
DRNC and sends eventual unsolicited Iu-Release-Command.
CU ( RL failure) to
DRNC.
3) RNSAP: Uplink Signalling Direct
3) DRNC sends CU to SRNC Transfer Indication/Forwarded Cell Update 4) UA08) SRNC
identified in the CU. responds to CU with
RRC Release (DSCR) via
4) RNSAP (RRC Connection Release (DSCR)) RNSAP.

“Traditional RRE” Procedure 4) Reception of CU across Iur triggers

“Traditional-RRE” reaction on SRNC
6-7) Normal 5) RNSAP: DL Sig Trans Req (CUC) (i.e. RL deletion followed by re-
completion of 6) Cell Update Confrm
establishment). In this case the re-
Traditional-RRE 7) Radio Configuration Complete establishment is a new Iur setup, not
present prior to the failure.

New 9370 behaviour

 Scenario 2 flow: SRNC/Nodeb Detected failure - mobility Unaffected Behaviour

Pre-PM132010 UA08
behaviour.

1) Precondition: UE is in CELL_DCH on cell1 under SRNC. Either CS- PM132010 behaviour.

only, PS-only or PS+CS mRAB call.

UE NODEB DRNC SRNC Core

1) CS, PS or PS+CS RAB established (CELL_DCH), no Iur

2) NBAP (RLF)
2) NodeB detects/reports RLF 3) SRNC starts normal RRE processing,
failure, which it sends to SRNC. which means deleting old RL and
rrcReestCSMaxAllowedTimer/ waiting for the CU to arrive (guarded by
“Traditional RRE” rrcReestPSMaxAllowedTimer rrcReestCSMaxAllowedTimer/rrcReestP
SMaxAllowedTimer).
4) UE detects RL Procedure
failure and sends
CU to DRNC. Starts
T314/15, guarding 4a-UA08) CU rejected by
completion of CU the DRNC (DSCR).
procedure.
5) RNSAP: Uplink Signalling Direct
4) Cell Update (RL failure) Transfer Indication/Forwarded Cell Update

5a-UA08) SRNC drops call

(via
T314/15 5) New Behaviour: DRNC sends CU to VS.RAB.Drop.CN.Init.CSV)
SRNC identified in the CU.

8-9) Normal 7) Cell Update Confirm 6) RNSAP: DL Sig Dir Req (CUC)
completion of 5b) Continuation of RRE (via
8) Radio Configuration Complete reception of CU from Iur)
Traditional-RRE

New 9370 behaviour

 Additional PM132010 Info
• Existing RRE triggering rules (e.g. triggered upon failure of last RL, cpich Ec/I0 above minimum
configured threshold, call must be in a DCH state) are unchanged by PM132010.
• Existing RRE restrictions wrt interactions with ongoing procedures (e.g. RRE does not occur if a
RANAP procedure is in progress) are unchanged by PM132010.
• In these cases the call would be dropped due to the RLC/RL failure.
• CU causes which can trigger RRE over Iur are RL failure and RLC unrecoverable error (other CU
causes for the related scenarios will still result in a DSCR).
• UE must be camping on a cell under the DRNC which is known to SRNC (i.e. provisioned to SRNC as
neighboring cell or provided by DRNC via SHO-Iur) or else the SRNC is unable to perform RRE over
Iur upon reception of CU.
• The CUC on the DRNC is sent over the common channel, which is un-ciphered (today the CUC sent
on the SRNC cell is ciphered).
• When the PM119418-introduced flag isReleasePsOnRncDetectedTrbRlcErrorAllowed is true, a TRB
RLC error for an mRAB call triggers PS release, without invoking RRE, irrespective of whether the
PRL is on the SRNC or DRNC.
• PM132010 does not affect this behavior.
• RRE/Iur for a 2msTTI call triggers fallback to 10ms.