KPI Optimization: LTE ERAB Success Rate

Pertama, mari kita pahami definisi dan poin-poin di mana ERAB KPI dipatok. Setelah UE mengirimkan
pesan RRC Setup Complete ke eNB, eNB mengirimkan S1 Initial UE Message ke MME yang menunjukkan tujuan
UE (Attach, TAU, CSFB, Service Request, dsb) dan kredensialnya. Setelah MME menerima pesan ini dan
memutuskan bahwa pembawa diperlukan, MME akan mengirimkan Permintaan Pengaturan Konteks Awal ke eNB.
Pesan ini dianggap sebagai ERAB Attempt karena berisi pembawa yang akan ditambahkan bersama dengan nilai
QCI-nya. eNB menerima pesan ini dan menambahkan DRB (Data Radio Bearer) berdasarkan profil pembawa
dalam Permintaan Pengaturan Konteks Awal. Tetapi sebelum eNB dapat menambahkan pembawa, eNB perlu
mengaktifkan keamanan untuk koneksi. Hal ini dilakukan dengan Perintah Mode Keamanan yang membawa
algoritma ciphering dan perlindungan integritas. Setelah ini eNB mengirimkan pesan RRC Connection
Reconfiguration ke UE yang menambahkan DRB dan termasuk konfigurasi untuk DRB seperti identitas pembawa,
PDCP & konfigurasi RLC (AM/UM dll). SRB2 juga ditambahkan pada saat ini dengan pesan ini. UE menerima
pesan-pesan ini dan mengkonfigurasi ulang koneksi. Kemudian UE merespons dengan pesan Security Mode
complete dan RRC Connection Reconfiguration Complete. Saat eNB menerima pesan-pesan ini, eNB
mengirimkan Respon Pengaturan Konteks Awal ke MME dan pesan ini dianggap sebagai ERAB Success.

Common Failures In ERAB Setup Phase

Sekarang mari kita pahami kegagalan umum yang biasanya menyebabkan kegagalan setup ERAB. Sering kali, kegagalan
setup ERAB dapat dibagi menjadi dua kategori besar.

Ø Radio Induced ERAB Setup Failures

Ø MME Induced ERAB Setup Failures
Mari kita lihat secara mendalam keduanya dan temukan cara untuk mengatasinya
Radio Induced ERAB Setup Failures
• Radio Link Failure
Pertimbangkan UE yang menerima Perintah Mode Keamanan tetapi gagal mempertahankan koneksi radio setelahnya.
Hal ini dapat terjadi dalam dua skenario berikut:
1. N310 consecutive out-of-sync events and T310 expiry
N310 menunjukkan interval 200 kegagalan decoding PDCCH berturut-turut. Sederhananya, jika UE gagal mendekode
PDCCH selama 200ms, maka akan dianggap sebagai satu N310. Namun, dari sini dan seterusnya, ini adalah jendela geser
dengan granularitas 10ms. Jadi, jika nilai N310 adalah 2 maka itu berarti bahwa jika UE gagal memecahkan kode PDCCH selama
210 ms, itu akan melebihi ambang batas N310 yang dikonfigurasi. Setelah N310 terlampaui, UE memulai timer T310 dan jika
UE tidak dapat mempertahankan koneksi (masih tidak dapat men-decode PDCCH) sebelum T310 berakhir, UE akan memulai
RRC ReEstablishment. Mari kita pahami dengan sebuah contoh. Pertimbangkan N310 dari 11 dan T310 dari 500ms, maka UE
akan menginisiasi RRC Connection ReEstablishment setelah 800 ms (N310 = (200 + (10*10)) = 300ms + T310 = 500ms).

2. Maximum RLC retransmission count exceeded

Pertimbangkan bahwa UE menerima Perintah Mode Keamanan dan pesan Konfigurasi Ulang Koneksi RRC. Sekarang, UE
harus mengirimkan pesan Security Mode Complete dan RRC Connection Reconfiguration Complete di Uplink. Namun, jika eNB
gagal menerjemahkan tanggapan ini, ia akan mengirim NACK ke UE atau eNB mungkin tidak mengirim apa pun jika benar-
benar gagal bahkan menerima pesan-pesan ini. Lapisan RLC di UE dikonfigurasikan untuk mengirim ulang pesan jika pesan
tidak diterima. Jadi, lapisan RLC akan terus mengirim ulang sampai pengakuan yang valid diterima. Tetapi RLC tidak dapat
mengirim ulang pesan yang sama tanpa batas waktu dan memiliki batas atas transmisi ulang. Setelah batas itu tercapai, RLC
tidak akan mengirim ulang lagi dan UE akan menganggap bahwa sambungan radio terganggu. Hal ini akan memicu Permintaan
ReEstablishment RRC.

Namun, dalam kedua kasus ini, Permintaan ReEstablishment RRC akan ditolak oleh eNB karena pemrosesan permintaan
ini mengharuskan adanya konteks UE yang valid di eNB. Tetapi karena UE tidak menanggapi Perintah Mode Keamanan, maka
eNB tidak menganggap konteks sudah aktif dan menolak Permintaan ReEstablishment RRC. Pada contoh yang sama, eNB akan
mengirimkan Initial Context Setup Fail ke MME yang mengindikasikan Kegagalan Setup ERAB.

Optimization
Jika skenario semacam itu diamati secara konsisten, maka akan menjadi ide yang bagus untuk beralih dari periode
SRI adaptif ke periode SRI tetap. Ini akan menghindari konfigurasi ulang periodisitas SRI dan akan mencegah masalah ini.

Selain itu, menggunakan peningkatan PUCCH seperti IRC pada PUCCH dapat membantu mengurangi kemungkinan
masalah tersebut.

3. No Response From UE
Dalam hal ini, UE menerima Perintah Mode Keamanan dan pesan Rekonfigurasi Ulang Koneksi RRC di downlink
tetapi tidak menanggapi pesan-pesan ini di uplink. Hal ini dapat mengakibatkan berakhirnya Inactivity Timer dan eNB akan
mengirimkan Permintaan Pelepasan Konteks UE ke MME selama fase pengaturan ERAB yang akan menyebabkan kegagalan
pengaturan ERAB. Mari kita lihat mengapa skenario ini terjadi di jaringan langsung. Setelah UE menerima pesan downlink
yang membutuhkan respon, maka UE akan membutuhkan alokasi uplink untuk mengirim respon. Untuk mendapatkan
alokasi uplink, UE meminta eNB dengan menggunakan Indikator Permintaan Penjadwalan atau SRI. UE mengirimkan SRI
berdasarkan Konfigurasi SRI yang dibagikan dengannya dalam Pesan Pengaturan Koneksi RRC. Konfigurasi SRI memberi
tahu UE tentang periodisitas SRI dan menentukan subframe di mana UE akan mengirim SRI. Jadi, eNB akan mencari SRI UE
itu hanya dalam subframe itu dan berdasarkan itu, eNB mengalokasikan sumber daya uplink ke UE dengan
menginstruksikan UE pada PDCCH. Sekarang, vendor telah pindah ke interval SRI adaptif yang dapat menghasilkan
konfigurasi SRI baru dalam pesan Rekonfigurasi Koneksi RRC. Ada UE yang tidak mendukung perubahan konfigurasi SRI ini
dan mereka tetap menggunakan konfigurasi SRI lama. Jadi, setelah mereka menerima Security Mode Command dan pesan
RRC Connection Reconfiguration di downlink dan mereka ingin merespons di uplink, mereka harus mengirim SRI terlebih
dahulu. UE akan mengirimkan SRI sesuai dengan Konfigurasi SRI lama yang dibagikan dalam pesan RRC Connection Setup
sementara eNB akan mencari SRI UE dalam subframe yang didefinisikan dalam Konfigurasi SRI dari pesan Rekonfigurasi
Koneksi RRC. Hal ini akan menghasilkan skenario di mana eNB akan menganggap bahwa tidak ada respon dari UE dan
setelah timer tidak aktif berakhir, setup ERAB akan gagal.

Hal ini juga dapat terjadi jika UE berada dalam jangkauan yang buruk atau jika PUCCH memiliki interferensi yang
tinggi. UE akan terus mengirimkan SRI di lokasi yang benar pada PUCCH tetapi eNB mungkin tidak dapat membacanya
sehingga menghasilkan skenario yang sama seperti yang dijelaskan di atas.

Optimalisasi
Jika skenario semacam itu diamati secara konsisten, maka akan menjadi ide yang bagus untuk beralih dari periode
SRI adaptif ke periode SRI tetap. Ini akan menghindari konfigurasi ulang periodisitas SRI dan akan mencegah masalah ini.

Selain itu, menggunakan peningkatan PUCCH seperti IRC pada PUCCH dapat membantu mengurangi kemungkinan
masalah tersebut.
4. RLC Mode Issue
Hal ini jarang terlihat dalam jaringan ketika mode UM (Unacknowledged Mode of RLC) QCI digunakan untuk UE yang
tidak mendukung mode UM. Contoh yang umum adalah QCI7 yang merupakan Non-GBR QCI yang didefinisikan untuk live
streaming atau layanan suara dan biasanya bekerja dalam mode UM. Tetapi ada banyak UE yang tidak mendukung mode
UM dan eNB gagal menambahkan bearer dengan mode UM untuk mereka. Masalah ini dapat dilihat dari counter karena
akan menunjukkan bahwa kegagalan ERAB pada antarmuka Radio hanya terjadi pada QCI7 atau QCI lain yang diatur ke
Mode UM.
Optimization
Cukup dengan mengubah mode RLC untuk QCI dari UM ke AM akan menyelesaikan masalah ini.

Security Mode Failure

Masalah lain yang agak jarang terjadi adalah masalah Kegagalan Mode Keamanan. Dalam hal ini, UE menerima
Perintah Mode Keamanan dari eNB tetapi merespon dengan pesan Kegagalan Mode Keamanan. Akibatnya, eNB
mengirimkan Initial Context Setup Failure ke MME yang mengakibatkan kegagalan setup ERAB. Hal ini terjadi jika
konfigurasi keamanan pada eNB tidak didukung oleh UE atau terkadang dapat terjadi jika UE tidak dapat menangani
Perintah Mode Keamanan dan Rekonfigurasi Koneksi RRC secara bersamaan. Dalam sebagian besar kasus, hal ini ternyata
ada masalah pada UE.
5. MME Induced ERAB Setup Failures
Mari kita lihat kegagalan ERAB yang disebabkan MME. Hal ini mungkin mengejutkan tetapi sebagian besar kegagalan
setup ERAB yang disebabkan MME di jaringan komersial sebenarnya disebabkan oleh interface radio dan bukan MME.
Saya tahu hal ini sulit dimengerti, tetapi bagi anda yang telah mempelajari RRC dan S1 traces akan memahaminya dengan
lebih jelas setelah saya menjelaskan masalah ini.

Seperti yang dijelaskan pada bagian di atas, ketika UE mengalami RLF setelah menerima Security Mode Command,
UE dapat mencoba RRC ReEstablishment yang sebenarnya memberitahu eNB bahwa ada RLF di sisi UE. Pertimbangkan UE
yang mengalami RLF sebelum menerima Perintah Mode Keamanan. UE hanya dapat mengirim RRC ReEstablishment
setelah keamanan diaktifkan tetapi jika UE mengalami RLF sebelum Perintah Mode Keamanan diterima, UE tidak dapat
mengirim Permintaan RRC ReEstablishment.

Sekarang, pertimbangkan bahwa UE mengalami RLF setelah pesan RRC Setup Complete dan sebelum Perintah Mode
Keamanan, UE ini akan menganggur dan mencoba kembali koneksi RRC baru dengan mengirimkan Permintaan Koneksi
RRC lainnya. Katakanlah UE mengirimkan Permintaan Koneksi RRC ke eNB lain (eNB2) dan eNB2 akan mulai
memprosesnya. eNB2 tidak tahu bahwa eNB1 sudah memiliki proses setup ERAB yang sedang berlangsung untuk UE ini.
eNB2 akan mengirimkan S1 Initial UE Message ke MME untuk UE ini dan MME akan melihat bahwa sudah ada proses setup
ERAB lain yang sedang berlangsung dengan eNB1. Jadi, agar MME dapat memulai proses pengaturan ERAB baru dengan
mengirimkan Permintaan Pengaturan Konteks Awal ke eNB2, MME harus terlebih dahulu menghentikan proses pada
eNB1, karena tidak dapat memiliki konteks terpisah dari UE yang sama pada dua eNB yang berbeda. Sebagai hasilnya,
MME akan mengirimkan Perintah Pelepasan Konteks UE ke eNB1 yang meminta untuk membatalkan proses pengaturan
ERAB. eNB1 mencoba untuk menemukan UE melalui antarmuka udara dan setelah menerima Perintah Pelepasan Konteks
dari MME, ia akan menganggap bahwa MME membatalkan setup ERAB dan akan mematoknya sebagai kegagalan setup
ERAB yang disebabkan oleh MME. eNB1 akan mengirimkan Kegagalan Setup Konteks Awal ke MME dan setup ERAB pada
eNB1 akan dipatok di bawah kegagalan yang disebabkan oleh MME. Namun, masalah ini sebenarnya disebabkan karena
masalah radio tetapi eNB1 tidak dapat mengetahuinya.
 Masalah ini juga dapat terjadi jika UE mengirimkan Permintaan Koneksi RRC kedua ke eNB yang sama atau bahkan
ke sel yang sama. Pada level RRC, eNB tidak memeriksa nilai TMSI dan UE direferensikan oleh CRNTI-nya. Jadi, jika UE yang
sama mengirimkan Permintaan Koneksi RRC lain ke eNB yang sama, UE akan mengalokasikan CRNTI baru dan akan
menganggapnya sebagai koneksi baru. Tetapi ketika eNB akan mengirimkan S1 Initial UE Message ke MME, MME akan
memeriksa TMSI dan akan mengirimkan UE Context Release Command ke sesi sebelumnya yang mengakibatkan kegagalan
setup ERAB pada proses pertama.

Skenario lain yang dapat menyebabkan kegagalan ERAB Setup yang disebabkan MME adalah Timer Pengaturan
Konteks Awal pada MME. Jika timer tersebut diatur ke nilai kecil dan eNB menunggu UE untuk merespon Security Mode
Command, MME akan mengirimkan UE Context Release Command karena timeout. Hal ini juga akan mengakibatkan
Kegagalan Pengaturan ERAB yang disebabkan MME.

Optimization
Tidak ada optimasi nyata pada skenario pertama karena ini murni masalah cakupan dan peningkatan cakupan
dengan perubahan fisik atau lunak dapat dilakukan untuk menguranginya. Skenario kedua dapat diminimalkan dengan
meningkatkan Timer Pengaturan Konteks Awal pada MME.