10 drop call analysis v1_5

Soc Classification level Presentation / Author / Date 1 © Nokia Siemens Networks

LTE OPTDrop Call analysis

Last updated: March 18, 2011


Outline

• UE-detected RF problems: RRC Connection Re-Establishment• eNB-detected radio link problems

– PUSCH RLF– CQI RLF– Ack/Nack RLF

• eNB-initiated release: TA timer expiry• eNB-initiated release: maximum RLC retransmissions exceeded• eNB-initiated release: GTP-U failure• Timers and constants (3GPP)


RRC connection Re-Establishment by UE

• When UE is in RRC_CONNECTED and RRC security is active, it can trigger RRC Connection Re-establishment– upon T310 expiry

– upon reaching the maximum number of RLC retransmissions

– upon handover failure (T304 expiry)

– upon non-HO related random access problem

• 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


RLF due to T310 expiry

• For UE “normal operation” means:– Not waiting for RRC Connection Setup/Reject (T300 not running)

– Not waiting for RRC Re-establishment Establishment/Reject (T301 not running)

– handover not ongoing (T304 not running)

– No RLF recovery ongoing (T311 not running)

normal operationradio

problem detection

no recovery during T310 no recovery during T311 goes back to idle

radio link failure

RRC_CONNECTED RRC_IDLE

First Phase Second Phase

n310 consecutive out-of-sync indications

n311 consecutive in-sync indications

during t310

RRC connection re-establishment attempted during

t311

Cell reselection and Tracking Area

Update if RRC Re-Establishment

fails


RLF due to maximum RLC retx reached

from RRC Connection Reconfiguration:drb-ToAddModList drb-ToAddModList value 1 drb-Identity : 1 rlc-Config am ul-AM-RLC t-PollRetransmit : ms40 pollPDU : p32 pollByte : kB25 maxRetxThreshold : t8

normal operation RLC retransmissions until max value no recovery during T311 goes back to idle

radio link failure



RLC retransmissions

until max RLC retx threshold is reached

RRC connection re-establishment attempted during

t311



fails


RLF due to HO failure

from RRC Connection Reconfiguration:

mobilityControlInfo targetPhysCellId : 33 t304 : ms1000 newUE-Identity Bin : 14 EB (= 5355)

normal operation Attempting PRACH to target cell no recovery during T311 goes back to idle

radio link failure



RRC Conn ReConf with MobilityInfo (”HO command”)

RRC connection re-establishment

attempted to source or target cell during t311



fails

T304 running while UE

attempting access to target cell.

T304 expires


RLF due to non-HO random access failure

normal operation Attempting PRACH to serving cell no recovery during T311 goes back to idle

radio link failure



Example: Random Access triggered due to missing PUCCH SR resources, or

PDCCH order

RRC connection re-establishment

attempted to serving cell during

t311



fails

UE attempting random access to

serving cell.

RACH failure

• In RL10/RL20, PDCCH order -triggered RA is not supported

• Random Access Scheduling Request is supported


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.

• Reading the re-est cause IE is the only way to see why failure happened from UE point of view (no RRC re-est cause specific counters in RL10/RL20)


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


Example ‘UE drop call’ signalling RL10/RL20EventId Time Channel Direction Message

RRCSM 10:36:32.194 DCCH Uplink RRCConnectionReconfigurationComplete

RRCSM 10:36:32.216 BCCH-SCH Downlink SystemInformationBlockType1

RRCSM 10:36:32.345 BCCH-SCH Downlink SystemInformation

RRCSM 10:36:32.662 DCCH Uplink MeasurementReport

RRCSM 10:36:33.617 DCCH Uplink MeasurementReport

RRCSM 10:36:33.779 DCCH Downlink RRCConnectionReconfiguration

RRCSM 10:36:33.779 DCCH Uplink RRCConnectionReconfigurationComplete

RRCSM 10:36:35.344 BCCH-BCH Downlink MasterInformationBlock





RRCSM 10:36:35.422 CCCH Uplink RRCConnectionReestablishmentRequest

RRCSM 10:36:35.555 CCCH Downlink RRCConnectionReestablishmentReject

RRCSM 10:36:36.254 BCCH-BCH Downlink MasterInformationBlock


L3SM 10:36:36.254 Uplink TRACKING_AREA_UPDATE_REQUEST

RRCSM 10:36:36.254 CCCH Uplink RRCConnectionRequest

RRCSM 10:36:36.328 CCCH Downlink RRCConnectionSetup

RRCSM 10:36:36.328 DCCH Uplink RRCConnectionSetupComplete

RRCSM 10:36:41.382 DCCH Downlink DLInformationTransfer

L3SM 10:36:41.382 Downlink TRACKING_AREA_UPDATE_ACCEPT

L3SM 10:36:41.382 Uplink TRACKING_AREA_UPDATE_COMPLETE

In new cell

HO command


Outline

• UE radio link failure causes, T310 expiry• eNB radio link failure causes


• RLF triggering by eNB• Timing Alignment timer expiry

– At UE– At eNB

• eNB-triggered release due to maximum RLC retransmissions• eNB-triggered release due to GTP-U failure• Timers and constants (3GPP)


RL problem detection at eNB, generic info

• Radio link problem detection mechanisms are NSN-internally specified specified in Radio L1/U-plane/RRM SFSes

• 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 internal criteria and filtering with internal counters to decide when there is a radio link problem occurring and when there is a radio link problem recovery occurring.

• When the threshold of problem / problem recovery is reached, link monitor indicates this to L3.

• Link monitors in RL10/RL20:1. Uplink PUSCH DTX detection for scheduled uplink data (RRM SFS ID 2041)

2. CQI DTX detection for periodic CQI reports in PUCCH and PUSCH (Radio L1 SFS)

3. Uplink Ack/Nack DTX detection for transmitted downlink data (RRM SFS ID 2006)


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, PUSCH DTX is declared• The detection of the radio link problem by the uplink scheduler is based

on the comparison of UL grant assignment and the DTX detection on PUSCH for the assigned PRBs. The detection is based on the DTX PUSCH indication provided by the UL physical layer.

• The result is received by LTE MAC in reliableULtransmissionFlag parameter (which can be seen in UL TTI trace).

• LTE MAC performs RLF detection and recovery from PUSCH DTX functionality in UE basis if at least one of the vendor-specific parameters rlpDetMaxTUl and rlpDetMaxNUl is non-zero.

• If the eNB detects for multiple resource allocations for UL data transmission to the same UE “DTX “on the assigned PUSCH PRBs either for a configurable period of time (rlpDetMaxTimeUl) or for a configurable number of resource allocation attempts (rlpDetMaxNoUl), the UL scheduler sets the PUSCH_Rlf on.

• The recovery of the radio link is indicated when for a configurable number of contiguous UL resource assignments, data is detected on PUSCH. The required number of UL resource assignment for recovery from the radio link problem is specified by the vendor-specific O&M parameter rlpDetEndNoUl.



RLF detection in case of rlpDetMaxTUl is not zero:

• LTE MAC shall start timer rrmUlPuschDtxTimer with value rlpDetMaxTUl for the UE to which indication with reliableULtransmissionFlag=FALSE is received for the first time after indication with reliableULtransmissionFlag=TRUE.

• The timer rrmUlPuschDtxTimer shall be stopped when indication with reliableULtransmissionFlag=TRUE is received for the UE.

• If the timer rrmUlPuschDtxTimer reaches rlpDetMaxTUl value, LTE MAC shall indicate RLF of the UE to LTE UEC (UE Control program block) by using MAC_RadioLinkStatusInd message with rlsCause value RlsCause_PuschRlf_ON.

• RlsCause_PuschRlf_ON can be read in Emil trace or BTS UDP log

• reliableULtransmissionFlag can be read in UL TTI trace



RLF detection in case of rlpDetMaxNUl is not zero:

• LTE MAC shall count consecutive indications with reliableULtransmissionFlag=FALSE in UE basis and store the counter value to internal parameter rrmUlPuschDtxDetections.

• LTE MAC shall initialize the counter to zero and reset it after every indication with reliableULtransmissionFlag=TRUE. If a counter rrmUlPuschDtxDetections of some UE reaches rlpDetMaxNUl value, LTE MAC shall indicate RLF of the UE to LTE UEC by using MAC_RadioLinkStatusInd message with rlsCause value RlsCause_PuschRlf_ON.



RLF recovery, in case of RLF failure has been indicated to LTE UEC with cause RlsCause_PuschRlf_ON,

• LTE MAC shall count consecutive indications with reliableULtransmissionFlag=TRUE for those UEs for which the indication is sent and store the counter value to internal parameter rrmUlPuschTxDetections.

• LTE MAC shall initialize the counter to zero and reset it after every indication of reliableULtransmissionFlag=FALSE.

• If the counter rrmUlPuschTxDetections of a UE reaches rlpDetEndNUl value, LTE MAC shall indicate RLF cancellation of the UE to LTE UEC by using MAC_RadioLinkStatusInd message with rlsCause value RlsCause_PuschRlf_OFF.

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

UL grant

PUSCH RLF: RlsCause_PuschRlf, counter-based RLF detection example

time

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

3 2

vendor-file parameters in this example:

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

UL grant

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

relia

bleU

Ltra

nsm

issi

onF

lag=

FA

LS

E

UL grant

PUSCH_RLF ON

relia

bleU

Ltra

nsm

issi

onF

lag=

TR

UE

UL grant

PUSCH_RLF OFF

RLF timer running

downlink

uplink

T_RLF = T310 + T311


Periodic CQI RLF: RlsCause_CqiRlf_ON

Source: Radio L1 SFS • 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 UDP log/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 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 in PUSCH

Periodic CQI RLF: RlsCause_CqiRlf, example

time

CQ

I DT

X

Per

iodi

c C

QI d

etec

ted

6 1

vendor-file parameters in this example:

CQI_RLF ON

CQI_RLF OFF

RLF timer running

Per

iodi

c C

QI d

etec

ted

LNCEL/cqiPerNp=10ms

CQ

I DT

X

CQ

I DT

X

CQ

I DT

X

CQ

I DT

X

CQ

I DT

X

CQ

I DT

X

CQ

I DT

X

Per

iodi

c C

QI d

etec

ted

Per

iodi

c C

QI d

etec

ted

CQ

I DT

X

CQ

I DT

XT_RLF = T310 + T311


Uplink RF problems, Emil example

Example of UL

problems


Ack/Nack RLF: RlsCause_AckNackRlf_ON

Source: RRM SFS ID 2006

• After DL scheduled data, eNB expects HARQ ACK/NACK on PUCCH or PUSCH – The detection shall only consider transmission attempts where HARQ

ACK/NACK feedback by UE is expected by eNB.

• If for consecutive DL resource allocations to the same UE the HARQ feedback from the UE is always "DTX“, either for a configurable period of time or for a configurable number of consecutive DL resource allocation attempts (parameters rlpDetMaxTimeDl and rlpDetMaxNoDL), DL scheduler declares radio link problem.

• If for a configurable number (parameter rlpDetEndNoDl) of consecutive DL resource allocations to the same UE the HARQ feedback from the UE is not "DTX", DL scheduler undeclares radio link problems.

• Setting rlpDetMaxTimeDl=0 switches off time-based radio problem detection. Setting rlpDetMaxNoDL=0 switches off counter-based radio problem detection. If both options are disabled, radio problem detection based on UL Ack/Nack is disabled completely.


Random Access Scheduling Request detection

• RA_SR link state notification in eNB is triggered when we receive a RACH msg3 which contains a C-RNTI and the UE with this C-RNTI is already active in the cell (time alignment status for the UE is ‘in-sync’).

• This is not a radio link failure


Random Access Scheduling Request and L1 PUCCH reconfiguration, example from RL20• First RA_SR detected indicating that SR sending on PUCCH has failed and

PUCCH SR and CQI config was released by UE RA SR triggered

RA SR detected from UE

L1 PUCCH reconfiguration


Random Access Scheduling Request and L1 PUCCH reconfiguration, example from RL20

DL-DCCH-Message : { message c1 : rrcConnectionReconfiguration : { rrc-TransactionIdentifier 1, criticalExtensions c1 : rrcConnectionReconfiguration-r8 : { radioResourceConfigDedicated { physicalConfigDedicated { cqi-ReportConfig { cqi-ReportModeAperiodic rm30, nomPDSCH-RS-EPRE-Offset 0, cqi-ReportPeriodic setup : { cqi-PUCCH-ResourceIndex 10, cqi-pmi-ConfigIndex 27, cqi-FormatIndicatorPeriodic widebandCQI : NULL, ri-ConfigIndex 161, simultaneousAckNackAndCQI TRUE } }, soundingRS-UL-ConfigDedicated release : NULL, schedulingRequestConfig setup : { sr-PUCCH-ResourceIndex 35, sr-ConfigIndex 24, dsr-TransMax n64 } } } } }}

Periodic CQI reporting on PUCCH reconfigured

Scheduling Request resource on PUCCH reconfigured

RLF related parameters in vendor file, RL10

?xml version="1.0"?><raml version="2.1" xmlns="raml21.xsd"><cmData scope="all" type="actual"><header><log action="created" appInfo="AppName" appVersion="LN1.0"

dateTime="2010-11-17T10:28:13" user="Golden Vendor File Inc22"></log>

<log dateTime="Mon Jan 01 01:32:14 +0000 1990" action="modified" appInfo="RAMLH"></log>

</header><managedObject class="LNBTS" distName="LNBTS-*" operation="update"

version="LN1.0">

613310002050000


When is RRC + S1 release triggered by eNB?

Source: UE State handling SFS (July 29 2010)

• 3GPP does not specify eNB radio link failures, but NSN eNB mimics the behaviour of the UE RLF specified in 3GPP.

• 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

• T_RLF = T310 + T311


RLF triggering by eNB, signalling

eNBUE MME S-GW

S1AP: UE Context Release Command

S1AP: UE Context Release CompleteRRC: RRC Connection Release

Release all UE related resources,

remove UE context

Set UE to RRC-IDLE

Set UE to ECM-IDLE

Detect radio link problem, T_RLF

expires

S1AP: UE Context Release Request

S11 interaction to inform S-GWabout connection release

UE inRRC-CONNECTED


Cause Values for eNB initiated UE S1 Context release

Cause Value to be used Use Case Description (triggering eNB initiated UE context release)

Related SFS Requirements

Ongoing X2 handover is aborted for any reason where the UE has left the source cell and is not allowed to return

MM.1033

Ongoing S1 handover is aborted for any reason where the UE is not allowed to continue in the source cell

MM.1095

S1AP: ERROR INDICATION [syntax error] received at Source eNB in response to S1AP: HANDOVER CANCEL message

MM.1191

Security configuration becomes permanently inoperable and no other defense action is defined (or was unsuccessful)

SEC.704 & SEC.1003

RNL Unspecified

Key refresh procedure SEC.694 RNL User Inactivity eNB initiated release due to user inactivity UESH.420

eNB-initiated release due to radio link failure UESH.720 Rejection of RRC Connection Re-establishment Request

UESH.807

eNB initiated Release due to UE being out-of-sync UESH.974 Handling of Event “Maximum number of RLC retransmissions reached”

BM.462

Timer THOoverall expiry MM.990 Source eNB initiates UE context release due to a rejected RRC Connection Re-establishment

MM.1255

RNL Radio Connection with UE Lost

RRC Connection Re-establishment rejected at Target eNB for a UE performing Measurement Configuration

MM.1257

Failure to send RRC Connection Reconfiguration at Target eNB

MM.1060 RNL Failure in the Radio Interface Procedure

Handover Handling due to timer TRECGuardTimerRadioBearerManagement expiry

MM.1076

RNL TX2RELOCoverall Expiry Timer TX2RELOCoverall expiry at Source eNB MM.852 RNL TS1RELOCoverall Expiry Timer TS1RELOCoverall expiry at Source eNB MM.1144

Initiating UE context release with Redirect to LTE MM.1522 & UESH.1078

RNL E-UTRAN Generated Reason

Initiating UE context release without Redirect (redirection fails)

MM.1523 & UESH.1192

RNL Inter-RAT Redirection Initiating UE context release with Redirect to other RAT

MM.1522 & UESH.1078

Handling of Event “GTP-U Error Indication” (S-GW has rejected the reception of uplink data packets)

BM.389 TNL Transport Resource Unavailable

eNB intiated release due to GTP-U path failure detection (Note: Not used in RLT/RL05TD.)

UESH.1267

Path Switch Request Failure at Target eNB MM.725 TNL Unspecified

Timer TX2RELOCcomp expiry at Target eNB

MM.805


Outline




– At UE– At eNB



UL in-sync and out-of-sync substates

• RRC_CONNECTED substates: UL in-sync and UL out-of-sync

E-UTRARRC_IDLE

E-UTRA RRC_CONNECTED

TAUL in-sync

TAUL out-of-sync

RRC Connection Release

Expiry of Short Inactivity Timer (intentional)Timing maintenance issue (unintentional)

Contention-based RA success after UL data arrivalPDCCH order success after DL data arrivalPDCCH order success after Inactivity timer expirationRRC Connection Reestablishment

RRC Connection SetupRRC Connection Release

Radio link failure In RL10/RL20, if eNB detects UE out-of-sync, S1 + RRC are released

(dropped call)


TA timer expiry at UE

3GPP TS 36.321: When timeAlignmentTimer expires at UE, UE MAC layer shall:

- flush all HARQ buffers;- notify RRC layer to release PUCCH/SRS;- clear any configured downlink assignments and uplink grants

3GPP TS 36.331: Upon receiving a PUCCH/ SRS release request from MAC layer, the UE RRC shall:

• release CQI reporting config, ie it stops CQI reporting• release Scheduling Request Config

– Radio L2 SFS (July 29 2010): For RL09/RL10/RL20 the approach is to keep the UE always in-sync in UL. For later releases an alignment with RRC may be required in order to indicate to reassign PUCCH and SRS resources (i.e., at least on expiry of the timing alignment timer). The details are FFS yet.

– Bearer Management SFS: L1 reconfiguration to recover from TA expiry is not supported in RL10


TA timer expiry at eNB

Presentation / Author / Date

Maintenance of UL Time Alignment by eNB (source: Radio L2 SFS)

• UL TA update is done periodically and in addition on per-need basis. MAC entity provides PHY layer the information when a TA update is needed together with the TA update value. MAC entity in eNB shall send it to UE via Timing Alignment MAC control element.

• As UE detects Out-of-Sync status using a Timing Alignment Timer, the timer shall be started or restarted whenever an initial TA or a TA update command is received (see [3GPP-36.321], section 5.2). If the timer expires, the UE detects out-of-sync status.

• eNB needs to prevent UE TA timer from expiring, because in RL10/RL20 there is no way to bring UE back in-sync (without dropping call) if TA timer expires

• The interval between periodic TA update commands is based on the Timing Alignment Timer reduced by a configurable offset taTimerMargin.

• Radio L2 SFS: TA command period = TimeAlignTimer – taTimerMargin

• A configurable parameter TimeAlignmentMaxOffset is used to determine the maximum allowed timing alignment offset before a per-need timing alignment update is required.




• If the TA offset measured by the UL PHY layer is greater than the configurable threshold TimeAlignmentMaxOffset then a TA command is sent to the UE.

• If the reported TA offset also exceeds a threshold calculated in RL10 as taSchedulingThreshold = max(taOffsetSchedMgn, TimeAlignmentMaxOffset +0.5µs), the UL scheduler is informed that the UE is drifting out of alignment

• When HARQ ACK feedback is received for the TA command then:

• For a per-need TA command and when taSchedulingThreshold (see above) was exceeded: the UL scheduler is informed that the TA is OK again.

• The periodic timing alignment timer is (re)started.

• If no HARQ ACK feedback is received for a TA command within the maximum number of DL HARQ transmissions then:

• The TA update command shall be repeated up to a configurable maximum number of times taCommandMaxRetries or until the timing alignment timer expires; the latest available timing advance estimation shall be used for every repetition.

• If the maximum number of retries is exceeded or the timing alignment timer has expired, then status UE UL out-of-sync is detected TatExpiry seen in UDP Log and Emil

• Immediate release of RRC and S1 follows (there is no waiting for T_RLF expiry)



eNBUE MME S-GW

S1AP: UE Context Release Command

S1AP: UE Context Release CompleteRRC: RRC Connection Release

Release all UE related resources,

remove UE context

Set UE to RRC-IDLE

Set UE to ECM-IDLE

TA timer expires

S1AP: UE Context Release Request

S11 interaction to inform S-GWabout connection release

UE inRRC-CONNECTED

NOTE: TA out-of-sync causes

immediate release (no T_RLF involved)


TA timer expiry at eNB, Emil example


TaTExpiry followed by immediate S1 +

RRC release


TA timer expiry at eNB, user-configurable parameters


Parameter abbreviated Name

Description

Ac-cess

Parameter Type

Range/ Step-size

Default value

Para-meter Scope

Reference

Multi- plicity

taTimer Determines the number of subframes after which a UE assumes being Out-of-Sync in UL if no Time Alignment Command was received.

RW BTS restart

O {500, 750, 1280, 1920, 2560, 5120, 10240}

1280 cell 36.331 timeAlignmentTimer

1

taMaxOffset

Determines the maximum allowed time alignment offset. If value is exceeded the need for time alignment update is given.

RW O 0..5/0.01 Unit: μs

0.52 (corresponds to 16*Ts)

cell TF_LTE_SFS_RL2_697

1

Always check the current values (defaults and the actual used) of the eNB sw version in use.


TA timer expiry at eNB, vendor parameters


Parameter abbreviated Name

Description

Ac-cess

Parameter Type

Range/ Step-size

Default value

Para-meter Scope

Reference

Multi- plicity

taTimerMargin

Used to control the interval between periodic timing alignment commands being sent to the UE. The actual time interval between updates will be TimeAlignTimer – taTimerMargin The upper value is constrained by the value of TimeAlignTimer.

RW O 0..2560/1 Unit: subframes

89 Cell TF_LTE_SFS_RL2_697

1

taOffScheMarg

Used to determine when to no longer consider a UE that is drifting out of time alignment in uplink scheduling;

R V 1.5…4/0.1 unit: µs

2 BTS TF_LTE_SFS_RL2_697

1

taCmdMaxRetry

The number of times the TA command will be retried before MAC assumes the UE has gone out-of-sync.

R V 0..10/1 1

BTS TF_LTE_SFS_

RL2_697 1

Always check the current values (defaults and the actual used) of the eNB sw version in use.


LTE 473, eNB differentiation between in-sync and out-sync (RL30)

• RRC connected substates: UL in-sync and UL out-of-sync

E-UTRARRC_IDLE

E-UTRA RRC_CONNECTED

TAUL in-sync

TAUL out-of-sync

PDCCH order failure after DL data arrivalPDCCH order failure after Inactivity timer expiration

Expiry of Short Inactivity Timer (intentional)Timing maintenance issue (unintentional)

Contention-based RA success after UL data arrivalPDCCH order success after DL data arrivalPDCCH order success after Inactivity timer expirationRRC Connection Reestablishment

RRC Connection SetupRRC Connection Release

Radio link failure

Uplink RA SR or PDCCH order to bring UE back in-sync (RL30)


Ue out-of-sync recovery (RL30)

SOURCE: RRM_LTE_SFS_RRM.3849• Initiation of UE resynchronization with MAC• If for a UE being in UL out-of-sync state new data (either control or data PDUs from

RLC/PDCP for either SRBs or DRBs) arrive in (otherwise empty) eNodeB buffers for transmission in downlink, DRX manager shall initiate the procedure to resynchronize the UE in uplink by requesting a PDCCH order from (DL) MAC for the according UE. DRX manager shall provide information about the next UE DRX Active phase (i.e., the next on duration and its length) along with the request in order to enable MAC/DL scheduler to place the PDCCH order in time domain such that the UE will be able to receive it.

• DRX manager expects to receive back an indication of MAC about PDCCH order success (UE again UL in-synch) or about final failure (repetition of PDCCH order will be done in MAC, see RL2.1238).

• DRX manager shall not initiate multiple overlapping resynchronization procedures.• Note: following successful UE resynchronization, higher layers will reassign dedicated

resources on PUCCH and for SRS to the UE. As long as these are the same resources or at least resources with the same periodicity and reporting instances, there is no need to reconfigure the DRX Start Offset. Further development: As soon as this is not the case any more, configuration of dedicated resources on PUCCH will require reconfiguration of UEs DRX Start Offset; this in turn will require to enhance DRX reconfiguration procedure substantially as the restrictions as defined in RRM.2504 may no longer apply.

• Note: it is not foreseen that MAC control elements for the DL also trigger a resynchronization of a UE as there should be no need to transmit those in UL out-of-sync state.


Outline




– At UE– At eNB



RLC layer STATUS polling mechanism

Source: 3GPP 36.322 v8.8.0, June 2010, Bearer Management SFS, PDDB• RLC layer retransmissions only in RLC acknowledged mode• RLC AM transmitter requests a STATUS PDU from RLC receiver (sets

poll bit on in RLC header)– After the number of bytes transmitted since previous poll exceeds the value of

amRlcPBTab3ulPollByte (uplink, ue cat3) or amRlcPBTab3dlPollByte (downlink, ue cat3), or

– After pollPdu RLC PDUs have been transmitted since previous poll– in the last data PDU in the RLC transmit buffer

• The RLC AM receiver responds to polling request by transmitting a STATUS PDU which acknowledges successfully received PDUs and also selectively nacks unsuccessfully received PDUs (“selective NACK”). – RLC receiver will not send STATUS PDU more often than interval defined by

parameter tProhib.– RLC receiver also sends STATUS PDU if tReord timer expires (but not if timer

tProhib is running).– NOTE: with RL10 default PDDB settings tProhib=50ms and tReord=50ms.

• If RLC transmitter receives no STATUS PDU within tPollretr, a new poll request along with unacknowledged data will be sent to RLC receiver

• RLC AM window size is fixed to 512 RLC PDUs (segments of an RLC PDU are counted as one PDU).

RLC layer ARQ mechanism

Source: 3GPP 36.322 v8.8.0, June 2010, Bearer Management SFS, PDDB

• RLC transmitter will retransmit all nacked data in the STATUS PDU

• Maximum number of UL and DL RLC retransmissions is defined by vendor parameter drbAmMxRtxTh (default=16)

Rx

Tx

time

RLC P

DU

Poll b

it se

t

RLC Status

Polling trigger reached ACKed RLC PDUs can be removed from buffer

Ttransfer-1 Ttransfer-2Twait<= tProhib

AM RLC Round Trip Time


Release due to maximum number of RLC retransmissions (eNB-triggered)

Source: Bearer Management SFS

• RL10: When eNB detects that an RLC PDU has reached the maximum number of retransmissions, eNB releases the UE (S1 + RRC release). – vendor parameter drbAmMxRtxTh (default=16)

• RL30 (when RRC Conn Re-Est is supported): after max RLC retransmissions has been reached

eNB starts a timer to wait for an UE triggered RRC Connection Reestablishment. If the timer expires: eNB releases the UE.

Otherwise: UE has triggered a RRC Connection Reestablishment procedure and eNB performs the RRC Connection Reestablishment procedure (as for a RLF).


Release due to maximum number of RLC retransmissions (eNB-triggered, RL30)


UE eNB MME

S1AP: UE CONTEXT RELEASE REQUEST

RRC Connection Reestablishment procedure

eNB detects RLC maximum

retransmission event

eNB waits for RRC reestablishment by

UE (timer controlled)

Timer expiresCase Timer expiration

UE detects RLF or RLC maximum

retransmission event

UE CONTEXT RELEASE procedure

UE starts Reestablishment

NOTE: In RL10, eNB releases S1 + RRC immediately (since RRC Conn Re-Est

not supported)

NOTE: supported in

RL30


Release due to maximum number of RLC retransmissions (eNB-triggered, RL10 example)

Max DL RLC retrans RRC release


Outline




– At UE– At eNB



Release due to GTP-U Error Indication from S-GW (eNB-triggered)


• Handling of Event "GTP-U Error Indication" (single S1 bearer, RL10)

• eNB may receive a “GTP-U Error Indication” on an active (single) S1 bearer (S-GW has rejected the reception of uplink data packets) - for more details see [DATAPATH SFS].871. In that case eNB shall send the S1AP message UE CONTEXT RELEASE REQUEST with cause “TNL Cause Transport Resource Unavailable” to MME - for details see [UESTATE SFS].720).

• NOTE: error behaviour in RL10 (as of Feb’11), GTP-U error triggered sometimes in normal release increments TNL drop shows in drop KPIs to be fixed in future sw.


Release due to GTP-U Error Indication from S-GW (eNB-triggered)

GTP-U Error received from S-GW release S1 + RRC


Outline




– At UE– At eNB



Timers (3GPP 36.331 v8.8.0)


Timer Start Stop At expiry

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

Perform the actions as specified in 5.3.3.6

T301 Transmission of RRCConnectionReestabilshmentRequest

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

Go to RRC_IDLE

T302 Reception of RRCConnectionReject while performing RRC connection establishment

Upon entering RRC_CONNECTED and upon cell re-selection

Inform upper layers about barring alleviation as specified in 5.3.3.7

T303 Access barred while performing RRC connection establishment for mobile originating calls



T304 Reception of RRCConnectionReconfiguration message including the MobilityControl Info orreception of MobilityFromEUTRACommand message including CellChangeOrder

Criterion for successful completion of handover to EUTRA or cell change order is met (the criterion is specified in the target RAT in case of inter-RAT)

In case of cell change order from E-UTRA or intra E-UTRA handover, initiate the RRC connection re-establishment procedure; In case of handover to E-UTRA, perform the actions defined in the specifications applicable for the source RAT.


Timers (3GPP 36.331 v8.8.0)


Timer Start Stop At expiry

T305 Access barred while performing RRC connection establishment for mobile originating signalling



T310 Upon detecting physical layer problems i.e. upon receiving N310 consecutive out-of-sync indications from lower layers

Upon receiving N311 consecutive in-sync indications from lower layers, upon triggering the handover procedure and upon initiating the connection re-establishment procedure

If security is not activated: go to RRC_IDLE else: initiate the connection re-establishment procedure

T311 Upon initiating the RRC connection re-establishment procedure

Selection of a suitable E-UTRA cell or a cell using another RAT.

Enter RRC_IDLE

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

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

Discard the cell reselection priority information provided by dedicated signalling.

T321 Upon receiving measConfig including a reportConfig with the purpose set to reportCGI

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

Initiate the measurement reporting procedure, stop performing the related measurements and remove the corresponding measId


Constants (3GPP 36.331 v8.8.0)


Constant Usage

N310 Maximum number of consecutive "out-of-sync" indications received from lower layers

N311 Maximum number of consecutive "in-sync" indications received from lower layers

Here the terms “in-sync” and “out-of-sync” refer to generic PHY layer problems, not Time Alignment timer expiry.

10 drop call analysis v1_5

Documents

ue ta timer

ta expiry

initial ta

connected ta ul

ta update value

ta command period

ue rrc

timing alignment update