Anda di halaman 1dari 9

This page covers LTE timers which include T300, T301, T303, T304, T305, T310, T311, T320

and
T321.
LTE
Timers
T300

T301

T303

T304

T305

T310

T311

T320

T321

Function at Start/Stop/Expiry
>>Starts at the RRC connection REQ transmit
>>Stops at the Receipt of RRC connection setup or reject message OR at the cell
reselection time OR upon abortion of connection establishment by Higher layers (L2/L3).
>>At the expiry performs the actions
>>Starts at the RRC Connection Re-establishment REQUEST
>>Stops at the Receipt of RRC Connection Re-establishment OR
RRC Connection Re-Establishment REJECT message OR
When selected cell becomes unsuitable to continue further
>>At expiry, it Go to RRC_IDLE mode
>>Starts when access is barred while performing RRC CONNECTION ESTABLISHMENT
for MO(Mobile Originating) calls
>>Stops while entering RRC_CONNECTED and upon cell re-selection mode
>>At expiry, Informs higher layers about barring alleviation
>>Starts at the Receipt of RRC CONNECTION RECONFIGURATION message along with
Mobility Control Info OR at the receipt of mobility from EUTRA command message including
CELL CHANGE ORDER
>>Stops at the successful completion of HANDOVER to EUTRA or CELL CHANGE
ORDER is met
>>At expiry, it performs action based on need.
1. In the case of CELL CHANGE ORDER from E-UTRA OR intra E-UTRA handover, initiate
the RRC connection re-establishment procedure.
2. In case of HANDOVER to E-UTRA, perform the actions defined as per the specifications
applicable for the source RAT.
>>starts when access is barred while performing RRC CONNECTION ESTABLISHMENT
for MO signaling
>>Stops when entering RRC_CONNECTED and when UE does cell re-selection
>> At expiry, Informs higher layers about barring alleviation
>>Starts when UE detects PHY layer related problems (when it receives N310 consecutive
out-of-sync INDs from lower layers)
>>Stops 1. When UE receives N311 consecutive in-sync INDs from lower layers/
2. Upon triggering the HANDOVER procedure
3. Upon initiating the CONNECTION RE-ESTABLISHMENT procedure
>> At expiry, if security is not activated it goes to RRC IDLE else it initiates the
CONNECTION RE-ESTABLISHMENT Procedure
>>Starts while initiating RRC CONNECTION RE-ESTABLISHMENT procedure
>>stops upon selection of suitable E-UTRA cell OR a cell using another RAT
>>At expiry it enters RRC IDLE state
>> Starts upon receipt of t320 or upon cell re- selection to E-UTRA from another RAT with
validity time configured for dedicated priorities (in which case the remaining validity time is
applied).
>>Stops upon entering RRC_CONNECTED state, when PLMN selection is performed on
request by NAS OR upon cell re-selection to another RAT
>> At expiry, it discards the cell re-selection priority info provided by dedicated signaling
>>starts upon receipt of measConfig including a reportConfig with the purpose set
to reportCGI
>> Stops at either of following cases:

1. Upon acquiring the information needed to set all fields of globalCellIdfor the requested
cell
2. upon receipt of measConfig that includes removal of thereportConfig with the purpose
set to reportCGI
>> At expiry initiates the measurement reporting procedure, stop performing the related
measurements and remove the correspondingmeasID

Timer

Start

Stop

At

T300

Transmission of RRCConnectionRequest

Reception of RRCConnectionSetup or
RRCConnectionReject message, cell
re-selection and upon abortion of
connection establishment by upper
layers

Perfor
action
specifi
5.3.3.

T301

Transmission of
RRCConnectionReestabilshmentRequest

Reception of
Go to
RRCConnectionReestablishment or
RRCConnectionReestablishmentReject
message as well as when the selected
cell becomes unsuitable

T302

Reception of RRCConnectionReject while performing


RRC connection establishment

Upon entering RRC_CONNECTED and Inform


upon cell re-selection
layers
barrin
allevia
specifi
5.3.3.

T303

Access barred while performing RRC connection


establishment for mobile originating calls

Upon entering RRC_CONNECTED and Inform


upon cell re-selection
layers
barrin
allevia
specifi
5.3.3.

T304

Reception of RRCConnectionReconfiguration message


including the MobilityControl Info or reception of
MobilityFromEUTRACommand message including
CellChangeOrder

Criterion for successful completion of In cas


handover to EUTRA or cell change
chang
order is met (the criterion is specified from E
in the target RAT in case of inter-RAT) intra E
hando
initiate
RRCco
reestabl

proced
case o
hando
UTRA,
the ac
define
specifi
applica
the so
T305

Access barred while performing RRCconnection


establishment for mobile originating signalling

Upon entering RRC_CONNECTED and Inform


upon cell re-selection
layers
barrin
allevia
specifi
5.3.3.

T310

Upon detecting physical layer problems i.e. upon


receiving N310 consecutive out-of-sync indications
from lower layers

Upon receiving N311 consecutive insync indications from lower layers,


upon triggering the handover
procedure and upon initiating the
connection re-establishment
procedure

If secu
activa
RRC_I

else: i
conne
establ
proced

T311

Upon initiating the RRCconnection


reestablishmentmprocedure

Selection of a suitable E-UTRA cell or Enter


a cell using another RAT.

T320

Upon receiving t320 or upon cell (re)selection to EUTRA from another RAT with validity time configured
for dedicated priorities (in which case the remaining
validity time is applied).

Upon entering RRC_CONNECTED,


when PLMN selection is performed on
request by NAS, or upon cell
(re)selection to another RAT (in which
case the timer is carried on to the
other RAT).

Discar
resele
priorit
inform
provid
dedica
signall

T321

Upon receiving measConfig including a reportConfig


with the purpose set to reportCGI

Upon acquiring the information


needed to set all fields of cellGlobalId
for the requested cell, upon receiving
measConfig that includes removal of
the reportConfig with the purpose set
to reportCGI

Initiat
measu
report
proced
perfor
related
measu
and re
corres
measI

Drop Sessions (Part 1 of 2)


Lauro
28 Mar 2012 6:01 PM

0
There are several reasons why a session may drop in LTE. However, whether the
session is dropped or not depends on the particular vendor implementation. That is, the
drop may be caused by a UE message or by measurements carried out by the eNodeB.
Both the UE and the eNodeB may check if the radio link is in-synch. In this blog, we will
describe the activities that the UE carries out to determine if the radio link is in-synch
and their consequences. Part 2 of this blog, will present the activities that the eNodeB
may carry out to determine if the radio link is in-synch or not.
So. When is the Radio Link in-synch?
The UE is expected to monitor the RS in the downlink. Based on the signal strength of
the Reference Signals (i.e., the RSRP), the UE will determine if it can decode the
PDCCH based on a certain set of parameters that are provided in the specs. Each UE
will have a different RSRP threshold in which it will assume it cannot read the PDCCH.
If the Reference signals have enough strength such that the UE can decode
consistently the PDCCH, then the link is In-Synch.
How do we determine if the Radio Link is out of Synch?
The full procedure for determining if the link has failed due to being out of sync is shown
in the figure below. In the picture, there are three parameters shown:
n310: This parameter indicates the number of 200 ms intervals when the UE is unable
to successfully decode the PDCCH due to low RSRP detected. That is, this parameter
indicates the number of times in which the UE cannot successfully decode 20
consecutive frames in the downlink.
t310: It is a timer, in seconds, used to allow the UE to get back in synchronization with
the eNodeB.
n311: This parameter indicates the number of 100 ms intervals that the UE must
successfully decode the PDCCH to be back in-synch with the eNodeB. That is, this
parameter indicates the number of times in which the UE must successfully decode 10
consecutive frames in the downlink in order for the UE to assume the radio link is insynch.

If the UE detects n310 consecutive out-of-sync indications, it starts the t310 timer. If the
timer expires, the link has failed. If the UE detects n311 consecutive in-sync indications
prior to the t310 timer expiring, then the timer is stopped and the link has not failed.

So what happens after the UE detects that the link failed?


If the UE determines that the Radio Link fails, the UE will try to reconnect with an RRC
Connection Reestablishment Request message. There are a number of cases that
could occur based on vendor implementation.
What if the eNodeB does not support RRC Connection Reestablishment?
The case shown in the figure below is the simplest case where the eNB does not
support RRC Connection reestablishment. In this case, the eNB responds with an RRC
Connection Reestablishment Reject message. Simultaneously, the eNB will realize that
the radio link has failed and request the connection to be release to the MME. It first
requests to drop the UE Context or the connection to the UE. The cause value is set to
Radio Connection with UE Lost. The MME will respond with a UE Context Release
Command. At this point, the eNodeB will respond with the UE Context Release
Complete message to the MME and will release the RRC connection with the UE by
sending an RRC Connection Release to the UE. Depending on the RF conditions, the
UE may or may not receive this message.

What if the eNodeB does support RRC Connection Reestablishment?


If the eNodeB supports RRC connection Reestablishment, and assuming that the
eNodeB finds both the UL and DL in synch when it receives the RRC connection
reestablishment request message, two scenarios may occur: RRC connection
reestablishment success and failure.
In the case of an RRC connection reestablishment success, the following signaling is
carried exchanged.

If the RRC connection gets successfully reestablished, then the session does not get
dropped.
If the RRC connection reestablishment procedure fails in one of its steps, then the
eNodeB will send the UE context release request message to the MME. Note that the
RRC connection reestablishment process may fail in several steps. Below, in the figure,
only one case is shown.

If the RRC connection reestablishment fails, then the session is dropped.


Yes, you are right!! But think in the consequences first!
If you increase the power of the RS, If you increase n310, if you increase t310 or if you
decrease n311 to its minimum value, the then the number of drop calls will decrease.

Anda mungkin juga menyukai