lect_RACH

7/30/2019 lect_RACH

http://slidepdf.com/reader/full/lectrach 1/37

EETS 8316

Wireless NetworksFall 2012

Shantanu [email protected]

Lecture: Random Access in LTEhttp://lyle.smu.edu/~skangude/eets8316.html

7/30/2019 lect_RACH


7/30/2019 lect_RACH


RACH for 6 Events

• Initial access from RRC_IDLE• RRC Connection Re-establishment procedure

• Handover

• DL data arrival during RRC_CONNECTED requiring random

access procedure– E.g. when UL synchronization status is “non-synchronized”

• UL data arrival during RRC_CONNECTED requiring randomaccess procedure– E.g. when UL synchronization status is "non-synchronized" or there

are no PUCCH resources for SR available• For positioning purpose during RRC_CONNECTED requiring

random access procedure– E.g. when timing advance is needed for UE positioning

7/30/2019 lect_RACH


2 Types of RACH Procedures

• Contention Based– Resources in contention pool for UEs to

randomly select

– UEs may choose identical “resources”

• Non-Contention Based– Some resources are reserved and can only

be assigned in a contention free manner byeNB; not available in the pool for randomselection

– UEs are assigned specific “resources” by eNB

7/30/2019 lect_RACH


RACH Events and Types (1/2)

• Non Contention Based

– Can be done for cases where eNB “knows” or“prods” a UE for RACH

– Which of the 6 events qualify?• Initial Access – NO

•RRC Conn. Re-establishment - NO

• Handover – YES, since eNB controlled handovers

• DL Data arrival – YES, since eNB has new data•UL Data arrival – NO

• Posit ioning – YES, since eNB needs to position

the UE (in RRC Connected mode)

7/30/2019 lect_RACH


RACH Events and Types (2/2)

• Contention Based

– Can be done for cases where UE “knows” or“initiates” RACH

•But UE always knows ULTIMATELY•So all cases except Positioning can use Contention-

based

– Why do contention based if non-contention

based available… for HO and DL data arrival?•Because the resources set aside for contention-free

assignment are limited in number… and may be ALLASSIGNED ALREADY

7/30/2019 lect_RACH


RACH Resources: Preambles

• 64 Mutually Orthogonal Preambles

– CDMA like – each preamble transmission canbe detected even with other preamble

transmissions

• RACH = Assert a Preamble in a RACHslot/subframe (a Resource block in 1ms)

• Collision = 2 UEs transmit the samePreamble in the same RACH slot

7/30/2019 lect_RACH


2 Sets: Collision-based and Non-

Collision-Based• 64 Preambles into 2 sets

– N Preambles in the set for collision-based RACH• UEs choose preambles randomly out of this set to use

• Chance that multiple UEs choose the same preamble =>Collisions possible

– (64-N) Preambles in the set for non-collision-basedRACH

• eNB alone can assign these for specific slots to specific UEs

• UEs can only use these, if assigned by the eNB, and for thespecific slots assigned => contention-free

• Since COLLISION-BASED is the default fall-back option, more Preambles in that set

7/30/2019 lect_RACH


Contention Based RACH

7/30/2019 lect_RACH


Contention Based RACH: Basics

• Que: What’s this “Contention Resolution” here?

7/30/2019 lect_RACH


Steps 1 & 2

• 1: UE picks a Preamble randomly and transmits

• 2: eNB responds to a Preamble Detected

– Semi-synchronous (within a flexible window of which thesize is one or more TTI) with message 1;

– No HARQ yet

– Addressed to RA-RNTI on PDCCH

– Conveys at least• RA-preamble identifier

• Timing Alignment information• initial UL grant

• assignment of Temporary C-RNTI (which may or may not bemade permanent upon Contention Resolution)

7/30/2019 lect_RACH


J ustification for Mesg 2 Contents

• Preamble Identifier– Different Preambles will be assigned different timing

advance

– RA-RNTI does not identify a Preamble

• Timing advance: of course

• C-RNTI– Basic identity to participate in the Radio Network; for

PDCCH assignments etc.

• UL allocation for Mesg 3– Only those receiving Mesg2 should attempt Mesg3

– Plus UL allocation needed anyways

7/30/2019 lect_RACH


Step 3: First Scheduled UL TX (1/2)

• Uses HARQ• For initial access:

– Conveys the RRC Connection Request generated by theRRC layer

– Conveys at least NAS UE identifier but no NAS message– RLC TM: no segmentation

• For RRC Connection Re-establishment procedure:– Conveys the RRC Connection Re-establishment Request

generated by the RRC layer

– RLC TM: no segmentation

– Does not contain any NAS message

Note: NAS = Non-Access Stratum is a control plane protocol for the UE and the corenetwork

7/30/2019 lect_RACH


Step 3: First Scheduled UL TX (2/2)

• After handover, in the target cell:– Conveys the ciphered and integrity protected

RRC Handover Confirm generated by the RRClayer

– Conveys the C-RNTI of the UE (which wasallocated via the Handover Command)

– Includes an uplink Buffer Status Report whenpossible

• For other events:– Conveys at least the C-RNTI of the UE

7/30/2019 lect_RACH


J ustification of Mesg 3 Contents

• RRC Handover Confirm, Conn. Request,Conn. Re-establishment Request etc.

– Start the process for which the RACH wasdone

• C-RNTI

– Resolve Contention

7/30/2019 lect_RACH


Contention in Step 3

• Collision Scenario

– Multiple UEs transmit the same Preamble

– The Preamble is detected, and the eNB

responds with UL ALLOCATION for the UE– All who transmitted Preamble assume the

allocation is for them

• All of the them transmit in the UL allocation in step 3

• Collision happens in the UL allocation• No UL step is detected => No step 4 can happen

• UEs redo the RACH procedure… hopefully they donot choose identical Preamble with another UE

7/30/2019 lect_RACH


Step 4 Confirms No Collision?

• If Mesg 3 is successfully received by the eNB =>No collision in Mesg 3

– But UEs are still not confirmed that there was nocollision. Why?

– UEs do not know if their Mesg 3 was successful

– eNB needs to acknowledge Mesg 3 success

– Mesg 4 in the DL acknowledges successful Mesg 3=> “All is well” and RACH successful

• Mesg 4 with UE identity included => No moredoubts about collision => RACH success

7/30/2019 lect_RACH


Message 4 (1/2)

• Not synchronised with message 3• HARQ is supported

• Addressed to:

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

– The C-RNTI on PDCCH for UE inRRC_CONNECTED

• For initial access and RRC Connection Re-establishment procedure, no segmentation isused (RLC-TM)

7/30/2019 lect_RACH


Message 4 (2/2)

• The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA successand does not already have a C-RNTI

– E.g. Initial access => no pre-existing C-RNTI

• It is dropped by others. A UE which

detects RA success and already has a C-RNTI, resumes using its C-RNTI

– E.g. Any UE already RRC connected

7/30/2019 lect_RACH


Non-Contention Based RACH

7/30/2019 lect_RACH


Non Contention Based RACH: Basics

Preamble and Slot Identifies the exact UE for the eNB

7/30/2019 lect_RACH


Step 0: Preamble Assignment

• Within same eNB… for DL data arrival andPositioning

– Signaled via PDCCH– Note we cannot do DL-SCH transmissionswith HARQ since UL is not synched

• Across eNBs in Handover

– Signaled via HO command generated bytarget eNB and sent via source eNB

7/30/2019 lect_RACH


Step 1 and 2

• 1: UE transmits in the exact slot with the exactPreamble as assigned to it

• 2: The eNB responds with Mesg 2 on DL-SCH

– Semi-synchronous (within a flexible window of whichthe size is two or more TTIs)

– No HARQ

– Addressed to RA-RNTI on PDCCH

– Conveys at least:• Timing Alignment information and initial UL grant for

handover

• Timing Alignment information for DL data arrival

• RA-preamble identifier

7/30/2019 lect_RACH


Simplicity of Non-Contention BasedRACH Procedure

• No Mesg 3 is part of the RACH procedure, sinceMesg 2 completes the process without anycollision doubts

– For HO though, there is a Mesg 3 allocation to the UEto transfer the HO Confirm, and continue operation

• Mesg 2 looks very similar to that in the

contention-based RACH– No collision is known to both UE and eNB

– Timing advance adopted by the UE, and normaloperation proceeds

7/30/2019 lect_RACH


Specific RACH Events

7/30/2019 lect_RACH


1. RACH for Initial Access

• UE goes from RRC_IDLE toRRC_CONNECTED

• Always Contention Based RACH

• Mesg 3 contains info to start an RRCconnection, and any credentials info

7/30/2019 lect_RACH


2. RACH for RRC Connection

Reestablishment

7/30/2019 lect_RACH


What is RRC Conn. Reestablishment

• When Radio problems detected, instead of going to RRC_IDLE and BRUTE restarting,UEs try a “partial reset”

• For reestablishment,– RRC context has to be present at the eNB

– Security etc. should be already established

• Partial Reset => all radio bearers are

suspended EXCEPT– Signaling Radio Bearer 1, the basic flow for

control = SRB1http://howltestuffworks.blogspot.com/2011/10/rrc-connection-reestablishment-request.html

7/30/2019 lect_RACH


RRC Conn. Reestablish., When?

• Essentially some sort of Radio Failure

– Upon detecting radio link failure; or

– Upon handover failure; or

– Upon mobility from E-UTRA failure; or– Upon integrity check failure indication from

lower layers; or

– Upon an RRC CONNECTIONRECONFIGURATION failure

7/30/2019 lect_RACH


Radio Link Failure Example

• 2 Phases before full reset to RRC_IDLE– Phase 1: Keep trying to see if things start working

for a TIMEOUT T1

– Phase 2: Attempt RRC Conn. Re-establishmentfor TIMEOUT T2

7/30/2019 lect_RACH


Radio Link Failure: Phase 1

• Started upon radio problem detection

• Leads to radio link failure detection

– Unless recovered• No UE-based mobility

– Note that this is generally cell-reselection…so in phase 1, the UE stays in the same cell

• Based on timer or other (e.g. counting)criteria (T1)

7/30/2019 lect_RACH


Radio Link Failure: Phase 2

• Started upon radio link failure detection orhandover failure

• Leads to RRC_IDLE– Unless recovered through RRC Conn. Re-estab.

• UE-based mobility

– Cell re-selection

• Timer based (T2)

7/30/2019 lect_RACH


Mobility and Radio Link Failure

7/30/2019 lect_RACH


When RRC Conn. Reestab. Attempted

• UE stays in RRC_CONNECTED, and does RACH

• UE ID used in RACH for contention resolution (i.e.C-RNTI of the UE in the cell where the RLFoccurred + physical layer identity of that cell + short

MAC-I based on the keys of that cell) is used by theselected eNB to authenticate the UE and checkwhether it has a context stored for that UE– If the eNB finds a context that matches the identity of the

UE, it indicates to the UE that its connection can beresumed

– If the context is not found, RRC connection is releasedand UE initiates procedure to establish new RRCconnection. In this case UE is required to go viaRRC_IDLE

7/30/2019 lect_RACH


3. Handover

Will be treated in detail in Mobilityslides

7/30/2019 lect_RACH


RRC Connected RACH cases 4,5,6

• DL data arrival, but UL not synched for HARQACK-NACKs– Simple contention-free RACH mostly

– Contention-based RACH available as well• UL data arrival, but no scheduling requestchannel assigned, or UL allocation available– Basic contention based RACH required

• Positioning– Way to find the UE distance from the eNB

– Like DL data arrival, simple contention-free RACH

7/30/2019 lect_RACH


Summary

• 6 cases for RACH Access

• Contention based RACH

• Non-contention based RACH

Documents

lect_RACH