ZTE MF90 Network Selection

Login ke main menu lewat laptop atau HP, atau tablet...

Pilih setting seperti ditunjukkan panah ijo di atas...Terus pilih tab "Network" terus pilih yang network selection kyk gini :

Naaaah.....

{sebelumnya diskonek dl modemnya biar bisa ngesave konfig yang baru..}

Iseng Maen ZTE MF90 LTE

Berikut tampilan dan buku petunjuknya :

Home Gateway/Page settingan :

Untuk lebih jelasnya silahkan lihat video di bawah :

Terus Hasil test speed test pagi ini  {28 September 2016} :

Resource Allocation Type

Type resource allocation mendefinisikan cara bagaimana scheduler mengalokasikan resource block untuk setiap transmisi. Dalam istilah 'flexibility', cara untuk memberikan resource block dengan flexibilitas yang maksimum akan menggunakan deretan bit map (bit stream), setiap bit tersebut akan merepresentasikan setiap resource block group. Dengan cara tersebut akan dapat dicapai flexibilitas yang maksimum tetapi akan menghasilkan banyak proses kompilasi dari resource allocation atau terlalu banyak data (bit map yang terlalu panjang) untuk mengalokasikan resourcenya.
Oleh karena itu LTE memperkenalkan beberapa type dari resource allocation dan tiap tipe tersebut menggunakan prosedur yang telah terdefinisi sebelumnya. Ada tiga tipe resource allocation dalam LTE, yaitu resource allocation type 0, 1, dan 2. Penggunaan tiap tipe ini ke dalam tiap DCI seperti terlihat pada tabel di bawah :

Perlu diketahui bahwa sampai saat release 10, DCI format sudah mencapai DCI format 4, namun pada tabel di atas hanya ditampilkan sampai DCI format 2 saja, untuk format di lain belum dapat ditampilkan.

Resource Allocation Type 0
Resource allocation tipe 0 adalah cara yang paling sederhana dalam mengalokasikan resource allocation. Pertama resource blok dibagi menjadi group. Group ini sering disebut sebagai Resource Block Group (RBG). Jumlah resource block dalam tiap group tergantung pada sistem bandiwidth yang digunakan. Artinya ukuran RBG berbeda-beda tergantung pada system bandwidthnya. Hubungan antara ukuran RBG (jumlah resource block dalam RBG) dengan sistem bandwidth seperti terlihat pada tabel di bawah :

Sebagaimana diketahui bahwa resource allocation tipe 0 mengalokasikan resource dengan menggunakan bit map dan tiap bit tersebut mewakili satu buah resource block group. Susunan pada RA 0 ini adalah "RB --> RBG" dan resource allocation dilakukan pada level RBG. Contoh di bawah mungkin dapat memperjelas ilustrai RA 0 ini. Ilustrasi ini menggunakan sistem bandwidth 10 Mhz. Satu hal yang harus selalu diingat bahwa setiap bit map merepresentasikan satu RBG, bukan satu RB.

Field pertama yang perlu diperhatikan yaitu "RB-Assign". RB-assign berjumlah 17 bit yang diperoleh dari perhitungan berikut. Pertama sistem bandwidth adalah 10 Mhz berarti jumlah maksimum resource blocknya adalah 50. Nah jumlah maksimum tersebut jika kita cocokkan dengan tabel 7.1.6.1-1 pada ilustrasi di atas akan diperoleh bahwa RBG size adalah 3. Sow 1 bit map yang merepresentasikan 1 RBG akan memiliki 3 buah resource block atau PRB. Jika indeks PRB dimulai dari 0 - 49 (total 50), maka RBG atau bit map yang dibutuhkan adalah 49/3 = 17. Nah ketemu deh jumlah bit mapnya 17 biji ;) * moga jelas wkwkwk

Kemudian jika melihat deretan bit RB-assign = 00110100000000000. Kita liat ada 3 biji bit 1, berarti jumlah RBG-nya adalah 3 buah. Karena 1 RBG = 3 RB, maka total RB adalah 9 RB. Telah diketahui bahwa 1 RB itu sama dengan 12 RE (resource element atau sering juga disebut subcarrier dalam domain frekuensi) maka total RE adalah 12 x 9 = 108. Nah sampai di sini telah diketahui bahwa terdapat 108 RE. Setelah itu mari kita lihat field "MCS" yang bernilai '0'. Jika MCS ini kita cocokkan dengan tabel 7.1.7.1-1 "Modulation and TBS index table for PDSCH" yang terdapat pada TS 36213 7.1.7.1, seperti terlihat di bawah : (tabelnya sebagian aja, soalnya agak panjang)

Pada tabel terlihat bahwa untuk indeks MCS = 0, maka modulation ordernya ada 2. Hal ini berarti 1 RE = 3 bit. Sooowww..... 108 RE = 108 x 2 bit = 216 bit. Nah dari sini telah diketahui bahwa MAC layer dapat melakukan uplink sebanyak 216 bit pada transmisi berikutnya.

Resource Allocation Type 1
Resource tipe 1 ini juga menggunakan bitmap untuk mengalokasikan resource block, namun pada RA 1 ini ditambahkan beberapa susunan atau layer. Layer baru ini disebut sebagai subset RBG. Sehingga total hierarki RA tipe 1 adalah "RB-->RBG-->RBG subset" dan resource allocation dikerjakan pada revel RBG subset. Satu RBG subset dibentuk dari beberapa buah RBG. Namun jumlah RBG dalam tiap RBG subset juga tergantung dari sistem bandwidth yang digunakan. Hal yang perlu diperhatikan dalam RA tipe 2 ini yaitu:

• Setiap bit dalam bitmap sudah langsung merepresentasikan 1 buah RB
• Setiap RBG dialokasikan secara berurutan "across" beberapa RBG subset, seperti terlihat pada contoh di bawah 
• Jumlah subset sama dengan jumlah RB dalam RBG
• Tidak semua RB dapat dialokasikan karena jumlah subset tidak cukup untuk menkover semua RB

Contoh di bawah moga memberikan penjelasan yang lebih pas, pada contoh ini digunakan sistem bandwidth 10 Mhz.

Nah mari perhatikan field "RAType1", jumlah bit dalam field ini juga adalah 17 buah. Untuk memperoleh jumlah bit tersebut caranya sama dengan resource allocation tipe 0 sebelumnya. Namun pada RAType ini, 2 bit pertama menandakan subset, 1 bit berikutnya adalah shift, dan sisanya baru menunjukkan RB-Assign sebanyak 14 bit. Telah disebutkan di atas bahwa jumlah bit dalam bitmap atau RB-Assign sudah langsung menunjukkan jumlah resource block. Nah jika melihat RB-Assign tersebut hanya terdapat 3 buah bit 1, berarti jumlah resource blocknya ada 3 biji. Jika jumlah resource block ada 3 maka Resource Element (RE) = 3 x 12 = 36 RE. Sow.. klu udah dapat jumlah RE, langkah berikutnya adalah melihat field "MCS". MCS juga menunjukkan nilai 0, berati 1 RE = 2 bit. Sehingga jumlah bit total adalah 36 x 2 = 72 bit, selesai dah...!

Resource Allocation Type 2

Dalam RA type 2 ini, eNB mengalokasikan RB yang bersifat "contiguous", contiguous artinya berdekatan kali yah... ? :p. Contiguous RB tersebut adalah konsep "virtual" bukan konsep secara "physical". Ini berarti bahwa sekalipun MAC layer mengalokasikan beberapa contiguous RB, RB tersebut mungkin dapat secara tidak berurutan akan ditransmisikan pada PHY layer. Jadi harus ada aturan atau algoritma yang mengubah logical (virtual) RB allocation ini ke dalam bentuk physical RB allocation.
Ada dua tipe dari aturan konversi ini, yaitu localized dan distributed. Ketika digunakan localized maka baik virtual allocation ataupun physical allocation mengalokasikan RB dalam bentuk contiguous. Kemudian ketika digunakan distributed, virtual RB allocation bersifat contiguous namun physical allocation tidak bersifat contiguous, physical mendistribusikan RB pada range frekuensi secara keseluruhan. Di bawah ini adalah contoh ilustrasi untuk RA tipe 2 ini. Saya pikir ilustrasi ini sudah begitu jelas, jadi tidak usah ada penjelasan lagi dibawahnya. Pada contoh ini digunakan sistem bandwidth 10 Mhz juga.

From : sharetechnote
Reference:
TS-36.213 7.1.6 Resource Allocation

Resource Element Groups

Informasi control untuk downlink pada physical channel dimasukkan ke dalam suatu resource unit yang lebih kecil dari pada resource block. Alasan melakukan hal ini adalah melakukan distribusi transmisi melalui banwdith yang lebih besar untuk memperoleh frequency-diversity. Sebagaimana telah diketahui bahwa control information secara umum lebih kecil daripada data dan jika resource block digunakan untuk transmisi control information, transmission akan menjadi bersifat lokal dalam domain frekuensi, hal ini tentu tidak diharapkan dari sudut pandang control-channel-perfomance. Unit resource yang digunakan untuk transmisi control information sering disebut sebagai resource element group (REG), yang terdiri dari 4 buah subcarriers (resource elements) dalam resource block pada OFDM symbol. Sebuah resource block berisi dua atau tiga  REG tergantung dari resource block dalam OFDM symbol apakah membawa reference signal atau tidak, seperti pada gambar di bawah :

Ketika terdapat reference signal dalam resource block, 4 dari 12 subcarrier digunakan untuk transmisi reference signal tersebut. 8 subcarriers yang tersisa kemudian akan digunakan untuk membentuk dua buah REG. Harus diketahui bahwa posisi subcarrier reference signal dalam resource block tidak tetap dan tergantung pada pergeseran frekuensi yang digunakan dalam tiap Cell atau eNB.

Resource element group direpsentasikan dengan pasangan index (k',l') dari resource element dengan k adalah index terendah dalam group dengan semua resource element dalam group yang mempunyai nilai yang sama dengan l. Jumlah maksimum REG yaitu 4 buah OFDM simbol dalam sebuah subframe. Hal ini karena PDCCH hanya dapat mencapai maksimum 4 OFDM simbol dalam bandwidth yang kecil. Simbol OFDM yang pertama selalu mempunyai satu atau dua reference signal. Kemudian simbol OFDM kedua berisi dua reference signal untuk antena ports 2 dan 3 dalam kasus 4 cell-specific reference signal. Dalam kasus simbol OFDM pertama dan keduaketika jumlah port antenna dikonfigurasi jadi empat, maka terdapat 2 resource-element group dalam physical resource block n_prb yang terdiri dari resource element (k,l) dengan :

ko menunjukkan resource element pertama dalam resource block dan dirumuskan sebagai :

Harus dicatat bahwa sekalipun single cell-specific reference signal dikonfigurasi pada port antenna 0, resource element yang dicadangkan untuk reference signal port antenna 1 tetap tidak digunakan. Kita mengetahui bahwa setiap REG didefinisikan pada 6 resource element karena dua resource element digunakan untuk reference signal.
Di symbol OFDM kedua dalam kasus hanya satu atau dua cell-specific reference signal yang dikonfigurasi, symbol ketiga dan keempat, tiga resource element group pada physical resource block n_prb terdiri dari resource element(k,l) dengan :

Mapping dari symbol-quadruplet z(i+2),
z(i+3)> ke resource element group disimbolkan dengan resource element (k',l') didefinisikan sehingga element z(i) dimasukkan ke resource element (k,l) dari resource element group tidak digunakan untuk cell-specific reference signal dalam urutan naik dari i dan k. Alasan mendefinisikan istilah symbol-quadraplets dan kemudian menggunakan empat resource elements untuk REG adalah untuk mengontrol channel dapat menggunakan sampai empat layer SFBC-FSTD skema transmit diversity.

Channel Coding Processing for DL-SCH,PCH,MCH

Hal pertama yang harus dilakukan untuk memahami chanel coding processing di physical ini adalah familiar dengan bagan di bawah :

hal yang sangat penting untuk diketahui dari bagan di atas adalah inputnya berupa transport block dari MAC layer, dan outputnya adalah IQ data yagn akan ditrasmit oleh physical layer. Jadi dari bagan tersebut proses secara keseluruhan adalah mengubah transport block dari mac layer menjadi bit stream data yang siap dikirimkan oleh physical layer.
Nah sekarang mari melangkah ke bagan pertama yaitu, CRC Attachment. Proses ini cukup sederhana yaitu hanya menambahkan 24 bit CRC pada akhir setiap data pada transport block. Ilustrasi seperti terlihat di bawah :

Kemudian step berikutnya adalah Segmentasi code block CRC. Prinsip kerjanya yaitu memotong transport block dari step pertama menjadi block-block yang lebih kecil kemudian menambahkan CRC lagi pada setiap block2 kecil tersebut. Step dua ini terdengar sederhana, namun pertanyaannya mengapa block2 tadi harus dipecah lagi menjadi block2 kecil ? apakah setiap output dari step pertama harus selalu dipecah menjadi block2 kecil ? Nah perlu diketahui bahwa block2 yang dipecah distep ke 2 ini hanyalah block yang ukuran datanya yang besar saja. Jadi tidak semua output dari step satu akan displit lagi menjadi block2 yang lebih kecil. Jika block tersebut di pecah, maka ukuran maksimumnya adalah 6144 bit, hal ini sebagaimana yang dispesifikasikan di 36.212 bab 5.1.2-Code block segmentation and code block CRC attachment-. Ilustrasi untuk step 2 ini seperti terlihat di bawah :

Step ketiga adalah chanel coding. Chanel coding ini menggunakan turbo coding processing. Jika kita mengacu ke 36.212 mengenai turbo coding, secara sederhana input satu bit maka outputnya menjadi tiga bit setelah melewati turbo coding processor (ini berarti coding rate 1/3). Nah pada step ketiga ini, berarti 1 blok data menjadi 3 blok data seperti terlihat di bawah :

Step berikutnya adalah Rate Matching. Ide utamanya yaitu menggabungkan kembali 3 blok data dari turbo coding menjadi 1 blok data. Heum, mungkin orang2 yang bidangnya di physical mempunyai penjelasan yang cukup baik bagaimana proses mengubah satu blok menjadi 3 block di turbo coding atau mengubah kembali 3 block data menjadi 1 block di rate matching. Namun karena sy diamanahkan di MAC layer, jadi penjelasannya 3 block data menjadi 1 block TITIK wkwkwk..... =))
ilustrasinya seperti terlihat di bawah :

Sebagai tambahan untuk rate matching ini seperti terlihat :

Blok diagram ini diambil dari 36.212. Seperti terlihat bahwa 3 blok dari turbo coding digabung menjadi satu pada blok rate matching sehingga menghasilkan satu keluaran bit stream data. Tujuan kita pada step ini adalah berusaha mempelajari secara mandiri proses dari  "interleaving", "Bitcollection", dan "Bit selection and pruning."

Step terakhir adalah code block concatenation. Seperti namanya, pada bagian ini digabungkan beberapa blok data menjadi satu blok bit stream yang panjang.

Nah setelah melewati step terakhir tersebut, skr muncul pertanyaan, Apakah bit stream yang dihasilkan dari step terakhir ini sudah final dan akan langsung ditransmit melalui antena ? Jawabnya adalah BLM.... justru output dari step terakhir ini adalah input untuk proses berikutnya di physical layer. Jadi sebenarnya masih banyak yang harus dipelajari lagi untuk memahami blok2 diagram di physical layer yang dapat membuat rambut kita menjadi rontok.... tapi untung di Indonesia banyak yang jualan shampoo, sekalipun shampo palsu :D

Untuk overview pada physical layer untuk step berikutnya bisa dilihat pada diagram di bawah :

HARQ Process in LTE

Sebenarnya HARQ (Hybrid ARQ) adalah suatu proses yang agak kompleks dan susah untuk dipahami secara mendetail apalagi dalam posting seperti ini. Namun ada baiknya jika dapat diperoleh gambaran secara umum tentang HARQ process tersebut.

HARQ adalah gabungan dari kata "Hybrid" dan "ARQ". Hybrid berarti adalah kombinasi dari sesuatu sedangkan ARQ adalah Automatic Repeat request. Jadi secara sederhana HARQ itu adalah ARQ yang dikombinasikan dengan sesuatu, nah sesuatu tersebut adalah FEC, Forward Error Correction... :D

Terdapat perbedaan pada HARQ process jika menggunakan sistem FDD atau TDD untuk uplink dan downlink. Namun pada postingan ini yang dibahas hanyalah yang FDD saja.

Di dalam sistem FDD, terdapat 8 HARQ process yang dapat berjalan secara paralel untuk uplink dan downlink.
1) Downlink
   - Pada downlink dapat digunakan 8 HARQ process secara paralell (asynchronous process)
   - UE tidak tahu sama sekali tentang informasi HARQ process sebelum menerima informasi tersebut melalui   DCI berupa Process ID, RV, NDI, dsb..
Di sini akan diberikan ilustrasi mengenai, HARQ process untuk downlink :
i) Network Layer atas (RRC atau TE) --> Layer bawah : mengirim data ke layer bawah
ii) Netwok --> UE : mengirim data melalui PDSCH
iii) UE menerima PDSCH data
iv) UE mengecek CRC data tersebut, error atau tidak
v) Pada step ini kita mempunyai dua buah kasus :
    1) Jika UE mempunyai data yang akan dikiirim ke eNB, maka UE akan mengirim ACK/NACK ke eNB melalui PSUCH
    2) Jika UE tidak mempunyai data untuk dikirim ke eNB, maka UE akan mengirim ACK/NACK tersebut melalui PUCCH
vi) eNB menerima laporan CRC dari UE, dan  melakukan salah satu langkah di bawah :
     1) Jika menerima ACK, eNB mengirim data baru berikutnya
     2) Jika menerima NACK, HARQ process pada eNB melakukan retransmisi data dengan redudancy version yang berbeda dengan sebelumnya.
Untuk lebih jelasnya bisa dilihat pada flow di bawah :

2) Uplink

1.  HARQ process harus menggunakan proses tertentu yang dikirim pada subframe tertentu juga (proses synchronous). UE harus menggunakan nomer HARQ process yang sama pada setiap 8 subframes
2. Karena UE harus menggunakan HARQ process ID pada subframe tertentu, maka eNB mengetahui secara pasti kapan dan HARQ process ID seperti apa yang akan dikirim oleh UE. eNB juga tahu secara pasti tentang RV dan MCS yang digunakan oleh UE.
3. Ada dua mode operasi pada uplink ini, yaitu Adaptive dan Non-Adaptive HARQ

Flow di bawah adalah contoh HARQ process untuk Adapative UL transmission. Intinya adalah pada setiap transmisi, UE menggunakan RV dan MCS yang berbeda yang diperoleh dari DCI 0 yang dikirimkan oleh eNB.

Kemudian flow di bawah adalah contoh buat Non adaptive HARQ process. Intinya adalah UE menggunakan RV secara berurutan sesuai standard 36.321. Dan menggunakan konfigurasi uplink seperti konfigurasi sebelumnya sampai diterima konfigurasi yang baru DCI 0.

Nah sekarang, bagaimana UE mengetahui untuk menggunakan adaptive atau non-adaptive pada transmisi uplinknya ?

• UE menggunakan "adaptive retransmission" jika memperoleh DCI 0 dan NDI-nya blm ditoggled. Pada kasus ini, UE tidak pedul nilai dari HARQ feedback (PHICH), UE akan melakukan retransmisi jika memperoleh informasi dari DCI 0
• UE akan mengetahui akan menggunakan "Non Adapative retransmission" jika memperoleh HARQ feedback (PHICH = NACK) tetapi tidak memperoleh informasi konfigurasi dari DCI 0 yang baru

Hal-Hal Dasar Yang Penting Diketahui Sebagai Seorang Engineer LTE

Hal dasar yang perlu diketahui sebagai seorang engineer di LTE adalah familiar dengan gambar di atas.. :D

Kita dapat merepresentasikan komponen sinyal di LTE dalam dua dimensi. Seperti yang ditunjukkan gambar di atas, bagian horizontal adalah domain waktu sedangkan bagian vertikal adalah domain frekuensi. Unit terkecil dalam sumbu vertikal adalah sub-carrier sedangkan unit terkecil dalam sumbu horizontal adalah simbol. Jika unit terkecil dalam domain waktu dan frekuensi digabungkan, atau dkombinasikan, maka akan dihasilkan unit/satuan baru yang lebih besar seperti yang akan diceritakan di bawah.

Nah pertama-tama, mari kita lihat komponen vertikal dulu yaitu domain frekuensi. Band LTE (baik itu OFDM/OFDMA) dibuat dari beberapa frekuensi "saluran kecil" yang sering disebut sebagai subcarrier. Spasi antara subcarrier yang satu dengan subcarrier berikutnya selalu sama tanpa memperhatikan sistem bandwidth yang digunakan dalam band LTE. Oleh karena itu, jika system bandwidth LTE berubah, maka jumlah subcarrier juga akan berubah tetapi spasi subcarrier tetap yaitu 15khz. Jadi jika kita menggunakan sistem bandwidth 20 Mhz maka jumlah subcarrier adalah 1200. Jika menggunakan sistem bandwidth 10 Mhz maka jumlah total subcarrier adalah 600 buah, begitu seterusnya... :D

Beralih ke komponen horizontal yaitu domain waktu. Telah disebutkan di atas bahwa satuan terkecil dalam domain waktu disebut sebagai simbol, yang panjangnya sekitar 66,7 mikro second. Panjang simbol ini juga tidak memperhatikan sistem bandwidth yang digunakan, artinya seperti apapun sistem bandwidtnya panjang simbol tetap 66,7 mikro second. Seperti terlihat pada grafik di atas, di domain waktu, unit terbesar disebut "frame" yang panjangnya 10 ms. Setiap frame ini terdiri dari 10 buah subframe, sehingga 1 buah subframe panjangnya adalah 1 ms. Kemudian setiap subframe tersebut terdiri dari 2 buah slot dengan panjang 0,5 ms. Dan didalam tiap slot tersebut terdiri dari 7 buah simbol (dalam keadaan normal) dengan panjang masing-masing 66,7 us. Sow, didalam 1 buah frame itu ada 20 buah slot. Di dalam 1 buah subframe ada 14 simbol.

Nah jika unit terkecil dari domain waktu dan frekuensi digabungkan maka akan terbentuk unit terkecil yang disebut sebagai "resource element". Resource element tersebut dibentuk dari satu buah simbol dalam domain waktu dan satu buah subcarrier dalam domain frekuensi. Unit lain yang bisa dibuat dari kombinasi waktu dan frekuensi adalah "resource block (RB)". Resource block ini dibentuk dari 1 slot dalam domain waktu dan 12 buah sub-carrier dalam domain frekuensi. Perlu diketahui bahwa resource block ini adalah komponen yang sangat penting dalam menetapkan size data yang dapat dikirimkan ke dalam jaringan baik dari sisi protokol ataupun pengukuran RF. Sow,, dapat disimpulkan bahwa dalam resource block itu terdapat 7 buah simbol dan 12 buah subcarrier. Kemudian dalam resource block tersebut terdapat 84 resource element.

Hal laen penting untuk kita ketahui yaitu :
1. Dalam sistem bandwidth 20 Mhz terdapat 100 buah resource block
2. Dalam sistem bandwidth 10 Mhz terdapat 50 buah resource block, dst.......

untuk keterangan dasar yang lain mengenai MAC atau PHY, bisa di lihat di posting lainnya... :D

Random Access MAC PDU Format

MAC PDU untuk random access response dikirim sebagai balasan terhadap random access oleh UE. RAR tersebut terdiri dari MAC header dan satu atau lebih MAC Random Access Response (MAC RAR) seperti ditunjukkan pada gambar di bawah :

MAC RAR subheader berukuran tidak tetap dan terdiri dari extension (E), type (T), Backoff Indicator (BI), dan atau RAPID (Random Access Preamble Identifier). Field extension hanya satu bit dan berfungsi sebagai penanda apakah dalam dalam MAC subheader masih terdapat lagi subheader lain atau tidak. Field type juga hanya satu bit dan digunakan untuk menunjukkan apakah terdapat BI atau RAPID dalam subheader MAC RAR. Ukuran dari RAPID adalah 6 bit sebagai penanda bahwa terdapat 64 preamble yang dapat dipilih oleh UE. Jika terdapat BI pada subheader MAC RAR, maka UE akan mengeset backoff indicatornya ke nilai yang sesuai dengan BI pada subheader seperti yang ditunjukkan pada tabel di bawah :

Sebuah MAC RAR PDU terdiri dari tiga buah fields yaitu timind advance (TA), Uplink grant, dan T-CRNTI. Timing advance menunjukkan waktu pengaturan yang dibutuhkan agar UE dapat sinkron dengan timing pada eNB. T-CRNTI menunjukkan identitas sementara yang digunakan oleh UE sampai contention resolution berhasil atau sampai random access procedure lain dimulai. Ukuran dari setiap MAC subheader dan MAC RAR seperti terlihat pada tabeli di bawah :

Random Access MAC Procedures

Suatu prosedure Random Access (RA) dapat dinisialisasi oleh PDCCH (Physical Downlink Control Channel) atau dapat pula diinisialisasi oleh request dari MAC sublayer. Request dari PDCCH digunakan ketika terdapat data untuk UE yang berada pada eNB dan eNB tersebut menganggap UE yang bersangkutan tidak lagi singkron dengan timing pada eNB. Kemudian request dari MAC digunakan ketika terdapat data dari layer RRC (Radio Resource Control) atau pada user plane di UE. Request dari PDCCH atau RRC secara optional menunjukkan preamble random access dan resource PRACH pada UE. Sebelum prosedure RA dapat dimulai, UE harus mempunyai informasi tertentu untuk resource PRACH yang akan digunakan dan RA-RNTInya. UE juga harus mempunyai informasi tentang group dari random access preamble dan kumpulan tiap preamble yang ada ditiap group, threshold yang dibutuhkan untuk memilih group preamle, parameter yang dibutuhkan untuk menentukan TTI window, power ramping factor yaitu POWER_RAMP_STEP, paramter PREAMBLE_TRANS_MAX, initial preamble power yaitu PREAMBLE_INITIAL_RECEIVED_TARGET_POWER, dan informasi lain yang dibutuhkan sebelum UE memulai RA ini.

RA-RNTI (Random Access Radio Network Temporary Identifier) digunakan pada PDCCH ketika data random access response (RAR) dikirim. RA-RNTI ini menunjukkan resource di time-frequency mana UE mengirim preamblenya. TTI window adalah periode waktu dimana UE harus memonitor RAR dari eNB. Setelah UE telah siap melakukan prosedur RA maka UE akan mengeset PREAMBLE_TRANSMISSION_COUNTER ke 1 dan mengeset parameter backoff ke 0 ms dan melakukan pemilihan terhadap resource random access.

Jika random access preamble dan PRACH resource secara eksplisit telah diberitahukan oleh eNB dan waktu expire dari random access preamble tersebut belum habis, maka UE tidak harus melakukan pemilihan terhadap resource PRACH dan dapat langsung melakukan transmisi dari preamble yang telah dipilih. Namun jika ternyata belum disignalkan, berarti UE pertamakali harus memilih satu dari dua group dari preamble. Pemilihan group ini dapat berdasarkan ukuran message yang akan dikirim pada uplink atau dapat pula berdasarkan requsted resource atau kondisi chanel dari UE. Setelah group preamble telah dipilih, UE secara random memilih preamble yang ada ditiap group tersebut.
Setelah itu UE akan mengeset parameter preamble transmit power menjadi :

PREAMBLE_RECEIVED_TARGET_POWER =

PREAMBLE_INITIAL_RECEIVED_TARGET_POWER +

(PREAMBLE_TRANSMISSION_COUNTER - 1) * POWER RAMPING STEP

Transmit power tersebut mempertegas bahwa preamble transmit power dinaikkan setiap POWER_RAMPING_STEP untuk setiap retransmisi dari random access preamble.

Setelah mengeset transmit power, maka UE kemudian menentukan kesempatan random access berikutnya yang dapat digunakan dan mengirim preamble berdasarkan resource PRACH yang telah dipilih, preamble index dan PREAMBLE_RECEIVED_TARGET_POWER. MAC sublayer pada UE juga memberitahukan physical layer tentang RA-RNTI yang sesuai dengan resource dari PRACH. Jika jumlah transmisi maksimum preamble memenuhi :

PREAMBLE_TRANSMISSION_COUNTER =

PREAMBLE_TRANS_MAX + 1

Maka MAC sublayer akan memberikan notifikasi ke layer atas (RRC) bahwa telah terjadi masalah pada random access yang sekarang sedang dilakukan.

Setelah UE mengirim random access preamble ke eNB, UE akan menitor PDCCH sesuai dengan RA-RNTI dari preamble yang digunakan dalam TTI window untuk random access response. RA-RNTI dari suatu PRACH resource dalam preamble dihitung dengan menggunakan persamaan :

RA_RNTI = 1 + Tid + 10 * Fid

dimana 0 <= Tid < 10 adalah index dari subframe pertama resource PRACH dan 0 <= Fid < 6 adalah index   resource PRACH dalam subframe tersebut dalam urutan naik di domain frekuensi. UE dapat menghentikan monitoring untuk random access response setelah berhasil menerima RAR yang sesuai dengan nomor preamble yang telah dikirim sebelumnya. Ketika physical layer memberitahukan MAC sublayer tentang penerimaan RAR maka MAC sublayer akan bertindak sesuai dengan jenis RAR yang telah diterima. Jika RAR berisi subheader backoff indicator (BI), maka MAC akan mengeset variabel backoff indicatornya sesuai dengan nilai yang telah diperoleh dari subheader RAR tersebut, namun jika tidak berisi BI, maka parameter BI MAC tetap diset ke nol seperti sebelumnya hehehe.... :D.

Jika RAR berisi identifier atau nomor preamble yang telah dikirim sebelumnya, maka UE dapat menganggap penerimaan RAR ini telah sukses dan melakukan pemrosesan terhadap timing alignment dan UL grant yang diterima pada RAR PDU ini. Jika sebelumnya, random access preamble yang digunakan secara eksplisit disignalkan dari eNB (tidak dipilih oleh MAC UE), maka UE menganggap bahwa RA ini telah sukses dijalankan dan tidak perlu melanjutkan prosedur RA ke step berikutnya. Hal ini karena signaling eksplisit dari eNB menunjukkan bahwa tidak ada UE lain yang menggunakan preamble yang sama dengan preamble yang digunakan sekarang. Namun jika preamble tersebut dipilih oleh MAC sublayer berarti UE akan menggunakan atau mengeset temporary C-RNTI yang diterima dari RAR dan melangkah ke step RA procedure berikutnya yaitu "contention resolution". Hal ini dilakukan karena pada step ini belum jelas jika terdapat lebih dari satu UE menggunakan preamble yang sama dengan yang digunakan sekarang.

Jika tidak ada RAR yang diterima dalam periode TTI window atau jika semua RAR yang diterima berisi identifier preamle yang berbeda dengan dengan preamble yang telah dikirim sebelumnya, maka dapat dianggap bahwa RA procedure ini gagal. Jika dalam kondisi ini prosedur RA diinisialisasi oleh MAC atau PDCCH dan :

PREAMBLE_TRANSMISSION_COUNTER <

PREAMBLE_TRANS_MAX

maka UE akan menaikkan preamble transmission counter sebanyak satu buah. Lebih jauh lagi  jika preamble random access telah dipilih oleh MAC atau preamble RA dan resource PRACH secara eksplisit diberitahukan oleh eNB dan akan ekspired sebelum kesempatan RA berikutnya, maka UE (berdasarkan parameter backoff) menghitung dan menggunakan nilai backoff tersebut dan melakukan pemrosesan terhadap resource RA. Nilai backoff ini digunakan ketika RA baru akan dilakukan.

Untuk menyederhanakan proses RA ini, pada bagian ini ditentukan bahwa hanya uplink C-RNTI MAC control element saja yang akan akan dikirim. Message tersebut dikirim sebagai respond yang menunjukkan bahwa preamble yang digunakan untuk prosedur RA ini telah match dengan RAR dari eNB. Setelah msg3 dikirim atau setelah C-RNTI MAC control element dikirim, UE akan menjalankan contention resolution timer dan akan memonitor PDCCH sampai mac contention resolution tersebut habis. Ketika suatu transmisi pada PDCCH ditujukan pada C-RNTI diterima, UE dapat menganggap bahwa contention resolution telah berhasil dan akan menghentikan contention resolution timer serta membuang temporary C-RNTI. Namun jika contention resolution timer tersebut telah habis dan tidak ada transmisi PDCCH yang ditujukan ke C-RNTI yang diterima, maka UE menganggap bahwa step contention resolution ini gagal.  Jika dalam kondisi ini prosedur RA diinisialisasi oleh MAC atau PDCCH dan :

PREAMBLE_TRANSMISSION_COUNTER <

PREAMBLE_TRANS_MAX

maka UE akan kembali menaikkan preamble transmission counter sebanyak satu biji dan membuat temporary C-RNTI yang telah diterima sebelumnya. Selain itu, UE juga menghitung dan menjalankan backoff indicator dan melakukan proses terhadap random access procedure yang baru.

Discontinuous Reception (DRX)

Menghemat daya battery adalah salah satu issue yang begitu penting dalam mobile communication. Untuk mengurangi konsumsi daya battery pada UE maka digunakan mekanisme yang mengurangi monitoring UE pada PDCCH. Nah mekanisme tersebut dalam dunia LTE disebut sebagai Discontinuous Reception (DRX).

Dalam DRX harus selalu diperhitungkan dual hal, yaitu mengurangi latency transfer data dari eNB ke UE atau sebaliknya, dan mengurangi konsumsi battery pada UE dengan mengontrol monitoring UE pada PDCCH. Sehingga parameter-parameter dari DRX tidak akan terlepas dari penghematan battery dan mengurangi latency.

Pada LTE, terdapat 2 periode dari DRX, yaitu long DRX cycle dan short DRX cycle, yang dapat digunakan oleh UE dalam kondisi RRC_CONNECTED. Perlu diketahui bahwa penggunaan short DRX cycle secara optional dikonfigurasi oleh eNB.

Pada long DRX cycle, UE dapat memperpanjang umur betterynya. Sebagai contoh, dalam kasus UE sedang melakukan browsing web, maka akan sangat memboros daya battery jika UE harus memonitor chanel downlink secara kontinyu sementara user yang menggunakan UE hanya sedang membaca artikel pada browser tersebut. Pada kasus ini, penggunaan long DRX cycle dapat digunakan untuk mengurangi monitoring pada chanel downlink.

Kemudian pada short DRX cycle, UE dapat menggunakan fitur ini jika dianggap transfer data dapat membutuhkan waktu yang cepat. Contohnya pada jaringan packet-switched, beberapa paket user dapat tiba di eNB setelah beberapa potongan data lain tiba. Pada kasus ini, jika UE diset ke long DRX cycle sebelum kedatangan paket user, maka paket user ini baru akan dikirim pada saat long DRX cycle telah habis. Karena telah mengalami delay paket ditambah dengan delay pada long DRX, otomatis hal ini akan merusak QoS dari user tersebut. Sehingga untuk menghidari hal ini terjadi atau untuk menghindari UE memasuki long DRX cycle lebih awal, maka UE diset pada kondisi short DRX cycle. Jika paket user tiba di eNB dan UE sedang berada pada short DRX cycle, maka UE akan kembali ke mode continuous reception dengan memberikan downlink assignment setelah short DRX cycle telah habis. Kemudian jika tidak ada lagi paket data user yang tiba selama short DRX cycle ini, maka UE dapat diset ke long DRX cycle dengan asumsi bahwa transfer data dari eNB ke UE telah selesai.

Gambar dibawah menunjukkan state transisi antara long DRX cycle, short DRX cycle, dan continuous reception mode. Jika kondisi tertentu dipenuhi, maka UE akan berpindah dari continuous reception mode ke short DRX cycle mode, atau dari short DRX cycle mode ke long DRX cycle mode, dan atau dari long DRX cycle mode ke continuous reception mode. Transisi tersebut dapat dikontrol oleh timer pada UE atau secara eksplisit mendapat perintah dari eNB.

drx-InactivityTimer (bisa dilihat di TS36331, Hal-159) mengontrol transisi dari continuous reception mode ke short DRX cycle atau long DRX cycle. Jika UE tidak menerima informasi resource allocation selama drx-InactivityTimer habis, maka UE akan beralih ke short DRX cycle (jika memang dikonfigurasi di UE) atau beralih ke long DRX cycle (jika short DRX tidak dikonfigurasi).

Ketika UE beralih ke short DRX cycle, maka UE tersebut akan segera menjalankan drxShortCycleTimer. UE akan tetap berada dalam short DRX cycle tersebut sampai drxShortCycleTimer habis, dan kemudian akan beralih ke long DRX cycle jika drxShortCycleTimer tersebut telah habis. Jika UE menerima notifikasi resource allocation dimana drxShortCycleTimer sedang running, maka UE akan beralih ke continuous reception mode. Sebenarnya, kapanpun ketika UE menerima notifikasi resource allocation untuk transmisi baru dalam DRX cycle, maka UE akan segera kembali ke continuous reception mode.

Telah disebutkan sebelumnya, bahwa peralihan DRX cycle ini selain dikonfigurasi oleh timer, dapat juga secara eksplisit atas perintah dari eNB. Jika eNB telah yakin betul bahwa tidak ada lagi data untuk UE atau jika tidak ada lagi schedule untuk downlink data buat UE, maka eNB dapat mengirim DRX command MAC CE ke UE. Ketika UE menerima DRX command MAC CE, maka UE akan segera beralih ke short DRX cycle (jika dikonfigurasi) atau beralih ke long DRX cycle.

Pada continuous reception mode, UE akan memonitoring PDCCH pada semua subframes kecuali untuk subframe uplink pada half-duplex FDD dan subframe untuk measurement gap. Secara sederhana, continuous reception mode dapat match dengan waktu ketika drx-InactivityTimer sedang running.

Pada short DRX cycle dan long DRX cycle, UE memonitor PDCCH untuk beberapa subframe saja dari semua subframe yang tersedia. Karena UE hanya memonitor sebagian subframe maka dapat dipastikan bahwa konsumsi dayanya juga dapat dikurangi. Untuk menunjukkan adanya data untuk downlink dan mengurangi latency data tersebut, maka UE dan eNB harus saling memahami kapan UE diperintahkan untuk memonitor PDCCH dan kapan eNB dapat mengirim informasi resource allocation ke UE. Waktu untuk memonitoring PDCCh pada setiap DRX cycle disebut sebagai "On Duration" dan waktu ini berada diawal untuk setiap DRX cycle. Lebih spesifik lagi, sebenarnya dalam DRX cycle itu "On Duration" berarti UE harus memonitor PDCCH dan "DRX period" berarti UE tidak boleh memonitor PDDCH.

Jumlah subframe atau lama waktu UE harus memonitor PDCCH dalam setiap DRX cycle dikontrol oleh onDurationTimer (bisa juga dilihat 36331 halaman yang sama dengan sebelumnya). Pada waktu awal untuk setiap DRX cycle, UE akan menjalankan onDurationTimer dan memonitor PDCCH selama onDurationTimer tersebut belum habis. Periode atau panjang timer tersebut mengontrol scheduling flexibility dari eNB. Jika panjang onDurationTimer hanya satu subframe, maka eNB hanya dapat mengirim informasi resource allocation hanya dalam subframe tersebut. Namun jika panjang onDurationTimer tersebut lebih dari satu subframe, berarti eNB dapat memilih salah satu dari subframe yang tersedia untuk UE dalam pengiriman informasi resource allocation. Hal ini tentunya menguntungkan bagi eNB khususnya ketika PDCCH sedang busy. Namun disisi UE, hal ini dapat berdampak buruk karena dibutuhkan daya lebih untuk memonitor PDCCH.

Gambar bagian a) di bawah menunjukkan waktu untuk short DRX cycle dan long DRX cycle. Tanpa memperhatikan jenis dari DRX cycle yang digunakan, UE harus memonitor PDCCH selama On Duration. Dengan memerintahkan UE untuk memonitor PDCCH paling tidak pada On Duration, eNB tidak harus menunggu untuk akses dari UE. Selama periode diluar On Duration, UE dapat menghemat daya batterynya untuk tidak memonitor PDCCH atau informasi resource allocation.

Waktu aktif adalah waktu ketika UE harus memonitor PDCCH karena kemungkinan adanya informasi resource allocation. Waktu aktif ini termasuk dalam periode drx-InactivityTimer, drx-RetransmissionTimer, dan onDurationTimer ketika sedang running. Ketika informasi resource allocation diterima selama waktu aktif tersebut, UE akan melakukan start atau restarts drx-InactivityTimer dan memonitor PDCCH pada setiap subframe selama drx-InactivityTimer  running. Sehingga dapat disimpulkan bahwa informasi resource allocation yang diterima selama waktu aktif ini akan memperpanjang waktu aktif itu sendiri. Ilustrasi ini dapat dilihat pada gambar bagian b) di bawah.

Pada akhir dari drx-InactivityTimer atau pada penerimaan DRX command MAC CE, UE menghetinkan waktu aktif dan beralih ke short atau long DRX cycle. eNB dapat mengirim DRX MAC CE kapan saja ke UE untuk memerintahkan UE masuk ke DRX cycle. Ilustrasi seperti terlihat di bawah.

Untuk memaksimalkan efisiensi battery dari UE, maka HARQ juga dapat dilibatkan dalam operasi DRX. Sebagaimana diketahui, sekuensial process pada HARQ yaitu:  transmisi data dari pengirim--delay propagasi dalam radio interface--decode data pada receiver--transmisi ACK/NACK--delay propagasi dari ACK/NACK--penerimaan ACK/NACK pada pengirim data--dan transmisi data lain. Dengan melihat semua sequence tersebut, dibutuhkan waktu ynag cukup lama antara transmisi data yang satu dengan berikutnya pada HARQ process.

Untuk memperoleh keuntungan dari kondisi ini, HARQ RTT timer digunakan untuk setiap DL HARQ process untuk mengurangi konsumsi daya pada UE selama menunggu HARQ retransmissions. Ketika decoding transport block untuk downlink gagal, UE akan menjalankan HARQ RTT timer untuk HARQ process tersebut, dengan mengganggap bahwa HARQ retransmission berikutnya akan terjadi paling tidak setelah HARQ RTT timer telah habis. Nah jika HARQ RTT timer ini sedang running, maka UE tidak harus memonitor PDCCH sehingga dapat terjadi penghematan terhadap daya batterey... :D



Edited from :
"Radio Protocols for LTE and LTE-Advanced" by SeungJune Yi, SungDuck Chun, 'oungDae Lee, SungJun Park, & SungHoonung.

Default Bearer, Dedicated Bearer,.. Apa Sebenarnya Bearer itu ?

Jika kita sering menghadapi data flow dalam jaringan LTE atau jika sering membaca standard-standard tentang LTE, maka pada kita dapat menjumpai kata yang sering disebut dengan bearer. Nah sebelum berbicara mengenai apa itu Bearer, mari lihat definisi dari bearer itu sendiri :

"Bearer is just a virtual concept. It defines how the UE data is treated when it travels across the network. Network might treat some data in a special way and treat others normally. Some flow of data might be provided guaranteed bit rate while other may face low transfer.  In short, bearer is a set of network parameter that defines data specific treatment   e.g. Person A will always get at least 256 Kbps download speed on his LTE phone while for person B there is no guaranteed bit rate and might face extremely bad download speed at times"

"Bearer adalah hanya suatu konsep virtual. Bearer ini mendefinisikan bagaimana data dari UE diperlakukan ketika berada dalam jaringan. Jaringan/eNB mungkin  memperlakukan suatu data dengan special dan data lain secara normal saja. Beberapa data flow mungkin disediakan bit rate yang pasti sedangkan data lain hanya menunggu resource yang tersedia. Secara sederhana, bearer adalah kumpulan parameter tertentu dari jaringan yang mendefinisikan bagaimana suatu data diperlakukan. Sebagai contoh, seseorang akan selalu memperoleh kecepatan download paling rendah 256 Kbps pada teleponnya yang support jaringan LTE sedangkan orang lain yang tidak memiliki guaranted bit rate mungkin dapat memperoleh kecepatan download yang jelek haha... :D "
okay sekarang mari kita lihat lebih jauh tentang default bearer dan dedicated bearer

Default Bearer

Ketika UE masuk ke dalam jaringan untuk yang pertamakalinya, UE tersebut akan diberikan default bearer saja selama UE tersebut berada dalam jaringan. Default bearer ini tidak mempunyai QoS dan tidak mempunyai juga best effort service. Setiap default bearer mempunyai satu IP address. UE dapat mempunyai default bearer yang laen. Nah karena mempunyai beberapa default bearer, berarti UE juga mempunyai beberapa alamat IP yang berbeda untuk setiap default bearer tersebut. Namun setiap UE hanya dapat mempunyai maksimum 11 default bearer saja.

Dedicated Bearer
Secara simpel, yang membedakan default bearer dan dedicated bearer itu adalah QoS. Yah dedicatedd bearer mempunyai QoS. Dedicated bearer bertindak sebagai bearer tambahan yang prioritasnya berada di atas default bearer. Namun dedicated bearer ini tidak membutuhkan IP address tambahan, sehingga default bearer ini selalu berhubungan dengan default bearer sebelumnya yang telah dikonfigurasi dari jaringan. Untuk layanan seperti VoIP, IMS, VoLGA, kita membutuhkan guaranted bit rate dan juga prioritas untuk flow datanya. Nah disinilah peranan dedicated bearer untuk layanan tersebut. Sebagai contoh, seseorang yang menonton video di Youtube mungkin dapat mengalami masalah dalam hal buffering, tetapi jika performance untuk VoIP atau Skypenya tidak mengalami masalah yang sama karena berada dalam dedicated bearer. Liat gambar di bawah :D

Non Persistent Scheduling in LTE

Pada mode persistent scheduling, UE dapat mengirim data ke eNB setiap saat ketika eNB mengirim UL Grant setiap saat. Tetapi bagaimana jika eNB tidak mengirim UL grant tersebut setiap waktu ? Dalam kasus ini, UE harus meminta eNB untuk mengirim UL grant (DCI 0). Jika eNB mengirim UL Grant, maka UE dapat mengirim data (UL data) diperbolehkan dalam UL Grant tersebut. Prosedur ini bisa dilukiskan seperti di bawah :

1.     UE mengirim SR (Scheduling Request) pada PUCCH
2.     eNB membalas dengan mengirim UL Grant (DCI 0) pada PDCCH
3.     UE mendekode DCI 0 dan melakukan transmisi data pada PUSCH sesuai dengan Resource Block (RB) yang dispesifikasikan pada DCI 0
4.     eNB kemudian mendekode data pada PUSCH
5.     eNB kemudian mengirim ACK/NACK pada PHICH
6.     jika eNB mengirim NACK, maka UE kembali pada langkah pertama

1. 
   

Persistent Scheduling in LTE

Ada beberapa skema scheduling dalam LTE. Yang paling sederhana adalah persistent scheduling. Pada mode ini eNB mengrim ‘Grant’ pada DCI Format 0 pada setiap subframe. Ilustrasinya seperti terlihat pada point-point di bawah :

1. eNB mengirim data pertama pada PDSCH dan PDCCH yang mempunyai DCI Format 1 untuk DL data decoding dan DCI Format 0 untuk UL Grant. Jika tidak ada data downlink yang perlu untuk dikirimkan ke UE, eNB hanya mengirim DCI Format 0 pada PDCCH tanpa PDSCH
2. UE mendekode PCFICH untuk mengetahui nilai CFI
3. UE mendekode PDCCH dan memperoleh informasi pada DCI Format 1
4. Berdasarkan DCI Format 1, UE mendekode data downlink dari eNB sebelumnya
5. UE mendekode informasi pada DCI Format 0 dari PDCCH
6. UE mengirim ACK/NACK untuk data downlink tersebut melalui UCI
7. UE mengecek field Grant
8. Jika Grant tersebut mencukupi/diperbolehkan, maka UE melakukan transmisi data Uplink melalui PUSCH
9. eNB mendekode data dari UE tersebut dan mengirim ACK/NACK melalui PHICH
10. UE mendekode PHICH dan melakukan retransmisi jika PHICH tersebut berisi NACK

Untuk lebih jelasnya bisa dilihat pada flow di bawah :

Untuk informasi yang lebih detail tentang DCI Format 0, bisa dilihat TS 36.212 bagian 5.3.3.1.1-Format 0.

Proses yang diilustrasikan di atas pada kenyataannya sangatlah rumit dan membutuhkan banyak troubleshooting dan debugging. Jadi dalam hal fase development dan testing, biasanya proses tersebut dipecah dalam beberapa procedure yang lebih sederhana/kecil dan memeriksa procedure-prosedure tersebut step by step.

Step 1 : Penerimaan data downlink dan tidak ada transmisi ACK/NACK

• eNB mengirim data pada PDCCH dan PDSCH
• Periksa apakah UE dapat mendecode data pada PDSCH

Untuk dapat melakukan hal ini UE harus dapat melakukan langkah 2, 3, dan 4 di atas.

Step 2 : Penerimaan DCI Format 0

•       eNB mengirim DCI Format 0 (UL Grant) tanpa transmisi data pada PDSCH
•     periksa apakah UE dapat mendekode DCI Format 0

Hal ini harus dipastikan bahwa alokasi Resource yang UE decode harus sesuai dengan DCI Format 0 yang dikirim oleh eNB

Step 3 : Transmisi PUSCH berdasarkan DCI Format 0

• a)      eNB mengirim DCI Format 0 (UL Grant) tanpa transmisi data pada PDSCH
• b)      UE melakukan transmisi UL data pada PUSCH
• c)      eNB mendekode data yang diterima pada PUSCH
• d)      periksa apakah data yang didekode oleh eNB sama dengan apa yang dikirim UE

untuk melakukan hal ini, UL DMRS untuk PUSCH harus sudah diimplementasikan dan harus dipastikan bahwa UE melakukan transmisi data pada PUSCH sesuai dengan resource block yang dispesifikasikan pada DCI Format 0

Step 4 : Penerimaan DL data dan ada transmisi ACK/NACK

• a)      eNB mengirim data melalui PDCCH dan PDSCH
• b)      UE mendekode data pada PDSCH
• c)      UE juga harus mengirim ACK/NACK untuk data pada PDSCH tersebut

Step 5 : transmisi UL data dan penerimaan ACK/NACK

• a)      eNB mengirim DCI Format 0 (UL Grant) tanpa transmisi data pada PDSCH
• b)      maka UE melakukan transmisi data pada PUSCH
• c)      kemudian eNB mendekode data pada PUSCH yang dikirim UE
• d)      eNB mengirim ACK/NACK pada PHICH
• e)      UE harus dapat mendekode ACK/NACK dari eNB tersebut

f)        UE harus melakukan retransmisi jika memperoleh NACK

GENERAL MESSAGE STRUCTURE in LTE

1.     BCCH-BCH-Message

   

Message ini dikirim oleh E-UTRAN ke UE melalui BCCH kemudian melewati BCH. Isi messagenya yaitu :

BCCH-BCH-Message ::= SEQUENCE {

            Message                      BCCH-BCH-MessageType

}

BCCH-BCH-MessageType ::=      MasterInformationBlock

2.      BCCH-DL-SCH-Message

Message ini dikirim oleh E-UTRAN ke UE melalui BCCH kemudian melewati DL-SCH transport chanel. Isi messagenya yaitu :

BCCH-DL-SCH-Message ::=  SEQUENCE {

            Message                                  BCCH-DL-SCH-MessageType

}

BCCH-DL-SCH-MessageType ::= CHOICE {

            systemInformation                              SystemInformation,

            systemInformationBlockType1           systemiInformationBlockType1

}

3.     MCCH-Message

Message ini dikirim oleh E-UTRAN ke UE melalui MCCH logical channel. Isi messagenya yaitu :

MCCH-Message ::=                SEQUENCE {

            Message                                  MCCH-MessageType

}

MCCH-MessageType  ::= CHOICE {

            mbsfnAreaConfiguration-r9               MBSFNAreaConfiguration-r9

}

4.      PCCH-Message

Message ini dikirim oleh E-UTRAN ke UE melalui PCCH. Isi messagenya yaitu :

PCCH-Message ::=    SEQUENCE {

            Message                      PCCH-MessageType

PCCH-MessageType ::=  CHOICE {

            Paging                         paging

}

5.     DL-CCCH-Message

     Message ini dikirim oleh E-UTRAN ke UE melalui CCCH logical channel kemudian melewati DL-SCH transport channel. Isi messagenya yaitu :

      DL-CCCH-Message  ::=  SEQUENCE {

            Message                      DL-CCCH-MessageType

}

       DL-CCCH-Message ::=  CHOICE {

            rrcConnectionReestablishment               RRCConnectionReestablishment

            rrcConnectionReestablishmentReject     RRCConnectionReestablishmentReject

            rrcConnectionReject                               RRCConnectionReject

            rrcConnectionSetup                                RRCConnectionSetup

}      }

     

    6.      DL-DCCH-Message

     Message ini dikirim oleh E-UTRAN ke UE melalui DCCH logical channel kemudian melewati DL-SCH transport channel, Isi messagenya yaitu:

DL-DCCH-Message ::=  SEQUENCE {

            Message                      DL-DCCH-MessageType

}

      DL-DCCH-MessageType ::= CHOICE {

            csfbParameterResponseCDMA200                CSFBParametersResponseCDMA2000

            dlInformationTransfer                                     DLInformationTransfer

            handoverFromEUTRAPreaparationRequest HandoverFromEUTRAPreparationRequest

            mobilityFromEUTRACommand                     MobilityFromEUTRACommand

            rrcConnectionReconfiguration                       RRCConnectionReconfiguration

            rrcConnectionRelease                                     RRCConnectionRelease

            securityModeCommand                                  SecurityModeCommand

            ueCapabilityEnquiry                                       UECapabilityEnquiry

            counterCheck                                                  CounterCheck

            ueInformationRequest-r9                                UEInformationRequest-r9

            loggedMeasurementsConfiguration-r10         LoggedMeasurementsConfiguration-r10

            rnReconfiguration-r10                                    RNReconfiguration-r10

}    }

    

   7.      UL-CCCH-Message

     Message ini dikirim oleh UE ke E-UTRAN melalui UL-SCH kemudian melewati CCCH logical channel. Isi messagenya yaitu :

      UL-CCCH-Message  ::=  SEQUENCE {

            Message                      UL-CCCH-MessageType

}

      UL-CCCH-MessageType ::=  CHOICE {

            rrcConnectionReestablishmentRequest          RRCConnectionReestablishmentRequest

            rrcConnectionRequest                                    RRCConnectionRequest

}      }

}

    8.      UL-DCCH-Message

     Message ini dikirim oleh UE ke E-UTRAN melalui UL-SCH kemudian melewati DCCH logical channel. Isi messagenya yaitu :

      UL-DCCH-Message  ::=  SEQUENCE {

            Message                      UL-DCCH-MessageType

}

      UL-DCCH-MessageType  ::=  CHOICE {

            csfbParameterRequestCDMA2000                 CSFBParameterRequestCDMA2000

            measurementReport                                        MeasurementReport

            rrcConnectionReconfigurationComplete        RRCConnectionReconfigurationComplete

            rrcConnectionReestablishmentComplete       RRCConnectionReestablishmentComplete

            rrcConnectionSetupComplete                         RRCConnectionSetupComplete

            securityModeComplete                                   SecurityModeComplete

            securityModeFailure                                       SecurityModeFailure

            ueCapabilityInformation                                UECapabilityInformation

            ulHandoverPreparationTransfer                    ULHandoverPreparationTransfer

            ulInformationTransfer                                    ULInformationTransfer

            counterCheckResponse                                   CounterCheckResponse

            ueInformationResponse-r9                              UEInformationResponse-r9

            proximityIndication-r9                                    ProximityIndication-r9

            rnReconfigurationComplete-r10                     RNReconfigurationComplete-r10

}      }