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 in-
synch.

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.
 Drop Sessions (Part 2 of 2)
Lauro
29 Mar 2012 5:19 PM
 1

In the previous blog, we described the activities that the UE carries out to evaluate the
condition of the radio link to determine if it was in-synch or out of synch. Depending on
the vendor’s implementation, an out of synch indication may result in a drop session.

In this blog, we will concentrate on the activities carried out by the eNodeB when it
detects that the radio link has failed.

The types of failure that the eNodeB may detect (again, these may be vendor specific)
are:

a) DL failure (RLC failures)

b) UL failure (Physical layer failure).

DL Failure at the RLC layer:

The RLC Layer has a failure when data or signaling that is sent over the air is
unsuccessful and the RLC Layer stops trying. When data is sent over the air, but is
received incorrectly, the receiver will send a NACK. Also, the transmitter can send a
request for an acknowledgement of all received packets, by setting the poll bit. The
receiver will then send a list of all received packets. If a sent packet is not received, it is
considered lost. In either case, the transmitter will retransmit. See figure below.
This procedure can repeat, but at some point the transmitter will give up on the packet.
If that happens, the transmitter declares that the radio link has failed and starts the
procedures to communicate that to the other side.

The parameter MaxRetxThreshold determines the number of times a packet is

retransmitted at the RLC layer in the downlink. If this number is reached, the eNodeB
declares a DL RLC failure and “kills” the context as shown in the picture below.
UL Failure at the Physical layer:

Not all vendor implementation support this type of failure detection. It essentially
consists in measuring the power of the sounding reference signals (SRS) sent by the
UE in the UL. If the power is below a given SINR threshold, a timer gets started. If the
SINR remains under the stated SINR threshold for the entire duration of the timer, then
the eNodeB declares the UL as out of synch and proceeds to “kill” the context. If the
SINR of the SRS goes above a second specified threshold during the timer duration, the
UL is said to be in-synch and no actions are carried out.

Below, the actions carried out by eNodeB are shown when an UL Physical Layer failure
is detected.
Yes, you are right!!! But think about the consequences again!

Yes, increasing the value of maxretxthreshold may result in a decrease in the number of
drop sessions due to RLC DL failures.

However, to avoid a large number of drops, the best thing to do is to clean the RF
environment in your network.
 TIMER TIMER ON
STATE CAUSE OF START NORMAL STOP
NUM. VALUE EXPIRY
T3402 Default EMM DEREGISTERED At attach failure and ATTACH REQUEST Initiation of the
12 min. EMM REGISTERED the attempt counter sent TRACKING AREA attach procedure
NOTE 1 is equal to 5. UPDATE REQUEST or TAU procedure
At tracking area sent
updating failure
and the attempt
counter is equal to 5.
T3410 15s EMMREGISTEREDINITIATED ATTACH REQUEST ATTACH ACCEPT Start T3411 or
sent received T3402 as
ATTACH REJECT described in
received subclause
5.5.1.2.6
T3411 10s EMM DEREGISTERED. At attach failure due ATTACH REQUEST Retransmission of
ATTEMPTING TO-ATTACH EMM to lower layer failure, sent the ATTACH
REGISTERED. T3410 timeout or TRACKING AREA REQUEST or
ATTEMPTING TO-UPDATE attach rejected with UPDATE REQUEST TRACKING AREA
other EMM cause sent UPDATE REQUEST
values than those
treated in subclause
5.5.1.2.5.
At tracking area
updating failure due
to lower layer failure,
T3430 timeout or TAU
rejected with other
EMM cause values
than those treated in
subclause 5.5.3.2.5.
T3412 Default EMM REGISTERED In EMM-REGISTERED, When entering state Initiation of the
54 min. when EMM DEREGISTERED periodic TAU
NOTE 2 EMM-CONNECTED or procedure
NOTE 5 mode is left. when entering EMM-
CONNECTED mode.
T3416 30s EMM REGISTERED INITIATED RAND and RES stored SECURITY MODE Delete the stored
EMM REGISTERED as a result of a UMTSCOMMAND received RAND and RES
EMM DEREGISTERED INITIATED authentication SERVICE REJECT
EMM-TRACKINGAREA UPDATING challenge received
INITIATED TRACKING AREA
EMM-SERVICE REQUEST UPDATE ACCEPT
INITIATED received
AUTHENTICATION
REJECT received
AUTHENTICATION
FAILURE sent
EMM DEREGISTERED
or
EMM-NULL entered
T3417 5s EMM- SERVICE REQUEST Bearers have been Abort the
SERVICEREQUESTINITIATED sent EXTENDED set up procedure
SERVICE SERVICE REJECT
REQUEST sent in case received
f and g in subclause
5.6.1.1
T3417ext 10s EMM- EXTENDED SERVICE Inter-system change Abort the
SERVICEREQUESTINITIATED REQUEST sent in case from S1 mode to procedure
d in A/Gb mode or Iu
subclause 5.6.1.1 mode is completed
EXTENDED SERVICE Inter-system change
REQUEST sent in case from S1 mode to
e in A/Gb mode or Iu
subclause 5.6.1.1 and mode is failed
the CSFB response SERVICE REJECT
was set to "CS received
fallback
accepted by the UE"
T3418 20s EMM REGISTEREDINITIATED AUTHENTICATION AUTHENTICATION On first expiry,
EMM REGISTERED FAILURE (EMM cause REQUEST received the UE should
EMM-TRACKINGARE = #20 "MAC failure" consider the
AUPDATINGINITIATED or #26 "non-EPS network as false
EMM DEREGISTEREDINITIATED authentication
EMM- unacceptable") sent
SERVICEREQUESTINITIATED
T3420 15s EMM REGISTERED INITIATED AUTHENTICATION AUTHENTICATION On first expiry,
EMM REGISTERED FAILURE (cause = REQUEST received the UE should
EMM DEREGISTERED INITIATED #21 "synch failure") consider the
EMM-TRACKINGAREA UPDATING sent network as false
INITIATED
EMM-SERVICE REQUEST
INITIATED
T3421 15s EMM DEREGISTERED INITIATED DETACH REQUEST DETACH ACCEPT Retransmission of
sent received DETACH REQUEST
T3423 NOTE 3 EMM REGISTERED T3412 expires while When entering state Set TIN to "P-
the UE is in EMM- EMM DEREGISTERED TMSI"
REGISTERED.NO- or
CELLAVAILABLE when entering EMM-
and ISR is activated. CONNECTED mode.
T3430 15s EMM-TRACKING AREA TRACKING AREA TRACKING AREA Start T3411 or
UPDATING INITIATED UPDATE UPDATE ACCEPT T3402 as
REQUEST sent received described in
TRACKING AREA subclause
UPDATE REJECT 5.5.3.2.6
received
T3440 10s EMM REGISTERED INITIATED ATTACH REJECT, Signalling connection Release the
EMM-TRACKING AREA DETACH REQUEST, released signalling
UPDATING INITIATED TRACKING AREA Bearers have been connection and
EMM DEREGISTERED INITIATED UPDATE REJECT with set up proceed as
EMM-SERVICE REQUEST any of the EMM cause described in
INITIATED #11, #12, #13, #14 subclause 5.3.1.2
EMM REGISTERED or #15 SERVICE
REJECT received with
any of the EMM cause
#11,#12, #13 or #15
TRACKING AREA
UPDATE ACCEPT
received after the UE
sent TRACKING AREA
UPDATE REQUEST in
EMMIDLE mode with
no "active" flag
T3442 NOTE 4 EMM REGISTERED SERVICE REJECT TRACKING AREA None
received with EMM UPDATE REQUEST
cause #39 "CS sent
domain temporarily
not available"

The default value of this timer is used if the network does not indicate another value in an EMM signalling
Note 1
procedure.
The value of this timer is provided by the network operator during the attach and tracking area updating
Note 2
procedures. (This Timer value is set in Attach Accept message as well).
The value of this timer may be provided by the network in the ATTACH ACCEPT message and TRACKING
Note 3
AREA UPDATE ACCEPT message. The default value of this timer is identical to the value of T3412.
The value of this timer is provided by the network operator when a service request for CS fallback is
Note 4
rejected by the network with EMM cause #39 "CS domain temporarily not available".
The default value of this timer is used if the network does not indicate a value in the TRACKING AREA
Note 5 UPDATE ACCEPT message and the UE does not have a stored value for this timer.
(This Timer value is set in Attach Accept message as well).
Timer (EPS Mobile Management - UE Side)

Following table comes from 24.301 - 10.2 Timers of EPS mobility management (Table
10.2.1: EPS mobility management timers – UE side)