LTE KPI Optimization : RRC Success Rate

 Halo semuanya, dan selamat datang di sesi tentang pengoptimalan KPI LTE. Hari ini, kita akan membahas tingkat RRC Success untuk LTE. Pertama, mari kita bahas tentang RRC KPI dan alur panggilan karena kita perlu memahami alur panggilan sebelum kita dapat memahami di mana letak hambatan KPI. Kemudian, kita akan membahas keterbatasan utama yang kita miliki dan tindakan pengoptimalan apa yang dapat kita lakukan untuk mengurangi atau mengatasi masalah tersebut. Jadi, mari kita mulai.

Pertama, mari kita pahami apa tingkat RRC Success dan mengapa kita memerlukan pengaturan RRC. Ketika pengguna, katakanlah dalam mode idle, perlu terhubung ke jaringan LTE, mereka harus melalui fase penyerahan, dan RRC ikut berperan. RRC diperlukan karena Anda perlu memiliki koneksi ke jaringan, dan untuk itu, Anda perlu memberi tahu jaringan bahwa Anda memerlukan beberapa sumber daya. Jadi, hal pertama yang dilakukan UE adalah melakukan akses acak. Di sini, UE mengirimkan permintaan akses ke eNodeB, dan sebagai respons, eNodeB membalas dengan pesan respons akses. Pesan ini berisi timing advance, yaitu waktu yang diperlukan untuk memastikan bahwa uplink disinkronkan dengan eNodeB. Setelah itu, UE mengirimkan permintaan koneksi RRC, juga dikenal sebagai pesan tiga. Di sinilah eNodeB meminta pengaturan RRC. Jadi, KPI RRC kita dimulai dari sini. Jika kita memiliki tingkat kegagalan yang tinggi, jika UE mengirimkan permintaan akses dan kita tidak menerimanya, atau jika UE menerima respons akses tetapi kita tidak menerima permintaan koneksi RRC, dalam hal ini, KPI RRC akan tidak terpengaruh. KPI RRC dimulai pada titik ini.

 

Sekarang, mari kita bahas tentang berbagai jenis pesan RRC. Ada banyak jenisnya, tapi yang utama yang kita miliki adalah pengaturan konteks awal, serah terima, dan pemilihan ulang sel. Jadi, mari kita pahami setiap jenisnya. Jika misalnya saya memiliki ponsel dan ingin mengirim sesuatu, misalkan saya ingin mengirim pesan WhatsApp, yang akan saya lakukan adalah mencoba menyambung ke jaringan dengan pengaturan konteks awal karena saya perlu mengirim beberapa data . Sekarang, jika saya memiliki ponsel dan berpindah dari satu lokasi ke lokasi lain, maka saya mengubah kode area pelacakan, dalam hal ini, saya perlu melakukan pembaruan area pelacakan. Dalam hal ini, permintaan koneksi RRC akan memiliki sinyal handover. Demikian pula, jika saya memiliki ponsel dan saya menerima panggilan suara masuk atau seseorang mengirimi saya pesan WhatsApp, maka saya akan menerima permintaan respons paging dari jaringan. Dalam hal ini, permintaan koneksi RRC akan memiliki sinyal pemilihan ulang sel. Jadi dengan melihat signalnya kita bisa menentukan jenis layanan apa yang diinginkan, jenis layanan apa yang ingin diakses jaringannya. Ini adalah sesuatu yang bisa kita peroleh dari jenis pesan ini.

 

Sekarang, apa yang terjadi setelah itu? eNodeB membaca permintaan koneksi RRC dan kemudian merespons dengan pengaturan RRC. Ini membawa beberapa konfigurasi jaringan langsung yang diperlukan oleh UE untuk memulai koneksi jaringan atau menyelesaikan pengaturan RRC. Setelah membaca konfigurasi ini, UE menerapkannya dan merespons dengan pesan pengaturan RRC lengkap, yang akan menjadi pesan nomor lima. Ketika eNodeB menerima pesan ini, eNodeB mengakui bahwa pengaturan RRC berhasil, dan kami menyebutnya sebagai upaya pengaturan RRC yang berhasil. Jadi, tingkat RRC Success inilah yang kita sebut dengan RRC KPI. 

Sekarang, ada beberapa pengatur waktu penting di sini. Misalnya, kita memiliki pengatur waktu UE T300, yang dimulai setelah UE mengirimkan pesan tiga dan berhenti ketika menerima pesan empat, yang merupakan pengaturan RRC. Sekarang, jika pengatur waktu ini terlalu kecil, UE akan menghentikan pengatur waktu ini dan mengirimkan permintaan koneksi RRC lagi, sehingga kita akan mengalami kegagalan pada akhirnya karena eNodeB akan mengirimkan pesan ini lebih lama lagi sebelum pengatur waktu berakhir, dan pesan ini akan tidak pernah tiba. Jadi, jika kita meningkatkan timer ini, kita memiliki peluang lebih tinggi untuk menerima setup RRC, terutama ketika kita mengalami kemacetan di eNodeB. Timer lain di sisi eNodeB adalah timer T302. Timer ini dimulai ketika eNodeB menerima permintaan koneksi RRC dan menunggu setup RRC selesai. Ini diatur oleh timer di sisi eNodeB. Sekarang, jika pengatur waktu ini kecil, jika habis masa berlakunya, eNodeB akan menganggapnya sebagai kegagalan RRC, dan dengan demikian, kita akan memiliki tingkat RRC Success yang lebih rendah. Jadi, meningkatkan timer ini juga dapat meningkatkan peluang tingkat RRC Success. Ini adalah dua pengatur waktu dasar yang kami miliki di bagian RRC.

Sekarang, mari kita lanjutkan dan pahami jenis kegagalan atau batasan terpenting yang kita miliki pada tingkat RRC Success. Salah satu masalah paling umum yang kami hadapi untuk KPI tingkat RRC Success LTE adalah kegagalan RRC karena tidak adanya respons. Artinya UE mengirimkan permintaan koneksi RRC, eNodeB merespon dengan setup RRC, namun setelah itu, UE mengirimkan setup RRC selesai, namun eNodeB tidak menerimanya atau eNodeB tidak dapat mendecodenya. 

Dalam kasus ini, kami melihat tingkat RRC Success mengalami kegagalan, dan tingkat RRC Success kami lebih rendah. Ini adalah skenario umum yang biasanya terlihat dalam masalah liputan. Ketika Anda memiliki masalah cakupan, penyelesaian pengaturan RRC akan memiliki tingkat kegagalan yang lebih tinggi. Sekarang, mengapa hal ini bisa terjadi? Mari kita pahami masalah paling umum dan mengapa hal itu terjadi. Pada dasarnya, ini adalah masalah sinyal.

 Nah, jika kita memahaminya, permintaan koneksi RRC juga merupakan pesan uplink. Penyiapan RRC selesai juga merupakan pesan uplink. Jadi, mengapa pesan ini berhasil didekodekan tetapi terkadang pesan ini tidak berhasil didekodekan untuk UE yang sama? Hal ini terjadi karena besarnya pesan. Mari kita pahami ini. Pertimbangkan skenario ini. Pertama, kami memiliki pengguna yang menggunakan permintaan koneksi RRC untuk data MO atau akses kosong. Sekarang, pengguna ini akan mengirimkan setup RRC selesai, yang akan menjadi paket yang jauh lebih kecil, mungkin sekitar 10 byte.

Jadi, jika 10 byte dan hanya memerlukan dua blok sumber daya, maka daya UE didistribusikan ke dua blok sumber daya saja. Di sisi lain, permintaan koneksi RRC membawa pesan NAS, yang merupakan permintaan lampiran atau permintaan pembaruan area pelacakan. Jadi, ini adalah pesan yang jauh lebih besar. Itu bisa mencapai 100 byte dari 50 byte. 

Jadi, jika pesannya lebih besar, maka memerlukan lebih banyak blok sumber daya. Jadi, katakanlah dalam contoh ini, kita memiliki 10 blok sumber daya. Jadi, sekarang daya per blok sumber daya adalah 200 miliwatt dibagi 10 blok sumber daya, yaitu 20 miliwatt. Jadi, kita dapat melihat bahwa daya per blok sumber daya kini lima kali lebih kecil dibandingkan dengan data MO atau akses kosong. Lalu, apa yang akan terjadi pada sisi eNodeB? Lebih mudah untuk memecahkan kode pesan yang memiliki kekuatan lebih tinggi dibandingkan dengan pesan yang memiliki kekuatan lebih rendah. Jadi, kemungkinan kegagalan total penyiapan RRC untuk pensinyalan MO jauh lebih tinggi. Jadi, jika Anda membandingkan tingkat keberhasilan penyiapan RRC untuk akses kosong, pensinyalan MO, dan pensinyalan MO, kemungkinan besar Anda akan melihat bahwa pensinyalan MO memiliki tingkat RRC Success yang jauh lebih rendah. 

Jadi, ini juga berarti bahwa dalam jaringan di mana Anda memiliki lebih banyak permintaan koneksi RRC berdasarkan sinyal MO, jaringan tersebut akan memiliki tingkat keberhasilan penyiapan RRC yang lebih rendah. Dan mengapa jaringan memiliki lebih banyak permintaan sinyal MO? Katakanlah jika satu jaringan memiliki area pembaruan area pelacakan yang lebih kecil dibandingkan dengan jaringan lain yang memiliki area pelacakan lebih besar, maka jaringan tersebut akan memiliki lebih banyak pembaruan area pelacakan. Jadi, permintaan sinyal MO akan lebih banyak. Jadi, Anda dapat memeriksa jaringan Anda dan mengetahui berapa banyak permintaan koneksi RRC yang datang dari sinyal MO. Dan jika terlalu tinggi, tingkat keberhasilan penyiapan RRC Anda akan sedikit lebih rendah dibandingkan dengan jaringan lain yang memiliki permintaan sinyal MO lebih sedikit.

Masalah lain yang dapat menyebabkan kegagalan total pengaturan RRC adalah gangguan. Jika eNodeB menghadapi masalah interferensi, eNodeB mungkin tidak dapat memecahkan kode pesan uplink, yang juga dapat berdampak pada tingkat RRC Success. Dalam hal ini, Anda dapat mengaktifkan penggabungan penolakan (rejection) interferensi dengan menerapkan algoritma IRC pada eNodeB. Selain itu, jika pola gangguannya berbeda-beda, misalnya lebih tinggi pada siang hari dan lebih rendah pada malam hari, berarti hal tersebut berkaitan dengan lalu lintas. 

Dalam hal ini, menyesuaikan kemiringan dapat membantu meningkatkan skenario interferensi Anda dan KPI RRC lainnya juga. Jika Anda melihat interferensi yang tinggi baik pada siang maupun malam hari, biasanya hal tersebut mengindikasikan adanya interferensi dari luar. Dalam hal ini, Anda dapat memeriksa apakah interferensi terjadi pada pita penuh atau pita parsial. Jika hanya pada pita parsial, Anda dapat menjadwalkan data uplink di lokasi bebas gangguan, yang juga dapat meningkatkan performa dan KPI Anda.

Ini adalah beberapa hal yang dapat terjadi dan membantu Anda dalam skenario gangguan. Masalah lain yang dapat terjadi dan menyebabkan kegagalan total penyiapan RRC adalah UE yang tidak kompatibel. Katakanlah UE yang telah mengirimkan permintaan koneksi RRC akan direspon dengan pengaturan RRC, tetapi UE mengetahui dalam pengaturan RRC bahwa ia tidak mendukung konfigurasi ini. Jadi, ini mungkin berhenti di sini dan pengaturan RRC tidak selesai. 

Dalam kasus ini, ia mungkin mencoba lagi permintaan sambungan RRC dan kembali menerima pengaturan RRC yang tidak kompatibel. Jadi, itu akan gagal lagi. Dalam hal ini, UE yang tidak kompatibel dapat terus mencoba mengakses jaringan dan, singkatnya, hal ini dapat mengacaukan KPI. Untuk masalah seperti itu, Anda dapat melacaknya di lapisan RRC, dan dalam permintaan koneksi RRC, Anda dapat memeriksa TMSI. Jika TMSI sama untuk beberapa permintaan, Anda dapat mengidentifikasi bahwa ini adalah UE yang menyebabkan masalah, dan Anda dapat mengetahui bahwa ini bukan masalah jaringan tetapi masalah UE. Ini adalah beberapa trik yang dapat Anda lakukan untuk kegagalan RRC, terutama untuk masalah tanpa respons.

Pilihan lainnya adalah kegagalan RLC karena penolakan (rejection). Hal ini terjadi dalam skenario ketika UE mengirimkan permintaan koneksi RRC, dan ditanggapi dengan penolakan (rejection) pengaturan RRC. Dalam hal ini, UE akan mengalami kegagalan RRC, namun kegagalan ini biasanya terjadi ketika eNodeB sedang mengalami kepadatan, artinya telah mencapai jumlah maksimum pengguna yang terhubung atau semacam algoritma kontrol penerimaan sedang berjalan atau telah mencapai batas lisensinya atau sudah mencapai batas lisensinya. telah mencapai batas sinyalnya, misalnya jumlah upaya panggilan per detik. Jadi, masalah seperti itu dapat menyebabkan penolakan (rejection) RRC, dan ini biasanya terjadi ketika lalu lintas tinggi atau situs memuat banyak. Dalam hal ini, UE mendapat penolakan (rejection) pengaturan RRC dan kemudian menunggu pengatur waktu T302,

dan setelah T302 habis masa berlakunya, ia dapat mencoba mengirim kembali permintaan koneksi RRC. Jadi, pengatur waktu ini bertindak sebagai histeresis untuk memastikan bahwa satu pengguna atau beberapa pengguna tidak membanjiri eNodeB dengan terlalu banyak permintaan setelah penolakan (rejection). Jadi, ini adalah pengatur waktu yang dapat Anda mainkan dalam skenario tertentu ketika Anda memiliki tingkat penolakan (rejection) yang tinggi. 

Jika timer ini dinaikkan maka yang terjadi adalah UE akan mengirimkan permintaan koneksi RRC lebih lanjut, dan dalam hal ini, kita mempunyai kemungkinan tidak akan mengalami kongesti. Skenario lain, katakanlah, ambil contoh ini. Sekarang, kita mempunyai eNodeB dengan kapasitas penuh karena, katakanlah, ia dapat menangani lima pengguna. Jadi, katakanlah kelima pengguna terhubung. Sekarang, jika UE dari mode idle mencoba menyambung, ia akan mengirimkan permintaan koneksi RRC, dan eNodeB akan merespons dengan penolakan (rejection) pengaturan RRC. Dalam hal ini, UE akan ditolak, dan RRC akan gagal. Sekarang, apa yang akan terjadi sekarang? Apa yang bisa kita lakukan untuk skenario ini? Salah satu cara cepat untuk menangani masalah tersebut atau mengurangi kemacetan ini adalah dengan menyesuaikan pengatur waktu mode idle.

Jadi kalau timer mode idle kita kurangi, misalkan kita kurangi dari 20 detik menjadi misalkan dua detik, maka semua pengguna akan cepat lepas karena tidak ada aktivitas. Jadi, jika pengatur waktu mode idle adalah 20 detik dan saya membuatnya, katakanlah, dua detik, maka semua pengguna akan dilepaskan dengan cepat karena sebelumnya mereka menunggu selama 20 detik, dan sekarang mereka hanya akan menunggu selama dua detik, dan eNodeB akan merilisnya. 

Jadi, UE akan berpindah ke mode idle dengan cepat, dan dalam hal ini, kita akan memiliki kapasitas lebih besar di sini. Sekarang, kelemahannya adalah ketika Anda melepaskan lebih banyak UE ke mode idle, mereka akan mencoba untuk terhubung lagi. Jadi, Anda akan memiliki lebih banyak permintaan koneksi RRC. Jadi, jika eNodeB menghadapi masalah batas pengguna yang terhubung, namun tidak ada masalah dengan upaya panggilan per detik atau batas, maka meningkatkan pengatur waktu mode idle sebenarnya dapat membantu. Jika eNodeB tidak menghadapi masalah batas pengguna yang terhubung, namun menghadapi masalah upaya panggilan per detik, maka meningkatkan pengatur waktu mode idle dapat membantu dalam kasus ini. Nah, itulah beberapa hal yang bisa kita lakukan untuk skenario penolakan (rejection) RRC.

Masalah lain yang dapat menyebabkan kegagalan total pengaturan RRC adalah kapasitas PUCCH. PUCCH di uplink memiliki kapasitas terbatas karena harus menggandakan pengguna untuk pengakuan HARQ, umpan balik CQI, dan permintaan penjadwalan mereka. Jadi, ketika Anda memiliki banyak pengguna, kemungkinan kapasitas CCH Anda sudah mencapai batasnya. Dalam hal ini, eNodeB dapat mengirimkan penolakan (rejection) pengaturan RRC karena kemacetan PUCCH. Dalam hal ini, Anda dapat memperluas PUCCH dengan menggunakan fitur seperti PUCCH dinamis atau adaptif. Yang perlu Anda lakukan adalah terus memantau permintaan dan menyediakan lebih banyak sumber daya GPU CCH, yang dapat memperluas kapasitas dan tidak akan mengakibatkan penolakan (rejection) pada level RRC RL untuk skenario kemacetan berbasis PUCCH. Ini adalah beberapa trik yang bisa kita lakukan untuk skenario penolakan (rejection) RRC.

Itu saja untuk hari ini. Saya rasa kita telah membahas dua skenario utama, yang pertama adalah kegagalan RRC karena tidak adanya respons, yang telah kita diskusikan, dan yang lainnya adalah kegagalan RLC karena penolakan (rejection), yang juga telah kita diskusikan. Kami juga membahas tentang masalah fading yang umum dan bagaimana hal itu dapat menyebabkan kegagalan pengaturan RRC karena tidak ada respons. Kami mendiskusikan masalah cakupan terkait dan apa yang dapat kami lakukan untuk mengatasinya. Kalau untuk penolakan (rejection) RRC lebih ke masalah kemacetan dimana kita mengalami trafik yang tinggi. Meski hal ini tidak Anda lihat setiap hari, ada baiknya Anda mengetahui apa penyebabnya dan bagaimana cara mengatasinya.

 

Terima kasih banyak untuk hari ini.