RRC Re-Establishment

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 16
At a glance
Powered by AI
The document discusses various RRC connection failures including RACH failure, RRC Connection Reject, RRC Re-establishment Reject, and failures due to timers.

RACH failure, RRC Connection Reject due to congestion, and RRC Re-establishment Reject if UE context is incorrect or admission control fails.

RRC Connection Reject occurs when resources cannot be provided, RRC Re-establishment Reject when UE context is incorrect or admission fails, RRC Release releases the connection.

i Here i will try to give the reasons of lte negative scenarios such as RACH Failure, RRC connection Reject,

RRC re-establishment Reject and RRC Release.

Broadly the following are the most RRC failures:

When we refer to EPS bearers, it means we always refer to Data Radio bearers (DRBs) when in comes to
E-UTRAN Radio/Air interface. EPS never directly refers to SRB. A PDN Connection gets mapped all the
way till a DRB and is available only in user plane. Usually EPS bearer identity in EPS = DRB identnty in
E-UTRAN, let it be default or dedicated bearers. The DRBs exists in the path UE <--> eNodeB <--> S-GW
<--> P-GW.

But the story is entirly different in case of SRBs. We can say, SRB exists in the path UE <--> eNodeB <-->
MME <--> S-GW <--> P-G, but it is not true, SRBs exists only in the path UE <--> eNodeB. After eNodeB
SRBs are not mapped to any other bearers in EPC. SRBs exists only in control plane of UE <--> ENodeB
and these are used to exchange the information (through NAS or AS signaling messages) that helps in
setup/ modification/ release of DRBs.

So when we refer to EPS bearers they are all logical path and in terms of radio bearers they are refered
as DRBs. SRB though it is also a logical path, it does not find its context in EPS bearers.

That’s the good catch. I would like to make one thing sure. 11 EPS bearers are never mapped on 8 logical channel
Ids. Each EPS bearer, i.e. DRB is mapped to one DTCH logical channel. So, following table shows mapping.

DRBs DTCH Channel


(Logical Instance)
----------------------------------------------
DRB-1 <--> DTCH-3
DRB-2 <--> DTCH-4
DRB-3 <--> DTCH-5
...
...
DRB-8 <--> DTCH-10
DRB-9 <--> ???
DRB-10 <--> ???
DRB-11 <--> ???

Following description is according to my understanding.

Table 4.8.2.1.7-1 of spec 36.508 dictates how the values of DRB id should be used. As per this document filling of the
DRB-ToAddMod information element (IE) is done as follows:
Consider we are establishing DRB2 through RRCConnectionReconfiguration Message.
Then,

DRB-ToAddMod(drbId) ::= SEQUENCE {


eps-BearerIdentity drbID+4
drb-Identity drbID
pdcp-Config PDCP-Config-DRB-AM
(Considering case of AM)
rlc-Config RLC-Config-DRB-AM
(Considering case of AM)
logicalChannelIdentity drbID+2
logicalChannelConfig LogicalChannelConfig- of DRB for AM
}

Table 4.5.3.3-1 of same spec which gives detailed procedure of generic radio bearer establishment, indicates the
number of drbs to be added (N) is 0 <= N <= 7.
Thus, Specification nowhere specifies what is the mapping after all logical Channel IDs are used up?
We can expect this field to be updated in upcoming publication of 36.331 spec.
What do you say?

1. RRC failures because of RACH failure


1.1. RACH failure occurs very often.
1.1.1. While initial attach at the time of sending RRC connection request,
1.1.2. Handover (contention based/non contention),
1.1.3. Rach procedure on DL data arrival when out of sync(Non Contention Based/Contention Based),
1.1.4. RACH Procedure on UL Data Arrival when Out-of-Sync,
1.1.5. RACH Procedure on RRC Connection Re-establishment when Out-of-Sync
2. RRC Connection Reject
2.1. eNodeB may send RRC Connection Reject in response to the UE’s RRC Connection Request. This typically
happens if the cell is congested and the necessary radio resources for the connection setup cannot be provided
and/or the eNodeB is overloaded. According to the 3GPP TS 36.331 , there is no reject cause value specified for the
RRC connection reject message in the LTE . However RRC connection reject message provides the wait time
parameter. The value of this wait time is an integer number in the range of 1–16. Wait time defines how many
seconds the UE should wait after reception of RRC Connection Reject until a new RRC connection request message
is sent.

3. RRC Re-establishment Reject.


3.1 If UE is receiving very less RSRP so enodeb will ask MME to release UE context as cause radio failure but in
this case UE is sending RRC connection re_establishment. But enodeB will send
RRC_re_establishment_Reject and then it release UE.
3.2 Resstablsihment is sent after following are found to be correct
physCellId,shortMAC-I ,c-RNTI t and there are enough resources to cater to the coming UE(Admission
Control).
RRC Connection Reestablishment Reject is sent when either value of the above are incorrect or admission
control fails.
EnodeB already has the information ,for shortMAC-I it consults the PDCP layer for assess it's correctness

4. RRC Failures due to Timer Expires


4.1. T300(After UE sending RRC_connection_Requiest but not received set up within T300)
4.2. T301 (After UE sending RRC_connection_Reestablishment_Requiest but not received set up within T300
so UE will go to idle)
4.3. T304(After Receiving RRC_Reconfiguration for Handover but not gone to RRC-Connected(successful
Handover) with in T304 so UE initiates RRC_re_estblishment Procedure)
4.4. T303 and T305( Access barred while performing RRC connection establishment for mobile originating
callsT303 and mobile origination signallingT305 but not gone to connected state within T303&T305)
4.5. T310(After Receiving N310 out of sync orders but not received N311 in sync orders with in T310 So UE
will go to idle if security is not activated)
4.6. T311(After UE initiating RRC_Restablishment procedure but not selected suitable EUTRA cell with in
T311 so UE will go to idle)

5. RRC Connection Release(apart from expiry of inactivity timer)


5.1 Max RLC Retransmission Reached
5.2 RLF(Radio Link Failure) UE RSSI is very low at enodeB and not able to sense UE then enodeB
asks MME to Release UE with cause radio failure.
5.3 If UE is receiving very less RSRP so enodeb will ask MME to release UE context as cause radio failure but in
this case UE is sending RRC connection re_establishment. But enodeB will send
RRC_re_establishment_Reject and then it release UE.
5.4 So eNodeB will release UE after sending RRC_connection_re_establishemnt_Reject. This is one case of
RRC_Release cause as other.
5.5 In case of MME load balancing, MME will ask UE to initiate TAU.
Suppose MME wants to free up some resources to do a load balancing, then as a part of RRC
connection release message it will sends with cause as 'load balancing TAU required', then UE
initiates TAU procedure.

6. RRC Reconfiguration Failure:


6.1 After receiving RRC Reconfigration from eNodeB, if the configurations are not match with UE then UE will
initiate Re_establishmetn Procedure if security is activated, if security is not activated then RRC Release will
happen.

7 UE will remain idle irrespective of eNodeB RRC Release.(UE will remain in idle if T301(Restablishment
request),T311(Restablishment procedure for suitable EUTRA cell or for another RAT) expiry, Also at expiry of
T310 if security is not activated)

RRC Connection Reestablishment Request


The purpose of RRC CONNECTION RE-ESTABLISHMENT procedure is to re-establish the RRC
connection, which involves the resumption of SRB1 operation and the re-activation of security (without
changing algorithms). The UE shall only initiate this procedure when AS security has been activated.

The connection re-establishment succeeds only if the concerned cell is prepared i.e. has a
valid UE context. In case E-UTRAN accepts the re-establishment, SRB1 operation resumes while the
operation of other radio bearers remains suspended. If AS security has not been activated, the UE
doesn’t initiate this procedure, instead, it moves to RRC_IDLE directly

The UE initiates the RRC CONNECTION RE-ESTABLISHMENT procedure when one of the following
conditions is met:
 Upon detecting radio link failure; or
 Upon handover failure; or
 Upon mobility from E-UTRA failure; or
 Upon integrity check failure indication from lower layers; or
 Upon an RRC CONNECTION RECONFIGURATION failure

RRC Connection Reestablishment Request Message

Direction: UE => E-UTRAN


Signalling Radio Bearer: SRB0
RLC Mode: TM
Logical Channel: CCCH
Transport Channel: UL-SCH

IEs in RRC CONNECTION REESTABLISHMENT REQUEST message are given below:

ue-Identity: UE identity is included to retrieve UE context and to facilitate contention resolution by


lower layers. The UE Identity shall be set as follows:
1. Set the C-RNTI to the C-RNTI used in the source PCell (In case of handover and mobility
from E-UTRA failure) or used in the PCell in which the trigger for the re-establishment occurred
(other cases);
2. Set the physCellId to the physical cell identity of the source PCell (handover and
mobility from E-UTRA failure) or of the PCell in which the trigger for the re-establishment
occurred (other cases);
3. Set the shortMAC-I to the 16 least significant bits of the calculated MAC-I
reestablishmentCause: This IE indicates the failure cause that triggered the re-establishment
procedure and shall be set as follows:
1. If the re-establishment procedure was initiated due to reconfiguration failure (the UE is
unable to comply with the reconfiguration sent in RRC CONNECTION RECONFIGURATION), then
set thereestablishmentCause to the value 'reconfigurationFailure';
2. If the re-establishment procedure was initiated due to handover failure (intra-LTE
handover failure or inter-RAT mobility from EUTRA failure) then, set
the reestablishmentCause to the value'handoverFailure'
3. Set the reestablishmentCause to the value 'otherFailure' if the re-establishment
procedure was triggered due other causes than indicated in cases 1 and 2
Example: RRC CONNECTION REESTABLISHMENT REQUEST
Reference: 3GPP TS 36.331
Reactions:
Posted by Kumar Swamy Pasupuleti at 12:41 PM
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest
Labels: EPC, RRC, RRC Messages
47 comments:

1.

AnonymousDecember 12, 2012 at 5:22 PM

wht do u think about other failure?


Reply

2.

Kumar Swamy PasupuletiDecember 13, 2012 at 4:59 AM


Hi

'OtherFailure' could be because of radio link failure, integritycheck failure etc.. whichever
doesn't fall in the category of 'handoverFailure' or 'reconfigurationFailure'
Reply

3.

manish kakkarJanuary 28, 2013 at 2:47 PM

Is it possible UE Can trigger re-estbalishment without initiative RACH procedure ?


Reply

4.

Kumar Swamy PasupuletiFebruary 1, 2013 at 9:37 AM


It is not possible to trigger re-establishment procedure without RACH procedure.
Reply

5.
Guru PrakashJune 24, 2013 at 12:17 PM

Based on what condition eNB come to know UE has lost its Radio link between the UE and
eNB?
Reply

6.

Ankur SinhaJuly 9, 2013 at 10:57 AM

upon receiving N310 consecutive "out-of-sync" indications for the Cell from lower layers a
timer T310 is started and when this timer expires. It is understood by UE that RLF has
occured
Reply

7.

CanvasAugust 14, 2013 at 10:07 AM

How many times a UE can try re-establishment?


Reply

8.

Kumar Swamy PasupuletiAugust 26, 2013 at 10:04 AM


Once the RRC Connection Re-establishment procedure is triggered, the UE shall start the
timer T311, and once the UE selects a suitable cell, this T311 timer is stopped, and RRC
initiates the transmission of RRC Connection Re-establishment message and start the
timer T301. This timer is stopped only when "Reception of RRC Connection
Reestablishment or RRC Connection Reestablishment Reject message as well as when
the selected cell becomes unsuitable"

If either T311 or T301 expires, the UE goes to Idle mode and no more RRC Connection
Re-establishments sent. This implies that the UE could try re-establishment only once after
the procedure is triggered.

Reply

9.

AnonymousAugust 31, 2013 at 8:19 PM

Hi

is it possible eNB detect the false RRC Connection Re-establishment request?


Reply
Replies

1.
Kumar Swamy PasupuletiSeptember 2, 2013 at 6:02 AM
Please specify what do you mean by False RRC connection re-est request
Reply

10.

PV ReddySeptember 2, 2013 at 11:48 AM

Integrity Check Failure Case:

It check fails at UE PDCP, it intimates to RRC about it and RRC triggers RRC Connection
re-establishment.
How about at eNodeB, What RRC will do once it got indication from PDCP of eNOdeB.

Regards,
Venky
Reply

11.

Kumar Swamy PasupuletiSeptember 2, 2013 at 12:14 PM


Most of such error handling is done by releasing the existing RRC connection with release
cause "other"
Reply

12.

sarvjeetSeptember 14, 2013 at 6:39 AM

WHAT IS MEAN BY VALID UE CONTEXT


Reply

13.

sarvjeetSeptember 14, 2013 at 6:44 AM

and please also explain short mac-i,pcell


Reply

14.
Kumar Swamy PasupuletiSeptember 15, 2013 at 5:40 PM
Usually, eNB maintains (at RRC) an UE context once the connection is established (also,
a context between the MME and eNodeB)

The IE ShortMAC-I is used to identify and verify the UE at RRC connection re-
establishment. The 16 least significant bits of the MAC-I calculated using the security
configuration of the source PCell

PCell is the primary cell on which UE has initiated the connection establishment and
attached to. This terminology is wrt to Carrier Aggregation where there could be more than
one serving cell (aggregated) to increase the bandwidth. All additional serving cells apart
from PCell are referred to as secondary cells (SCells)

Reply

15.

AnonymousOctober 18, 2013 at 5:57 PM

Hi,

Since RRC Re-establishment occur after losing RRC connection so every rrc re-
establishment request can consider as RRC drop irrespective of re-establishment success
or failure. ??

If re-establishment occur due to handover failure is it possible to get re-establishment


success because handover means cell will be change and Ue context will not be available
in new cell.
Reply

16.

Kumar Swamy PasupuletiOctober 21, 2013 at 10:42 AM


The re-establishment (triggered due to HO failure) can also be successful as the UE
context is not moved to new cell until HO success
Reply
Replies

1.
RajeshKumar@CommonManDecember 24, 2014 at 8:27 AM

Means UE send RRC Re-Establishment Req to Old eNB rather than new
eNB in case of HO?
Reply
17.

AnonymousOctober 30, 2013 at 8:02 AM

If the radio link is failed with current cell due to HO failure. UE tries to establish RRC
connection again by sending RRC connection reestablishment request to eNB. Suppose
in our scenario, by that time UE is moved to new cell (target eNB) where it is getting good
signal, then,

Will the same UE sends RRC connection re-establishment request or new RRC connection
request to target eNB? (But still the existing UE context with source eNB has not been
transferred to target eNB.)

Can anyone clear this?


Reply

18.

Kumar Swamy PasupuletiOctober 30, 2013 at 10:38 AM


The UE sends RRC Connection Re-establishment towards new eNB.

The RLF Indication procedure may be initiated after a UE attempts to re-establish the radio
link connection at eNB B after a failure at eNB A. The RLF INDICATION message sent
from eNB B to eNB A shall contain the following
information elements:
- Failure Cell ID: PCI of the cell in which the UE was connected prior to the failure occurred;
- C-RNTI: C-RNTI of the UE in the cell where UE was connected prior to the failure
occurred;
- shortMAC-I (optionally): the 16 least significant bits of the MAC-I calculated using the
security configuration of the source cell and the re-establishment cell identity;
- UE RLF Report Container (optionally): the RLF Report received from the UE

eNB B may initiate RLF Indication towards multiple eNBs if they control cells which use the
PCI signalled by the UE during the re-establishment procedure. The eNB A selects the UE
context that matches the received Failure Cell ID and C-RNTI, and, if available, uses the
shortMAC-I to confirm this identification, by calculating the shortMAC-I and comparing it to
the received IE
Reply
Replies

1.
Luv SinghAugust 7, 2014 at 12:18 PM

This comment has been removed by the author.


2.

Luv SinghAugust 7, 2014 at 12:20 PM

Hi Swamy , considering the above case , so eNB B has got the context of
UE from eNB A or from its controlled cells . And now eNB tries to match the
fetched MAC-I & ue MAC-I (in Estab req message) & it fails . Then eNB B
sends reject msg to UE .
Could you please tell possibilities of MAC-I verification failure at eNB ??

3.

Irfan AliAugust 31, 2015 at 4:52 PM

Very good reply KSP. Just a few updates

-- shortMAC-I is signed with the source cell K_rrc_integrity (see 36.331,


section 5.3.7.4)

There are two situations:

-- if eNB B is already a "prepared" cell, i.e eNB B had received HO Request


from eNB A which used the UE's old-CRNTI, then eNB B has UE context
and will continue with successful RRC Re-establishment.

-- Else, eNB B is not a prepared cell, i.e had not previously received HO
Request from eNB A. From Rel-12 onwards, eNB-B will send a RLF
indication message to eNB A. eNB A will verify the UE' CRNTI and then will
proceed with Handover Request message to eNB B. (See 36.300 Section
20.2.2.12, If the previous serving eNB matches the correct context, it may
also trigger the Handover Preparation procedure towards the eNB that
initiated the Radio Link Failure Indication procedure.).
This way eNB-B gets UE's context from eNB-A. But this is only supported
from Rel-12 onwards.

Once RRC Connection is Re-established the AS keys are changed to eNB-


B.
Reply

19.

Kamran KhanApril 15, 2014 at 12:49 PM

Hi,
I have a particular problem was wondering if you could help. I have RRC connection
recofiguration (HO information) then RRC Connection reconfiguration complete in target
cell. X2 based so I can see pathswitch being acknowledged for erab id 5 but then the HO
fails the UE reads MIB in the target cell and also does a RRC connection re-establishment
with cause "HO Failure". Is this to do with lower layer sync issue or something else ?
Reply

20.

AnonymousSeptember 9, 2014 at 6:22 AM

what is the total size of the message ?


Reply

21.

Kumar Swamy PasupuletiOctober 15, 2014 at 7:28 PM


6 bytes
Reply

22.

Sreekumar NkOctober 23, 2014 at 2:34 PM

How can I make Ue to trigger re-establishment request by integrity check failure. I mean
after UE attached to Pcell and scell is configured I want UE to send re-establishment with
reason as other failure. Can you please help?
Reply

23.

Kumar Swamy PasupuletiOctober 23, 2014 at 3:07 PM


Try radio link failure instead of integrity check failure which must be easy in any test
environment.
Reply

24.

Sreekumar NkOctober 24, 2014 at 6:27 AM

Sorry, I have to use integrity check because it is a specific requirement. How to trigger this?
Thanks in advance.
Reply
Replies
1.
Kumar Swamy PasupuletiOctober 24, 2014 at 10:52 PM
Which Test environment is being used? after succesful security procedure,
reconfigure integrity protection algorithm at the simulator side but don't
signal to the UE. I think this will do the job, but I am not 100% sure
Reply

25.

nokomjz01November 12, 2014 at 12:19 AM

Hello, Im noticing that all of the "LTE RRC Connection Reestablishment Requests" are
rejected inmediatly by the network. Is it possible that the network im working on currently
does not have active the Reestablishment feature? And if so What is it needed to activate
it and what is the procedure? Thanks a lot.
Reply
Replies

1.
Kumar Swamy PasupuletiNovember 12, 2014 at 9:43 AM
Hi,
Is Reestablishment request is sent on the serving cell or any other cell?
There may be a possibility that the UE is sending Reestablishment request
message on some other cell, and that particular cell is not prepared for
Reestablishment, meaning that it can't fetch UE's context from the source
cell....

2.

nokomjz01November 12, 2014 at 4:10 PM

Hi, In all of the cases the Reestablishment request is sent on the serving cell
and on directed to the serving cell. Also in all of the drive tests i have seen
there isn't a single successful "LTE RRC Connection Reestablishment".
Reply

26.

AnonymousDecember 10, 2014 at 10:23 AM

Could you please tell how rrc will get re-established if radio-link failure detect (due to RLC
Max retransmission) at eNodeB side?
Reply

27.

AnonymousJanuary 14, 2015 at 1:31 PM

hi
Reply

28.

AnonymousFebruary 17, 2015 at 1:46 PM

Hi!

I am trying to detect a radio link failure. In case the re establishment cause is 'otherFailure',
but it is not specified exactly if it is RLF or something else, how can I track this using other
messages? For example by receiving an RRCConnectionRequest, could it mean that the
UE went into Idle mode due to a radio link failure and now it is trying to reconnect to the
network?

Thanks in advance :)
Reply

29.

AnonymousJune 17, 2015 at 12:24 PM

Hi
I want to reduce RRC reestablishment attempt for HO to Improve HO Performance so
which NSN Parameter need to tune to Reduce RRC reestablishment attempt.
Reply

30.

AnonymousJune 18, 2015 at 3:55 AM

Hi
I want to reduce RRC reestablishment attempt for HO to Improve HO Performance so
which NSN Parameter need to tune to Reduce RRC reestablishment attempt.

Reply
Reply

31.

Mohal JoshiSeptember 17, 2015 at 11:34 PM


This comment has been removed by the author.
Reply

32.

Mohal JoshiSeptember 17, 2015 at 11:35 PM

When Radio Link Failure occurs T311 timer starts along with Reestablishment. However
receipt of which message or event on UE side will stop the T311 timer. Standard simply
says "“selection of suitable E-UTRA cell” but doesn't explicitly say that on receipt of which
message from eNB will UE stop running T311 Timer
Reply
Replies

1.
Kumar Swamy PasupuletiOctober 6, 2015 at 9:13 AM
Hi Mohal,

There is no need to receive any message from the eNodeB to for the
"Selection of suitable E-UTRA Cell".

The UE shall select a suitable cell based on idle mode measurements and
cell selection criteria.

A "suitable cell" is a cell on which the UE may camp on to obtain normal


service. The UE shall have a valid USIM and such a cell shall fulfil all the
following requirements.
- The cell is part of either:
- the selected PLMN, or:
- the registered PLMN, or:
- a PLMN of the Equivalent PLMN list
- The cell is not barred, see subclause 5.3.1 in 36.304;
- The cell is part of at least one TA that is not part of the list of "forbidden
tracking areas for roaming" [4], which belongs to a PLMN that fulfils the first
bullet above;
- The cell selection criteria are fulfilled, see subclause 5.2.3.2 in 36.304;

If more than one PLMN identity is broadcast in the cell, the cell is considered
to be part of all TAs with TAIs constructed from the PLMN identities and the
TAC broadcast in the cell.

For more information on Cell selection/reselection procedures, please look


into 36.304
Reply
33.

MAINPAL SINGHDecember 28, 2015 at 7:10 AM

Hi KSP,

Which message EnodeB will communicate to MME after Receiving the Reestablishment
Complete message from UE. what else messages will transverse between enodeb and
mme, before sending Reconfiguration message to UE from EnodeB after Reestablishment
complete message has been received at EnodeB.

Thanks
Reply

34.

AnonymousJanuary 3, 2016 at 7:14 PM

How UE sends Reestablishment request message to other cells?


Reply
Replies

1.
Kumar Swamy PasupuletiJanuary 4, 2016 at 9:11 AM
It is same way as RRC Connection Request (establishment)...
Reply

35.

UnknownJanuary 4, 2016 at 10:27 AM

Hi,
Can anyone explain various reasons of HO fails in both preparation phase and execution
phase in LTE?
Reply

36.

Hammad AyubJanuary 7, 2016 at 9:02 AM

This comment has been removed by the author.


Reply
37.

Raheel ShahzadJanuary 8, 2016 at 5:00 PM

Hi KMP,
If you please tell me the initial trouble shooting for SINR. SRB1 success ratio can be
degraded because of SINR?. or SINR is main cause of Re-establishment? thanks

You might also like