Random Access Channel (RACH) in LTE

Dalam jaringan LTE, proses RACH terbagi menjadi dua bagian yaitu contention-based dan contention-free. RACH akan dilakukan oleh setiap UE ketika :

- Melakukan initial akses ke jaringan atau RRC Connection Request

- Jaringan sedang down

- UE melakukan handover, {eNB mengalokasikan scheduling grant ke eNB target}

- Sinkronisasi UL hilang

- Ketika UE tidak mempunyai resource/bandwidth untuk mengirim data

Sebelum dilakukan RACH, UE harus memilih secara acak preamble yang disediakan oleh eNB. Dalam jaringan LTE, setiap cell mempunyai 64 preamble yang khusus digunakan untuk RACH contention based. UE memilih secara acak berarti ada kemungkinan 2 UE memilih preamble yang sama. Sow pada waktu yang sama preamble tersebut akan tiba di eNB dalam waktu yang sama yang menyebabkan terjadinya collision “tabrakan”. Kejadian tabrakan tersebut sering disebut “contention” :D dan proses RACH yang mengatasi masalah ini disebut “contention-based”. Makanya disebut RACH contention-based haha…

eNB akan  mengatasi masalah tersebut dengan suatu proses yang disebut “contention-resolution”

Pada kasus RACH contention-free, eNB memberikan preamble ke UE atas kehendak UE. Jadi UE tidak memilih preamble tersebut secara acak. Hal ini dilakukan jika UE ingin berpindah dari suatu cell ke cell lain atau sering disebut sebagai handover. Sow… preamble yang diberikan ke UE pada kasus ini tidak akan mengalami collision makanya RACH ini disebut sebagai contention-free. Namun untuk melakukan RACH contention-free, UE harus berada dalam state Connected Mode. Prosedur yang sangat sederhana untuk menggambarkan contention-free ini seperti terlihat di bawah :

i) UE --> eNB : RACH Preamble Assignment

ii) UE <-- eNB : RACH Preamble (RA-RNTI, petunjuk untuk ukuran L2/L3 message)

iii) UE --> eNB : Random Access Response (Timing Advance Command, C-RNTI, UL grant untuk L2/L3 message)

Kembali ke RACH contention-based. Ilustrasi yang paling-paling sederhana untuk contention-based ini seperti terlihat pada langkah-langkah di bawah :

i) UE --> eNB : RACH preamble (RA-RNTI, menunjukkan ukuran L2/L3 message)

ii) UE <-- eNB : Random Access Response (Timing Advance, T_C-RNTI, UL grant untuk L2/L3 message)

iii) UE --> eNB : L2/L3 message

iv) UE <-- eNB : message untuk contention resolution

Jika pada step 1 terjadi collision, contohnya 2 UE mengirim PRACH yang sama. Maka dalam hal ini kedua UE tersebut akan menerima T_C-RNTI dan resource yang sama dari eNB pada step ke-2. Sehingga kedua UE tersebut juga akan mengirim L2/L3 message pada alokasi resource yang sama (dalam hal ini lokasi time/frequency yang sama) ke eNB pada step 3. Jika hal ini terjadi maka L2/L3 message yang dikirim UE tersebut akan berinterferensi dan eNB tidak dapat mendecode kedua L2/L3 message tersebut. Dalam kasus ini,  tidak satupun UE yang akan menerima response dari eNB berupa  HARQ ACK sehingga kedua UE menganggap bahwa RACH process telah gagal dan akan kembali mengulangi langkah pertama. Kemungkinan lain yang bisa terjadi adalah eNB dapat melakukan decode terhadap salah satu L2/L3 message dari salah satu UE. Nah dalam kasus ini, UE yang L2/L3 messagenya sukses di decode oleh eNB akan mendapat respon berupa HARQ ACK. HAR             Q ACK inilah yang disebut “contention resolution” process.

Lebih jauh pada contention-based. Pada step 1 UE akan mentransmit preamble dengan aturan seperti terlihat pada table di bawah  (dari 3GPP specification TS36.211-tabel 5.7.1-2) :

Sesuai table di atas, jika UE menggunakan “PRACH Configuration Index 0” maka UE tersebut akan mentransmit preamblenya pada SFN (System Frame Number) yang genap pada subframe pertama untuk setiap SFN yang genap. Kemudian jika memperhatikan dengan seksama table di atas, maka PRACH Configuration Index 14 adalah preamble yang paling mudah bagi eNB didecode karena UE dapat mengirim PRACH pada semua SFN dan semua slot pada frame.

Jika telah diketahui waktu UE untuk mengirim preamble, maka pertanyaan berikutnya adalah kapan seharusnya eNB akan merespons preamble tersebut ? nah untuk menjawab pertanyaan ini maka kita dapat mengacu ke 3GPP TS36.321, bab 5.1.4 :

“Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the RA Response window which starts at the subframe that contains the end of the preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes.”

Dari penggalan paragraph tersebut dapat diketahui bahwa eNB akan merespond RACH Preamble paling cepat setelah 3 subframe (3 ms) berikutnya saat RACH preamble tiba di eNB. Kemudian respon yang paling lambat sesuai ukuran window dari preamble. Ukuran window setiap preamble dapat berawal dari 0 sampai 12 subframe, sehingga dapat disimpulkan bahwa waktu paling lambat eNB merespon preamble dari UE adalah 12 ms. Wew…12 ms masih merupakan waktu yang sangat cepat :-S.

Kemudian konfigurasi dari RACH message dapata dilihat pada 3GPP 36-331. Pada TS tersebut bisa dilihat pada SIB2, seperti terlihat di bawah :