Lte Optimisation Cases Part14

LTE Optimisation Cases Part I Strictly for Internal Use Only •

Jussi Reunanen,

•

NPO Korea : Jeongho Cho, Jared Cho, Kyeongtaek Kim, Henry Lee, Jason Lee, David Sun; Ekawit Komolpun; Riku Luostari; Jussi Brannfors ; Shuji Satou; Charles Sun

•

2015-05-19 v.7.5 (26/10/2015 in Riyadh)

1 28/10/2015 © Nokia 2014 For internal use

Agenda – Part I & II • Introduction • RRC Setup Success Rate and CSSR • Handover Success Rate

PART I

• Dropped Call Rate • UL Throughput • DL Throughput • PUCCH Power Control • Paging

2 28/10/2015 © Nokia 2014 For internal use

PART II

Introduction – Performance Improvement • LTE Optimisation … - HO success rate - RRC setup success rate

3 28/10/2015 © Nokia 2014 For internal use

Strong Correlation

Dropped Call Rate

Introduction – Performance Improvement • NEVER underestimate the basic L1 optimization – even 4G (LTE) relies on the fact that L1 must be optimized properly • Massive improvement in the performance by basic L1 optimization in a cluster Cluster level drive test results

Diff.

Drive Test Result (Antenna Tilting)

Unit

DL Throughput

(Mbp s)

5 Mbps ↑

Handover Attempts

(#)

33 % ↓

Average SINR

(dB)

2.3 dB ↑

Experienced improvement

4 28/10/2015 © Nokia 2014 0.5 ↑ Average CQI For internal use

Introduction – Things Can go Wrong Very Fast • Launch of new terminal Samsung Galaxy S3 on 9th July caused massive increase in dropped call rate • This was due to the fact that cDRX handling was somewhat different in S3 compared to the earlier models so many bearer setups ended up being dropped when cDRX configuration was given to the UE (RRC Connection Reconfiguration message) • After cDRX switched off the performance returned to the previous level

5 28/10/2015 © Nokia 2014 For internal use

cDRX off in test cluster

cDRX off in in whole network

Agenda • Introduction • RRC Setup Success Rate and CSSR • Handover Success Rate • Dropped Call Rate • UL Throughput • DL Throughput • PUCCH Power Control • Paging

6 28/10/2015 © Nokia 2014 For internal use

Introduction

• Worst BTSs in terms of RRC Setup Failure Rate - Based on hourly statistics from 13th April until 23rd April

• Includes Golden Cluster and Analysts Visit area sites - 4 BTSs missing as those are under different iOMS than iOMS2

• 135290 seems to be the worst cell • RACH success rate (RACH setup success rate) fluctuates between 90% and 85% 7 28/10/2015 © Nokia 2014 For internal use

Introduction MSG1 : Random Access Preamble • UE selects one of the 64 − Ncf available PRACH contention-based signatures for the preamble • Ncf is the number of signatures reserved by the eNodeB for contention-free RACH • There are two possible groups defined and one is optional • Group A and group B • The eNodeB can control the number of signatures in each subgroup according to the observed loads in each group

Contention -based Radom Access Procedure

UE Random Access Preamble

• • •

•

8 28/10/2015 © Nokia 2014 For internal use

(on PRACH )

(with embedded 1-bit indication for L2/L3 message size)

1 Random Access Response (on PDCCH + PDSCH ) (Timing Adjustment, C-RNTI, UL grant for L2/3 message..)

MSG2 : Random Access Response generated by MAC on DLSCH: • Semi-synchronous (within a flexible window of which the size is

one or more TTI) with message 1 No HARQ Addressed to RA-RNTI on PDCCH Conveys at least RA-preamble identifier, Timing Alignment information, initial UL grant and assignment of Temporary C-RNTI (which may or may not be made permanent upon Contention Resolution) Intended for a variable number of UEs in one DL-SCH message

eNB

2 L2/L3 message (PUSCH transmission including contentin resolution identity)

3

Contention resolution Message 4

Introduction MSG3: First scheduled UL transmission on UL-SCH: • Uses HARQ • Size of the transport blocks depends on the UL grant conveyed in step 2 and is at least 80 bits • For initial access: – Conveys the RRC Connection Request generated by the RRC layer and transmitted via CCCH – Conveys at least NAS UE identifier but no NAS message – RLC TM: no segmentation

Contention -based Radom Access Procedure

UE

eNB Random Access Preamble

(on PRACH )

(with embedded 1-bit indication for L2/L3 message size)

1 Random Access Response (on PDCCH + PDSCH )

• For RRC Connection Re-establishment procedure

(Timing Adjustment, C-RNTI, UL grant for L2/3 message..)

2

– Conveys the RRC Connection Re-establishment Request generated by the RRC layer and transmitted via CCCH – RLC TM: no segmentation – Does not contain any NAS message

• After handover, in the target cell:

L2/L3 message (PUSCH transmission including contentin resolution identity)

3

– Conveys the ciphered and integrity protected RRC Handover Confirm generated by the RRC layer and transmitted via DCCH

– Conveys the C-RNTI of the UE (which was allocated via the Handover Command) – Includes an uplink Buffer Status Report when possible

• For other events:

– Conveys at least the C-RNTI of the UE

9 28/10/2015 © Nokia 2014 For internal use

Contention resolution Message 4

Introduction MSG4: Contention Resolution on DL: • Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention • Not synchronised with message 3 • HARQ is supported • Addressed to:

Contention -based Radom Access Procedure

UE

eNB Random Access Preamble

(on PRACH )

(with embedded 1-bit indication for L2/L3 message size)

1

– The Temporary C-RNTI on PDCCH for initial access and after radio link failure

Random Access Response (on PDCCH + PDSCH )

– The C-RNTI on PDCCH for UE in RRC_CONNECTED

(Timing Adjustment, C-RNTI, UL grant for L2/3 message..)

• HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3, echoed in the Contention Resolution message • For initial access and RRC Connection Re-establishment procedure, no segmentation is used (RLC-TM) • The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a C-RNTI; it is dropped by others • A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI 10 28/10/2015 © Nokia 2014 For internal use

2 L2/L3 message (PUSCH transmission including contentin resolution identity)

3

Contention resolution Message 4

RACH Success Rate M8001C6 RACH_STP_ATT_SMALL_MSG : RACH setup attempts for small size messages (contention based), updated due receipt of an RA preamble group A sent by the UE to the eNB M8001C7 RACH_STP_ATT_LARGE_MSG : RACH setup attempts for large size messages (contention based), updated due receipt of an RA preamble group B sent by the UE to the eNB M8001C286 RACH_STP_ATT_DEDICATED : The receipt of a dedicated RA preamble sent by the UE to the eNB (used in e.g. HO procedure) – RL40 M8001C8 RACH_STP_COMPLETIONS : The number of RACH setup completions (contention based and dedicated preambles). Counter is updated when RA preamble response is sent by the eNB to the UE.

UE

eNB

RANDOM ACCESS PREAMBLE RANDOM ACCESS RESPONSE

MSG3 e.g. RRC CONNECTION REQUEST

RACH Success Rate : 100*(Sum(M8008C4)+Sum(M8013C17) + Sum(M8013C18) + Sum(M8013C19) + Sum(M8013C20) + Sum(M8013C21))/(Sum(M8001C6) + Sum(M8001C7)

M8013C17 SIGN_CONN_ESTAB_ATT_MO_S : Signalling Connection Establishment attempts due to MO-Signalling, counter is updated following the receipt of an RRC Connection Request message sent by the UE to eNB (cause MO Signaling) M8013C18 SIGN_CONN_ESTAB_ATT_MT : Signalling Connection Establishment attempts due to MT-Access, updated due receipt of an RRC Connection Request message sent by the UE to eNB (cause MT Access) M8013C19 SIGN_CONN_ESTAB_ATT_MO_D : Signalling Connection Establishment attempts due to MO-Data, updated due receipt of an RRC Connection Request message sent by the UE to eNB (cause MO Data) M8013C20 SIGN_CONN_ESTAB_ATT_OTHERS : Signalling Connection Establishment attempts due to others, updated due receipt of an RRC Connection Request message sent by the UE to eNB (cause Others) M8013C21 SIGN_CONN_ESTAB_ATT_EMG : Number of Signalling Connection Establishment attempts for emergency calls, updated due Reception of the RRC: RRCConnectionRequest message (cause emergency) M8008C4 RRC_CON_RE_ESTAB_ATT : RRC Connection Re-establishment attempts 11 28/10/2015 © Nokia 2014 For internal use

MME

Note : the formula above is not accurate as nominator does not include cases where msg3 is just C-RNTI (can be quite high during high traffic event and/or with DRX enabled) – RL70 improves accuracy

RACH Success Rate RACH Success Rate UE

PUSCH/UL-SCH/CCCH: RRC Connection Request

eNB

MME

PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response

RRC Connection Request

Note that the RACH Success Rate formula does not include HO related preambles/performance

PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/DCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

•

The formula counts the ratio between receiving RRC Connection Request and receiving RACH preamble (from BTS point of view)

•

Best ways to improve RACH success rate are -

Decrease the #received RA preambles •

-

Improve the reception of RRC Connection Request reception at the BTS •

-

reduce the cell overlap and therefore reduce the surrounding BTSs from hearing the preambles addressed to another cells – the RACH preambles are formed using Zadoff – Chu sequences which have excellent cross correlation properties and therefore the neighboring cells do not cause interference BUT this only in case the root sequence planning is properly done (having long enough reuse of same root sequence) and in case the zero correlation zone (cyclic shift length) is properly planned See the UL improvements for RRC Setup Success Rate

Improve the RA response reception by the UE •

See the DL improvements for RRC Setup Success Rate

12 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate • Currently achievable values for RACH success rate are between 80 and 90% (1056 based formula) • The UE seems to respect the T300 settings as after scenario 2 the RACH Success Rate decreased • The UE is allowed to transmit > preamble trans max amount of preambles in case of cell reselection but not in any other case - Below example is not case of re-selection i.e. it is some sort of UE failure

13 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures • The reason for the BTS not receiving the RRC Connection Setup Complete can be - UE does not hear the contention resolution or RRC Connection Setup -message UE

PUSCH/UL-SCH/CCCH: RRC Connection Request

eNB

MME

PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response

53% of analysed RRC Setup failures are due DL problem

RRC Connection Request PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/DCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

- BTS does not hear the RRC Connection Setup Complete –message (or nothing else from UL) UE

PUSCH/UL-SCH/CCCH: RRC Connection Request

eNB

MME

PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response

47% of analysed RRC Setup failures are due UL problem

RRC Connection Request PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/DCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request

14 28/10/2015 © Nokia 2014 For internal use

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

RRC Setup Failures – DL Problem UE

eNB

MME

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response RRC Connection Request PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/DCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

• As the UE does not hear the RRC Connection Setup or the Contention Resolution (msg4) the UE cannot send anything in UL - Even periodical CQI report cannot be sent as that is configured by the RRC setup message - Therefore as UE does not receive RRC setup message there are no CQI reports and CqiRlf is set ON •

the problem of not receiving the periodical CQI reports could be caused by PUCCH i.e. not enough power for PUCCH (but as 50 consecutive reports are needed to be missed i.d. DTXed and only 2 received to cancel the CqiRLF it can be considered that UE has not received the RRC Connection Setup at all)

15 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – DL Problem – Periodic CQI RLF: RlsCause_CqiRlf_ON • The eNB supports CQI DTX detection for periodic CQI reports on PUCCH and PUSCH • If MAC layer receives nCqiDtx consecutive reports from UL PHY, the MAC declares CqiRLF_ON - can be seen in BTS log and Emil

• If the MAC has set CqiRLF_ON for a specific UE and nCqiRec consecutive CQI reports are again detected successfully for that UE, the MAC sets CqiRLF_OFF • The parameters nCqiDtx and nCqiRec are in the vendor-specific parameter file • For both PUSCH and PUCCH the periodic CQI is encoded using a Reed Muller block code and comes along without any CRC - Hence, the UL PHY indicates a DTX detection for periodic CQI reports on PUCCH or PUSCH whenever a report is configured but no reliable transmission from the UE could be detected - So the output of the detector shall be either the detected CQI report or a DTX indication

• NOTE: CQI_RLF detection does not apply to aperiodic CQI report on PUSCH 16 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – DL Problem – Periodic CQI RLF: RlsCause_CqiRlf_ON

RLF timer running

CQI_RLF ON LNCEL/cqiPerNp=20ms

vendor-file parameters in this example:

2

17 28/10/2015 © Nokia 2014 For internal use

time CQI_RLF OFF

T_RLF = T310 + T311 + (eNB internal timer) = 2s+3s+2200ms=7.2s

RRC Setup Failures – UL Problem UE

eNB

MME

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble

PDSCH/DL-SCH/CCCH: RA Response RRC Connection Request

PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/DCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

• As the BTS does not hear the RRC Connection Setup Complete - Periodical CQI reports are sent by the UE and received by BTS, visible in the Emil log as no CQIRlf_ON

18 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures 2nd request received 60ms after the first and 3 rd another 60ms from the 2nd

Same cell, same UE HEX

UL-CCCH-Message : { message c1 : rrcConnectionRequest : { criticalExtensions rrcConnectionRequest-r8 : { ue-Identity s-TMSI : { bin mmec '00000010'B, m-TMSI '11001011 00001000 01011100 00011101'B }, establishmentCause mt-Access, spare '0'B } } } 19 28/10/2015 © Nokia 2014 For internal use

• The same UE (identified by the m-TMSI) sends the RRC Connection Request 3 times through the same cell from which the last one only is successful 2 first attempts are failing due to no reply to RRC Connection Setup message (by RRC Connection Setup Complete) • As shown in the next slide

RRC Setup Failures 2nd request received 60ms after the first and 3 rd another 60ms from the 2nd

Same cell, same UE

- Frequent RRC Setup Failures due to no UE reply (graph below from UE L3 log point of view) UE

eNB

MME

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH:RA Preamble PDSCH/DL-SCH/CCCH: RA Response PDSCH/DL-SCH/CCCH: Contention Resolution

+

RRC Connection Setup PUSCH/UL-SCH/CCCH: RRC Connection Setup Complete NAS Attach Request, PDP Connection Request 20 28/10/2015 © Nokia 2014 For internal use

S1AP Initial UE Message NAS Attach Req, PDP Conn Req

RRC Setup Failures – RA Preamble

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response MGS3

21 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Preamble UE • The UE initiates the RRC Conenction Establishment PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble procedure when upper layers request establishment of PDSCH/DL-SCH/CCCH/SRB0:RA Response an RRC connection while the UE is in RRC_IDLE

eNB

• UE L3 sends RRC Connection Request to lower layers (L2/L1) which are responsible for preamble sending and RA response monitoring and starts timer T300, this in case -

T302 (RRC Connection Reject includes waitTime which is T302) is not running T303, T305 – additional cell barring timers (specific to RRC causes) In case any barring timer is running

• T300 : Timer T300 supervises the RRC connection establishment procedure Start: Transmission of RRCConnectionRequest Stop: Reception of RRCConnectionSetup or RRCConnectionReject message, cell re-selection and upon abortion of connection establishment by upper layers - 100ms (0), 200ms (1), 300ms (2), 400ms (3), 600ms (4), 1000ms (5), 1500ms (6), 2000ms (7) - In case T300 expiry the UE will stop RRC Connection Establishment procedure and starts and informs 28/10/2015 © Nokia 2014 higher layer about failed procedure -

22 For internal use

RRC Setup Failures – RA Preamble • In case of initial access, ra-PreambleIndex (Random Access Preamble) and ra-PRACH-MaskIndex (PRACH Mask Index) have not been explicitly signalled and contention based RA Procedure is used • Random Access Preamble is selected by the UE as follows:

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response

1. if Random Access Preambles group B exists and if the potential message size (data available for transmission plus MAC header and, where required, MAC control elements) is greater than messageSizeGroupA and if the pathloss is less than PCMAX – preambleInitialReceivedTargetPower – deltaPreambleMsg3 – messagePowerOffsetGroupB, then Random Access Preambles group B is selcted, else the Random Access Preambles group A is selected 2. select the same group of Random Access Preambles as was used for the preamble transmission attempt corresponding to previous transmission of Msg3 3. UE Randomly selects a Random Access Preamble within the selected group 4. determine the next available subframe containing PRACH permitted by the restrictions given by the prach-ConfigIndex, the PRACH Mask Index and physical layer timing requirements (a UE may take into account the possible occurrence of measurement gaps when determining the next available PRACH subframe) 23 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Preamble • From UE point of view the specific parameters related UE PUSCH/UL-SCH/CCCH: RRC Connection Request to random access parameters are delivered from PRACH: RA Preamble higher layers to the lower PDSCH/DL-SCH/CCCH/SRB0:RA Response - Preamble sequence definition - Preamble TX power for the first preamble

10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

XCAL: LTE ML1 random access request (MSG1)

- Random access request timing in terms of subframe number (defined by the RACH availability) •

Subframe 4, system frame number 409

- Delay from sending the preamble to the start waiting for RA response (window start) 3 TTI •

Subframe 7 (TTI), system frame number 409 (radio frame)

•

36.321 chapter 5.1.4 “Response window which starts at the subframe that contains the end of the preamble transmission plus three subframes and has length raResponseWindowSize subframes.”

24 28/10/2015 © Nokia 2014 For internal use

eNB

3 TTI (3ms) processing delay between BTS receiving the RA preamble and sending the RA response

Version : 4 Preamble_Sequence : 39 Physical_root_Index : 84 Cyclic_Shift : 138 PRACH_Tx_Power(dBm) : -12 Beta_PRACH : 242 N_ra_prb : 1 Preamble_Format : 0 Duplex_Mode : FDD Random_access_request_timing Starting_subframe_number : 4 Starting_system_frame_number : 409 Random_access_response_window_start Starting_subframe_number : 7 Starting_system_frame_number : 409 Random_access_response_window_end Starting_subframe_number : 7 Starting_system_frame_number : 410 RA_RNTI : 5

3TTI processing delay by 3GPP

RRC Setup Failures – RA Preamble UE • From UE point of view the specific parameters PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble related to random access parameters are delivered PDSCH/DL-SCH/CCCH/SRB0:RA Response from higher layers to the lower 10 TTI (10ms) -

Window start for the RA response

• -

Subframe 7 (TTI), system frame number 409 (radio frame)

Window end for the RA response •

Subframe 7 (TTI), system frame number 410 (radio frame)

waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI, defined by raRespWinSize + 3TTI (processing delay)

-

13 TTIs defined by raRespWinSize parameter (3+raRespWinSize parameter)

-

RA_RNTI = 5 (i.e. PRACH Configuration index = 4 -> PRACH subframe = 4 and frequency resource = 0, see next slide) RA-RNTI range : 0001-003C i.e. integer values 1 - 60

-

Value (hexa-decimal) 0000 0001-003C

RNTI N/A RA-RNTI, C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPC-PUCCH-RNTI and TPC-PUSCH-RNTI (see note)

003D-FFF3

C-RNTI, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI, TPCPUCCH-RNTI and TPC-PUSCH-RNTI Reserved for future use P-RNTI SI-RNTI

25 28/10/2015 © Nokia 2014 For internal useFFF4-FFFD FFFE FFFF

eNB

XCAL: LTE ML1 random access request (MSG1) Version : 4 Preamble_Sequence : 39 Physical_root_Index : 84 Cyclic_Shift : 138 PRACH_Tx_Power(dBm) : -12 Beta_PRACH : 242 N_ra_prb : 1 Preamble_Format : 0 Duplex_Mode : FDD Random_access_request_timing Starting_subframe_number : 4 Starting_system_frame_number : 409 Random_access_response_window_start Starting_subframe_number : 7 Starting_system_frame_number : 409 Random_access_response_window_end Starting_subframe_number : 7 Starting_system_frame_number : 410 RA_RNTI : 5

3TTI processing delay by 3GPP

RRC Setup Failures – RA Response

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response

26 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response

SBR ID

Usage

0

for RRC messages using the CCCH logical channel e.g. RRC Connection Setup message

1

for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2 (prior security activation), all using DCCH logical channel;

2

for NAS messages, using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured ONLY after security activation.

27 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response • Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the UE monitors the PDCCH for Random Access Response(s) identified by the RA-RNTI = 1 + t_id+10*f_id

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

PDSCH/DL-SCH/CCCH/SRB0:RA Response

3TTI processing delay by 3GPP

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

- Where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6) - The UE may stop monitoring for Random Access Response(s) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted Random Access Preamble

28 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response

• preambleTransMax, preamble transmission maximum defines the maximum number of Random Access transmissions -

preambTxMax (3 (0), 4 (1), 5 (2), 6 (3), 7 (4), 8 (5), 10 (6), 20 (7), 50 (8), 100 (9), 200 (10)), default 8 (5)

• With the default values and assuming 1TTI PRACH configuration i.e. prachConfIndex from 3 to 8 and taking into account 36.213 following statement (chapter 6.1.1) -

“If no random access response is received in subframe n, where subframe n is the last subframe of the random access response window, the UE shall, if requested by higher layers, be ready to transmit a new preamble sequence no later than in subframe n+4”

-

Assuming prachConfIndex set to have single PRACH resource per radio frame

29 28/10/2015 © Nokia 2014 For internal use

ResponseWindowSize + 4TTI

New preamb

preambTxMax*20ms=8*20ms = 160ms

3 TTIs

-

Last preamb

• The new preamble can be transmitted earliest (from the last sent preamble) 3TTI + ResponseWindowSize (7TTI) + 4TTI = 14TTI and with the default prachConfIndex this means after 20ms from the first preamble > the whole preamble retransmission time is max

RRC Setup Failures – RA Response • MAC PDU for RAR consists of a MAC header and zero or more MAC RARs and optionally padding

• The MAC PDU header consists of one or more MAC PDU subheaders - each subheader corresponding to a MAC RAR - except for the Backoff Indicator subheader - If included, the Backoff Indicator subheader is only included once and is the first subheader included within the MAC PDU header

Backoff Indicator subheader which consists of the five header fields

MAC PDU consisting of a MAC header and MAC RARs E/T/R/R/BI subheader

E/T/RAPID subheader 1

E/T/RAPID subheader 2

...

E/T/RAPID subheader n

E

MAC header

MAC RAR 1

MAC RAR 2

...

MAC payload

30 28/10/2015 © Nokia 2014 For internal use

MAC RAR n

T

R

R

BI

Oct 1

Padding (opt)

A MAC PDU subheader consists of the three header fields E/T/RAPID E

T

RAPID

Oct 1

RRC Setup Failures – RA Response • The MAC header is of variable size and consists of the following fields: - E: The Extension field is a flag indicating if more fields are present in the MAC header or not •

The E field is set to "1" to indicate at least another set of E/T/RAPID fields follows

•

The E field is set to "0" to indicate that a MAC RAR or padding starts at the next byte

- T: The Type field is a flag indicating whether the MAC subheader contains a Random Access ID or a Backoff Indicator •

The T field is set to “0” to indicate the presence of a Backoff Indicator field in the subheader (BI)

•

The T field is set to “1” to indicate the presence of a Random Access Preamble ID field in the subheader (RAPID);

- R: Reserved bit, set to "0"; - BI: The Backoff Indicator field identifies the overload condition in the cell •

The size of the BI field is 4 bits;

- RAPID: The Random Access Preamble IDentitfier field identifies the transmitted Random Access Preamble •

The size of the RAPID field is 6 bits

• The MAC header and subheaders are octet aligned 31 28/10/2015 © Nokia 2014 For internal use

E

T

RAPID

Oct 1

RRC Setup Failures – RA Response

• Example : preamble sequence sent is 8 but the BTS seems to respond to sequence 10 - This is simply explained by the way the RA-RNTI is assigned

Hex (4A) -> Bin (01001010)

- RA-RNTI = 1 + t_id+10*f_id - Where t_id is the index of the first subframe of the specified PRACH (0≤ t_id <10), and f_id is the index of the specified PRACH within that subframe, in ascending order of frequency domain (0≤ f_id< 6) and this f_id is always set to 0 in FD LTE case (TD LTE has several frequency domain opportunities for PRACH) => only t_id makes the difference for RA_RNTI in FD case - So several UEs can select to use the same RA-RNTI and single msg2 can send several RA responses (to different RAPID - According to 36.213 “If a random access response is received in subframe n, and the corresponding DL-SCH transport 32 block 28/10/2015 Nokia contain 2014 does© not a response to the transmitted preamble sequence, the UE shall, if requested by higher layers, be For internal use ready to transmit a new preamble sequence no later than in subframe n+5.”

RRC Setup Failures – RA Response

• In successful case the RA response includes the RAPID corresponding to the one selected by the UE as seen in graphs below

Hex (48) -> Bin (01001000)

33 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response • In MAC RAR message the eNB allocates the UE a temporary C-RNTI, initial Timing Advance and possibly UL resources are granted also

• A MAC RAR consists of the four fields: - Reserved = “0” 1Bit - Timing Advance Command TA (0, 1, 2… 1282) 11bits - UL Grant 20bits - Temporary C-RNTI 16 bits R

Timing Advance Command

Timing Advance Command

UL Grant

Oct 1 Oct 2

UL Grant

Oct 3

UL Grant

Oct 4

Temporary C-RNTI

Oct 5

Temporary C-RNTI

Oct 6

34 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response • • •

The higher layers indicate the 20-bit UL Grant to the physical layer This is referred to the Random Access Response Grant in the physical layer The content of these 20 bits starting with the MSB and ending with the LSB are as follows: -

-

Hopping flag – 1 bit. Fixed size resource block assignment – 10 bits (RIV) Truncated modulation and coding scheme – 4 bits TPC command for scheduled PUSCH – 3 bits. In case of Msg3, the value comes from deltaMsg2 ulpcRarespTpc (-6...8 dB, step 2 dB), default 0dB (according to the table below TPC command vs. actual power decrease/increase applied by the UE from 36.213) UL delay – 1 bit CQI request – 1 bit R TPC Command 0 1 2 3 4 5 6 7

35 28/10/2015 © Nokia 2014 For internal use

Value (in dB) -6 -4 -2 0 2 4 6 8

Timing Advance Command

Timing Advance Command

UL Grant

Oct 1 Oct 2

UL Grant

Oct 3

UL Grant

Oct 4

Temporary C-RNTI

Oct 5

Temporary C-RNTI

Oct 6

RRC Setup Failures – RA Response

• The RA response : 4A 02 E0 BE BC 56 83 can be decoded as follows - 4A : 0100 1010 E: The Extension field is a flag indicating if more fields are present in the MAC header or not -The E field is set to "1" to indicate at least another set of E/T/RAPID fields follows -The E field is set to "0" to indicate that a MAC RAR or padding starts at the next byte

02E : 0000 0010 1110

0BEBC : 0000 1011 1110 1011 1100

UL Grant : 0000 1011 1110 1011 1100 RAPID = 10 (dec) R = reserved = 0

Timing Advance command = 46 (dec)

This indicates that only a single RA response follows right after the corresponding header T: The Type field is a flag indicating whether the MAC subheader contains a Random Access ID or a Backoff Indicator The T field is set to “0” to indicate the presence of a Backoff Indicator field in the subheader (BI) The T field is set to “1” to indicate the presence of a Random Access Preamble ID field in the subheader (RAPID); Next is the 6bits RAPID field

0: Hopping flag : 0 (no hopping) 000 1011 111 : 10 bit Fixed size resource block assignment = 95 (d) RIV based on 36.213 -> L_CRBs = contiguously allocated #PRBs = 2 (10mhz case) -> RB_start = starting number of the PRB allocation = 45 (10mhz case) 0101 : 4 bits Modulation and coding scheme = 5 (d) 111 : 3bit TPC command for scheduled PUSCH = 8 (d) = 8dB 0 : 1bit UL delay ‘ – always set to 0 (no additional delay for MSG3) 0 : 1bit CQI request - always set 0 (according to R1-084665 no aperiodic CQI report is requested with the Random Access Response message for the contention based Random Access Procedure)

- 56 83 : 0101 0110 1000 0011 = Temporary C-RNTI 36 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – RA Response

• The RA Response is sent using PDSCH (informed by PDCCH DCI)

• PDCCH aggregation level is default set by parameter pdcchAggRaresp (def 4)

UE

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

eNB

PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

3TTI processing delay by 3GPP

- The PDSCH message for RA Response is sent using QPSK modulation and default coding rate set by parameter maxCrRaDl = 0.12 - The 48bit (single RA response) RA response (+header = 1B = 56bit) has to use very low coding rate due to the very small amount of bits (turbo coding efficiency is greatly degraded) - There is no PDSCH HARQ for the RA response and therefore each retransmission (that would be needed for RA response) cause retransmission of PRACH preamble and therefore cause reduction in RACH success rate UE eNB UE does not hear RA response (PDSCH message or corresponding PDCCH order) => UE keeps on restransmitting the RA preambles until it receives RA response

RRC Connection Request

RA Preamble RA Response RA Preamble RA Response RA Preamble

37 28/10/2015 © Nokia 2014 For internal use

RA Response

RRC Setup Failures – RA Response • In case the UE does not receive RA response within the specified window then the UE will reattempt and send the new RA preamble with higher power (increment PREAMBLE_TRANSMISSION_COUNTER by 1, #preamble in formula below) = reattempt of preamble occurs in 20ms intervals

UE

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

eNB

PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response

3TTI processing delay by 3GPP

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

=> PL = 10dBm – 95dBm = 105dB Initial Power = © Nokia 2014 38 28/10/2015 min{23dBm, -104dBm + 0dB +105 dB } = 1dBm For internal use

ResponseWindowSize + 4TTI

New preamb

3 TTIs

For example: preambleInitialReceivedTargetPower = -104dBm DELTA_PREAMBLE = 0dB (Format 1) powerRampingStep = 2dB preambleTransMax = 8 Cell RS Transmitting Power = 10dBm RSRP = -95dBm PCMAX = 23dBm

Last preamb

PreambleTxP = min{PCMAX, preambleInitialReceivedTargetPower + DELTA_PREAMBLE + (#preamble - 1) x powerRampingStep + PL}

RACH Success Rate Improvement • It should be noted that each time the UE does not get RA response (due to the e.g. PDCCH blocking on common search space or UE does not hear the RA response on PSDCH) the UE will assume that the BTS did not hear the preamble and increases the preamble power • This preamble power as such is no issue but the problem is that when the UE gets the RA response it might have done several preamble retransmissions and increased the Tx power by e.g. 20dB (max number of transmitted preambles * step size) which generates massive inter cell interference on PUSCH for msg3 • Therefore IT IS UTMOST IMPORTANT THAT EACH PREAMBLE LEADS TO SUCCESSFUL RRC REQUEST I.E. RACH SUCCESS RATE SHOULD BE RELATIVELY HIGH (~80-85%) by - Decrease the cell overlap by using extensive down tilting - Improve the RA response detection (PDCCH aggregation level, PDSCH coding rate for RA response) • Otherwise the PUSCH interference just becomes massive 39 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement • Also in some interference limited scenarios it might be beneficial to limit the number of preambles allowed to be transmitted by the UE (decrease of preambleTransMax) but then the problem very often is that even the statistics improve (RACH success rate and RRC setup success rate) the end user experience might be sacrificed - This phenomena is known from 3G as well and is caused by the fact that some UEs further away from BTS might not have enough power to compensate the UL path loss - This causes nice reduction in received preambles and ghost calls and RACH success rate can be massively improved but also can cause problems with call setups from end user point of view - Therefore in case the max RACH power is limited (in terms of #preambles and/or max power) then extensive field testing (drive testing is not enough but rather walk test is needed in order to cover all possible locations where end users might be) is required to make sure that end user experienced is not sacrificed and any improvement in RACH success rate is not just based on statistics but actually also experienced by the end users as improvement Cell coverage for PRACH with high enough power for the UE to RACH setup pump up the preamble power and compensate the UL noise UL&DL success rate rise and path loss i.e. UL and DL coverage are in balance improvement is

DL Cell coverage for PRACH when limiting the preamble steps or power causing some terminals not be able to compensate the UL 40 28/10/2015 © noise Nokia 2014 rise and path loss leading to unsuccessful call setups For internal use which are NOT seen in the statistics

further discussed after MSG5 is discussed

RACH Success Rate Improvement

• RACH Success Rate can be further improved by improving the RA response reception at the UE - Decrease the PDSCH coding rate for RA reponse maxCrRaDl = 0.12 -> 0.05 - Due to above the PDCCH aggregation level needs to be increased pdcchAggRaresp = 4 -> 8 - This causes capacity impact to PDCCH (Common Search Space i.e. no direct impact to UE specific search space but indirectly due PDCCH inter cell interference) and PDSCH which is analyzed below

DCI Format

0

1

1A

1C

2A

41 For

•

-> impact is e.g. for 4 RA responses per 10ms (400/s) in terms of used PRBs 1.6% -> 3.2% and for 20 RA responses per 10ms (2000/s) 8% -> 16%

•

for moderate load the impact is minimal especially when taking into account that if RACH success rate can be improved from 50%-60% to 80-90% by this change then the retransmitted RA responses that cause additional reservation (potentially to several cells due to overlapping) are close to halved Coding Rate Coding Rate Coding Rate Coding Rate : Rate : Rate : Rate Number of : Rate matched to 2 matched to 4 matched to 8 channel matched to 1 CCE (144 CCE (288 CCE (576 coded bits CCE (72 bits) bits) bits) bits) 132 0.6111111 0.3055556 0.1527778 0.0763889

Bw [MHz] 20

Num Bits 44

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

20

55

165

0.7638889

0.3819444

0.1909722

0.0954861

15

49

147

0.6805556

0.3402778

0.1701389

0.0850694

10

47

141

0.6527778

0.3263889

0.1631944

0.0815972

5

43

129

0.5972222

0.2986111

0.1493056

0.0746528

20

44

132

0.6111111

0.3055556

0.1527778

0.0763889

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

0.4305556 0.4166667 0.4027778 0.3888889 2014 0.8888889 0.8055556 0.7916667 0.7222222

0.2152778 0.2083333 0.2013889 0.1944444 0.4444444 0.4027778 0.3958333 0.3611111

0.1076389 0.1041667 0.1006944 0.0972222 0.2222222 0.2013889 0.1979167 0.1805556

0.0538194 0.0520833 0.0503472 0.0486111 0.1111111 0.1006944 0.0989583 0.0902778

20 31 15 30 10 29 5 28 28/10/2015 20 64 15 internal use58 10 57 5 52

©

93 90 87 84 Nokia 192 174 171 156

RACH Success Rate Improvement • The PrachCs defines the cell range for the cell i.e. the cell range limit below which the call attempts are properly handled • In case the call (preamble) attempt arrives further than PrachCs defined cell range then this problem is visible in LTE_1056b Complete RACH Setup Success Rate KPI as msg3s are not properly received - 100 * SUM(M8008C4 + M8013C17 + M8013C18 + M8013C19 + M8013C20 + M8013C21)/SUM(M8001C6 + M8001C7)

• See example below Until 1st October 1pm the PrachCs was set to 3km and after to 5km - After the change LTE_1056b improved significantly - i.e. after the change the msg3s from the terminal were properly processed improving the LTE_1056b significantly -

42 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement • The KPI LTE_5569a i.e. 100* sum(M8001C8) /sum(M8001C6 + M8001C7 +M8001C286) seems to also react on the prachCs change positively - This is caused by the fact that in case of contention based preambles the msg2 is sent regardless of the TA accuracy but in case of contention free preambles the msg2 is not sent in case the preamble (that is known eNB as it is allocated) is received with wrong TA (wrong TA here means within wrong cyclic shift)

• Two scenarios when msg2 is not sent 1.

eNB does not send RAR at all in case eNB receives a dedicated preamble that was not assigned to any UE • in this case the eNB knows that it was a falsely detected preamble (nothing transmitted by UE and eNB falsely detected a preamble out of the noise) and it does not send a RAR 2. eNB is overload and not able to schedule the RAR • this should be rare case and with the current load this should never happen • The counter M8001C8 is also working wrongly before RL60 (1.0 or 3.2PD) in case of several RAR messages are multiplexed into the same msg2 in case of high traffic (see next slide) 43 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement – M8001C8 Correction in RL60

• Counter M8001C8 RACH setup completions is updated every 160ms however the PM counters counting small, large and dedicated preambles are updated immediately when the event occurs - This can produce a mismatch of the number of preambles and setup completions, resulting in success rates larger than 100%

• Additionally, M8001C8 only updated with "1" even if multiple UEs received a RA response msg in that TTI causing success rate < 100%

• Correction : M8001C8 is updated immediately when the RA response is sent and with the correct number of RA responses sent to the UEs - A general problem is, in case preamble is close to the end of the measurement period, but success is only in next period, this may lead to success rates larger than 100% in a single measurement period but the average over all periods is correct 44 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement Impact of Long DRX • LTE1056b = 100 * SUM(RRC_CON_RE_ESTAB_ATT + SIGN_CONN_ESTAB_ATT_MO_S + SIGN_CONN_ESTAB_ATT_MT + SIGN_CONN_ESTAB_ATT_MO_D + SIGN_CONN_ESTAB_ATT_OTHERS + SIGN_CONN_ESTAB_ATT_EMG) / SUM(RACH_STP_ATT_SMALL_MSG+ RACH_STP_ATT_LARGE_MSG) • i.e. #specified msg3 / #contention based preambles • After RL50 Increase in RACH_STP_ATT_LARGE_MSG no change in RACH_STP_ATT_SMALL_MSG and no change or small degradation on LTE_1056b • The increase in RACH_STP_ATT_LARGE_MSG is caused by increase of PDCCH orders

45 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement Impact of Long DRX • There are some long DRX related scenarios where denominator of LTE_1056b is incremented but nominator is not - UE considers being UL in-sync (i.e. , running in UE, has not expired yet) and tries to send UL capacity request via SRI on PUCCH however UE might in UL out of sync from eNB point of view as after STIT (short term inactivity timer) expiry the eNB will no longer send TA commands to the UE • As eNB point of view UE is out of sync it cannot receive the SRI on PUCCH and UE will not receive any capacity allocation after dsrTransMax amount of SRIs on PUCCH (def 64) UE will perform random access scheduling request • This random access scheduling request is done using contention based random access procedure utilizing either preamble group A (small size msg3 preamble) or group B (large size msg3 preamble) • This random access scheduling request is counted by LTE_1056b denominator but as the msg3 is simply the MAC C-RNTI Control Element those are not counted by LTE_1056b nominator • Therefore when PDCCH order amount increases i.e. #UEs in extended DRX and eNB not sending TA commands, the amount of contention based preambles increases and LTE_1056b might decrease 46 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement Impact of Long DRX • There are some long DRX related scenarios where denominator of LTE_1056b is incremented but nominator is not - UE considers being UL out-of-sync (i.e. taTimer running in UE has expired) • In this case if UE has something to transmit (UL data arrival) it will initiate regular buffer status report, regular BSR triggering SR which in turn will trigger contention based random access procedure due to no SR resources being configured UE in UL out-of-sync - UE sends either preamble group A (small size msg3 preamble) or group B (large size msg3 preamble) which is counted by LTE_1056b denominator

• As the UE still is RRC_CONNECTED (i.e., no initial access to the cell) it will relay a C-RNTI MAC CE in msg3 of the contention-based random access procedure in order to allow for the eNB to indentify the UE - This msg3 is not counted by the nominator of the LTE_1056b

47 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement – RL60 & RL70 Improvements Impact of Long DRX • Statistics improvements for counting msg3 are introduced in RL60 and in RL70 as below - UL out-of-synch UEs which are re-synchronizing with the eNB due to the UL data arrival •

RL70 counter M8029C31

•

RL60 counter M8005C144

- It should be noted that this improvement only considers cases where there is UL data arrival indicated by the UE as msg3

48 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement – RL60 & RL70 Improvements Impact of Long DRX • Statistics improvements for counting msg3 are introduced in RL60 and in RL70 as below - All other cases where UE sends msg3 which is NOT RRC connection request increment counter M8029C32 in RL70 and due to this there is new KPI to replace LTE_1056d in RL70 i.e. LTE_5670a •

LTE_5670a = 100* sum(RACH_MSG3_CONTENTION) / sum(RACH_STP_ATT_SMALL_MSG+RACH_STP_ATT_LARGE_MSG)

•

Therefore M8029C32 includes ALL the msg3s : RRC connection setup, RRC connection re-establishment after RLF, UL data arrival in case of out-of-sync, Scheduling request using random access

- Without DRX enabled it seems that there are not so many out of synch UEs sending UL data arrival indications but rather SRIs sent on RACH

49 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate (Based on 3GPP Contribution by AT&T) • Problem scenario - UE sends RACH Preamble, but never receives RA response from eNodeB • RA lost in UL or RA can’t be successfully decoded by eNodeB • eNodeB silently drop the decoded RA due to congestion or other reasons • eNodeB sends RAR out but RAR lost in DL or RAR can’t be successfully decoded by device - UE Behavior: UE will keep sending RACH attempts and ramp up TX power if no expected response is received until T300 expires and UE will NOT stop sending the RACH retries even when PreambleTransMax (10) is reached • As the result, UE could e.g. send 98 RACH attempts every second non-stop • UE uses maximum TX power in more than 50% of these attempts - UL interference on PRACH - Consume resource in eNB, such as PDCCH, etc. - Unnecessary device power consumption 50 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate (Based on 3GPP Contribution by AT&T)

• TS 36.321 5.1.4 Random Access Response reception - “If no Random Access Response is received within the RA Response window, or if none of all received Random Access Responses contains a Random Access Preamble identifier corresponding to the transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE shall: • increment PREAMBLE_TRANSMISSION_COUNTER by 1;

• If PREAMBLE_TRANSMISSION_COUNTER = preambleTransMax + 1: - indicate a Random Access problem to upper layers.”

- It does not require MAC to stop the RACH procedure!!! 51 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate T300 modification • As previously indicated the RACH success rate decreased when T300 was increased • But also the T300 impacts on the RRC Setup success rate (as it supervises the total RRC setup procedure from UE side) • There is a trade off between RRC Setup success rate and RACH success rate depending on the T300 value as shown in table below (cluster test)

- Delays are based on DT

T300

52 28/10/2015 © Nokia 2014 For internal use

RRC Setup Success %

RACH Success %

Setup Delay [ms]

RRC Delay [ms]

RACH Delay [ms]

200ms

97.9%

78.4%

9.72

4.20

400ms

99.5%

75.6%

8.68

2.21

5.52 6.47

1000ms

99.8%

65.2%

12.91

2.23

10.68

RRC Setup Failures – MSG3

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0: RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

53 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble

10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

PDSCH/DL-SCH/CCCH/SRB0:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• The msg2 (RA response) includes the msg3 resource assignment and therefore there is no PDCCH resource assignment needed for msg3 • The RA response : 4A 02 E0 BE BC 56 83 can be decoded as follows

- 4A : 0100 1010

02E : 0000 0010 1110

0BEBC : 0000 1011 1110 1011 1100

UL Grant : 0000 1011 1110 1011 1100

0: Hopping flag : 0 (no hopping) 000 1011 111 : 10 bit Fixed size resource block assignment = 95 (d) RIV based on 36.213 -> L_CRBs = contiguously allocated #PRBs = 2 (10mhz case) -> RB_start = starting number of the PRB allocation = 45 (10mhz case) 0101 : 4 bits Modulation and coding scheme = 5 (d) 111 : 3bit TPC command for scheduled PUSCH = 8 (d) = 8dB 54 28/10/2015 © Nokia 2014 For internal use

0 : 1bit UL delay ‘ – always set to 0 (no additional delay for MSG3) 0 : 1bit CQI request - always set 0 (according to R1084665 no aperiodic CQI report is requested with the Random Access Response message for the contention based Random Access Procedure)

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request

10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

3TTI processing delay by 3GPP

PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• Allocation for msg3 (previous slide) is shown in the graph on the right • The UE sends the MSG3 with MCS given by parameters below: -

In case the UE has indicated large msg3 size when sending the preamble (group B) •

-

raLargeMcsUl = 5 – hidden parameter

•

Amount of bits to the transmitted is based on hidden parameter raLargeVolUl = 512 bits

•

Large size msg3 is also used in case of handover

•

This means that for msg3 amount of resources reserved is 8PRBs

In case the UE has indicated small msg3 size when sending the preamble (group A) •

•

raSmallMcsUl = 5 – hidden parameter

Amount of bits to be transmitted is based on parameter raSmallVolUl = 144bits, this means that for msg3 amount of resources reserved is 2PRBs 28/10/2015 © Nokia 2014

55 For•internal use If raSmallVolUl =

56bits then #PRBs can be reduced down to 1 and therefore MSG3 coverage can be improved by 3dB!!

I TBS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

N PRB 1 16 24 32 40 56 72 328 104 120 136 144 176 208 224 256 280 328 336 376 408 440 488 520 552 584 616 712

2 32 56 72 104 120 144 176 224 256 296 328 376 440 488 552 600 632 696 776 840 904 1000 1064 1128 1192 1256 1480

3 56 88 144 176 208 224 256 328 392 456 504 584 680 744 840 904 968 1064 1160 1288 1384 1480 1608 1736 1800 1864 2216

4 88 144 176 208 256 328 392 472 536 616 680 776 904 1000 1128 1224 1288 1416 1544 1736 1864 1992 2152 2280 2408 2536 2984

5 120 176 208 256 328 424 504 584 680 776 872 1000 1128 1256 1416 1544 1608 1800 1992 2152 2344 2472 2664 2856 2984 3112 3752

6 152 208 256 328 408 504 600 712 808 936 1032 1192 1352 1544 1736 1800 1928 2152 2344 2600 2792 2984 3240 3496 3624 3752 4392

7 176 224 296 392 488 600 712 840 968 1096 1224 1384 1608 1800 1992 2152 2280 2536 2792 2984 3240 3496 3752 4008 4264 4392 5160

8 208 256 328 440 552 680 808 968 1096 1256 1384 1608 1800 2024 2280 2472 2600 2856 3112 3496 3752 4008 4264 4584 4968 5160 5992

9 224 328 376 504 632 776 936 1096 1256 1416 1544 1800 2024 2280 2600 2728 2984 3240 3624 3880 4136 4584 4776 5160 5544 5736 6712

10 256 344 424 568 696 872 1032 1224 1384 1544 1736 2024 2280 2536 2856 3112 3240 3624 4008 4264 4584 4968 5352 5736 5992 6200 7480

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request

10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

-

If raSmallVolUl = 56bits then #PRBs can be reduced down to 1 and therefore MSG3 coverage can be improved by 3dB •

raSmallVolUl = 56bits but with MCS 5 (raSmallMcsUl = 5) the min TBS size is 72bits therefore TBS + CRC = 72b+24bits

•

Improvement in LTE_1056b is significant

•

Changing the raSmallVolUl from 144 to 72 (56) increases the effective coding rate a bit but the decrease in #PRBs from 2 to 1 increases the coverage, for power limited users, by 3dB, hence the improvement in LTE_1056b

•

Most optimal setting would be raSmallMcsUl = 4 and raSmallVolUl = 56 as shown in the table below but unfortunately raSmallMcsUl parameter is not modifiable and fixed to value 5 so therefore the selected TBS is 72bits (+24bit CRC = 96bits)

raSmallMcsUl raSmallVolUl (bits) 5 144 56 28/10/2015 © Nokia 2014 5 56 For internal use 4 56

MCS & PRB MCS5PRB2 MCS5PRB1 MCS4PRB1

TBS with CRC 168 96 80

Effective Coding Rate 0.291667 0.333333 0.277778

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

RRC Setup Failures – MSG3 -

With raSmallVolUl = 56bits less preambles with higher amount of msg3s

-

But clear decrease in RRC setup success rate due missing msg5 i.e. SIGN_CONN_EST_F_RRCCOMPL_MISSING failure counter is increased

-

This is simply due to the fact that msg3 detection is improved but msg5 not – see chapter msg5 for msg5 detection improvements

raSmallV olUl:56b

- 50000ATT/day

+ 30000ATT/day

57 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • The PRBs for the Msg3 of the contention based IAS/CAS Disabled Random Access Procedure or the initial transmission of the non-contention based Random Access Procedure for UEs not in TTI bundling mode are allocated at the borders of the available frequency range (note TTI bundling cannot be used Initial transmission 1 non adaptive for msg3 – UE A re-transmission for for msg3 of the contention based RA procedure) msg3 – UE A - To avoid conflicts between the PRB allocation of the PRACH and the possible nonadaptive HARQ retransmissions of the Msg3 the Msg3s are placed on the side of the spectrum that is furthest away from the PRACH - In contrast to the Msg3s all initial transmissions of the non-contention based Random Access Procedure of UEs not in TTI bundling mode are placed on the side of the spectrum the PRACH is located st

• If such an initial transmission has to be retransmitted the adaptive HARQ retransmission may select PRBs for which are not already assigned to the PRACH - If several Random Access Procedures have to be considered in the same TTI, the UL-Scheduler allocates the PRBs for Msg3s and initial transmissions in consecutive PRBs at the corresponding side of the spectrum 58 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • When Interference aware UL scheduling is enabled (ulsSchedMethod == InterferenceAware) or Channel aware UL scheduling is enabled (ulsSchedMethod == ChannelAware) the RA msg3 in contention based RA procedure and the 1st scheduled UL transmissions of non-contention based RA procedure in the preferred scheduling area if possible - Placing of these messages starts from the lower border of the preferred scheduling area if that is in the lower half of the bandwidth (prefSA < ulsNumSchedAreaUl / 2), otherwise it starts from the upper border of the preferred scheduling area

• If the preferred scheduling area contains PRBs used for PRACH, the allocation of msg3/1st scheduled UL transmissions starts from the PRB next to the PRACH allocation - Msg3s cannot be allocated on PRBs used for PRACH • This is required also in the subframes where PRACH is not present

- 1st scheduled UL transmissions of non-contention based RA procedure can be allocated on those PRBs in subframes where PRACH is not present 59 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3

• Note that msg3/1st scheduled UL transmissions are allocated some TTIs earlier than the final UL scheduling for that target TTI is done and the preferred scheduling area for the target TTI is determined therefore allocating msg3/1st scheduled UL transmissions the latest preferred scheduling area is used

60 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • Frequency domain scheduling for message 3s in TTI x is done assuming that transmissions of contention based RA msg3 done in TTI x-8 have to be repeated unless maximum amount of transmissions (harqMaxMsg3) is reached -

This means that PRBs, which were used for contention based RA msg3 transmissions 8 TTIs before the TTI currently under scheduling, are reserved for RA msg3 retransmissions

• In determining the frequency resource for TTI x, also whether PHICH resource index (PHICH group and cyclic shift) is individual for this UE or not needs to be considered -

3-bit uplink uplink physical demodulation reference signal sent on uplink scheduling entry (n2Dmrs in PDCCH DCI0 capacity grant) is defined so that PHICH resources (PHICH group index and orthogonal sequence index within the group, 36.213 chapter 9.1.2) of different UEs scheduled to the same TTI won't overlap •

For PUSCH transmissions scheduled from serving cell in subframe n, a UE shall determine the corresponding PHICH resource of serving cell c in subframe n+kPHICH, where kPHICH is always 4 for FDD

•

seq group seq group , nPHICH ) pair where nPHICH The PHICH resource is identified by the index (nPHICH is the PHICH group number and nPHICH is the orthogonal sequence index within the group as defined by:

group group group nPHICH  ( I PRB _ RA  nDMRS ) mod N PHICH  I PHICH N PHICH





seq group PHICH nPHICH  ( I PRB _ RA / N PHICH  nDMRS ) mod 2 N SF 61 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 group group group nPHICH  ( I PRB _ RA  nDMRS ) mod N PHICH  I PHICH N PHICH

- Where





seq group PHICH nPHICH  ( I PRB _ RA / N PHICH  nDMRS ) mod 2 N SF

•

nDMRS is mapped from the cyclic shift for DMRS field (according to 36.213 table 9.1.2-2 given below right) in the

•

nDMRS is set to zero, if there is no PDCCH with uplink DCI format for the same transport block, and

•

most recent PDCCH with uplink DCI format for the transport block(s) associated with the corresponding PUSCH transmission -

if the initial PUSCH for the same transport block is semi-persistently scheduled, or

-

if the initial PUSCH for the same transport block is scheduled by the random access response grant

nDMRS, n2Dmrs values are selected so that the UEs are distributed equally to available PHICH groups taking into account that PHICH resource index (PHICH group and orthogonal sequence index within the group) is unique for each UE for which PHICH is transmitted in the same TTI

- Note that for a TTI bundle the PHICH is sent corresponding to the 4th subframe of the bundle •

PHICH N SF is the spreading factor size used for PHICH modulation (and is 4 for normal cyclic prefix and 2 for

extended cyclic prefix)

   lowest _ index  I PRB _ RA I PRB _ RA     • 62 28/10/2015 © Nokia 2014  I lowest _ index  1  PRB _ RA For internal use

for the first TB of a PUSCH with associated PDCCH or for the case of no associated PDCCH when the number of negatively acknowledg ed TBs is not equal to the number of TBs indicated in the most recent PDCCH associated with the correspond ing PUSCH for a second TB of a PUSCH with associated PDCCH

Cyclic Shift for DMRS Field in PDCCH with uplink DCI format in

nDMRS

000 001 010 011 100 101 110 111

0 1 2 3 4 5 6 7

RRC Setup Failures – MSG3 group group group nPHICH  ( I PRB _ RA  nDMRS ) mod N PHICH  I PHICH N PHICH



- Where •



seq group PHICH nPHICH  ( I PRB _ RA / N PHICH  nDMRS ) mod 2 N SF

group is the number of PHICH groups configured by higher layers and according to parameter N g  1 6 ,1 2 ,1,2 N PHICH

phichRes

group N PHICH

   



DL  N g N RB 8   DL  2  N g N RB 8



for normal cyclic prefix for extended cyclic prefix

1 for TDD UL/DL configurat ion 0 with PUSCH transmission in subframe n  4 or 9 I PHICH   0 otherwise

63 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • In determining the frequency resource for TTI x, also whether PHICH resource index (PHICH group and cyclic shift) is individual for this UE or not needs to be considered -

To keep equal distribution among the groups per TTI, LTE MAC PS has to continuously keep track of how many UEs are in each PHICH group •

-

This includes also UEs scheduled with Random Access Message 3 / 1st Scheduled Uplink Transmission

When defining n2Dmrs value for a UE, LTE MAC PS calculates the PHICH group with different n2Dmrs values until a group with the least number of UEs is found

•

Only in case it is not possible to allocate (orthogonal sequence index would overlap or no n2Dmrs value correspond to the wanted PHICH group) UE to the PHICH group(s) with the lowest number of UEs with any n2Dmrs value, unequal distribution is allowed

•

In this case a possible group with the least number of UEs is selected

• If unique PHICH index cannot be found or it is allowed to select the same PHICH index for more than one UE, however PHICH index of contention based Random Access Message 3 is always unique -

UE is not scheduled if overlapping with contention based Random Access Message 3 cannot be avoided

64 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • In determining the frequency resource for TTI x, also whether PHICH resource index (PHICH group and cyclic shift) is individual for this UE or not needs to be considered - When performing this check, it is assumed that all RA msg3 transmissions in TTI x-8 will fail (note that PHICH index of normal UEs, including 1st scheduled uplink transmissions in non-contention based RA, scheduled in TTI x-8 shall not be considered as it is possible to change the PHICH index for their retransmissions) - If PHICH resource index collides with another UE that has already been allocated to the frequency domain in this TTI, allocation shall be attempted to the next possible frequency positions - In case there is still a collision, transmissions shall be posponed to the next TTI where this UE shall be allocated to frequency in first position

65 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 • Random Access Message 3 allocation example in 5 Mhz bandwidth • When scheduling a new msg3 / 1st scheduled UL transmission to a TTI, the PRB resources are chosen so that PHICH index does not overlap with the PHICH indices of contention based RA msg3s in the TTI 8 subframes earlier -

In SFN 0 TTI 8 the allocation starting from PRB 5 cannot be used for 1st scheduled UL transmission because PHICH would overlap with msg3 number 2 (n_PHICH^group calculations give the same value SFN 0 1 2 1 PRB / TTI 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7

group group group nPHICH  ( I PRB _ RA  nDMRS ) mod N PHICH  I PHICH N PHICH

n

group PHICH

 (lowest # PRB  0) mod( roundup( N g  (25 / 8))  0  N g

group nPHICH  1 for lowest# PRB  5 or 21 regarless of N g

0 1 2

1

-

Also allocation starting from PRB 18 is not possible for msg3 because the PHICH would overlap with 1st scheduled UL transmission number 3 already allocated in SFN 0 TTI 8 The numbers in messages indicate the order in which the messages are scheduled in the example

5

9 5

7 8

7

9 10 11 12 13 14 15

10

16 17

PUCCH

4

18 19 20

66 28/10/2015 © Nokia 2014 For internal use

8

4 6

-

3

3

n_DMRS=0 n_PHICH^group n_PHICH^seq INDEX 0 0 1 1 0 2 0 1 3 1 1 4 0 2 5 1 2 6 0 3 7 1 3 8 0 4 9 1 4 10 0 5 11 1 5 12 0 6 13 1 6 14 0 7 15 1 7 16 0 0 1 1 0 2 0 1 3 1 1 4 0 2 5 1 2 6 0 3 7 1 3 8 0 4 9

21 22 23 24

6 2

PRACH 1st scheduled UL transmission of non-contention based RA (initial transmission) succesful contention based RA msg3 transmission unsuccesful contention based RA msg3 transmission

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH/SRB0:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• According to 36.213 “If a PDCCH with associated RA-RNTI is detected in subframe n, and the corresponding DL-SCH transport block contains a response to the transmitted preamble sequence, the UE shall, according to the information in the response, transmit an UL-SCH transport block in the first subframe n+k1 , k1 6 , if the UL delay field in section 6.2 is set to zero where n+k1 is the first available UL subframe for PUSCH transmission. The UE shall postpone the PUSCH transmission to the next available UL subframe after n+k1 if the field is set to 1” • This means that the BTS can start to expect to receive the msg3 min 6 TTIs after the RA response is sent out Transmission at eNB

Reception at eNB

67 28/10/2015 © Nokia 2014 For internal use

RA Response Window

PRACH

RA Message 3 or 1st Scheduled Transmission in UL Window

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble

PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• The UE sends the MSG3 with the power given by : PPUSCH i   min PCMAX ,10 logM PUSCH i   PO _ PUSCH  j     j   PL  TF i   f i 

-

Where i=subframe number and for PUSCH (re)transmissions corresponding to the random access response grant j=2 and

P0 _ PUSCH  j   P0 _ NOMINAL _ PUSCH  j   P0 _ UE _ PUSCH  j 

•

P0_NOMINAL_PUSCH(2) = P0_PRE+ ΔPREAMBLE_Msg3 -

P0_PRE= PREAMBLE_INITIAL_RECEIVED_TARGET_POWER = preambleInitialReceivedTargetPower

-

ΔPREAMBLE_Msg3 = DeltaPreambleMsg3 (delivered to the UE in SIB2 or as a part of MobilityControlInfo IE e.g. in RRC Connection Reconfiguration – message i.e. value could be changed as per UE and signaling cause)

-

P0_UE_PUSCH(2) = 0

-

(2) = 1

68 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• The UE sends the MSG3 with the power given by :

PPUSCH i   min PCMAX ,10 logM PUSCH i   PO _ PUSCH  j     j   PL  TF i   f i  •

f(i) is initialised with value f(0) as:

f (0)  Prampup   msg 2

TPC Command 0 1 2 3 4 5 6 7

Value (in dB) -6 -4 -2 0 2 4 6 8

-

Where Prampup = the total power ramp-up from the first to the last preamble i.e. the total power ramping until the preamble is acknowledged by the RA response

-

msg2 is given by the table on the right and is given by RA response TPC field according to the ulpcRarespTpc parameter (this value could be changed e.g. As per preamble type : contention based RA or non-contention based RA)

-

According to 36.213 the accumulation is always enabled if the TPC command (i.e. msg2) is included in a PDCCH with DCI format 0 where the CRC is scrambled by the Temporary C-RNTI and therefore the f(0) value is taken into account by the UE (NSN eNB always sets TPC command for msg2 -> accumulation is always used)

© Nokia 2014 PCMAX M PUSCH i  ispreambleIn PPUSCH Msg 328/10/2015  min ,10 logfor vedTargetPower   PREAMBLE_Msg3  PL  TF i   preamble power ramp up   Msg 2  •69 The total power msg3 given asitialRecei : For internal use

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ NACK

PHICH:HARQ NACK

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

PHICH:HARQ NACK

• The UE retransmits the msg3 in case it receives HARQ NACK - Retransmissions use non-adaptive HARQ where NACK is sent with PHICH but no PDCCH grant at the same time and therefore then UE is forced to use the same resources as given in Random Access Response message (msg2) - It should be noted that the NDI is not toggled in case of msg3 re-transmissions but previous NDI value is used instead - When the “harqMaxMsg3” expires, the UE should stop sending Msg3 reTx •

But juts to make sure eNB will also send an “ACK” for the last reTx to avoid some UE’s misbehavior

70 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG3 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ NACK

PHICH:HARQ NACK

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

PHICH:HARQ NACK

• The UE retransmits the msg3 in case it receives HARQ NACK - Each retransmission (non adaptive HARQ) is transmitted using the power calculated with the formula below (just updated based on the latest PathLoss measurements i.e. OLPC component is updated)

PPUSCH Msg3  min PCMAX ,10 logM PUSCH i   preambleInitialRecei vedTargetPower   PREAMBLE_Msg3    j  PL  TF i   preamble power ramp up   Msg 2 

- The msg3 HARQ retransmissions are done up to harqMaxMsg3 amount and after each (re)transmission the UE waits for raContResoT –time for the contention resolution message

• In case the UE does not receive any response to msg3 (re)transmission i.e. DTX is detected by eNB, until ContentionResoltionTimer expiry, the UE starts the RACH procedure from the beginning by resending the selected (same) preamble but with higher power 71 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution + RRC Connection Setup

72 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

•

PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission -

The ContentionResolutionTimer expiry time is given to UE in SIB2 •

mac-ContentionResolutionTimer The maximum content resolution timer parameter defines the maximum amount of time allowed for contention resolution -

-

raContResoT (8ms (0), 16ms (1), 24ms (2), 32ms (3), 40ms (4), 48ms (5), 56ms (6), 64ms (7)), default 32ms (3)

maxHARQ-Msg3Tx Indicates the maximum number of HARQ transmissions used for message 3 of the contention-based random access procedure •

•

PRACH: RA Preamble

harqMaxMsg3 (1...8, step 1), default 5

Regardless of the possible occurrence of a measurement gap, the UE monitor the PDCCH until mac-ContentionResolutionTimer expires or is stopped -

if notification of a reception of a PDCCH transmission is received from lower layers, the UE considers the RA Procedure as successful

-

Contention Resolution is based on either C-RNTI on PDCCH or UE Contention Resolution Identity on DL-SCH

73 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• The Contention Resolution Message is addressed to C-RNTI or temporary C-RNTI and in case of Temporary C-RNTI, echoes UE identity contained in L2/L3 message UE

eNB

RRC Connection Request RA Preamble (RA-RNTI) RA Response (Temporary C-RNTI) HARQ Contention Resolution + RRC Connection Setup

74 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts mac-ContentionResolutionTimer and restart mac-ContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

•

•

PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

The CR and RRC Connection Setup messaging supports HARQ, and HARQ feedback is sent only by the Ue which detects its own identity (from CR message) -

•

PRACH: RA Preamble

Other UEs understand there was a collision and will start the RA process from the beginning

The UE to which the Contention Resolution Message was sent responds with ACK after correctly receiving the message with the matching Temporary C-RNTI or C-RNTI -

Othervise RA Procedure is started again from sending RA preamble

-

if mac-ContentionResolutionTimer expires, contention resolution is considered unsuccessful and UE is expected to send another HARQ (re)transmission or start the procedure from beginning by sending new preamble (with increased power as PREAMBLE_TRANSMISSION_COUNTER in incremented by 1)

UE Contention Resolution Identity MAC control element is identified by MAC PDU subheader with LCID -

This control element has a fixed 48-bit size and consists of a single field

75 28/10/2015 © Nokia 2014 For internal use

Index 00000 00001-01010 01011-11011 11100 11101

LCID values CCCH Identity of the logical channel Reserved UE Contention Resolution Identity Timing Advance Command

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

•

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

The CQI reporting is only started when measurements are configured in RRC Setup message and therefore the contention resolution message is sent in DL using default QPSK modulation and coding rate -

Used coding rate is defined by parameter maxCrRa4Dl, e.g. 0.39, this value is higher (less channel coding) compared to the RA response (maxCrRaDl = 0.12)

-

The maxCrRa4Dl should have the same value as maxCrRaDl = 0.12 to improve the detection of Contention Resolution message

-

Negative impact will be slight reduction in DL tput (but net effect can be positive due to less resources reserved due to less overlapping reservations)

-

TTI trace analysis shows that there are 4 transmissions but only DTX received which indicates that CR message is not received by the UE (or corresponding PDCCH allocation is not received) with maxCrRa4Dl = 0.39 No response for RRC Connection Setup

time SFN [h:min:s:m s] 76 28/10/2015 © Nokia318 2014 10:41:23:054 10:41:23:062 318 For internal use 10:41:23:070 10:41:23:078

319 320

eSFN

cellId

cRnti

1 9 7 5

3485 3485 3485 3485

37044 37044 37044 37044

mimoMode dynMimoMode rrmMimoCqirrmMimoRi trNumCW1trNumCW2 TX div TX div TX div TX div

-

-

-

NewTx NewTx NewTx NewTx

-

ackNack Cw1

ackNack Cw2

modulatio n CW1

DTX DTX DTX DTX

DTX DTX DTX DTX

QPSK QPSK QPSK QPSK

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

•

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

3TTI processing delay by 3GPP

PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

Decreasing the maxCrRa4Dl back to the original value of 0.12 (from 0.39) means -

-

Contention resolution + RRC Connection Setup message size is 48bits + MAC header (24bits) = 216bits

This TB + CRC goes through the turbo coder (channel coding) and to the rate matching •

-

-

-

The rate matching unit will match the amount of bits according to the max coding rate parameter of bits is according to the maxCrRa4Dl paramter

Final amount of bits is : •

maxCrRa4Dl = 0.12 -> 216b/0.12=1800bits

•

maxCrRa4Dl = 0.39 -> 216b/0.39=554bits

After QPSK modulation •

maxCrRa4Dl = 0.12 -> 216b/0.12=1800bits -> 900symbols

•

maxCrRa4Dl = 0.39 -> 216b/0.39=554bits -> 277symbols

Single PRB has 12 sub carriers and 12 symbols (assuming 2 symbols for PDCCH)

77 28/10/2015 © Nokia 2014 • maxCrRa4Dl = 0.12 For internal use

•

-> 216b/0.12=1800bits -> 900symbols -> roundup(900/12/12)=7PRBs

maxCrRa4Dl = 0.39 -> 216b/0.39=554bits -> 277symbols -> roundup(277/12/12)=2PRB

(8bits) + 136bits + CRC check a0 , a1 ,..., a A 1

Transport block CRC attachment

so that the final amount b0 , b 1 ,..., b B 1 Code block segmentation Code block CRC attachment cr 0 , cr1 ,..., cr  K r 1

Channel coding d r(i0) , d r(1i ) ,..., d r(i)D

r 1

Rate matching

er 0 , er1 ,..., er  Er 1 Code block concatenation

f 0 , f1 ,..., f G 1

RRC Setup Failures – MSG4 •

The actual value for maxCrRa4Dl (analysis below applies also maxCrRaDl ) should be optimised as per RRC Setup Success rate increase requirement and at the same time balancing the capacity impact -

Below (left) chart shows the coding rate vs. #PRBs needed per msg4 (Contention Resolution + RRC Connection Setup)

-

This decrease of max coding rate for msg4 decreases capacity (i.e. amount of PRBs available for user data) so therefore the impact to the throughput needs to be calculated •

In case the PRACH resources availability is once per 10ms radio frame and amount of required msg4s is according to the amount of (contention based) preambles per cell i.e. Max up to 40, it is possible to calculate the impact to the throughput as given in the graph on the right (for 10Mhz LTE) per 10ms (50*10=500PRBs available)

•

Impact to tput is given as decrease to total amount of PRBs available per radio frame as per coding rate and per different #sent MSG4s per that 10ms frame

Most optimal coding rates in case of 2 symbols for PDCCH

78 28/10/2015 © Nokia 2014 For internal use

Coding rate <0.07 is not possible due to not enough capacity per single 10ms frame for 40 MSG4s and coding rate <0.06 is not possible due to not enough capacity per single 10ms frame for 36 MSG4s

RRC Setup Failures – MSG4 •

•

As can be seen from the graph below decreasing the coding rate from 0.39 to 0.12 increases the PRB usage for MSG4 as below: -

1 MGS4 per 10ms (100 RRC setup atts per cell/s on average) : 0.4% -> 1.4%

-

2 MGS4 per 10ms (200 RRC setup atts per cell/s on average) : 0.8% -> 2.8%

-

4 MGS4 per 10ms (400 RRC setup atts per cell/s on average) : 1.6% -> 5.6%

-

12 MSG4 per 10ms (1200 RRC setup atts per cell/s on average) : 4.8% -> 16.8%

-

36 MSG4 per 10ms (3600 RRC setup atts per cell/s on average) : 14.4% -> 50.4%

As the MSG4 has HARQ it is not recommended to increase the PDCCH aggregation level for MSG4 and decrease the PDSCH coding rate too aggressively as that would lead to increase in PRB usage for MSG4s especially with high load

79 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – Contention Resolution UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

• Successful case shown below i.e. ACK for the first attempt of CR message

ssful Response later for same UE

time [h:min:s:ms]

SFN

eSFN

10:41:23:144 327 1 10:41:23:177 330 4 10:41:23:185 331 2 10:41:23:197 332 4 10:41:23:198 332 5 10:41:23:205 333 2 10:41:23:206 333 3 10:41:23:213 334 0 10:41:23:249 337 6 10:41:23:257 338 4 10:41:23:258 338 5 10:41:23:265 339 2 10:41:23:266 339 3 10:41:23:273 340 0 10:41:23:274 340 1 10:41:23:281 340 8 80 28/10/2015 © Nokia 2014 10:41:23:330 7 For internal use 345 10:41:23:338 346 5

cellId

cRnti

mimoMode dynMimoMode rrmMimoCqirrmMimoRi trNumCW1trNumCW2

3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485 3485

25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633 25633

TX div TX div TX div TX div TX div TX div TX div TX div 2x2 Mimo 2x2 Mimo TX div 2x2 Mimo TX div 2x2 Mimo TX div 2x2 Mimo 2x2 Mimo 2x2 Mimo

Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop Open Loop

7 7 7 7 7 7 7 8.756836 9.382813 9.382813 9.382813 9.382813 8.507813 8.507813 8.507813 8.570313 8.570313

1.399414 1.399414 1.399414 1.399414 1.399414 1.399414 1.399414 1.850586 1.962891 1.962891 1.962891 1.962891 1.962891 1.962891 1.962891 1.981445 1.991211

NewTx NewTx ReTx: 1 NewTx NewTx ReTx: 1 ReTx: 1 ReTx: 2 NewTx ReTx: 1 NewTx ReTx: 2 ReTx: 1 ReTx: 3 ReTx: 2 ReTx: 4 NewTx ReTx: 1

NewTx ReTx: 1 ReTx: 2 ReTx: 3 ReTx: 4 NewTx ReTx: 1

ackNack Cw1

ackNack Cw2

ACK NACK ACK NACK NACK DTX ACK ACK NACK DTX DTX NACK NACK NACK ACK ACK DTX NACK

DTX DTX DTX DTX DTX DTX DTX DTX NACK DTX DTX NACK DTX NACK DTX ACK DTX NACK

modulatio Modulatio n n CW1 CW2 QPSK 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM

16QAM 16QAM 16QAM 16QAM 16QAM 16QAM 16QAM

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup PUCCH: HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

• The delay between re-attempts 60ms indicates following (provided that the raContResoT is 32ms) - UE waits for the contention resolution message for 32ms - then re-sends the RRC request i.e. additional 20ms per request - Sum of these two and 60ms delay between RRC requests (in above emil logs) means that UE need to re-transmit preamble once : 32ms+20ms= 52ms

• In above case the problem is therefore that the UE does NOT hear the contention resolution message either due to the raContResoT expiry before all HARQ retransmissions for MSG4 are done or UE does NOT hear the corresponding PDCCH message 81 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

•

PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup PUCCH: HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

pdcchAggMsg4 (def 4)

mac-ContentionResolutionTimer The maximum content resolution timer parameter defines the maximum amount of time allowed for contention resolution -

•

PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ

The parameter defines the reserved number of Control Channel Elements (CCEs) for dedicated Random Access Message 4 assingment on PDCCH -

•

PRACH: RA Preamble

raContResoT (8ms (0), 16ms (1), 24ms (2), 32ms (3), 40ms (4), 48ms (5), 56ms (6), 64ms (7)), default 32ms (3), value to be tested 7 (optimisation in case of positive impact to 4, 5 or 6)

harqMaxTrDl e.g. 3 defines the max amount HARQ retransmission : the HARQ delay is 8ms plus some 0.6ms UE processing delay (timing difference in between UL and DL) so 3 transmissions equal 3*9ms=27ms which covers the raContResoT default 32ms, in case harqMaxTrDl is increased 3->4 the raContResoT should be increased accordingly to 40ms -

Negative impact : can cause minor delay in call setups in case of additional HARQ retransmissions needed for RRC connection

82 28/10/2015 © Nokia 2014 establishment For internal use

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup PUCCH: HARQ

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

•

It should be noted that when harqMaxTrDL and/or harqMaxTrUl is/are increased this causes additional delay for the user plane packet delivery to PDCP layer (from RLC layer) and might cause discardTimer expiry

•

However following should be noted -

As stated in 36.323 “The transmitting side of each PDCP entity for DRBs shall maintain the following timers: •

-

•

a) discardTimer

The duration of the timer is configured by upper layers [3]. In the transmitter, a new timer is started upon reception of an SDU from upper layer.”

Therefore the discard timer only applies to the user plane packet delivery to PDCP layer, but there is no need to increase the UP disacrdTimer parameter as for the delay sensitive services it is more important to get the packets delivered on time rather than late so the discardTimer for delay sensitive services should not be modified 83 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG4 •

It should be noted that when harqMaxTrDL and/or harqMaxTrUl is/are increased this causes additional delay for the packet delivery to PDCP layer (from RLC layer UM/AM) and might cause re-ordering timer expiry (tReord) -

The default values for tReord is 50ms for all rlc profiles (for DRB modifiable for some profiles and for SRB hard coded value)

-

Assuming harqMaxTrDL, harqMaxTrUl = 7 -> reordering time is 6*8ms = 48ms i.e. 50ms default value for tReord is ok however it should be noted that 6*8ms=48ms applies for UL as it has fixed HARQ RTT but in DL the HARQ RTT is not fixed which means that in 6*8=48ms applies only for low load scenario (when loading increases the HARQ RTT might be delayed causing tReord to expire and therefore packet discards can increase and this needs to be monitored)

Packet 1

HARQ tx 1

Packet 1

HARQ tx 3

Packet 1

HARQ tx 5

Packet 1

Packet 2

Packet16

Packet30

Packet44

Packet 3

Packet17

Packet31

Packet45

Packet 4

Packet18

Packet32

Packet46

Packet 5

8ms

Packet19

8+8+8ms

Packet33

8+8+8+8+8ms

Packet47

Packet 6

Packet20

Packet34

Packet48

Packet 7

Packet21

Packet35

Packet49

Packet 8

Packet22

Packet36

Packet 1

HARQ tx 2

Packet 1

HARQ tx 4

Packet 1

Packet 9

Packet23

Packet37

Packet10

Packet24

Packet38

Packet11 Packet12

Packet13

Packet25

8+8ms

Packet26

Packet50

HARQ tx 6

Packet39

8+8+8+8ms

Packet40

84 28/10/2015 © Nokia 2014 Packet14 For internal use

Packet27

Packet41

Packet28

Packet42

Packet15

Packet29

Packet43

8+8+8+8+8+8ms = 48ms

HARQ tx 7 message c1 : rrcConnectionSetup : { rrc-TransactionIdentifier 2, criticalExtensions c1 : rrcConnectionSetup-r8 : { radioResourceConfigDedicated { srb-ToAddModList { { srb-Identity 1, rlc-Config explicitValue : am : { ul-AM-RLC { t-PollRetransmit ms100, pollPDU pInfinity, pollByte kBinfinity, maxRetxThreshold t16 }, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms0 } },

RRC Setup Failures – MSG4 • The RLC timer t-PollRetransmit depends on the RLC round trip time from sending polling request to receiving RLC status report - The maximum round trip time depends on the setting of the HARQ transmission thresholds in both directions - Using the 50 ms value defined for the t-Reordering above, the value of tPollRetransmit is set to 50ms+50ms=100ms • t-PollRetransmit is by default set to 100ms for SRB and 120ms for DRB (tPollRetr) • maxRetxThreshold is set to 16 for SRB and also 16 for DRB (drbAmMxRtxTh) • Note that the parameters above are hard coded for SRB • Above means that the RLC (re)transmissions takes - SRB 100ms*16 = 1600ms

- DRB 120ms*16 = 1920ms

85 28/10/2015 © Nokia 2014 For internal use

drb-ToAddModList { {eps-BearerIdentity 5, drb-Identity 4, pdcp-Config { discardTimer ms750, rlc-AM { statusReportRequired TRUE}, headerCompression notUsed : NULL}, rlc-Config am : { ul-AM-RLC { t-PollRetransmit ms120, pollPDU p64, pollByte kB500, maxRetxThreshold t16}, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms50}}, logicalChannelIdentity 3, logicalChannelConfig { ul-SpecificParameters { priority 9, prioritisedBitRate kBps16, bucketSizeDuration ms100, logicalChannelGroup 2} } }, {eps-BearerIdentity 6, drb-Identity 5, pdcp-Config { discardTimer ms750, rlc-AM { statusReportRequired TRUE}, headerCompression notUsed : NULL}, rlc-Config am : { ul-AM-RLC { t-PollRetransmit ms120, pollPDU p64, pollByte kB500, maxRetxThreshold t16}, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms50} }, logicalChannelIdentity 4, logicalChannelConfig { ul-SpecificParameters { priority 9, prioritisedBitRate kBps16, bucketSizeDuration ms300, logicalChannelGroup 3} } } },

RRC Setup Failures – MSG4 UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request 10 TTI (10ms) waiting time for the RA response . Started after sending the corresponding RA preamble + 3TTI defined by raRespWinSize + 3TTI (processing delay) Once RRC Connection Request (Message 3 of RA Procedure) has been transmited, the UE starts macContentionResolutionTimer and restart macContentionResolutionTimer at each HARQ retransmission, raContResoT (def. 32ms)

DCI Format

0

1

1A

1C

PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup PUCCH: HARQ

Coding Rate : Rate matched to 1 CCE (72 bits) 0.6111111

Coding Rate : Rate matched to 2 CCE (144 bits) 0.3055556

Coding Rate : Rate matched to 4 CCE (288 bits) 0.1527778

Coding Rate : Rate matched to 8 CCE (576 bits) 0.0763889

Bw [MHz] 20

Num Bits 44

Number of channel coded bits 132

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

20

55

165

0.7638889

0.3819444

0.1909722

0.0954861

15

49

147

0.6805556

0.3402778

0.1701389

0.0850694

10

47

141

0.6527778

0.3263889

0.1631944

0.0815972

5

43

129

0.5972222

0.2986111

0.1493056

0.0746528

20

44

132

0.6111111

0.3055556

0.1527778

0.0763889

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

20

31

93

0.4305556

0.2152778

0.1076389

0.0538194

15

30

90

0.4166667

0.2083333

0.1041667

0.0520833

10

29

87

0.4027778

0.2013889

0.1006944

0.0503472

5

28

84

0.3888889

0.1944444

0.0972222

0.0486111

20

64

192

0.8888889

0.4444444

0.2222222

0.1111111

174

0.8055556

0.4027778

0.2013889

0.1006944

171

0.7916667

0.3958333

0.1979167

0.0989583

156

0.7222222

0.3611111

0.1805556

0.0902778

86 28/10/2015 © Nokia 15 58 2014 10 57 For internal use

2A

5

52

3TTI processing delay by 3GPP MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable, in vendor file) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

•

It should be noted that for the DCI format 1A that is used for MSG4 PDCCH indication having coding rate of 0.14 – 0.15 in case of default 4 CCEs is used

•

This 0.14 – 0.15 coding rate is in line with the suggested setting for MSG4 default coding rate on PDSCH i.e. maxCrRa4Dl = 0.12 -

•

The difference between 0.14-0.15 on PDCCH to 0.12 on PDSCH should be compensated by use of 1/3 convolutional coding on PDCCH vs. 1/3 turbo coding used on PDSCH

In case maxCrRa4Dl is set to 0.05 then also the default aggregation (pdcchAggMsg4) level for MSG4 PDCCH order delivery should be changed to 8

RRC Setup Failures • T300 : Timer T300 supervises the RRC connection establishment procedure

T300 : started when UE L3 sends RRC Connection Request to L2/L1 and stopped in case of RRC Connection Setup is received or RRC Connection Reject

- Start: Transmission of RRCConnectionRequest - Stop: Reception of RRCConnectionSetup or RRCConnectionReject message, cell re-selection and upon abortion of connection establishment by upper layers • •

-

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

100ms (0), 200ms (1), 300ms (2), 400ms (3), 600ms (4), 1000ms (5), 1500ms (6), 2000ms (7), Default: 200ms (1) In case T300 expiry the UE will stop RRC Connection Establishment procedure and informs higher layers about failed procedure

The T300 should be set according to the following formula taking into account the worst case scenario i.e. UE does not get any response from eNB in terms of ACK/NACK for msg3 or msg4 until the very last sent preamble which then leads to successful transmission of msg3 (after max amount of retransmissions) and reception of msg4 (again after max amount of retransmission)  (preambleTxMax -1)*( raRespWinSize + 3ms + 6ms + raContResoT) + raRespWinSize + 3ms +6ms + (harqMaxMsg3-1)*8ms + raContResoT + 4ms = 7*(7+3+6+32)+7+3+6+(5-1)*8+32+4 = 7*(48ms) + 16ms + 4*8ms + 36ms = 420ms -> T300 = 600ms •

(preambleTxMax – 1) times unsuccessful contention resolutions : UE sends preamble then waits for RA response raRespWinSize + 3TTI (slide 25 graph), then sends msg3 6TTI (slide 43) after receiving the RA response and no response to msg3 at all until raContResoT expires then retransmits the preamble again • Then the last preamble is sent and UE waits for RA response raRespWinSize + 3TTI (slide 25 graph) then sends msg3 6TTI (slide 43) 87 28/10/2015 © Nokia 2014 after receiving the RA response. UE sends harqMaxMsg3-1 amount of msg3 messages (with nack) until finally receives the ACK and For internal use receives the random access contention resolution message (the last raContResoT includes all the possible DL retransmissions for msg4). 4ms is considering the UE delay waiting for msg4 i.e. the last retransmitted preamble scenario.

RRC Setup Failures • T300 : Timer T300 supervises the RRC establishment procedure

T300 : started when UE L3 sends RRC Connection Request to L2/L1 and stopped in case of RRC Connection Setup is received or RRC Connection Reject

connection

- Start: Transmission of RRCConnectionRequest - Stop: Reception of RRCConnectionSetup or RRCConnectionReject message, cell re-selection and upon abortion of connection establishment by upper layers

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH: RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PDSCH/DL-SCH/CCCH/SRB0: Contention Resolution + RRC Connection Setup

• And raContResoT is defined based on 9ms* harqMaxTrDl and rounded up to the closest available value • raContResoT (8ms (0), 16ms (1), 24ms (2), 32ms (3), 40ms (4), 48ms (5), 56ms (6), 64ms (7)), default 32ms (3), value to be tested 7 (optimisation in case of positive impact to 4, 5 or 6) • However it should be noted that the eNB can/will respond with RA response earlier (as is the case when no congestion in RA response delivery) basically right after 3ms expiry so we could therefore reduce the effectively used raRespWinSize down to 1ms => (preambleTxMax -1)*(1ms + 3ms + 6ms + raContResoT) + 1ms + 3ms +6ms + (harqMaxMsg3-1)*8ms + raContResoT + 4ms = 7*(1+3+6+32)+1+3+6+(5-1)*8+32+4 = 7*(42ms) + 10ms + 4*8ms + 36ms = 372ms -> T300 = 400ms • i.e. With the default parameter settings the T300 should be set min 400ms to enable max amount of RRC Connection Requests sending and extra time for RRC Connection Setup reception

88 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ ACK

PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution + RRC Connection Setup PUCCH:HARQ ACK PUCCH: Scheduling Request PDCCH:UL Capacity Grant PUSCH/UL-SCH/DCCH/SRB1: RRC Connection Setup Complete PHICH: HARQ ACK

89 28/10/2015 © Nokia 2014 For internal use

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request RRC Setup Failures – MSG5 PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response • In case the timer PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ ACK MinLifeTimeOfHalfOpenRrcConnection PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution expires before MSG5 (RRC Connection + RRC Connection Setup PUCCH:HARQ ACK Setup Complete) is received by the eNB the PUCCH: Scheduling Request PDCCH:UL Capacity Grant corresponding RRC setup attempt is PUSCH/UL-SCH/DCCH/SRB1: RRC Connection Setup Complete stopped by the eNB PHICH: HARQ ACK • Counter M8013C6 SIGN_EST_F_RRCCOMPL_MISSING that is incremented when the corresponding timer above expires

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

- Msg5 success rate can be calculated as : • -

M8013C5/(M8013C5+M8013C6+M8013C7)

The msg5 failures can be caused by either UL power control settings or by having too large TBS selected for msg5 transmission causing too many PRBs being allocated

90 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5 • MGS5 i.e. RRC Connection Setup Complete message is the first message that is sent by the UE following exactly the given power control scheme - The UE sends the MSG5 with the power given by : Open loop part

Closed loop part

PPUSCH i   min PCMAX ,10 logM PUSCH i   PO _ PUSCH  j     j   PL  TF i   f i  Tx power for PUSCH in Subframe i in dBm

Number of allocated resource blocks

Maximum allowed UE power in this particular cell, but at maximum +23 dBm, 36.101)

Cell-specific parameter configured by L3

Combination of cell- and UE-specific components configured by L3

Downlink path loss estimate

PUSCH transport format Power control adjustment derived from TPC command received in subframe (i-4)

- Where i=subframe number and for PUSCH (re)transmissions corresponding to the dynamic scheduling (j=1)

P0 _ PUSCH  j   P0 _ NOMINAL _ PUSCH  j   P0 _ UE _ PUSCH  j 

•

P0_NOMINAL_PUSCH(j) has range of -126 … +24dBm indicating from full pathloss compensation (-126) to no pathloss compensation (+24) -

•

j  0,1

This can be used to have different BLER operation points to achieve different probability of retransmissions

P0_UE_PUSCH(j) with the range of -8 … 7dB is used by the eNB to compensate any systematic offsets in the UE’s transmission power settings arising from a wrongly estimated pathloss

91 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5 •

•

α(j) is used as path-loss compensation factor as a trade-off between total uplink capacity and cell-edge data rate, -

Full path-loss compensation maximizes fairness for cell-edge UE’s,

-

Partial path-loss compensation may increase total system capacity, as less resources are spent ensuring the success of transmissions from cell-edge UEs and less inter-cell interference is caused to neighboring cells

-

For α(j=0, 1) can be 0, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9 and 1.0, where 0.7 or 0.8 give a close-to maximum system capacity by providing an acceptable cell-edge performance

The closed loop part f(i) is adjusted by the BTS PC decision algorithm shown below depending on the lower and upper SINR and RSSI parameters given for the matrix below

• It should be noted that the TPC commands for closed loop PC can be delivered to the UE in DCI 0 (UL allocation grant) or with DCI3/3A (not supported in the current release) and therefore at the time of MSG5 transmission the UL PC is mostly done by OLPC (MSG5 is the first DCI0 scheduled message) – Therefore when modifying the OLPC settings the RRC setup success rate needs to be monitored as especially the success rate of receiving the RRC setup complete message (and successfully UE receiving the MSG4) – Typically this means • p0NomPUSCH = -80dBm (max) • ulpcAlpha = 0.8 (min) 28/10/2015 © Nokia 2014

92 For internal use

RRC Setup Failures – MSG5 • The parameter iniMcsUl is used to allocate the initial MCS for msg5

• raSmallVolUl change from 144b to 56b (with MCS = 5 this means 1PRB is needed) the RACH success rate is greatly improved but CSSR reduced due to the missing msg5 • Therefore msg5 detection needs to be improved

- One way is to decrease the iniMcsUl parameter

RRC Setup Success Rate 93 28/10/2015 © Nokia 2014 iniMcsUl=4(Before) 99.2% For internal use

iniMcsUl=2(After)

99.4%(+0.2%)

E-RAB Setup Success Rate

RACH Setup Success Rate

99.7%

74.0%

99.7%

75.1%(+1.1%)

RRC Setup Failures – MSG5 • Graph below right shows typical problem example of msg5 delivery -

The msg3 is transmitted with 1 PRB and MCS 5

-

The msg5 resource request is initiated by scheduling request •

The resource allocation for SR user is fixed to 4 PRBs and iniMcsUl to determine the initial UL resource allocation for SR user in case UE does not have GBR bearer nor pure GBR LCG (4PRBs allocation is also used in case of C-RNTI delivery with msg3 via RA procedure without BSR)

-

As can be seen the UL AMC reduces the MCS with each RLC retransmission (note that HARQ retransmissions must be done with the initial transmission #PRBs and MCS id)

-

The MCS is reduced by the UL AMC algorithm shown below triggered by first transmission HARQ feedback •

ulamcDeltaCini = 0, ulamcDeltaCmin = -5, ulamcDeltaCmax = 5, ulamcCStepUp = 0.2, ulTargetBler = 10%

•

DeltaC stepdown = 1.8

•

Above parameters mean that after 3 initial transmissions the MCS is reduced -

First RLC Tx DTX -> Delta C = -1.8, 2nd -> -3.6, 3rd -> -5.4 => MCS reduced for 4th RLC Tx

for first HARQ feedback  ACK, min(C(t  1)  Cstepup, Cmax ),  C(t )  max(C(t  1)  Cstepdown, Cmin ), for first HARQ feedback  NACK or DTX, C(t  1), for first HARQ feedback  N/A.  94 28/10/2015 ©CNokia 2014 stepdown  Cstepup  For internal use

1 - BLER target BLER target

msg3 4 2 1

3

RRC Setup Failures – MSG5 • Graph below right shows typical problem example of msg5 delivery - The minimum TBS size is defined by parameter ulsMinTbs = 104b - Therefore when MCS is reduced to 0 the number of PRBs needs to be increased from 4 PRBs to 5 PRBs - Therefore decreasing the parameter ulsMinTbs below 88bit means that the MCS can be reduced down to 0 without increase of #PRBs i.e. it remains at 4 PRBs - As the UE is reporting negative PHR the reduction of 1 PRB (5->4) can improve the msg5 reception I TBS 0 1 2 3 4 595

1 2 3 16 32 56 24 56 88 32 72 144 40 104 176 56 120 208 28/10/2015 © Nokia224 2014 72 144

For internal use

4 88 144 176 208 256 328

N PRB 5 120 176 208 256 328 424

6 152 208 256 328 408 504

7 176 224 296 392 488 600

8 208 256 328 440 552 680

9 224 328 376 504 632 776

10 256 344 424 568 696 872

msg3 4 2 1

3

RRC Setup Failures – MSG5 • It should be noted that proactive UL scheduling i.e. ilReacTimerUl >0 can speed up the link adaptation as any NACK for dummy grants also impacts the link adaptation - dummy grant size given by hidden parameter ilMinDatvolUl = 560bits impacts to the large msg5 resource allocations

- TAU or attach need to be segmented into several RLC segments in case of 4 PRB with MCS 2 (TBS 176bits) but with proactive scheduling the whole large message can be sent in single RLC segment - Therefore ilReacTimerUl values such as 5ms could be used to improve the response to any SRB messaging (or alternatively ilReacTimerUl mod 100 = 5 to enable proactive scheduling for both non-GBR DRB and SRB)

• Also this feature was designed to improve the call setup time, so during the initial RRC connection setup the dummy grants will be allocated from TTI {(HARQ Ack for Msg4) +8ms } and the number of dummy grants is decided by timer ilReacTimerUl - So with setting 200ms it will basically cover the whole Attach Procedure - The DRB timer ilReacTimerUl mod 100 != 5 will not be triggered by any DL SRB messages

96 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5 ilReacTimerUl (0...2000 ms, step 5 ms)

RL30/RL40

RL50

100ms

Timer restarted each time the last non-GBR packet is sent for duration of 100ms

Timer restarted each time the last non-GBR packet is sent for duration of 100ms

105ms

Timer restarted each time the last non-GBR packet is sent for duration of 105ms

Timer restarted each time the last non-GBR packet is sent for duration of 100ms or each time DL SRB (0,1,2) data is transferred until UL SRB data is received or max 20ms

5ms

Timer restarted each time the last non-GBR packet is sent for duration of 5ms

Timer restarted each time DL SRB (0,1,2) data is transferred until UL SRB data is received or max 20ms

97 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request

PRACH: RA Preamble

• The UE needs to request the UL grant for sending the msg5 by sending scheduling request message on PUCCH

• If PUCCH is having too low power the SRI cannot be received properly by the eNB which leads into the SRI delivered over RACH which can be detected by emil logs as shown below • This kind of problem leads to call setup failure as the response for SRI on RACH is simply just eNB resending the PUCCH parameters for the UE • Therefore improvement can be achieved simply by allowing slightly more power for PUCCH - In this case increasing the p0NomPucch from -118dBm to -115dBm provides necessary improvement for cell edge users 98 28/10/2015 © Nokia 2014 For internal use

PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ ACK PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution + RRC Connection Setup PUCCH:HARQ ACK

PUCCH: Scheduling Request

dSrTransMax = 64 times SR on PUCCH PUSCH/UL-SCH/CCCH : SRI on PRACH i.e. MSG3 = C-RNTI PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response MSG3 = C-RNTI

RRC Setup Failures – MSG5 • After the successful reception of msg5 the following messages i.e. responses to security mode command and rrc connection reconfiguration are transmitted using initial MCS (iniMcsUl) and initial PRBs (iniPrbsUl, def=10) • As msg5 (and Service Request) is sent with initial MCS and 4PRBs the default for initial PRBs (iniPrbsUl) = 10 is too high and therefore decrease of iniPrbsUl to same value as msg5 (4 PRBs) is recommended

99 28/10/2015 © Nokia 2014 For internal use

RRC Setup Failures – MSG5

Algorithm triggered on every TTI

• Negative impact of decreasing initial PRBs from 10 to 4 is that the ramp up of #PRBs for data transmissions can take longer time

OLLA FUG / EDG

• This procedure can be speed up by e.g. decreasing the eUlLaPrbIncDecFactor (def. =0.8)

No

ATB triggeerd by periodical trigger or EDG triggered Yes

• This way it is possible to achieve the same UL tput with both initial #PRBs = 10 or 4

Test Pattern ulsMinTbs=10 test1 4 test2 p0NomPucch test3 Curre =-118 nt iniPrbsUl=10 eUlLaPrbIncD Ave ecFactor=0.8

RSRP:-100dBm ULPing DL-TP TP[Mbps [ms] [Mbps] ] 50 47.80 8.49 38 46.46 8.22 38 52.19 8.20

Yes

BLER > ulTargetBler

RSRP:-119dBm ULPing DL-TP TP[Mbps [ms] [Mbps] ] 50 15.25 0.74 66 14.32 0.28 61 14.37 0.77

48.82

8.30

53

35.23

2.80

59

14.65

0.60

ulsMinTbs=72 test1 50 48.68 p0NomPucch test2 38 51.02 =-116 test3 39 48.81 New iniPrbsUl=4 eUlLaPrbIncD 100 28/10/2015 © Nokia 2014 42 49.50 ecFactor=0.7 Ave

8.05 8.21 8.02

76 36 50

35.54 35.48 35.24

2.76 2.94 2.66

57 70 40

14.22 13.56 15.50

0.30 0.72 0.72

8.09

54

35.42

2.79

56

14.43

0.58

For internal use

42

RSRP:-110dBm ULPing DL-TP TP[Mbps [ms] [Mbps] ] 41 34.99 2.99 45 35.26 2.84 73 35.43 2.57

No

BLER is lower than the given target and OLLA has already set the MCS Index to the eUlLaLowMcsThr+ eUlLaDeltaMcs ?

No

No

BLER is higher than the given target and OLLA has already set the MCS Index to the eUlLaLowMcsThr, while MAX_NUM_PRB is still over the lowest PRB threshold (eUlLaLowPrbThr) ?

Amount of PRBs is decreased by factor eUlLaPrbIncDecFactor (multiply existing PRB amount)

The number of PRBs is increased by factor eUlLaPrbIncDecFactor (divide existing PRB amount)

provide MAX_NUM_PRB and NewMCS

END

RRC Setup Failures – MSG5 • Total improvement of all parameter changes for msg5 (and messages after msg5) is clearly visible for RRC setup success rate, ERAB setup success rate and even dropped call rate is improved (due to improved performance in HO areas)

101 28/10/2015 © Nokia 2014 For internal use

RRC Setup Success Rate vs. RACH Success Rate • Special event performance in coverage limited area (stadium) • Simple comparison between RACH success rate and RRC setup success rate can indicate problems in RA response reception (as currently the power offset for MSG3 over acknowledged preamble is 10dB, we can assume that the MSG3 reception is no issue – this was tested to be the case) • RACH success rate decreases rapidly when traffic increases (more users start to make calls in different coverage and interference conditions) from around 90% to below 50% • The RRC Setup Success Ratio is close to 100% through out the whole event

102 28/10/2015 © Nokia 2014 For internal use

RRC Setup Success Rate vs. RACH Success Rate • The average PUSCH SINR performs properly within the CLPC range [8…10]dB and PUCCH SINR well above the defined CLPC range [0…4]dB • The RACH success rate problem therefore is not in UL – MSG3 performance but rather in DL in terms of RA response performance

103 28/10/2015 © Nokia 2014 For internal use

RRC Setup Success Rate vs. RACH Success Rate • The RACH setup success problem means that RA response cannot be received by the UE and therefore the preamble must be retransmitted -

As the RA response does not have HARQ it means that each retransmission of RA response is initiated by sending a new preamble affecting to RACH success rate

• The RRC setup success rate is not affected at all indicating that the HARQ retransmissions for msg4 and msg5 do their job by guaranteeing the perfect success rate UE

eNB

RRC Connection Request RA Preamble RA Response

UE UE does not hear RA response (PDSCH message or corresponding PDCCH order) => UE keeps on restransmitting the RA preambles until it receives RA response

eNB RRC Connection Request

HARQ ACK

Contention Resolution + RRC Connection Setup RA Preamble

HARQ NACK

RA Response

Contention Resolution + RRC Connection Setup

RA Preamble

HARQ NACK Contention Resolution + RRC Connection Setup

RA Response RA Preamble RA Response

104 28/10/2015 © Nokia 2014 For internal use

HARQ ACK

RRC Setup Success Rate vs. RACH Success Rate • It should be noted that the RA response and MSG4 PDCCH aggregation levels were set the same as well as the coding rates for both of the messages therefore the retransmissions really provide performance difference • Therefore the recommendation is: - pdcchAggRaresp = 8 (def. 4) - maxCrRaDl = 0.05 (def 0.12) - maxCrRa4Dl = 0.12 (def. 0.12) - pdcchAggMsg4 = 4 (def. 4)

105 28/10/2015 © Nokia 2014 For internal use

RRC Setup Success Rate vs. RACH Success Rate

• pdcchAggRaresp = 8 means coding rate of 0.05 for 10Mhz case which means that the corresponding PDSCH coding rate i.e. maxCrRaDl should be set to 0.05

DCI Format

0

1

1A

1C

Coding Rate : Rate matched to 1 CCE (72 bits) 0.6111111

Coding Rate : Rate matched to 2 CCE (144 bits) 0.3055556

Coding Rate : Rate matched to 4 CCE (288 bits) 0.1527778

Coding Rate : Rate matched to 8 CCE (576 bits) 0.0763889

Bw [MHz] 20

Num Bits 44

Number of channel coded bits 132

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

20

55

165

0.7638889

0.3819444

0.1909722

0.0954861

15

49

147

0.6805556

0.3402778

0.1701389

0.0850694

10

47

141

0.6527778

0.3263889

0.1631944

0.0815972

5

43

129

0.5972222

0.2986111

0.1493056

0.0746528

20

44

132

0.6111111

0.3055556

0.1527778

0.0763889

15

43

129

0.5972222

0.2986111

0.1493056

0.0746528

10

43

129

0.5972222

0.2986111

0.1493056

0.0746528

5

41

123

0.5694444

0.2847222

0.1423611

0.0711806

20

31

93

0.4305556

0.2152778

0.1076389

0.0538194

15

30

90

0.4166667

0.2083333

0.1041667

0.0520833

10

29

87

0.4027778

0.2013889

0.1006944

0.0503472

5

28

84

0.3888889

0.1944444

0.0972222

0.0486111

20

64

192

0.8888889

0.4444444

0.2222222

0.1111111

174

0.8055556

0.4027778

0.2013889

0.1006944

171

0.7916667

0.3958333

0.1979167

0.0989583

156

0.7222222

0.3611111

0.1805556

0.0902778

106 28/10/2015 © Nokia 15 58 2014 10 57 For internal use

2A

5

52

Negative Impact of Parameter Set • In some cases when RRC Connection Setup Success Rate is improved (according to the parameter set described) the RRC Success Rate (1-drop rate) degrade a bit as can be seen from the graph below • The degradation is caused by increase in EPC initiated releases due RNL indicating some problem in NAS messaging • Investigation from MME side indicates problems with NAS PDU delivery i.e. problems with messages related to e.g. ATTACH procedure • This can be direct cause of having better RRC setup performance where calls under worse radio conditions can be setup but then following NAS messaging fails or problems can be caused by longer delays in message delivery due to extended HARQ amount

107 28/10/2015 © Nokia 2014 For internal use

Negative Impact of Parameter Set

• The increased PDU delivery time and UEs under worse radio conditions having successful RRC setup is visible in terms of increase in HARQ retransmission rates for UL and DL (due to increased max amounts) • This however has not caused any degradation into RLC retransmission rates indicating that the HARQ retransmissions really can provide better probability for the UE to receive and transmit messages correctly

108 28/10/2015 © Nokia 2014 For internal use

Results

• When MaxCrRa4Dl was modified to 0.12 (from 0.39) on mindnight of 20th may and after the RRC Setup Success Ratio improved • Testing in FiVe shows that most “optimal” value would be 0.05

LTE_5232a RRC Connection Setup Attempts MO Sig LTE_5233a RRC Connection Setup Attempts MT Access LTE_5234a RRC Connection Setup Attempts MO Data LTE_5218a RRC Connection Setup Success Ratio 109 28/10/2015 © Nokia 2014 For internal use

maxCrRa4Dl=39 10480 90 7 99.41

maxCrRa4Dl=12 7928 4 693 99.9

maxCrRa4Dl=5 8610 179 699 99.96

Results 2 - MaxCrRa4Dl

Excellent improvement for the worst performing cells

• Test cluster includes 16 eNBs ~ 85cells

Improvement in RRC setup success rate

Average performance over the test cluster improved (min >99%) 110 28/10/2015 © Nokia 2014 For internal use

RACH success rate maintained

Improvement Improvement in DCR in HO success rate

Only moderate increase in RB usage

Results 3

Cluster

maxCrRa4Dl, harqMaxTrDl improved CSSR significantly. (97.7%  99.94%)

111 28/10/2015 © Nokia 2014 For internal use

Results 3

112 28/10/2015 © Nokia 2014 For internal use

Results 3

113 28/10/2015 © Nokia 2014 For internal use

Results 3

114 28/10/2015 © Nokia 2014 For internal use

Results 3 – RACH Success Rate • The deltaPreMsg3 increase 2->4dB did not improve the RACH success rate (scenario 3) • Also harqMaxMsg3 increase did not seem to improve the RACH success rate • This means that the MSG3 reception is not the problem causing poor RACH success rate but rather the UE not hearing the RA response • This means that the RACH success rate decrease is caused by T300 increase which allows UE initiate the RACH procedure more often after failing to hear RA response • It should be noted that the UE can send more preambles than max limit in case of cell reselection during RRC Connection Setup (see next slide)

115 28/10/2015 © Nokia 2014 For internal use

MME Timer Impacting the E-RAB Setup Success Rate

• For E-RAB setup phase the MME typically uses E-RAB setup success supervision timer and this timer could be 1.5s timer which is less our RRC protection timer (2s) shown on the right • This timer discrepancy can cause ERAB setup failures in case of any delays (as shown in the next slides – E-RAB setups) 116 28/10/2015 © Nokia 2014 For internal use

eNB

UE RRC Setup is successfully

rrcConnectionReconfiguration Timer tHalfRrcCon 2000ms starts

rrcConnectionReconfigComplete Timer tHalfRrcCon 2000ms is stopped

RL60 Improvements (RL60 PD3.1 & RL60 1.0 ) RL50 0.2.1 -> RL60 PD3.0

117 28/10/2015 © Nokia 2014 For internal use

RL60 PD3.0 -> RL60 PD3.1

RRC Setup and E-RAB Setup Success Further Improvements

• 3 SW optimizations implemented into RL60 to enhance UL performance in poor RF conditions at cell edge • 1. retxBSR-Timer enhancement • 2. Modification of UL HARQ reTx for high priority SR • 3. Scheduling Request handling enhancement 118 28/10/2015 © Nokia 2014 For internal use

KPI to be Improved

Optimizations

RRC SR

2

ERAB SR

1

1. retxBSR-Timer enhancement

RL50 Scenario

• When UE triggers a RRC connection message, and it is caused by Attach, Tracking Area Update, the RRC connection setup complete message will be much bigger that Service Request • With not big enough first UL grant, UE will segment the RLC SDUThe 1st RLC PDU contains MAC CE BSR but doesn’t set the RLC Poll bit, only the last segment will set the Poll bit • When the Msg5 1st HARQ layer transmission failed, UE will not trigger the RLC retransmission because the Poll bit is not set -

UE

RL50 eNB Cell Search

For Attach, Tracking area update purpose Poll bit is not set

rrcConnectionRequest (mo-Signalling) rrcConnectionSetup

rrcConnectionComplete (1st segment) HARQ retransmission failed

retxBSR -Timer 2560ms starts

Timer tHalfRrcCon 2000ms starts

UE is deleted duo to missing RrcConComplete

eNB doesn’t know what the failed data is, so eNB will not send new UL grant, either

• According to 3GPP UE will trigger “Regular BSR” when retxBSR-timer is expired • The retxBSR-timer is hardcoded to 2560ms in RrcConnSetup message since RL10 SW • To protect unacknowledged RRC message, Nokia eNB has 2 seconds internal timer • 119 So the UE will be2014 released before UE triggers “Regular BSR” 28/10/2015 © Nokia For internal use



retxBSRTimer is hardcoded to 2560ms

1. retxBSR-Timer enhancement • Overview

RL60 Scenario

Cell Search

- Change retxBSR-Timer to always be same as customer parameter “tReTxBsrTime”, i.e. 320ms.

For Attach, Tracking area update purpose

• Gain

- KPI RRC Setup SR will be improved

• Negative Impact - None

rrcConnectionSetup

Timer tHalfRrcCon 2000ms starts Poll bit is no set

rrcConnectionComplete (1st segment) HARQ retransmission failed

retxBSR-Timer 320ms starts

With retxBSR-Timer expiry, UE asks UL resource to set Regular BSR and RLC Poll bit is set rrcConnectionComplete is finally received

120 28/10/2015 © Nokia 2014 For internal use

rrcConnectionRequest (mo-Signalling)

retxBSR-Timer is set to 320ms as “tReTxBsrTime”

- UE will trigger Scheduling Request for sending “Regular BSR”earlier, then eNB will allocate new UL resource

- More UL transmission will happen and RrcConComplete message might be received successfully

RL60 eNB

UE



Scheduling Request and UL retransmission

2. Modification of UL HARQ reTx for high priority SR • According to DRX configuration, eNB will send the DRX parameters in RrcConReconfiguration to UE • After that, eNB will handle both DL and UL considering DRX operation • When UE received DL RrcConReconfiguration, it will send UL RLC Ack and RrcConReconfigComplet to eNB • When the UL channel condition is poor, the eNB might detect the first UL HARQ transmission as DTX • With DRX=On condition, eNB will assume the previous Scheduling Request is a false detection i.e. there is no UE to sending the message in the UL based on DTX detection • So eNB will not grant new UL resource for HARQ retransmission, then the UL message failed 121 28/10/2015 © Nokia 2014 For internal use



RL50 Scenario RL50 eNB

UE

RRC Setup is successfully

rrcConnectionReconfiguration DRX is On

rrcConnectionReconfigComplete Timer tHalfRrcCon 2000ms starts eNB detected DTX for the first UL transmission when DRX=On, so it will not grant new UL grant.

rrcConnectionRelease

Timer tHalfRrcCon is expired, eNB will release this UE

RL60 Scenario

2. Modification of UL HARQ reTx for high priority SR

• Overview - After eNB has sent RrcConReconfiguration, eNB will set the upcoming SR as high priority since eNB knows the UL message should come - For high priority SR the retransmission is allowed even with DRX=On

• Gain - More UL transmission will occur and RrcConReconfigComplete message might be received more often successfully - As a result, KPI E-RAB Setup SR will improved

• Negative Impact - None 122 28/10/2015 © Nokia 2014 For internal use



RL60 eNB

UE RRC Setup is successfully

rrcConnectionReconfiguration DRX is On Timer tHalfRrcCon 2000ms starts

rrcConnectionReconfigComplete

eNB detected DTX for the first UL transmission when DRX=On, but eNB will grant the UL resource for retransmission rrcConnectionReconfigComplete is finally received E_RAB Setup is successfully

3. Scheduling Request handling enhancement • Problem - 1 - During RRC Setup procedure, the DL RrcConSetup is received correctly by UE

- Due to bad UL channel quality, the HARQ ACK on PUCCH is not detected by eNB - RrcConSetup is SRB0 with RLC TM transmission, so there will be no DL RLC retransmission - When UE doesn’t get UL grant for RrcConComplete, UE tries to send Scheduling Request for UL resource - Without the ACK for RrcConSetup, eNB will not setup UL scheduling function for this UE and therefore all the SR is discarded by eNB - RrcConComplete might fail because of this

• Problem - 2 - During Handover procedure, the UL RrcConReconfigComplete message failed with all HARQ retransmission duo to bad UL channel quality - UE tries to ask UL resource via Scheduling Request to retransmit RrcConReconfigComplete - The target eNB didn’t receive the first UL message during HO, so eNB doesn’t react the UE’s SR - The Handover procedure might fail because of this

123 28/10/2015 © Nokia 2014 For internal use



3. Scheduling Request handling enhancement RL50 Scenario – Case 1 RL50 eNB

UE Cell Search

rrcConnectionRequest rrcConnectionSetup ACK is not received by eNB

HARQ layer ACK for rrcConnectionSetup

UE triggers SR to ask UL resource for RrcConComplete retransmission

124 28/10/2015 © Nokia 2014 For internal use

Scheduling Request



All SRs are discarded by eNB, up to parameter “dSrTransMax=64n”

3. Scheduling Request handling enhancement RL50 Scenario – Case 2 RL50 eNB

UE Random Access Procedure in HO

rrcConnectionReconfigComplete and HARQ reTx

UE triggers SR to ask UL resource for rrcConReconfigComplete retransmisson

125 28/10/2015 © Nokia 2014 For internal use

Scheduling Request



First UL message is not received by eNB

All SRs are discarded by eNB, up to parameter “dSrTransMax=64n”

3. Scheduling Request handling enhancement

• Overview - After eNB sent the RrcConSetup, eNB will setup the UL scheduling function for this UE, so the coming SR will be handled correctly

- After eNB starts to schedule the UL resource to 1st UL message in HO, eNB will also handle the coming SR even if 1st UL message failed

• Gain - Higher chance to receive RrcConComplete, thus, KPI RRC Setup SR will improve.

- Higher chance to receive RrcConReconfigComplete , thus, KPI HO SR will improve. - Less Preambles are triggered by exceeding maximum SR transmission, thus, KPI RACH SR will improve.

• Negative Impact - None 126 28/10/2015 © Nokia 2014 For internal use



3. Scheduling Request handling enhancement RL60 Scenario – Case 1 RL60 eNB

UE Cell Search

rrcConnectionRequest rrcConnectionSetup ACK is not received by eNB

HARQ layer ACK for rrcConnectionSetup

UE triggers SR to ask UL resource for RrcConComplete retransmission

Scheduling Request

PDCCH DCI0 UL Grant

RrcConComplete

127 28/10/2015 © Nokia 2014 For internal use



eNB starts to handle the SR even missing ACK for rrcConSetup

3. Scheduling Request handling enhancement RL60 Scenario – Case 2 RL50 eNB

UE Random Access Procedure in HO

rrcConnectionReconfigComplete and HARQ reTx

UE triggers SR to ask UL resource for rrcConReconfigComplete retransmission

Scheduling Request

PDCCH DCI0 UL Grant

rrcConReconfigComplete

128 28/10/2015 © Nokia 2014 For internal use

First UL message is not received by eNB

eNB starts to handle the SR even 1st UL message failed

Field Result with RL60 SW Upgrade Operator A - Field Cluster contains 413 sites. - UL Key improvements are in SW RL60 PD3.1 - KPI is improved clearly when SW is upgraded from RL60 PD3.0 -> RL60 PD3.1 RL50 0.2.1 -> RL60 PD3.0

129 28/10/2015 © Nokia 2014 For internal use



RL60 PD3.0 -> RL60 PD3.1

Sending RRC Connection Release when RRC Setup Complete is Missing • In RL50 when msg5 reception failure occurs the UE thinks it has valid c-RNTI and keeps on sending SRI which are not responded by eNB due to from eNB point of view the c-RNTI is not valid • UE will eventually send SRI using RACH procedure but eNB will not respond to msg4 (as msg3 indicates wrong c-RNTI) • UE will retry PRACH for 10 times until it sends error to NAS and NAS restarts the NAS procedure

UE

PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PHICH:HARQ ACK PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution + RRC Connection Setup PUCCH:HARQ ACK PDCCH:UL Capacity Grant PUSCH/UL-SCH/DCCH/SRB1: RRC Connection Setup Complete PUCCH: Scheduling Request

dSrTransMax = 64 times SR on PUCCH PUSCH/UL-SCH/CCCH : SRI on PRACH i.e. MSG3 = C-RNTI PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH : SRI on PRACH i.e. MSG3 = C-RNTI PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response

130 28/10/2015 © Nokia 2014 For internal use

eNB

Sending RRC Connection Release when RRC Setup Complete is Missing

• RL60 1.0 and RL70 contains correction for the scenario where msg5 is not received properly so that always RRC Release message is sent so that UE can re-initiate the RRC procedure without delay (due to the SRIs and SRI via PRACH decreasing the RACH success rate)

UE

eNB

PUSCH/UL-SCH/CCCH: RRC Connection Request PRACH: RA Preamble PDSCH/DL-SCH/CCCH:RA Response PUSCH/UL-SCH/CCCH/SRB0: RRC Connection Request PHICH:HARQ ACK PDSCH/DL-SCH/CCCH/SRB0 Contention Resolution + RRC Connection Setup PUCCH:HARQ ACK PUCCH: Scheduling Request PDCCH:UL Capacity Grant PUSCH/UL-SCH/DCCH/SRB1: RRC Connection Setup Complete PDSCH/DL-SCH/CCCH/SRB0 RRC Connection Release

MinLifeTimeOfHalfOpenRrcConnection, def . 2000ms (non modifiable) defines the time how long time the BTS keeps resources reserved for the RRC Connection Request (resource reservation is done once RRC Connection Request is reserved) Timer is stopped when RRC Connection Setup Complete is received

131 28/10/2015 © Nokia 2014 For internal use

RACH Success Rate Improvement – M8001C8 Correction in RL60

• Counter M8001C8 RACH setup completions is updated every 160ms however the PM counters counting small, large and dedicated preambles are updated immediately when the event occurs - This can produce a mismatch of the number of preambles and setup completions, resulting in success rates larger than 100%

• Additionally, M8001C8 only updated with "1" even if multiple UEs received a RA response msg in that TTI causing success rate < 100%

• Correction : M8001C8 is updated immediately when the RA response is sent and with the correct number of RA responses sent to the UEs - A general problem is, in case preamble is close to the end of the measurement period, but success is only in next period, this may lead to success rates larger than 100% in a single measurement period but the average over all periods is correct 132 28/10/2015 © Nokia 2014 For internal use

inactivityTimer (min 5s) expiry

Impact of inactivity timer

Data activity

Time

• 5s inactivityTimer was used only for one day on 24th July

Sum of RRC STP ATT Sum of E-UTRAN E-RAB Setup Attempts Sum of Intra HO Att

- #RRC setup attempts increased by ~20%

4000000 3205270

3000000 2000000 1000000

08.04.2014

08.02.2014

07.31.2014

07.29.2014

07.27.2014

07.25.2014

07.23.2014

07.21.2014

07.19.2014

0

07.15.2014

For internal use

5000000

07.13.2014

• inactivityTimer changes do not impact on RRC connected users but increase the RRC setup signaling 133 28/10/2015 © Nokia 2014

6000000

#RRC Attempts

- No clear change in max or average RRC connected users

RRC_Idle

07.17.2014

• In RL60 it is possible to adjust the inactivityTimer down to 5s (RL50 and earlier only 10s possible)

State

RRC_Connected

Impact of inactivity timer

• No changes in PDCCH utilization and performance - More slightly more RRC attempts but there seem to be no increase in PDCCH blocking nor average aggregation level as well as no increase is PDCCH DTX - This suggest that the increased signaling does not cause additional problems for PDCCH capacity

Sum of RRC STP ATT

Sum of E-UTRAN E-RAB Setup Attempts

Sum of Intra HO Att

Sum of Inter X2 based HO Att

6000000

#RRC attempts

5000000

4000000 3000000 2000000 1000000 0

134 28/10/2015 © Nokia 2014 For internal use

3205270

Impact of inactivity timer

• No change in HO attempts (intra or inter eNB) when inactivity timer was modified from 10s to 5s

Sum of E-UTRAN E-RAB Setup Attempts

Sum of Intra HO Att

Sum of Inter X2 based HO Att

6000000

1000000 900000

5000000

800000 700000

4000000

600000 3000000

3205270

500000 400000

2000000

1000000

300000 200000 100000

0 135 28/10/2015 © Nokia 2014 For internal use

0

#HO attempts

#RRC attempts. #ERAB attempts

• RRC and E-RAB setup attempts increase but there is no increase or decrease in intra eNB or inter eNB HOs

Sum of RRC STP ATT

Agenda

• Introduction • RRC Setup Success Rate and CSSR • Handover Success Rate

• Dropped Call Rate • UL Throughput • DL Throughput • PUCCH Power Control • Paging

136 28/10/2015 © Nokia 2014 For internal use

Handover Failures – Intra/Inter BTS HO Failure, Source Cell • From source cell the intra or inter BTS HO failure looks like the UE does not respond to the RRC Connection Reconfiguration message with L2 acknowledgement: - However the 36.331 states following (chapter 5.3.5.4) “The UE should perform the handover as soon as possible following the reception of the RRC message triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this message.”

- Therefore this indication (MaxRlcRetransExceeded) is not 100% accurate indication of DL problems in source cell

137 28/10/2015 © Nokia 2014 For internal use

Handover Failures – Missing Preambles

40.2% of all intra/inter BTS HOs are caused by this problem : HO execution phase

•

From the target cell point of view the intra/inter BTS HO failures look like the BTS never receives the preamble -

This could be caused by some problem with target cell UL •

Aggressive (high SINR window) CLPC tends to increase the inter cell interference faster when traffic increases compared to lower SINR window settings

•

The cell with most failures (no preambles received) is cell 3480 (135516) – 29.8% of all preamble failures

•

The SINR performance is showing a bit more fluctuation cells which can be caused by heavy inter cell interference

138 28/10/2015 © Nokia 2014 compared to the other For internal use

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Missing Preambles • From the target cell point of view the intra/inter BTS HO failures look like the BTS never receives the preamble -

The problem with the fluctuating SINR should be compensated by the preamble power ramping procedure (prachPwrRamp = 2dB and preambTxMax = 10 as usually used) which usually provides enough power ramping (initial power + 10*2dB = initial power + 20dB) • • •

•

-

Identify worst performing adjacency pairs Activate eNB logging for worst cell pairs and analyse the HO failure causes

Worst performing cell (HO execution phase failures) pairs need to be identified based on the statistics New eNB logs analysis should be taken and problem scenarios verified for the worst performing cell pair Inter-cell interference analysis in UL direction should be performed to find out if worst performing (HO performance) cells are part of worst inter cell interference cell pairs Preamble step size could be increased as well but such tuning would require careful inter cell interference re-analysis

type of problem could also be caused by the problem that the UE actually never received the RRC Connection Reconfiguration message from the source cell •

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules

This can be mitigated by increasing the harqMaxTrDl and checking potential “too late” Hos

PDCCH interference can also cause such problem in the source cell No however©this problem 139 28/10/2015 Nokiapotential 2014 Mitigate the problem with parameter tuning : should be relatively rare For internal use preamble power, retransmissions, HO (too late/too •

early HOs) and PDCCH

No

Missing preambles?

See next slide

Yes UL inter-cell interference analysis Problem adjacency pair part of most interfering cell pairs?

No

Yes Mitigate the problem by L1 optimisation on interfering cell

Problem adjacency pair part of most interfering cell pairs?

DL inter-cell interference analysis

Yes Mitigate the problem by L1 optimisation on interfering cell

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Several MSG2 Messages

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules Identify worst performing adjacency pairs Activate eNB logging for worst cell pairs and analyse the HO failure causes

25.6% of all intra/inter BTS HOs are caused by this problem : HO execution phase

• 50 retransmissions of msg2 No Several msg2s? indicate that the BTS receives Yes the preambles but either UE does not receive the msg2 or BTS does not hear the RRC Connection Reconfiguration Complete

all

See next slide

• Scenario is likely as below: - UE hears the RRC Connection Reconfiguration and tries to access the new cell (target cell) by sending RA preamble but UE does not hear the msg2 from target cell and therefore the UE retransmits the preambles continuously 140 28/10/2015 © Nokia 2014 For internal use

- Note that msg2 does not have HARQ -> each (re)transmitted msg2 therefore means that there is corresponding preamble received

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Several MSG2 Messages • The msg2 is indicated to the UE using PDCCH (as in case of RRC Connection Setup case) with fixed PDCCH Aggregation level

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules Identify worst performing adjacency pairs

- pdcchAggRaresp (def 4) Activate eNB logging for worst cell pairs and analyse the HO failure causes

• And msg2 itself is sent with default coding rate (as in case of RRC Connection Setup case)

No Several msg2s?

- maxCrRaDl = 0.12

Yes

• As all the RA responses (msg2) are retransmitted exactly in 20ms intervals, DL should be the problem (as the BTS keeps on transmitting the msg2 but UE keeps on transmitting the preambles)

UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No

Yes

- Decrease maxCrRaDl = 0.12 -> 0.05

Mitigate the problem by L1 optimisation on interfering cell

- Increase pdcchAggRaresp = 4 -> 8 (PDCCH usage needs to be monitored carefully)

Problem adjacency pair part of most interfering cell pairs?

141 28/10/2015 © Nokia 2014 For internal use

See next slide

No Mitigate the problem with parameter tuning : pdcch aggregation level (msg2), maximum codirng rate (msg2), tx power settings

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Several MSG2 Messages • According to 36.213 “…For PUSCH (re)transmissions corresponding to a semi-persistent grant then j=0 , for PUSCH (re)transmissions corresponding to a dynamic scheduled grant then j=1 and for PUSCH (re)transmissions corresponding to the random access response grant then j=2. P0_UE_PUSCH(2) = 0 and P0_NOMINAL_PUSCH(2) = P0_PRE+ ΔPREAMBLE_Msg3, where the parameter PREAMBLE_INITIAL_RECEIVED_TARGET_POWER (P0_PRE= preambleInitialReceivedTargetPower) and ΔPREAMBLE_Msg3 (= DeltaPreambleMsg3) are signalled from higher layers.” • The UE sends the MSG3 and or RRC Connection Reconfiguration Complete with the power given by : PPUSCH i   min PCMAX ,10 logM PUSCH i   PO _ PUSCH  j     j   PL  TF i   f i 

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules Identify worst performing adjacency pairs

Activate eNB logging for worst cell pairs and analyse the HO failure causes

No Several msg2s?

See next slide

Yes UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No

Yes

- f(i) is initialised with value f(0) as:

Mitigate the problem by L1 optimisation on interfering cell

DL inter-cell interference analysis

f (0)  Prampup   msg 2 Problem adjacency pair part of most interfering cell pairs?

142 28/10/2015 © Nokia 2014 For internal use

No Mitigate the problem with parameter tuning : pdcch aggregation level (msg2), maximum codirng rate (msg2), tx power settings

Yes

Mitigate the problem by L1 optimisation on interfering cell

Handover Failures – Several MSG2 Messages

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

- f(i) is initialized with value f(0) as:

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules

f (0)  Prampup   msg 2 •

• •

Where Prampup = the total power ramp-up from the first to the last preamble i.e. the total power ramping until the preamble is acknowledged by the RA response

Identify worst performing adjacency pairs

Activate eNB logging for worst cell pairs and analyse the HO failure causes

msg2 is given by the table below and is given by RA response TPC field according to the ulpcRarespTpc parameter

No Several msg2s?

According to 36.213 the accumulation is always enabled if the TPC command (i.e. msg2) is included in a PDCCH with DCI format 0 where the CRC is scrambled by the Temporary C-RNTI and therefore the f(0) value is taken into account by the UE (eNB always sets TPC command)

- The total power for msg3 is given as :

See next slide

Yes UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No

Yes

  PCMAX ,10 log M PUSCH i   preambleInitialRecei vedTargetP ower   PREAMBLE_Msg3    PPUSCH Msg3  min         j  PL   i  preamble power ramp up     TF Msg 2   TPC Command 0 1 2 3 4 5 6 28/10/2015 7

143 For internal use

©

Value (in dB) -6 -4 -2 0 2 4 6 Nokia 2014 8

Mitigate the problem by L1 optimisation on interfering cell

Problem adjacency pair part of most interfering cell pairs? No Mitigate the problem with parameter tuning : pdcch aggregation level (msg2), maximum codirng rate (msg2), tx power settings

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Several MSG2 Messages • Typical setting for msg2 is 7 (8dB) as given by the table below and is given by RA response TPC field according to the ulpcRarespTpc parameter

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules

• This means that the msg3 or RRC Connection Reconfiguration Complete –message reception should not cause any problems

Activate eNB logging for worst cell pairs and analyse the HO failure causes

• However if UL problems are suspected then msg3/RRC Connection Reconfiguration complete message power should be adjusted with extra care in order to avoid massive inter cell interference TPC Command 0 1 2 3 4 5 6 7

Value (in dB) -6 -4 -2 0 2 4 6 8

No Several msg2s?

See next slide

Yes UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No

Yes Mitigate the problem by L1 optimisation on interfering cell

• The MCS for RRC Connection Reconfiguration Complete is set according to raLargeMcsUl (def. = 5) 144 28/10/2015 © Nokia 2014 For internal use

Identify worst performing adjacency pairs

No Mitigate the problem with parameter tuning : pdcch aggregation level (msg2), maximum codirng rate (msg2), tx power settings

Problem adjacency pair part of most interfering cell pairs?

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Handover Failures – Single MSG2 Messages

Source

• From the target cell point of view the intra BTS HO failure looks like the BTS receives one preamble but after that seems that the target BTS never receives additional preambles

7.7% of all intra/inter BTS HOs are caused by this problem : HO execution phase

Target 145 28/10/2015 © Nokia 2014 For internal use

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Single MSG2 Messages • From the target cell point of view the intra BTS HO failure looks like the UE does not receive the msg2 or the BTS does not receive the RRC Connection Reconfiguration Complete • 36.133 states for non-contention based random access : “The UE may stop monitoring for Random Access Response(s) if the Random Access Response contains a Random Access Preamble identifier corresponding to the transmitted Random Access Preamble.” • This means that in case the UE can receive the msg2 it will stop sending preambles and therefore the unsuccessful reception of RRC connection reconfiguration complete depends on the power settings (calculated as for msg3 as shown in the next slide) for RRC Connection Reconfiguration Complete

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules Identify worst performing adjacency pairs

Activate eNB logging for worst cell pairs and analyse the HO failure causes

No

Single msg2s? Yes UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No Mitigate the problem with parameter tuning : UL tx power for RRC Connection Reconfiguration Complete

No

Yes Mitigate the problem by L1 optimisation on interfering cell

Problem adjacency pair part of most interfering cell pairs?

146 28/10/2015 © Nokia 2014 For internal use

See next slide

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Handover Failures – Single MSG2 Messages

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

- f(i) is initialised with value f(0) as:

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules

f (0)  Prampup   msg 2 •

• •

Where Prampup = the total power ramp-up from the first to the last preamble i.e. the total power ramping until the preamble is acknowledged by the RA response

Identify worst performing adjacency pairs

Activate eNB logging for worst cell pairs and analyse the HO failure causes

msg2 is given by the table below and is given by RA response TPC field according to the ulpcRarespTpc parameter

No Single msg2s?

According to 36.213 the accumulation is always enabled if the TPC command (i.e. msg2) is included in a PDCCH with DCI format 0 where the CRC is scrambled by the Temporary C-RNTI and therefore the f(0) value is taken into account by the UE (eNB always sets TPC command)

Yes UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

• The total power for msg3 is given as :

See next slide

No

Yes

  PCMAX ,10 log M PUSCH i   preambleInitialRecei vedTargetP ower   PREAMBLE_Msg3    PPUSCH Msg3  min         j  PL   i  preamble power ramp up     TF Msg 2   TPC Command 0 1 2 3 4 5 28/10/2015 6 7

147 For internal use

©

Value (in dB) -6 -4 -2 0 2 4 Nokia 2014 6 8

Mitigate the problem by L1 optimisation on interfering cell

Problem adjacency pair part of most interfering cell pairs? No Mitigate the problem with parameter tuning : UL tx power for RRC Connection Reconfiguration Complete

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Intra and inter eNB HO failure analysis per adjacency (M8015C9/M8015C8 = inter eNB HO success rate, M8015C2/M8015C1 = intra eNB HO success rate)

Handover Failures – Single MSG2 Messages - Typical setting for msg2 is 7 (8dB) as given by the table below and is given by RA response TPC field according to the ulpcRarespTpc parameter - This means that the msg3 or RRC Connection Reconfiguration Complete –message reception should not cause any problems

Check configuration of the most problematic cell pairs (source and target cell) : PCI planning rules and PRACH sequence rules

Identify worst performing adjacency pairs

Activate eNB logging for worst cell pairs and analyse the HO failure causes

No Single msg2s?

See next slide

Yes

- However if UL problems are suspected then msg3/RRC Connection Reconfiguration complete message power should be adjusted with extra care in order to avoid massive inter cell interference

UL inter-cell interference analysis

Problem adjacency pair part of most interfering cell pairs?

No

Yes

TPC Command 0 1 2 3 4 5 6 7

Mitigate the problem by L1 optimisation on interfering cell

Value (in dB) -6 -4 -2 0 2 4 6 8

148 28/10/2015 © Nokia 2014 For internal use

Problem adjacency pair part of most interfering cell pairs? No Mitigate the problem with parameter tuning : UL tx power for RRC Connection Reconfiguration Complete

DL inter-cell interference analysis

Yes

Mitigate the problem by L1 optimisation on interfering cell

Handover Failure – Handover Cancel • Almost all HO cancellations occur to cell 3480 (67%) indicating that the problems for cell 3480 in receiving the preambles also causes the UE to attempt HO or reestablishment to another cell • This failure scenario should be improved using the same set of parameters as for missing preamble and msg2 cases 12% of all intra/inter BTS HOs failures are caused by HO cancellation 149 28/10/2015 © Nokia 2014 For internal use

Handover Failure – Normal Release

• The normal releases are caused by the failing HOs which are then reestablished to another cell • This failure scenario should be improved using the same set of parameters as for missing preamble and msg2 cases

150 28/10/2015 © Nokia 2014 For internal use

12.8% of all intra/inter BTS HOs failures are caused by Normal Release

RL60/RL70 Improvement for HO robustness

151 28/10/2015 © Nokia 2014 For internal use

Background • Current Design: • UL Scheduler assigns UL grant MCS/PRBs (i.e. the TBS) for both contention-based and contentionfree RACH scenarios • The UL TBS used in contention-free RACH scenario* (e.g. HO) for MSG-3 is controlled by raLargeVolUl which is part of vendor file and is not operator configurable * Excluding PDCCH Order scenario • Current setting results in MCS-5**, 8 PRBs, for 680 bit actual TBS assignment for RACH MSG-3)

• Three Background Factors (Motivating a Change to Current Design):

** Assumes raLargeMcsUl =5 (per GMC)

• Handover KPI Improvement – if the UL TBS associated with MSG-3 can be made more reliable, Handover Robustness will be improved • VoLTE Robustness – contention-free RACH is used for intra-cell HO for enabling/disabling TTI-B.

Lab tests under new Impaired RF conditions (edge of cell, fading) show that this HO often fails and is currently the “weak-link” in VoLTE robustness

• SoftBank Competitive Assessment – data collected as part of SoftBank performance / Quality initiative shows that E// HO is significantly more reliable than current Nokia HO performance 152 28/10/2015 © Nokia 2014 For internal use

Proposal (Short-Term) • Short Term Proposal: (LTERLCR-4031 ) • Introduce new R&D parameters for the UL grant used for contention-free RACH (HO) scenarios* to use MCS-5, 2 PRBs (144 bits), instead of current MCS-5, 8-PRBs (680 bits)

* Excluding PDCCH Order scenario

• As in current design, this means it cannot be changed by the operator (R&D parameters)

• NOTE: No change is being made to the UL grant sizes used for contention-based RACH (i.e. Group A / Group B), via raSmallVolUl (operator configurable) and raLargeVolUl (vendor file, not operator configurable)

• Rationale: • Due to using R&D parameters, enhancement can be made fairly quickly (no new feature needed) • 144 bit UL grant is sufficient to transmit RRC Reconfiguration Complete + Long BSR + PHR in single TTI (whereas 680 bits results in many pad bytes**, or additional data, to be sent along with above) • 6 dB Improvement in HO robustness (use of 2 PRBs, instead of 8 PRBs, @ MCS-5) • Closes Competitive Gap with Ericsson (in fact, exceeds E// performance) • E// uses 72 bit TBS, which results in BSR + PHR + part of RRC Reconfiguration Complete message sent in initial UL grant for MSG-3 • eNB must assign additional TBS (generally more than 72 bits) to transport rest of RRC Reconfiguration Complete message • This results in additional delay for E// compared to above Nokia proposal 153 28/10/2015 © Nokia 2014 For internal use

** Large majority of HO in field occur when UE does NOT have data to immediately send

Longer-Term Proposal • Long Term Proposal: • Use existing parameters (raSmallVolUl ) to control when UE uses Group A / Group B preambles • Introduce new O&M parameters as needed to explicitly and separately control the UL MCS / PRBs used for the following scenarios: • Contention-based RACH Group A • Contention-based RACH Group B • Contention-free RACH (possibly further separate out intra-cell (e.g. TTI-B) vs. other HO scenarios)

• Rationale: • Maintain existing Group A / Group B contention-based RACH functionality and differentiation • Allow full control and optimization of reliability vs. “throughput” for each RACH scenario separately

154 28/10/2015 © Nokia 2014 For internal use

CT Feedback • Customer-Team Feedback was Requested and Received • Positive Benefits: • Improvement in reliability of MSG-3 during Handover • Improved robustness for TTI-B transitions / VoLTE • Close competitive gap with Ericsson on HO robustness

• Considerations: • 144 bits as proposed is sufficient for Long BSR + PHR + RRC Reconfiguration Complete • Change will be hardcoded and cannot be “undone” by operator (but currently TBS cannot be changed either as part of vendor file) • In good RF conditions, where robustness is not a concern, if the UE has data to send** it will have to wait until UL grant in response to BSR before this user data can be sent (instead of including some of it in the 680 bit current initial “MSG-3” TBS) • NOTE: since MCS-5 will continue to be used, this change will not impact the ability to “ramp up” the throughput after MSG-3

155 28/10/2015 © Nokia 2014 For internal use

** Large majority of actual HO in field today occur when UE does NOT have data to immediately send

KPI Measurement • Improvement in HO Success Rate KPIs is fully expected with this change: HO success KPI is defined as: 100*sum([M8009C7]) / sum([M8009C6]) which is 100*sum([SUCC_INTRA_ENB_HO]) / sum([ATT_INTRA_ENB_HO]) •

M8009C7 counter is updated when: The reception of an internal UE Context Release Request for the handover on the source side. Updated to the source cell.

•

This only occurs when the RRC Reconfiguration Complete message is received on the target cell: TF_LTE_SFS_MM.540 Release Radio resources in the source cell After reception of the RRC CONNECTION RECONFIGURATION COMPLETE message (according to MM.539) the eNB shall release any radio resources associated with the UE in the source cell. Req ID : TF_LTE_SFS_MM.647 Guarding timer for total length of handover. Once the handover has been initiated, the eNB shall set the guarding timer THOoverall which guards the total length of the handover. THOoverall shall be configurable by vendor. Note: The timer shall be reset when the RRC: RRC CONNECTION RECONFIGURATION COMPLETE message is received from the UE or handover preparation fails (see MM.539-Receiving RRC: RRC CONNECTION RECONFIGURATION COMPLETE message and section 5.3.3.5 for failure case). If the guarding timer THOoverall expires, see MM.989

•

THOOverall is stopped when either RRCConnReconfigComplete is received or when the intra eNodeb Handover is aborted for any reason. It will not be stopped by receipt of any UL data (Juergen Mayer)

156 28/10/2015 © Nokia 2014 For internal use

Solution Validation • Knife has been provided by development to allow testing the changed TBS size for MSG3 • Knife has been tested in SyVe AH RFPERF lab

• Test scenario: • Impaired / degraded RF conditions • EPA5 fading, very low SINR / edge of cell conditions • Representative of field environments such as SoftBank rural / suburban markets

• VoLTE traffic • TTI-B feature enabled • Test case executed many transitions into and out of TTI-B, all of which require an intra-cell HO involving non-contention RACH and MSG3 reception

• Objectives: • Verify correct and appropriate TBS sizes • Verify performance improvement 157 28/10/2015 © Nokia 2014 For internal use

TBS Size Verification • Objective: Verify (via knife) that UL grant sizes for MSG3 are as expected / correct • Result: TBS sizes are as expected. Note that variation can occur on HARQ retransmissions which are subject to change from normal uplink link adaptation. Baseline SW (RL60)

Knife_1stUlTransmSize_2_LN60_ENB_1311_615_00

TTI-B Deactivation (normal MSG3):

TTI-B Deactivation (normal MSG3):

TTI-B Activation (MSG3 is TTI Bundled):

TTI-B Activation (MSG3 is TTI Bundled):

• MCS-5, 8 PRBs, TBS of 85 bytes, being used for first transmissions (and most HARQ retx) • MCS-0, 5 PRBs, TBS of 15 bytes, sometimes used for HARQ retransmissions of MSG3 (per link adaptation)

• 3 PRBs always used • MCS-12, TBS of 73 bytes, nominally used (occasional use of lower MCS for HARQ retx of MSG3)

158 28/10/2015 © Nokia 2014 For internal use

• MCS-5, 2 PRBs, TBS of 18 bytes, being used for first transmissions (and most HARQ retx) • MCS-0, 5 PRBs, TBS of 15 bytes, sometimes used for HARQ retransmissions of MSG3 (per link adaptation)

• MCS-2, 3 PRBs, TBS of 18 bytes, being used for all first transmissions (higher MCS/TBS sometimes used for HARQ retx per link adaptation)

MSG3 Size Verification • Objective: Verify (via knife) that UL grant sizes for MSG3 are sufficient/appropriate • Result: RRC Reconfiguration Complete + Long BSR + PHR (+pad) fits in new MSG3 grant Example: Baseline SW, RRC Reconfiguration Complete sent via 9 byte RLC-AM PDU which fails initial transmission due to large TBS. RLC-AM retransmission eventually succeeds (using 15 byte TBS), and RLC-AM acknowledged 131 TTIs later. RLC (UE Log)

MAC

Example: with KNIFE, RRC Reconfiguration Complete sent via 9 byte RLC-AM PDU, along with BSR , PHR, and 2 bytes of MAC PAD, and succeeds on initial transmission (using 18 byte TBS). Immediately RLC-AM acknowledged (14 TTIs later) RLC (UE Log)

MAC

18 bytes is sufficient 159 28/10/2015 © Nokia 2014 For internal use

Performance Verification • Objective: Verify (via knife) that MSG3 robustness is substantially improved with solution • Result: Very significant measured improvement in MSG3 robustness and resulting HO speed, as expected, in impaired RF conditions NOTE: TTI-B deactivate (“Out”) case is also fully representative of normal inter-cell HO (MSG3 sent without TTIB in both cases)

MSG3 HARQ Statistics:

• Large reduction in DTX rates with knife as expected (2 vs. 8 PRBs granted) • Large improvement in First HARQ success rates as expected (more robust TBS) • Large reduction in overall MSG3 failure rate (where all HARQ attempts fail, and thus MSG3 fails) • SUMMARY: Faster and more reliable/robust Handovers with solution/knife, as expected

KPI FIRST HARQ SUCCESS RATE (TTI-B Deactivate) FIRST HARQ SUCCESS RATE (TTI-B Activate) MSG3 FAILURE RATE (TTI-B Deactivate) MSG3 FAILURE RATE (TTI-B Activate) 160 28/10/2015 © Nokia 2014 For internal use

BASELINE 12% 51% 31% 10%

KNIFE 84% 91% 10% 0%

Total counts shown in Table: MSG3 HARQ STATISTICS - IMPAIRED (EPA5) RF, EDGE OF CELL SINR CONDITIONS -- BASELINE --- MSG3 ROBUSTNESS KNIFE --

NewTx ReTx: 1 ReTx: 2 ReTx: 3 ReTx: 4

Handover Out of TTI-B ACK NACK 7 46 12 34 10 20 7 16 9 11

DTX 5 4 9 7 7

NewTx ReTx: 1 ReTx: 2

Handover Into TTI-B ACK NACK 30 26 17 9 6 4

DTX 3 3 2

NewTx ReTx: 1 ReTx: 2 ReTx: 3 ReTx: 4

NewTx ReTx: 1 ReTx: 2

Handover Out of TTI-B ACK NACK 49 8 6 2 1 1 2 Handover Into TTI-B ACK NACK 52 4 4 1

DTX 1 1 3 1 6 DTX 1 1

Intra eNB Handover – Timer U E

• THOoverall = T304 + T311 + T301 + THOoverallD

eN B 1 . R R C C o n n e c tio n R e c o n fig u r a tio n (M e a s u re m e n t C o n tro l)

Legend

P a c k e t d a ta

L 3 s ig n a llin g

- Where

L 1 /L 2 s ig n a llin g U L a llo c a tio n

•

T304 supervises the successful completion of a handover or cell change given by t304IntraLte parameter, def 1000ms

•

T311 is the RRC re-establishment supervision timer in UE (the maximum value 30000ms) def 3s

•

Timer T301 supervises the RRC connection reestablishment procedure

3 . H O D e c is io n

THOoverall T

4 . A d m is s io n C o n tr o l a n d R e s o u r c e A llo c a tio n D L a llo c a tio n

D e ta c h fr o m o ld c e ll a n d s y n c h r o n is e to n e w c e ll 6 . S y n c h r o n is a tio n 7 . U L a llo c a tio n + T A fo r U E 8 . R R C C o n n e c tio n R e c o n fig u r a tio n C o m p le te

9 . R e le a s e R e s o u rc e s P a c k e t d a ta

H andoverC om pletion

H andoverE xecution

5 . R R C C o n n e c tio n R e c o n fig u r a tio n

H O o v e r a ll

H andoverP reparation

2 . M e a s u re m e n t R e p o rts

Handover Handover CompletionHandover Preparation Execution

U s e r D a ta

•

-

Start: Transmission of RRCConnectionReestabilshmentRequest

-

Stop: Reception of RRCConnectionReestablishment or RRCConnectionReestablishmentReject message as well as when the selected cell becomes unsuitable

-

At expiry: Go to RRC_IDLE

-

Def. 200ms

THOoverallD Covers the estimated time taken to send an RRC:CONNECTION RECONFIGURATION message to the UE -

161 28/10/2015 © Nokia 2014 For internal use

Hard coded to 20ms

Intra eNB Handover – Timer U E

eN B 1 . R R C C o n n e c tio n R e c o n fig u r a tio n (M e a s u re m e n t C o n tro l)

Legend

P a c k e t d a ta

L 3 s ig n a llin g

- If an dedicated RACH preamble was assigned the eNB starts TRACH_Preamble_Reservation in parallel to THOoverall •

To prevent the eNB re-allocating the dedicated preamble which a UE is currently using, this timer is det longer than T304

•

It is assumed that a guarding time of 10ms is sufficient to consider processing in eNB and in UE before T304 can be started by UE

•

The timer is reset when the RRC: RRC CONNECTION RECONFIGURATION COMPLETE message is received from the UE or handover preparation fails

•

If the guarding timer TRACH_Preamble_Reservation expires, the dedicated preamble is free for reuse

L 1 /L 2 s ig n a llin g U L a llo c a tio n

THOoverall T

4 . A d m is s io n C o n tr o l a n d R e s o u r c e A llo c a tio n D L a llo c a tio n

D e ta c h fr o m o ld c e ll a n d s y n c h r o n is e to n e w c e ll 6 . S y n c h r o n is a tio n 7 . U L a llo c a tio n + T A fo r U E 8 . R R C C o n n e c tio n R e c o n fig u r a tio n C o m p le te

9 . R e le a s e R e s o u rc e s P a c k e t d a ta

162 28/10/2015 © Nokia 2014 For internal use

H andoverC om pletion

H andoverE xecution

5 . R R C C o n n e c tio n R e c o n fig u r a tio n

H O o v e r a ll

H andoverP reparation

3 . H O D e c is io n

Handover Handover CompletionHandover Preparation Execution

U s e r D a ta 2 . M e a s u re m e n t R e p o rts

- TRACH_Preamble_Reservation= T304 + T301 + THOoverallD •

where: -

T304 def. 1000ms

-

T301 def. 200ms

-

THOoverallD hard coded to 20ms

X2 Handover - Timers Source eNB

UE

TX2RELOCOverall

Serving GW

MME 0 . Area Restriction Provided

1 . RRC Connection Reconfiguration ( Measurement Configuration

)

Packet data

Packet data

UL allocation

Legend

2 . Measurement Reports

L 3

signalling

L 1 /L 2

3. HO Decision

5. Admission control and resource allocation 6 . Handover Request Acknowledge

DL allocation

signalling

User Data

4 . Handover Request

TX2RELOCprep

Handover Preparation

Problem in the HO execution phase i.e. TX2RELOCOverall expires before UE responds to the msg2 in source BTS

Target eNB

TX2RELOCexec Problem in the HO execution phase i.e. TX2RELOCexec expires before UE responds to the msg2 in target BTS

8 . SN Status Transfer Data Forwarding

Buffer packets from source eNB

9 . Synchronisation 10 11 12

12

. UL allocation

+

TA for UE

. RRC Connection Reconfiguration Complete

a . RRC Connection Reconfiguration

( Measurement Configuration

)

TX2RELOCcomp

b . RRC Connection Reconfiguration Complete

13

TRRCGuardTimerRadioBearerManagement

. Path Switch Request

14

=2000ms

. User Plane Update Request

End Marker

15. Switch DL path

Packet data 17

TDATAfwdS1

18

TDATAfwdX2

. UE Context Release

, Release S1, X2 signaling and radio resources. Continue forwarding packets

16

. Path Switch Request Acknowledge

Release X2 signaling connection

Data Forwarding End Marker

163 28/10/2015 © Nokia 2014 For internal use

19. Release remaining resources Packet data

Begin Sending S1-U data Release other X2 resources

Packet data

. User Plane Update Response

Handover Completion

Deliver buffered and in transit packets to target eNB

Detach from old cell

Handover Execution

7 . RRC Connection Reconfiguration

X2 Handover Overall •

•

Timer TX2RELOCoverall is the supervision timer for the whole X2 based HO supervision -

Started when X2AP : Handover Request Acknowledge –message is received from the target BTS

-

Stopped when X2AP : UE Context Release is received from the target BTS

Timer TX2RELOCoverall is set according to -

TX2RELOCoverall = T304 + T311 + T301 + TX2RELOCoverallDelta

-

where: •

T304 supervises the successful completion of a handover or cell change given by t304IntraLte parameter, def 1000ms (the value set in the target eNB)

•

T311 is the RRC re-establishment supervision timer in UE (the maximum value 30000ms) def 3s given in SIB2

•

-

Started Upon initiating the RRC connection re-establishment procedure

-

Selection of a suitable E-UTRA cell or a cell using another RAT

-

In case of expiry and no suitable cell found then enter RRC_IDLE

Timer T301 supervises the RRC connection reestablishment procedure -

Start: Transmission of RRCConnectionReestabilshmentRequest

-

Stop: Reception of RRCConnectionReestablishment or RRCConnectionReestablishmentReject message as well as when the selected cell becomes unsuitable

-

At expiry: Go to RRC_IDLE

-

Def. 200ms

164 28/10/2015 © Nokia 2014 For internal use

X2 Handover Overall - Timer TX2RELOCoverall is the supervision timer for the whole X2 based HO supervision

• Started when X2AP : Handover Request Acknowledge –message is received from the target BTS • Stopped when X2AP : UE Context Release is received from the target BTS - Timer TX2RELOCoverall is set according to • TX2RELOCoverall = T304 + T311 + T301 + TX2RelODelta • where: - TX2RelODelta hard coded to 150ms used as the estimated time taken to send the RRC: RRC CONNECTION RECONFIGURATION message to the UE plus the time taken for the UE to generate and send an RRC message in the target cell and for the target eNB to send an S1AP message to the MME (i.e. start the Path Switch procedure)

165 28/10/2015 © Nokia 2014 For internal use

X2 Handover Preparation • The source eNB generates an Old eNB UE X2AP ID so as to uniquely identify the UE over the X2 interface

- This identifier is stored and used in all messages over the X2 interface which involves the UE - The procedure for establishing a signalling connection over the X2 interface is similar to the procedure used for establishing a signalling connection over the S1 interface

• The X2 signalling connection is established between the source and target eNBs when the target eNB generates a New eNB UE X2AP ID and this is communicated to the source eNB in an X2AP: HANDOVER REQUEST ACKNOWLEDGE message Source eNB

TX2RELOCprep

TX2RELOCoverall

Target eNB

X2AP: Handover Request X2AP: Handover Request Acknowledge

166 28/10/2015 © Nokia 2014 For internal use

X2 Handover Preparation • When the decision has been made to handover the UE to another eNB, the source eNB sends an X2AP: HANDOVER REQUEST message to the target eNB over the X2 interface • Once the X2AP: HANDOVER REQUEST message has been sent to the target eNB, guarding timer TX2RELOCprep is started to guard the handover preparation phase -

Upon reception of the X2AP: HANDOVER REQUEST ACKNOWLEDGE message, guard timer TX2RELOCprep is stopped

UE

Source eNB

Target eNB

X2AP : Handover Request Admission Control and Resource Allocations

TX 2 RELOCprep

X2AP : Handover Request Acknowledge RRC: RRC Connection Reconfiguration Detach from Old Cell

Deliver Buffered and in Transit Packets to Target eNB

TX 2 RELOCexec

X2AP : SM Status Transfer Data Forwarding

Synchronization

Buffer Packets from Source eNB

UL Allocation + TA for UE

167 28/10/2015 © Nokia 2014 RRC: For internal useRRC Connection Reconfiguration Complete

- When resources have been successfully prepared in the target eNB, an X2AP: HANDOVER REQUEST ACKNOWLEDGE message is sent by the target eNB - If this message has been received by the source eNB in response to an X2AP: HANDOVER REQUEST message, the handover procedure continues - Note: If an error occurs while receiving this message, the message ignored and the expiry of timer TX2RELOCprep cancels the handover

X2 Handover Preparation • When the decision has been made to handover the UE to another eNB, the source eNB sends an X2AP: HANDOVER REQUEST message to the target eNB over the X2 interface • Once the X2AP: HANDOVER REQUEST message has been sent to the target eNB, guarding timer TX2RELOCprep is started to guard the handover preparation phase -

Hard Coded to 500ms

UE

Source eNB

Target eNB

X2AP : Handover Request

TX 2 RELOCprep

Admission Control and Resource Allocations X2AP : Handover Request Acknowledge

RRC: RRC Connection Reconfiguration Deliver Buffered and in Detach from Transit Packets to Target Old Cell eNB X2AP : SM Status Transfer

TX 2 RELOCexec

Data Forwarding

Synchronization

Buffer Packets from Source eNB UL Allocation + TA for UE

168 28/10/2015 © Nokia 2014 RRC: For internal useRRC Connection Reconfiguration Complete

- Following the handover request from higher layers, the MAC in the target eNB (in the target cell) needs to allocate a CRNTI which is signaled to the UE as part of the handover command message by the source eNB (inside the RRC container) • The UE will use this C-RNTI during noncontention or contention based access in the target cell

- Handover failure will be indicated from higher layers such that the allocated CRNTI can be released

X2 Handover Preparation & Execution • When the X2AP: HANDOVER REQUEST ACKNOWLEDGE message has been sent to the source eNB, timer TX2RELOCexec, which guards the handover execution phase of the procedure from the target eNBs point of view is started Timer is stopped in target eNB in case it receives RRC Connection Reconfiguration Complete message

-

• Timer TX2RELOCexec is set to the following value: TX2RELOCexec = T304 + T311 + TX2RELOCexecDelta

UE

Source eNB

Target eNB

X2AP : Handover Request Admission Control and Resource Allocations

TX 2 RELOCprep

X2AP : Handover Request Acknowledge RRC: RRC Connection Reconfiguration Detach from Old Cell

Deliver Buffered and in Transit Packets to Target eNB X2AP : SM Status Transfer Data Forwarding Buffer Packets from Source eNB Synchronization

UL Allocation + TA for UE 169 28/10/2015 © Nokia 2014 RRC:use RRC Connection Reconfiguration Complete For internal

• where: • T304 supervises the successful completion of a handover or cell change given by t304IntraLte parameter, def 1000ms (the value set in the target eNB) • T311 is the RRC re-establishment supervision timer in UE (the maximum value 30000ms) def 3s • TX2RELOCexecDelta is the estimated time taken from sending the X2AP: HANDOVER REQUEST ACKNOWLEDGE message to the UE starting timer TX 2 RELOCexec T304, plus the time taken for the UE to generate and send an RRC message in the target cell (hard coded 70ms)

X2 Handover Preparation & Execution • When the X2AP: HANDOVER REQUEST ACKNOWLEDGE message has been sent to the source eNB, timer TX2RELOCexec, which guards the handover execution phase of the procedure from the target eNBs point of view is started -

Timer is stopped in target eNB in case it receives RRC Connection Reconfiguration Complete message

• Timer TX2RELOCexec is set to the following value: -

TX2RELOCexec = T304 + T311 + TX2RELOCexecDelta

UE

Source eNB

Target eNB

X2AP : Handover Request

When receiving the RRC Connection Reconfiguration message the UE starts T304 (delivered to UE in mobilityControlInfo IE)

TX 2 RELOCprep

Admission Control and Resource Allocations X2AP : Handover Request Acknowledge

RRC: RRC Connection Reconfiguration Deliver Buffered and in Detach from Transit Packets to Target Old Cell eNB X2AP : SM Status Transfer

TX 2 RELOCexec

Data Forwarding

Synchronization 170 28/10/2015 © Nokia 2014 For internal use

Buffer Packets from Source eNB UL Allocation + TA for UE

RRC: RRC Connection Reconfiguration Complete

X2 Handover Preparation & Execution UE DL-DCCH-Message : { message c1 : rrcConnectionReconfiguration : { rrc-TransactionIdentifier 1, criticalExtensions c1 : rrcConnectionReconfiguration-r8 : { mobilityControlInfo { targetPhysCellId 136, t304 ms1000, newUE-Identity '10110000 11101111'B, radioResourceConfigCommon { rach-ConfigCommon { preambleInfo { numberOfRA-Preambles n40, preamblesGroupAConfig { sizeOfRA-PreamblesGroupA n32, messageSizeGroupA b144, messagePowerOffsetGroupB dB10 } }, powerRampingParameters { powerRampingStep dB2, preambleInitialReceivedTargetPower dBm-104}, ra-SupervisionInfo { preambleTransMax n10, ra-ResponseWindowSize sf7, mac-ContentionResolutionTimer sf32 }, maxHARQ-Msg3Tx 3 }, prach-Config { rootSequenceIndex 760, prach-ConfigInfo { prach-ConfigIndex 3, highSpeedFlag FALSE, zeroCorrelationZoneConfig 12, prach-FreqOffset 3 } }, pusch-ConfigCommon { pusch-ConfigBasic { n-SB 1, hoppingMode interSubFrame, pusch-HoppingOffset 4, enable64QAM FALSE },

171 28/10/2015 © Nokia 2014 For internal use

Source eNB

Target eNB

X2AP : Handover Request TX 2 RELOCprep

Admission Control and Resource Allocations X2AP : Handover Request Acknowledge

RRC: RRC Connection Reconfiguration Deliver Buffered and in Detach from Transit Packets to Target Old Cell eNB X2AP : SM Status Transfer

TX 2 RELOCexec

Data Forwarding

Synchronization

Buffer Packets from Source eNB UL Allocation + TA for UE

RRC: RRC Connection Reconfiguration Complete DL-DCCH-Message : { message c1 : rrcConnectionReconfiguration : { ul-ReferenceSignalsPUSCH { groupHoppingEnabled FALSE, groupAssignmentPUSCH 1, sequenceHoppingEnabled FALSE, cyclicShift 0 } }, p-Max 23, ul-CyclicPrefixLength len1 }, rach-ConfigDedicated { ra-PreambleIndex 41, ra-PRACH-MaskIndex 0 } },

DL-DCCH-Message : { message c1 : rrcConnectionReconfiguration : { radioResourceConfigDedicated { physicalConfigDedicated { pucch-ConfigDedicated { ackNackRepetition release : NULL }, cqi-ReportConfig { cqi-ReportModeAperiodic rm30, nomPDSCH-RS-EPRE-Offset 0, cqi-ReportPeriodic setup : { cqi-PUCCH-ResourceIndex 9, cqi-pmi-ConfigIndex 19, cqi-FormatIndicatorPeriodic widebandCQI : NULL, ri-ConfigIndex 161,

X2 Handover Preparation & Execution •

The dedicated preamble can be reused when MAC is informed by higher layers that the handover is successful (when RRC Connection Reconfiguration Complete is received) or has failed (when TX2RELOCEXEC expires)or is aborted

•

If timer TX2RELOCexec expires, the target eNB starts timer TRELOCreestablish which is the timer to wait the RRC ReEstablishment procedure completion -

TRELOCreestablish = T311* •

•

where T311* is the value used for T311 in the source cell -

is received by the target eNB in the RRC Context Container within the X2AP: HANDOVER REQUEST message

-

If the X2AP: HANDOVER REQUEST message does not contain any AS configuration information, the value used for T311 in the target cell shall be used although this may not be the same value as that used by the UE in the source cell

This timer is used to allow the UE to access the cell using the RRC Re-Establishment procedure in case the HO fails -

Upon expiry of the timer the UE's context is to be removed since it's not expected that the UE will access the cell after this time due to T311 expiry at the UE

Source eNB

Target eNB Data Forwarding TX2RELOCexec TRELOCreestablishment

172 28/10/2015 © Nokia 2014 For internal use

Release Dedicated Preamble

X2 Handover Preparation & Execution • If timer TX2RELOCexec expires, the identities generated for the UE to use to perform access to the target cell (i.e. C-RNTI, dedicated preamble) are released for use by another UE - These are the only resources which are released here since the UE will not use its dedicated preamble (if it was assigned one) after T304 in the UE expires

- Other resources in the target eNB are released after expiry of TRELOCreestablish

• If timer TRELOCreestablish expires, the target eNB releases its resources and clear any buffered forwarded data received from the source eNB Source eNB

Target eNB Data Forwarding TRELOCreestablishment

Release Resources

173 28/10/2015 © Nokia 2014 For internal use

X2 Handover Preparation & Execution • The RRC Connection Reconfiguration message after successful RRC Connection Reconfiguration Complete for the HO is used to setup the measurements from the new source cell • For this message CSI (CQI) report is needed and according to 36.213 - “In non-contention based random access procedure, the CQI request field is interpreted to determine whether an aperiodic CQI, PMI, and RI report is included in the corresponding PUSCH transmission according to section 7.2.1. In contention based random access procedure, the CQI request field is reserved.” - The aperiodic CSI report is requested by the RA response UL grant and based on that the PRB allocation can be done for the DL allocations for the consecutive allocations

174 28/10/2015 © Nokia 2014 For internal use

Agenda • Introduction • RRC Setup Success Rate and CSSR

• Handover Success Rate • Dropped Call Rate • UL Throughput

• DL Throughput • PUCCH Power Control • Paging

175 28/10/2015 © Nokia 2014 For internal use

Dropped Call Rate vs. DTX Ratio

• There is a direct correlation between dropped call rate and DTX ratio (PDCCH allocation done and DCI sent but no response in terms of ACK/NACK or PUSCH transmission) • This means that with decreased dropped call rate also the PDCCH utilisation can be decreased 176 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE • When UE is in RRC_CONNECTED and RRC security is active, it can trigger RRC Connection Re-establishment - upon T310 expiry (radio link failure) - upon reaching the maximum number of UL RLC retransmissions

- upon handover failure (T304 expiry) - upon non-HO related random access problem (problem indication from MAC while neither T300, T301, T304 nor T311 is running)

• If successful, RRC Conn Re-Establishment - reconfigures SRB1 to resume data transfer of RRC msgs - re-activates RRC security without changing algorithms

• NOTE: if UE is in RRC_CONNECTED while RRC security is not active, UE goes to RRC_IDLE, performs cell reselection and TAU 177 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE/RLF • Radio link failure handling in the LTE UE consists of radio link problem detection and actions taken if problem continues and results in loss of radio link

• This is based on the concept specified in [36.300] and [36.331] - When a radio link problem is detected, UE starts a timer (T1 as specified in [36.300], T310 in [36.331]) - If the radio link problem is fully recovered while the timer is running, normal operation can be continued, as if no radio problem occurred - If radio link problem continues and T1 timer expires, the UE will start another timer (T2 as specified in [36.300], T311 in [36.331]) - While this timer is running, the UE can request RRC connection re-establishment UE detects 1st out of sync

T310 expires RLF occurs -> UE tx turned off in 40ms RRC re-establishment starts T311 starts UE searches for the best cell

UE selects the target cell

UE acquires UE grant UE sends RRC connection re-estab request message, stops T311 and starts T301

Time UE detects up to n310 (n6,n10) -> UE starts time T310 = 6,5,4 (2000ms, 1000ms, 500ms) in case T300, T301, T304 nor T311 is 178running 28/10/2015 © Nokia 2014 For internal use

RLF timer T310 running

RRC re-establishment timer T311 = 1,2,3 (3000ms, 5000ms, 10000ms) running

In the netwrork = T311 + 200ms

UE acquired SI of traget cell UE sends RACH to target cell

Radio Link Failure Detection – UE/RLF UE detects 1st out of sync Normal Operation

UE detects up to n310 (n6,n10) -> UE starts time T310 = 6,5,4 (2000ms, 1000ms, 500ms) in case T300, T301, T304 nor T311 is running

Upon receiving n311=0,1,2 (1,2,3) consecutive "in-sync" indications from lower layers while T310 is running, the UE shall stop timer T310;

In this case, the UE resumes the RRC connection without explicit signalling, i.e. the UE resumes the entire radio resource configuration. Periods in time where neither "in-sync" nor "outof-sync" is reported by layer 1 do not affect the evaluation of the number of consecutive "in-sync" or "out-of-sync" indications.

• Normal Operation - UE not waiting for RRC Connection Setup/Reject (T300 not running) - UE not waiting for RRC Re-establishment Establishment/Reject (T301 not running) - handover not ongoing (T304 not running)

- No RLF recovery ongoing (T311 not running)

179 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE/RLF • The UE’s estimation of the downlink radio link quality is compared with out-of-sync and insync thresholds, Q and Q , for the purpose of radio link monitoring out

in

• These thresholds are expressed in terms of the BLock Error Rate (BLER) of a hypothetical Physical Downlink Control Channel (PDCCH) transmission from the serving cell (according to 36.133) - Q corresponds to a 10% BLER while out

- Q corresponds to a 2%BLER in

• The same threshold levels are applicable with and without DRX Attribute DCI format Number of control OFDM symbols

• Without DRX: - When no DRX is configured, out-of-sync downlink radio link quality estimated over the last 200 ms period becomes worse than the threshold Q out

• PDCCH/PCFICH transmission parameters shown in table on the right

180 28/10/2015 © Nokia 2014 For internal use

Aggregation level (CCE) Ratio of PDCCH RE energy to average RS RE energy

Value 1A [2]; Bandwidth  [10] MHz [3]; [3] MHz  Bandwidth  [5] MHz [4]; Bandwidth = [1.4] MHz 4; Bandwidth = [1.4] MHz 8; Bandwidth  [3] MHz [4] dB; when single antenna port is used for cell-specific reference signal transmission by the serving cell

occurs when the

[1] dB: when two or four antenna ports are used for cellspecific reference signal transmission by the serving cell Ratio of PCFICH RE energy to average RS RE energy

[4] dB; when single antenna port is used for cell-specific reference signal transmission by the serving cell

for out-of-sync

[1] dB: when two or four antenna ports are used for cellspecific reference signal transmission by the serving cell Note 1: DCI format 1A is defined in section 5.3.3.1.3 in 3GPP TS 36.212 [21]. Note 2: A hypothetical PCFICH transmission corresponding to the number of control symbols shall be assumed.

Radio Link Failure Detection – UE/RLF • Without DRX: - Similarly without DRX the in-sync occurs when the downlink radio link quality estimated over the last 100 ms period becomes better than the threshold Q in

•

See PDCCH/PCFICH transmission parameters for in-sync below Value 1C [2]; Bandwidth  [10] MHz [3]; [3] MHz  Bandwidth  [5] MHz [4]; Bandwidth = [1.4] MHz Aggregation level (CCE) 4 [0] dB; when single antenna port is used for cell-specific reference signal transmission by the serving cell Ratio of PDCCH RE energy to average RS RE energy [-3] dB; when two or four antenna ports are used for cell-specific reference signal transmission by the serving cell [4] dB; when single antenna port is used for cell-specific reference signal transmission by the serving cell Ratio of PCFICH RE energy to average RS RE energy [1] dB: when two or four antenna ports are used for cell-specific reference signal transmission by the serving cell Note 1: DCI format 1C is defined in section 5.3.3.1.4 in 3GPP TS 36.212 [21]. Note 2: A hypothetical PCFICH transmission corresponding to the number of control symbols shall be assumed.

Attribute

DCI format Number of control OFDM symbols

- The out-of-sync and in-sync evaluations are performed so that two successive indications from Layer 1 are separated by at least [10] ms. - Upon detection of out-of-sync, the UE initiates the evaluation of in-sync - The occurrences of out-of-sync and in-sync are reported internally by the UE’s physical layer to its higher layers, which in turn may apply layer 3 (i.e. higher layer) filtering for the evaluation of RLF

181 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE/RLF

• Window to estimate if BLER > out-sync threshold is [200ms] - Hence: out of last 200 TTIs at least 20 PDCCH have been received in error

• Window to estimate if BLER < in-sync threshold is [100ms] - Hence: out of last 100 TTIs at most 2 PDCCH have been received in error

in-sync

in-sync

in-sync

out-sync

out-sync

out-sync

out-sync

out-sync

out-sync

out-sync

out-sync

BLER of reference PCFICH + PDCCH

10% 2% >10ms

182 28/10/2015 © Nokia 2014 For internal use

time

Radio Link Failure Detection – UE/RLF • With DRX: - When DRX is in use, in order to enable sufficient UE power saving the out-of-sync and insync evaluation periods are extended and depend upon the configured DRX cycle length - The UE starts in-sync evaluation whenever out-of-sync occurs - Therefore the same period (T

Evaluate

_Q

out_DRX

) is used for the evaluation of out-of-sync and in-sync

- However, upon starting the RLF timer (T310) until its expiry, the in-sync evaluation period is shortened to 100 ms, which is the same as without DRX - If the timer T310 is stopped due to N311 consecutive in-sync indications, the UE performs insync evaluation according to the DRXbased period (T _Q ) Evaluate

DRX cycle length (s) ≤0.04 0.08 0.16 0.32 0.64 1.28 2.56

out_DRX

TEvaluate_Qout_DRX and TEvaluate_Qin_DRX (s) (DRX cycles) [Note (20)] [0.8 (10)] [1.6 (10)] [3.2 (10)] [6.4 (10)] [6.4 (5)] [12.8 (5)]

Note: Evaluation period length in time depends on the length of the DRX cycle in use 183 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE/RLF • In LTE a transition phase is caused by switching between DRX and non-DRX operation or switching between short and long DRX or vice versa -

These scenarios can occur often, and therefore the UE behavior is specifically defined for the evaluation of the radio link quality during the transition period

-

There are two main aspects of the requirements: •

Length of the transition period, T

•

Evaluation period, T

Evaluate_Transition

P

, during the transition

-

The transition period TP is equal to the evaluation period of the mode after the transition

-

During this phase the evaluation period T ,T

is defined as follows:

•

T

•

where T

•

Equation above applies to both in-sync and out-of-sync evaluations

•

After the transition period, the UE uses an evaluation period corresponding to the second mode

•

The evaluation periods during the transition from short to long DRX and vice versa are illustrated in figures in the next slide

Evaluate_Transition

≥ min(T

Evaluate_Transition

Evaluate_mode1

Evaluate_mode1

Evaluate_mode2

and T

184 28/10/2015 © Nokia 2014 For internal use

)

Evaluate_mode2

correspond to the evaluation periods of the first and the second mode respectively

Radio Link Failure Detection – UE/RLF • Transition from long DRX to short DRX

- T

Evaluate_Transition

DRX ON period

=T

Evaluate_mode2

;T

Evaluate_mode2

DRX cycle length before transition ; mode 1


Evaluate_mode1

TEvaluate_mode1

Tevaluate_transition = TEvaluate_mode2

DRX cycle length after transition ; mode 2 DRX ON period

Timer

• Transition from short DRX to long DRX - T

Evaluate_Transition

=T

Evaluate_mode1

DRX cycle length after transition ; mode 2 DRX ON period

;T

Evaluate_mode1

TEvaluate_mode1


Evaluate_mode2

Tevaluate_transition = TEvaluate_mode1

DRX cycle length before transition ; mode 2

DRX ON period

Timer

185 28/10/2015 © Nokia 2014 For internal use

Radio Link Failure Detection – UE/RLC ReTx UE does not find suitable cell for RRC Connection Reestablishment and T311 expires -> UE enters RRC IDLE state Once in idle state UE performs cell selection and when suitable cell found performs Tracking Area Update (or T311 running reselects to another RAT)

RLC trans

RLC trans RLC trans RLC trans RLC trans RLC trans RLC trans RLC trans RLC trans

0

1

2

3

4

5

6

RLC retransmissions until max RLC retransmission count (threshold) is reached maxRetxThreshold : t8

RRC – Connected State

from RRC Connection Reconfiguration: drb-ToAddModList drb-ToAddModList value 1 drb-Identity :1 rlc-Config am ul-AM-RLC t-PollRetransmit : ms120 pollPDU : p32 pollByte : kB25 186 28/10/2015 © Nokia 2014 For internal use maxRetxThreshold : t16

7

8 UE declares Radio Link failure and starts T311 and attempts RRC Connection ReEstablishment during T311

RRC – Idle State

Radio Link Failure Detection – HO Failure UE does not find suitable cell for RRC Connection Reestablishment and T311 expires -> UE enters RRC IDLE state Once in idle state UE performs cell selection and when suitable cell found performs Tracking Area Update (or reselects to another RAT)

PRACH RRC Connection Reconfiguration message with MobilityInfo IE aka “HO Command”. UE starts T304 timer

PRACH

PRACH PRACH PRACH PRACH PRACH PRACH PRACH T311 running

T304 running while UE tries to access the target cell -> PRACH Preamble transmissions until PRACH procedure goes through and UE successfully sends RRC Connection Reconfiguration Complete to the target cell or T304 expires or max number of preamble transmission is exceeded

RRC – Connected State from RRC Connection Reconfiguration:

mobilityControlInfo targetPhysCellId : 33 t304 : ms1000 newUE-Identity Bin : 14 EB (= 5355) 187 28/10/2015 © Nokia 2014 For internal use

T304 expires and UE declares Radio Link failure and starts T311 and attempts RRC Connection Re-Establishment during T311 running (to source, target or any cell)

RRC – Idle State

Radio Link Failure Detection – non HO RA Failure UE does not find suitable cell for RRC Connection ReRandom Access procedure PRACH PRACH PRACH establishment and T311 expires -> UE enters RRC IDLE triggered due no response to state PRACH PRACH the SRI on PUCCH (aka UE Once in idle state UE performs cell selection and when PRACH PRACH sends the SRI on PRACH) or PRACH PRACH suitable cell found performs Tracking Area Update (or eNB sends PDCCH order (to reselects to another RAT) initiate PRACH procedure for T311 running e.g. reaquiring UL sync)

UE attempting to establish connection to the serving cell via PRACH procedure (or eNB resending the PDCCH order)

RACH Failure : UE declares Radio Link Failure and starts T311 and tries RRC reestablishment to the serving cell or any suitable cell

RRC – Connected State

• Non-HO random access means

- PDCCH order -triggered RA - Random Access Scheduling Request 188 28/10/2015 © Nokia 2014 For internal use

RRC – Idle State

Re-Establishment Causes

Source: 3GPP TS 36.331 • UE sets the reestablishmentCause as follows: - if the re-establishment procedure was initiated due to RRC reconfiguration failure (i.e., the UE is unable to comply with the reconfiguration), UE sets the reestablishmentCause to the value 'reconfigurationFailure' - if the re-establishment procedure was initiated due to intra-LTE handover failure or inter-RAT mobility from EUTRA failure, UE sets the reestablishmentCause to the value 'handoverFailure' - Otherwise UE sets the reestablishmentCause to the value 'otherFailure‘. NOTE: This includes T310 RLF failure 189 28/10/2015 © Nokia 2014 For internal use

RRC Re-establishment Request, Example RRC SIGNALING MESSAGE Time: 9:38:13.165 RRCConnectionReestablishmentRequest (3GPP TS 36.331 ver 8.7.0 Rel 8) UL-CCCH-Message message c1 rrcConnectionReestablishmentRequest criticalExtensions rrcConnectionReestablishmentRequest-r8 ue-Identity c-RNTI Bin : 4C F0 (= 19696) physCellId : 30 shortMAC-I Bin : AB 7D (= 43901) reestablishmentCause : otherFailure spare Bin : 0 (2 bits) Data (hex): 09 9E 01 EA B7 D8

190 28/10/2015 © Nokia 2014 For internal use

This is the PCI of the cell where UE was last succesfully connected to

RL Problem Detection at eNB - Itroduction -

Multiple methods (called “link monitors”) are defined to detect a radio link problem in the eNB

-

When one link monitor detects a problem, it is really a radio link problem even if other link monitors have not yet indicated anything

-

Each link monitor has its own criteria to decide when radio link problem is flagged and de-flagged (radio link recovers)

-

If the RL Problem persists longer than T_RLF, RRC+S1 release is triggered T_RLF = t310 + t311 + (eNB-internal timer, pre RL40 MP1.1 200ms and RL40 MP1.1 onwards 2200ms)

•

-

Link monitors 1.

Uplink PUSCH DTX detection for scheduled uplink data

2.

CQI DTX detection for periodic CQI reports in PUCCH and PUSCH

3.

Uplink Ack/Nack DTX detection for transmitted downlink data

4.

PDCCH Order RLF

5.

SRS DTX detection

191 28/10/2015 © Nokia 2014 For internal use

RL Problem Detection at eNB - Itroduction • Based on the Emil log analysis the eNB detected problems are classified as below for one test cluster 6 eNBs • All the main drop causes are analysed in details in the following slides

192 28/10/2015 © Nokia 2014 For internal use

PUSCH RLF: RlsCause_PuschRlf_ON • When UE is scheduled for PUSCH transmission, eNB expects to receive UL transmission on the scheduled PRBs • If signal from UE cannot be detected at all, PUSCH DTX is declared - NOTE: The case where UL TBS is received but it fails CRC check is not DTX (it’s a NACK) • DTX PUSCH indication is provided by the UL physical layer. • The result is received by LTE MAC in reliableULtransmissionFlag parameter (which can be seen in UL TTI trace). • Both counter-based and timer-based RLF detection is supported • Timer-based PUSCH RLF detection:

- If “DTX“ is received on the PUSCH for a period of time defined by (rlpDetMaxTimeUl = 0 i.e. timer based detection is switched off), PUSCH RLF is set on • Counter-based PUSCH RLF detection: - If “DTX“ is received on the PUSCH for a consecutive number of times (rlpDetMaxNUl, hard coded to 1000), PUSCH RLF is set on 193 28/10/2015 © Nokia 2014 For internal use

PUSCH RLF: RlsCause_PuschRlf_ON

• The recovery of the radio link is indicated when for a configurable number of contiguous UL resource assignments data is detected on PUSCH (ACK or NACK received) - Defined by parameter rlpDetEndNUl (hard coded to 3)

194 28/10/2015 © Nokia 2014 For internal use

195 28/10/2015 © Nokia 2014 For internal use

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before)

uplink

Hard coded values: Example : rlpDetMaxNUl=4 rlpDetEndNUl=3

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=FALSE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

reliableULtransmissionFlag=TRUE

PUSCH RLF: RlsCause_PuschRlf, Counter Based RLF – Detection Example RLF timer running

time

PUSCH_RLF ON PUSCH_RLF OFF

Periodic CQI RLF: RlsCause_CqiRlf_ON

• The eNB supports CQI DTX detection for periodic CQI reports on PUCCH and PUSCH -

If MAC layer receives nCqiDtx (hard coded = 50) consecutive reports from UL PHY, the MAC declares CqiRLF_ON

-

can be seen in BTS log

-

If the MAC has set CqiRLF_ON for a specific UE and nCqiRec (hard coded = 2) consecutive CQI reports are again detected successfully for that UE, the MAC sets CqiRLF_OFF

• For both PUSCH and PUCCH the periodic CQI is encoded using a Reed Muller block code and comes along without any CRC -

Hence, the UL PHY indicates a DTX detection for periodic CQI reports on PUCCH or PUSCH whenever a report is configured but no reliable transmission from the UE could be detected

• NOTE: CQI_RLF detection does not apply to aperiodic CQI report on PUSCH

196 28/10/2015 © Nokia 2014 For internal use

Periodic CQI detected

Periodic CQI detected

CQI DTX

CQI DTX

CQI DTX

CQI DTX

CQI DTX

CQI DTX

CQI DTX

CQI DTX

RLF timer running

CQI DTX

Periodic CQI detected

CQI DTX

Periodic CQI detected

Periodic CQI RLF: RlsCause_CqiRlf, example

time LNCEL/cqiPerNp=10ms

Example : nCqiDtx=4 nCqiRec=2

197 28/10/2015 © Nokia 2014 For internal use

CQI_RLF ON

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before)

CQI_RLF OFF

Periodic CQI RLF: RlsCause_CqiRlf, example

T_RLF = 5.709s but based on parameters T_RLF = T310 [500ms] + T311 [5000ms] + 200ms T_RLF should be 5.5s i.e. additional 200ms

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before) 198 28/10/2015 © Nokia 2014 For internal use

Periodic CQI RLF: RlsCause_CqiRlf • RL40 allows setting of cqiPerNp (CQI periodicity network period) to 40ms (from 20ms)

• Improvement from this increase is extremely big as indicated below - ERAB Dropped Call Rate improved by 31% and PUCCH SINR improved 1.46dB • The improvement indicates that the CQI based DTX detection seems to cause some unnecessary dropped calls which are not detected by the end users i.e. occur during the inactivity periods in RRC Connected State ERAB Drop Rate

cqiPerNp change

cqiPerNp change CDR Before 0.179% 199 28/10/2015 Nokia 2014 After ©0.124% For internal use -0.055% Gap (31% improvement)

RACH SR 99.91% 79.76% 99.93% 79.85%

HO CQI SR 99.42% 10.26 99.43% 10.33

DL MCS 14.54 15.12

DL BLER 8.40% 8.42%

RI2 ratio 32.27% 35.01%

DL RB RRC Usage Attempts 8.17% 5744674 8.15% 5831813

PUCCH RSSI -96.56 -97.05

PUCCH SINR 9.79 11.26

PUSCH RSSI -95.63 -95.71

PUSCH SINR 16.81 16.61

0.02%

0.01%

0.57

0.03%

2.31%

0.04%

-0.49

1.46

-0.09

-0.19

CSSR

0.09%

0.08

8441

Periodic CQI RLF: RlsCause_CqiRlf

• RL40 allows setting of cqiPerNp (CQI periodicity network period) to 40ms (from 20ms) • Average throughput improvement in DL and UL detected during drive testing when cqiPerNp was increased to 40ms - Also BLER improved Throughput [Mbps] cqiPerNp

200 28/10/2015 © Nokia 2014 For internal use

PDSCH BLER [%]

Download

Upload

Download

Upload

20ms

19.7

14.5

9.1

5.1

40ms

22.9

17.2

8.6

4.3

Periodic CQI RLF: RlsCause_CqiRlf • PLMN level modifications show significant improvement in dropped call rate when changing cqiPerNp from 20ms to 40ms

- Improvement comes from less amount of CqiRlf

201 28/10/2015 © Nokia 2014 For internal use

Periodic CQI RLF: RlsCause_CqiRlf • PUCCH Power control plays also significant role in CQI based RL failure detection • Therefore proper power control for PUCCH is important

• Improvement in DCR is significant and decrease in SINR is less than decrease in RSSI i.e. PUCCH quality has improved Abbreviated Name

Parameter name

Range

Default Value

Modification

Test Value

p0NomPucch

Nominal power for UE PUCCH TX power calculation

-127... -96 dBm

-100

On-Line

-112

ulpcLowlevCch ulpcUplevCch

Lower RSSI threshold for PUCCH power command decision Upper RSSI threshold for PUCCH power command decision

-127... 0 dBm -127... 0 dBm

-103 -98

On-Line On-Line

-114 -109

ERAB Drop Rate 0.208%

RRC Setup Success Rate

Before

RRC Setup Amount 2887141

99.84%

RACH success rate 79.10%

HO success rate (X2+Intra) 99.67%

After

3333839

0.167%

99.88%

81.17%

99.69%

Gap

446698

Gap(%)

15.47%

-0.041%

0.05%

2.07%

0.02%

-19.69%

0.05%

2.61%

0.02%

DCR

RSSI_PUCCH

SINR_PUCCH

RSSI_PUSCH

SINR_PUSCH

-95.75

9.63

-93.30

16.96

-103.45

5.80

-93.23

17.08

-7.70

-3.83

0.07

0.12

-

-

-

-

RRC Setup Attempts

Parameter changes

202 28/10/2015 © Nokia 2014 For internal use

Parameter changes

Ack/Nack RLF: RlsCause_AckNackRlf_ON • After DL scheduled data, eNB expects HARQ ACK or NACK on PUCCH or PUSCH at known UL TTI • Timer-based ACK/NACK RLF detection: - If ACK/NACK “DTX“ is received for a configurable period of time (rlpDetMaxTimeDl = hard coded to 0 i.e. not in use), ACK/NACK RLF is set on

• Counter-based ACK/NACK RLF detection: - If ACK/NACK “DTX“ is received for a consecutive number of times (rlpDetMaxNoDl = hard coded to 1000), ACK/NACK RLF is set on

• The recovery of the RLF is indicated when for a configurable number of contiguous ACK/NACK opportunities ACK or NACK is detected on PUSCH or PUCCH (no DTX). - Defined by parameter rlpDetEndNoDl (hard coded to 3) 203 28/10/2015 © Nokia 2014 For internal use

Ack/Nack RLF: RlsCause_AckNackRlf_ON

T_RLF = T310 + T311 + 200ms = 6.20982 204 28/10/2015 © Nokia 2014 For internal use

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before)

PDCCH Order RLF • If there DL data in eNB buffer and UE is out-of-sync (shown as OutSync in Emil), UE must be brought back to in-sync (time aligned) with a RA procedure before DL data can be sent • Signaling of dedicated RA preamble via PDCCH (so-called PDCCH order) is done using DCI format1A

• In case that PDCCH order fails for a UE (i.e., no transmission of assigned dedicated preamble detected by eNodeB, or no msg3 transmission) the PDCCH order is repeated noRepPdcchOrder times (hard coded to 1), again using the selected preamble and considering DRX status of the UE accordingly • Final failure of the PDCCH order process is indicated as radio link problem to higher layers with cause “PDCCH order failure” (shown as OutSyncFinal in Emil log) -

In case of unsuccessful PDCCH order UE release is triggered by higher layers (silent radio link failure) using T_RLF

T_RLF = T310 + T311 + 200ms T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before) 205 28/10/2015 © Nokia 2014 For internal use

PDCCH Order RLF • For non-contention based random access the interval for PDCCH order transmissions is determined by time from the actual preamble assignment until successful reception of a transmission of the preamble - (UE PDCCH processing delay + maximum waiting time until next PRACH occasion + (preambleTransMax -1)*(RaRespWindSize + maximum waiting time until next PRACH occasion)) - As an example : 3ms + 9ms + (10-1)*(10ms+9ms)= 183ms • For contention based random access: - (UE PDCCH processing delay + maximum waiting time until next PRACH occasion + (preambleTransMax -1)*( RaRespWindSize + maximum waiting time until next PRACH occasion) + RAR to msg3 transmission delay + MaxNumberOf HarqTransmissionsMsg3 * HARQ RTT+ MacContResoTimer) - 3ms + 9ms + (10-1)*(10ms + 9ms) + 6ms + 5 * 8ms + 64ms = 293 • In addition the MAC layer contains hidden timer rdPdcchOrderExpT (def 450ms) which supervises the whole PDCCH order procedure

206 28/10/2015 © Nokia 2014 For internal use

Reaching Max #RLC Retransmissions • The 3GPP described reaction after the detection of the event “Maximum number of RLC retransmissions” for an RLC PDU is to initiate an intra-cell handover and this is supported in RL50

- As a work-around, eNB waits for an UE initiated RRC Connection Reestablishment • eNB never resumes the SRB/DRB without an intra-cell handover or RRC connection reestablishment because the affected RLC entity is still blocked - intra-cell handover cannot be initiated if the event “Maximum number of RLC retransmissions” has occurred for SRB1 (the RRC message RRCConnectionReconfiguration cannot be sent to UE) i.e. only applicable for SRB2 and DRBs

SBR ID

Usage

0

for RRC messages using the CCCH logical channel e.g. RRC Connection Setup message

1

for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2 (prior security activation), all using DCCH logical channel;

2

for NAS messages, using DCCH logical channel. SRB2 has a lower-priority than SRB1 and is always configured ONLY after security activation.

207 28/10/2015 © Nokia 2014 For internal use

Reaching Max #RLC Retransmissions – SRB1

17 RLC transmissions with polling interval of 100ms = 1700ms

• eNB RLC layer notifies that the RLC AM entity of a SRB1 (RRC message with piggybacked NAS) has reached the event “Maximum number of RLC retransmissions” for an RLC PDU - eNB initiates a S1AP release procedure: • eNB sends the S1AP message UE CONTEXT RELEASE REQUEST with cause “RNL Cause Radio Connection with UE Lost” to MME to initiate the UE release as for the radio link failure procedure • 17 RLC transmissions with polling interval of 100ms = 1700ms 208 28/10/2015 © Nokia 2014 For internal use

Reaching Max #RLC Retransmissions – SRB1 • t-PollRetransmit is by default set to 100ms for SRB and 120ms for DRB (tPollRetr)

• maxRetxThreshold is set to 16 for SRB and also 16 for DRB (drbAmMxRtxTh) • Note that the parameters above are hard coded for SRB • Above means that the RLC (re)transmissions takes

- SRB 100ms*17 = 1700ms - DRB 120ms*17 = 2040ms

209 28/10/2015 © Nokia 2014 For internal use

message c1 : rrcConnectionSetup : { rrc-TransactionIdentifier 2, criticalExtensions c1 : rrcConnectionSetup-r8 : { radioResourceConfigDedicated { srb-ToAddModList { { srb-Identity 1, rlc-Config explicitValue : am : { ul-AM-RLC { t-PollRetransmit ms100, pollPDU pInfinity, pollByte kBinfinity, maxRetxThreshold t16 }, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms0 } },

drb-ToAddModList { {eps-BearerIdentity 5, drb-Identity 4, pdcp-Config { discardTimer ms750, rlc-AM { statusReportRequired TRUE}, headerCompression notUsed : NULL}, rlc-Config am : { ul-AM-RLC { t-PollRetransmit ms120, pollPDU p64, pollByte kB500, maxRetxThreshold t16}, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms50}}, logicalChannelIdentity 3, logicalChannelConfig { ul-SpecificParameters { priority 9, prioritisedBitRate kBps16, bucketSizeDuration ms100, logicalChannelGroup 2} } }, {eps-BearerIdentity 6, drb-Identity 5, pdcp-Config { discardTimer ms750, rlc-AM { statusReportRequired TRUE}, headerCompression notUsed : NULL}, rlc-Config am : { ul-AM-RLC { t-PollRetransmit ms120, pollPDU p64, pollByte kB500, maxRetxThreshold t16}, dl-AM-RLC { t-Reordering ms50, t-StatusProhibit ms50} }, logicalChannelIdentity 4, logicalChannelConfig { ul-SpecificParameters { priority 9, prioritisedBitRate kBps16, bucketSizeDuration ms300, logicalChannelGroup 3} } } },

Reaching Max #RLC Retransmissions – DRB • If eNB RLC layer notifies that the RLC AM entity of a DRB has reached the event “Maximum number of RLC retransmissions” for an RLC PDU

- eNB starts the timer T_RLC based on the value of the RRC timer T311 - The timer T_RLC is stopped if the eNB accepts an RRC message RRCConnectionReestablishmentRequest from UE or the RLF timer T_RLF has expired - When the timer T_RLC expires, eNB checks whether the timer T_RLF is running: • If T_RLF is running, eNB ignores all subsequent indications that a problem triggering an RLF has recovered and wait for the expiration of T_RLF or an accepted RRC message RRCConnectionReestablishmentRequest from the UE

• Otherwise eNB sends the S1AP message UE CONTEXT RELEASE REQUEST with cause “RNL Cause Radio Connection with UE Lost” to MME to initiate the UE release as for the radio link failure procedure

210 28/10/2015 © Nokia 2014 For internal use

Reaching Max #RLC Retransmissions – DRB

T_RLC = T311 = 5s started (T_RLC = T311 + 200ms) T_RLC expiry

• Max RLC Retransmissions Exceeded in above case is for DRB as can be seen from thr TUP error message below (DRBid = 4 i.e. EPS Bearer Id = 5)

211 28/10/2015 © Nokia 2014 For internal use

Several Radio Link Problem Indications Active

T_RLF due CQI started T_RLF due CQI stopped T_RLF due AckNack Rlf T_RLF due Out of Synch Detected

Max RLC retransmissions for SRB1 -> immediate release

212 28/10/2015 © Nokia 2014 For internal use

When is RRC + S1 Release (=drop) Triggered by eNB? • When a radio link problem is detected, an eNB-internal timer (T_RLF) is started. The timer T_RLF is stopped when in case of radio link failure recovery. • For a given UE, T_RLF is started when any of the PUSCH RLF, CQI RLF or AckNack RLF is set to ON state

• For a given UE, T_RLF is stopped only if all RLFs are OFF • When the timer T_RLF expires, the UE is released from the eNB using eNB initiated S1 release + RRC connection release –> call drop

• T_RLF = T310 + T311 + (eNB internal timer, RL40 MP1.1 onwards 2200ms and 200ms before)

213 28/10/2015 © Nokia 2014 For internal use

Dropped Call Performance Improvement 1 Parameter Name Timer T300

Abbreviated name T300

Set1 200ms

Set2 400ms

Maximum number of out-of-sync indications

n310

n10

n6

Timer T310

t310

2000ms

500ms

Timer T311

t311

3000ms

5000ms

• Making the UE deciding the out of sync status faster – Reduce n310 from n10 to n6 • Making UE to decide RL failure status earlier and start looking for candidate for re-establishment – Reduce t310 from 2s to 500ms • Allow UE to search for RRC re-estab candidate longer time – Increase the t311 from 3s to 5s 214 28/10/2015 © Nokia 2014 For internal use

Dropped Call Performance Improvement 2 Parameter Name Timer T300

Abbreviated name T300

Set1 200ms

Set2 400ms

Set3 400ms

Maximum number of out-of-sync indications

n310

n10

n6

n6

Timer T310

t310

2000ms

500ms

1000ms

Timer T311

t311

3000ms

5000ms

5000ms

Timer T301

t301

200ms

200ms

400ms

T_RLF=T310+T311+(T301 or 200ms) T_RLF(set3)=1000ms+5000ms+(400ms or 200ms) T_RLF(set3)=6.2s or 6.4s

• T_RLF = 13.578307 – 07.370630 = 6.208s • Above means that T_RLF does not contain T301

215 28/10/2015 © Nokia 2014 For internal use

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before)

Dropped Call Performance Improvement 2 Parameter Name Timer T300

Abbreviated name T300

Set1 200ms

Set2 400ms

Set3 400ms

Maximum number of out-of-sync indications

n310

n10

n6

n6

Timer T310

t310

2000ms

500ms

1000ms

Timer T311

t311

3000ms

5000ms

5000ms

Timer T301

t301

200ms

200ms

400ms

• Set 3 has best performance due to – More time for RL failure detection in UE and therefore for starting T311 – Longer time for UE to send RRC Reestablishment Request i.e. T300 should be equal to T301

Value [%] STDEV Before

216 28/10/2015 © Nokia 2014 For internal use

Gap

0.016568947 0.17611639

RL40 Upgrade

0.160462035

0.015654355

T301,310 Change

0.146949134

0.029167255

Dropped Call Performance Improvement 2 • Based on the analysis it seems that the T_RLF = T310 + T311 + 200ms i.e. T_RLF does not include T301 UE detects 1st out of sync

T310 expires RLF occurs -> UE tx turned off in 40ms RRC re-establishment starts T311 starts UE searches for the best cell

UE selects the target cell

UE acquires UE grant UE sends RRC connection re-estab request message, stops T311 and starts T301

Time UE detects up to n310 (n6,n10) -> UE starts time T310 = 6,5,4 (2000ms, 1000ms, 500ms) in case T300, T301, T304 nor T311 is running

RLF timer T310 running

RRC re-establishment timer T311 = 1,2,3 (3000ms, 5000ms, 10000ms) running

UE acquired SI of traget cell UE sends RACH to target cell

In the network = T311 + 200ms

• However as can be seen from above the T301 supervises the RRC reestablishment i.e. is used the same way as T300 -> it is suggested that T301 is added to the T_RLF definition and T301 should be set similar to T300 217 28/10/2015 © Nokia 2014 For internal use

T_RLF = T310 + T311 + (2200 RL40 MP1.1 onwards and 200 before)

Dropped Call Performance Improvement 2 • RL40 MP1.1 includes T_RLF correction from T_RLF = T310 + T311 + 200ms to T_RLF = T310 + T311 + (max value for T301 + 200ms = 2200ms)

- In test case below T_RLF = T310 (1000ms) + T311 (5000ms) + 2200ms = 8200ms • This correction improved dropped call KPI significantly from ~0.15% to ~0.1% in 11 moderate loaded eNBs (44 cells) without any increase in #RRC Connected UEs

- Clear reduction in ENB_EPS_BEARER_REL_REQ_RNL (as expected)

218 28/10/2015 © Nokia 2014 For internal use

Dropped Call Performance Improvement 2

• Clear reduction in ENB_EPS_BEARER_REL_REQ_RNL (as expected) • And clear reduction in EPC_EPS_BEARER_REL_REQ_RNL (as expected) • And clear increase in all normal releases

• No negative impact on other KPIs

219 28/10/2015 © Nokia 2014 For internal use

Dropped Call Performance Improvement 3

Some site related problems Average level prior to parameter changes

220 28/10/2015 © Nokia 2014 For internal use

=> Main improvement => Minor improvement => Minor improvement

Dropped Call Performance Improvement 4 • Dropped calls decreased especially due to the first signaling messages which are using the selected Power Control strategy - 2nd RRC Connection Reconfiguration Complete to the target cell right after the HO - Clear impact visible due to the wrongly selected power control parameters After RL40 DCR improved

221 28/10/2015 © Nokia 2014 For internal use

After Changing P0 and Alpha, from 90, 1 to -100,1 DR improvement once again.

Dropped Call Performance Improvement 5

222 28/10/2015 © Nokia 2014 For internal use

RL60 Improvement

223 28/10/2015 © Nokia 2014 For internal use

Dropped Call Rate Improvement • The periodical CQI reporting DTX rate is used one of the RLF indications (leading to dropped call) - The parameter to control this is in vendor file “nCqiDtx” which defines the number consecutive DTXs detected instead of CQI report for periodical CQI reporting (PUCCH or PUSCH) - nCqiDtx was tested for 2 different eNBs with 2 different new values (0 i.e. disable and 100) Value

ERAB drop rate

QCI1 drop rate

nCqiDtx=50

0.15

1.26

nCqiDtx=0

0.04

0.00

74% improvement

100% improvement

Value

ERAB drop rate

QCI1 drop rate

nCqiDtx=50

0.28

0.58

nCqiDtx=100

0.16

0.12

43% improvement

79% improvement

224 28/10/2015 © Nokia 2014 For internal use

Dropped Call Rate Improvement • Very big improvement from both nCqiDtx = 0 and 100 due to the fact that 55.7% of all dropped calls are caused by CQI failure

225 28/10/2015 © Nokia 2014 For internal use

Dropped Call Rate Improvement • For RL60 the nCqiDtx is modifed to 100 and nCqiDtx will be then operator modifiable parameter in the future

226 28/10/2015 © Nokia 2014 For internal use

RL70 Improvement

227 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement LTE1617

> VoLTE drop rate can be further improved by re-establishment procedure, which enables the VoLTE connection to be maintained even after radio link failure 4 3 2 Cell A

Cell B

1

228 28/10/2015 © Nokia 2014 For internal use

1

= Radio link failure

2

= Re-establishment request

3

= Radio link failure indication

4

= Handset context retrieval by handover request

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • The gain from RLF triggered HO (LTE1617) should come from the RRC establishment success rate improvement and therefore reduced mute time (silence period due to the RLF and rrc connection re-establishment) -

It should be noted that the in case of RRC re-estab failure the UE can quickly send new RRC connection request and RRC connection and be setup from beginning fairly quickly and call can continue, this can also happen for VoLTE

• Below is simple comparison between RRC re-establishment and RRC re-establishment rejection + new RRC connection time

229 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • It should be noted that the RRC connection re-establishment time below does not include the UE context fetching process which is part of LTE1617 so additional 50-100ms should be added to the successful RRC connection re-establishment time below i..e 120 -> 170…220ms • So in theory the gain in mute time (silence period or no data period) should reduce from ~600ms to ~200ms i.e. 400ms gain • However it should be noted that the actual gain also depends on T310 and T311 settings

230 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • After activation of LTE1617 there is no real gain expected in terms of dropped call rate if the MME releases the duplicated S1 connection with NORMAL release cause - Duplicated S1 connection occurs when the UE tries to make HO from eNB-A cell to eNB-B cell but the HO fails and following RRC connection re-establishment fails (no LTE1617) and therefore UE makes new RRC setup attempt in eNB-B cell which causes new S1 connection establishment towards the MME

- The MME notices that there are 2 S1 connections for the UE and releases the old one (eNB-A) - This release can be done with cause NORMAL release or RADIO where the latter causes dropped call counting (EPC initiated E-RAB release due RNL) 231 28/10/2015 © Nokia 2014 For internal use

MME eNB-B UE

eNB-A UE

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • This scenario is shown below and as can be seen the release cause is : release-due-to-eutrangenerated-reason • The cause depends on MME implementation (below E///, Nokia MME seem to use NORMAL release) eNB-A

MME eNB-B UE

UE

232 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • In case duplicated S1 connection is released with NORMAL cause then LTE1617 does not improve dropped call rate but improves mute time duration - Mute time (silence period) is expected to decrease significantly - Preliminary tests (table on the right) show that silence period is reduced by 250ms for VoLTE and no data period is reduced by >1s for FTP transfer - Silence period reduction by only 250ms for VoLTE is a bit disappointing but this is just preliminary results and T310 or T311 were not adjusted at all (the timers could be greatly reduced) •

T310 = 2s

•

T311 = 3s

233 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs LTE1617 as shown in NEI slides Other eNB

Serving eNB

UE

Cell A with valid UE Context

Cell B

Successful case (1/3) •

UE initially served by cell A

•

RLF, HO failure, mobility from E-UTRA failure, integrity check failure detected Cell B selected during cell selection process acc. to 36.304 PRACH Random Access (Msg1) PRACH Random Access Response (Msg2)

• •

RRCConnectionReestablishmentRequest (Msg3) X2AP: RLF INDICATION

234 28/10/2015 © Nokia 2014 For internal use

RLF triggered Inter-eNB handover

RRC:RRCConnectionReestablishmentRequest

sent by the UE to the cell B covers information about PCI, C-RNTI, shortMAC-I used so far by serving cell A Based on the received PCI value, Other eNB recognizes that the so far serving cell A does not belong to Other eNB This is the trigger for sending of X2AP: RLF INDICATION by Other eNB The crucial information is that X2AP: RLF INDICATION message is sent to all eNBs for which NR, with signaled by RRC message PCI exists; (the serving eNB is one of them)

VoLTE KPIs LTE1617 as shown in NEI slides Other neighbor eNB, having the cell identified by the same PCI as the PCI of Cell A of Serving eNB

UE

Cell C, PCI=10

Successful case (2/3) Other eNB

Serving eNB

Cell A, PCI=10 with valid UE Context

•

Cell B

RRCConnectionReestablishmentRequest (Msg3)

•

(PCI=10, C-RNTI, shortMAC-I of Serving cell)

X2AP message ignored due to lack of UE Context identified by C-RNTI

•

X2AP: RLF INDICATION

(PCI=10, C-RNTI, shortMAC-I of Serving cell, ECGI of Other eNB)

X2AP message received by Serving eNB with valid UE Context is a trigger for inter-eNB HO

235 28/10/2015 © Nokia 2014 For internal use

X2AP: RLF INDICATION (PCI=10, C-RNTI, short MAC-I of Serving cell, ECGI of Other eNB)

•

Example: the database of Other eNB may cover two active NRs to cells identified by PCI=10 which are handled by Serving eNB (cell A identified by PCI=10) and other neighbor eNB (cell C identified by PCI=10) To both of these eNBs X2AP: RLF INDICATION message is sent with PCI=10, C-RNTI, shortMAC-I Other neighbor eNB, handling cell C, has no valid UE Context for the considered UE; this is the reason other neighbor eNB ignores incoming X2AP: RLF INDICATION message C-RNTI sent in X2AP:RLF INDICATION message and received by Serving eNB matches to an UE Context which is still valid in the Serving eNB; this check is a trigger for inter-eNB handover from Serving eNB to Other eNB

VoLTE KPIs LTE1617 as shown in NEI slides Other eNB

Serving eNB

UE

Cell A

Successful case (3/3) •

Cell B with valid UE Context

UE initially served by cell A RLF, HO failure, mobility from E-UTRA failure, integrity check failure detected

•

Cell B selected during cell selection process acc. to 36.304 PRACH Random Access (Msg1) PRACH Random Access Response (Msg2)

•

RRCConnectionReestablishmentRequest (Msg3) X2AP: RLF INDICATION X2AP: HANDOVER REQUEST

RLF triggered Inter-eNB handover

Admission Control RRCConnectionReestablishment (Msg4)

X2AP: HANDOVER REQUEST ACKNOWLEDGE

RRCConnectionReestablishmentComplete (Msg5) 236 28/10/2015 © Nokia 2014 For internal use

X2AP: HANDOVER REQUEST message is sent towards Other eNB; this way UE Context is provided to Other eNB which handles Cell B, selected by the UE as re-establishment target cell Assuming that Admission Control does not reject X2AP: HANDOVER REQUEST, initially unprepared cell B becomes a prepared cell (UE Context is provided to other eNB) and re-establishment procedure may be successfully completed X2AP: HANDOVER REQUEST is directed to Other eNB based on the content of IE:Reestablishment cell ECGI of the X2AP: RLF INDICATION message

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement

• Example below shows inter eNB RRC connection re-establishment • Delay from the “context fetching” is pretty short i.e. it takes only 50ms for target cell to send the RRC connection Re-establishment message after receiving the RRC connection Re-establishment Request message If source eNB identifies the C-RNTI it will respond to the target eNB with X2AP: Handover Request within which the UE CONTEXT is moved to the target eNB When serving eNB receives the X2AP : RLF INDICATION it will check whether it served corresponding C-RNTI or not

RRC connection Reestab signaling towards the target cell

237 28/10/2015 © Nokia 2014 For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • Activation of LTE1617 clearly improves the RRC connection re-establishment success rate, no visible gain in total E-RAB drop rate • Some (possible) improvement in QCI1 E-RAB drop rate highly depending on how the MME uses the release causes for duplicated S1 connections

Before (1/23~1/26) After (1/30~2/2) Gap

RRC Attempts

RRC Succ Rate

Rach Attempts

Rach Succ Rate

ERAB Attempts

ERAB Succ Rate

Call Drop Rate

RB Attempts

RB Succ Rate

7870046 8545973 675927

99.97 99.97 0

9873503 10936760 1063257

89.07 87.28 -1.79

13701966 14906424 1204458

99.99 99.99 0

0.06 0.07 0.01

15208945 16551025 1342080

99.94 99.93 -0.01

intra 2014 HO Attempts 238 28/10/2015 © Nokia Before For internal use (1/23~1/26) 217392 After (1/30~2/2) 239384

intra HO Succ Rate

inter HO Attempts

inter HO Succ Rate

IF HO Attempts

IF HO Succ Rate

RRE Attempts

RRE Succ Rate

99.92 99.9

734717 789687

99.54 99.59

168946 185651

99.56 99.64

31260 20780

12.27 55.73

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • Current LTE1617 implementation has some problem in terms of coding the msg4 MAC header, to be corrected – bug is not with the RRC connection setup – To be corrected in RL70 MP1

3C111100(UE Contention Resolution Identity) 1F11111(Padding)

• This combination 3C 1F is no longer supported in 36.321 AnnexB(normative) – next slide -

(In Rel8 case, Annex B is informative, but an attached CR is changed from informative to normative by Panasonic

239 28/10/2015 © Nokia 2014 proposal) For internal use

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • Reason for correction is due to the UE processing i.e. -

In RAN2#63bis meeting it was agreed that UE only needs to check the 6 MAC header structures listed in annex B of TS36.321 when processing a MAC PDU containing a UE Contention Resolution Identity MAC control element

• Therefore eNB needs to implement the same change in order to avoid any msg4 problems (for any cause RRC setup, RRC connection re-estab etc)

R

R

E

Case 1: MAC subheader for MAC control element

R

R

E

LCID

(11100)

R

R

E

LCID

(00000)

Case 2: MAC subheader for MAC control element + MAC subheader for MAC SDU (CCCH)

R

R

E

LCID

(11111)

R

R

E

LCID

(11111)

R

R

E

LCID

(11100)

R

R

E

LCID

(11111)

R

R

E

LCID

(00000)

R

R

E

LCID

(11100)

R

R

E

LCID

(00000)

Case 3: MAC subheader for single-byte padding + MAC subheader for MAC control element + MAC subheader for MAC SDU (CCCH)

Case 4: MAC subheaders for two-byte padding + MAC subheader for MAC control element + MAC subheader for MAC SDU (CCCH)

R

R

E

LCID

(11100)

R

R

E

LCID

(11100)

R

R

E

LCID

(00000)

R

R

E

LCID

(00000)

F R

240 28/10/2015 © Nokia 2014 For internal use

LCID (11100)

F

L R

E

LCID

L L

(11111)

R Case 5: MAC subheader for MAC control element + MAC subheader (7-bits L-field) for MAC SDU (CCCH) + MAC subheader for padding

R

E

LCID

(11111)

Case 6: MAC subheader for MAC control element + MAC subheader (15-bits L-field) for MAC SDU (CCCH) + MAC subheader for padding

VoLTE KPIs Dropped call rate – RRC Connection Re-establishment improvement • Correct header implementation for RRC Connection Re-establishment is as below

241 28/10/2015 © Nokia 2014 For internal use

242 28/10/2015 © Nokia 2014 For internal use