Lauro joined Award Solutions in 2008, bringing over ten years of experience in the wireless telecommunication industry working with mobile cellular, broadband and satellite communications. Has a thorough knowledge and understanding of all standardized radio transmission technologies (i.e.: GSM, GPRS, EDGE, WCDMA, HSxPA, HSPA+,IS-95, cdma 1xRTT, 1xEV-DO) and non-standardized technologies (i.e.: Flash OFDM, I-Burst, etc.) as well as and their migration path to 4G and beyond (LTE and WiMAX).
Lauro has co-authored four different telecommunication books, has published 18 international refereed journal papers and over 30 international conference papers, all of them results of research in the wireless telecommunication area. Additionally, has presented over 20 different wireless related courses nationally and internationally to a diverse class of clients. Lauro has a thorough knowledge of mathematical analysis and hands-on experience on wireless and traffic engineering design, including Design, Planning, Performance & Optimization as well as computer simulation of mobile wireless networks. Through research and computer simulation techniques has helped a large base of clients (carriers, vendors, new start up companies) develop optimum technological solutions.
Currently, Lauro is one of the instructors at Award Solutions. His current focus is UMTS, HSPA/HSPA+ and LTE. He is also involved in the development of cutting edge training on optimization courses for LTE operators in the USA.
Lauro holds a Ph.D. in electrical engineering (EE) from King's College London, UK (the University of London), a MSc. In EE. and a B.EE from the National Polytechnic Institute, Mexico, all of them with specialty in telecommunications.
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.