BAB III
PROSES OPTIMISASI TRANSCODERPOOL
3.1 Diagram Alur Optimisasi Transcoder Pool
Dalam proses optimisasi transcoder ini dilakukan dengan cara pengecekkan kondisi TRApool untuk dilanjutkan dengan metode optimisasinya seperti load balancing dan atau adding capacity.
Gambar 3.1 Flowchart Proses Optimisasi TRApool
3.2 Pengechekan Performansi TRA
Pengechekan performance TRA dilakukan bisa berdasarkan alert yang setiap hari muncul dan juga saat pengecekkan congestion pada suatu BSC dengan kondisi kenaikkan congestion terjadi tersebar diseluruh cell under BSC tersebut.
3.2.1 Pengecekkan Berdasarkan Alert
Pengecekkan performansi TRA berdasarkan alert Self Configuration of Transcoder Pools (SCTP) merupakan rutinitas pengecekkan karena alert dikirimkan setiap hari sehingga dapat dilakukan monitoring secara kontinu.
Tabel 3.1 Alert TRA per BSC
Dari contoh alert diatas, diketahui bahwa ada 3 status SCTP yaitu active, passive dan halted. Status active dimaksudkan kondisi TRA yang masih beroperasi. Passive dimaksudkan kondisi TRA yang belum beroperasi bisa dikarenakan BSC tersebut baru sehingga traffic belum dialirkan, sedangkan untuk halted dimaksudkan adanya problem di hardware.
Self Configuration of Transcoder Pools (SCTP) sendiri merupakan aplikasi yang digunakan dalam proses balancing traffic pada TRA pool. SCTP akan melakukan proses request dan receive resource pada TRA pool yang sudah mencapai threshold capacity (request) ke pool lain yang capacity-nya masih available untuk menerima (receive). Hal itu dilakukan agar kualitas performance voice tetap terjaga dan tidak menimbulkan congestion.
Pada SCTP juga dapat diketahui kapasitas pools yang ada pada suatu BSC sehingga kita dapat mengetahui pool mana yang sudah mencapai batasnya. Pada alert diatas diketahui bahwa BSC BMLG2 status SCTP nya halted adalah proses request dan receiveresource pada TRA pool nya terganggu / bermasalah.
Hubungan antara status BSC dari alert SCTP yang problem (halted) dengan kenaikkan congestion adalah pada saat pool A sudah mencapai batasnya dan dia melakukan proses request ke pool B, C dan D agar dapat melakukan load sharing, namun pool B, C dan D tidak memberikan resource untuk melakukan load sharing. Maka pada proses request pool A akan terus looping (berlangsung) menyebabkan penumpukkan request ke pool yang dituju dan traffic yang mengalir ke pool A tidak dapat tertampung, sehingga pool A menjadi congest. Kondisi tersebut berimbas pada kualitas voice, yaitu sulit melakukan panggilan.
3.2.2 Pengecekkan Berdasarkan Statistik
Pengecekkan statistik performansi TRA dilakukan untuk mengetahui pool mana yang sudah ataupun belum full resource-nya sebagai langkah awal untuk troubleshooting TRA apakah nantinya akan menggunakan cara balancing ataupun adding capacity.
Dalam hal ini diambil kasus yang terjadi pada region I ( Pulau Jawa dan Kepulauan Madura) yaitu area Malang dimana performansi congest pada BMLG2 terus meningkat. .
Gambar 3.2 Performance utilization Congestion TRA BMLG2
Pada kondisi gambar 3.2 menunjukan utilisasi presentase performance (Average of perceive_cong_ratio) kualitas suara pada area BMLG2 mengalami peningkatan congest yang tinggi,terlihat pada BMLG2 terjadi kenaikan > 3%. Hal ini yang mengakibatkan terjadinya alarm pada BSC tersebut. Untuk standart kenaikan congest / drop calls pada jaringan GSM nilainya sebesar 1,0 – 2,0 % , jika melebihi dari nilai tersebut maka jaringan pada suatu BSC tersebut sangat buruk.
3.3 Planning Balancing TRA
Proses balancing dilakukan dengan langkah – langkah sebagai berikut: 1. Memperhatikan nilai Per_Used tiap pool, dengan batas percentage
penggunaannya < 70% (nilai presentage sesuai dengan table alarm)
2. Melihat kondisi available resource tiap pool (TRA_Avail) kemudian bandingkan dengan TRA_Used.
3.3.1 Nilai Per_Used (Percentage Used)
Proses load balancing TRA bisa dilakukan jika pada TRApool nilainya lebih dari 70%. Sehingga pool yang kekurangan resource untuk menampung traffic yang kelebihan resource dilakukan load sharing ke pool lain sehingga beban pada pool tersebut bisa mencapai nilai ≤ 70% agar meminimalisir congestion.
Untuk kasus ini, di aplikasikan pada BMLG2 dimana pool AMRFR akan mendekati 75% mencapai di nilai 74,15% sehingga untuk menghindari congestion diperlukan proses loadbalancing ke pool lain yang masih available.
Tabel 3.2 Kapasitas TRA POOL BMLG2
Terlihat pada tabel 3.2 nilai BSC Malang kapasitas pool AMRFR (PER_used) hampir mencapai 75% sedangkan untuk pool yang lain masih dibawah 50%. Batas aman untuk TRA nilainya dibawah 70%.
Kondisi pool AMRFR nilai Per_Used yang mencapai 74,15% dikarenakan adanya congestion TRA yang terjadi pada pool tersebut.
3.3.2 Kondisi TRA_Avail
Langkah yang kedua dalam proses balancing load TRApool adalah kondisi TRA_Avail. Hal ini juga menjadi acuan untuk menentukan pool mana yang akan di load balancing dengan kondisi mengurangi percentage using dari pool yang sudah melebihi 70% namun tidak membuat destination pool yang akan ditambahkan kapasitas bernilai > 70%.
Tabel 3.3 Destination pool
Keterangan :
TRA_AVAIL : TRA Availability TRA_Used : TRA Used TRA_idle: free space TRA
PER_used : Precentage used PER_idle : Precentage free space
Dari Tabel 3.3 terlihat beberapa pool selain AMRFR memiliki nilai Per_Used yang berada > 70% namun jika dilihat kondisi TRA_Avail di compare dengan TRA_Used yang memungkinkan menjadi destination pool adalah AMRHR. Hal tersebut dikarenakan nilai TRA_Avail presentage used bernilai 32,50% (PER_Used). Masih cukup resource untuk dilakukan balancing dengan pertimbangan nilai Per_Used tidak mencapai > 70%. Sedangkan untuk pool yang lain kapasitas TRA Availability kecil sehingga tidak memungkinkan untuk dilakukan load balancing.
3.3.3 SkenarioPerhitungan Load Balancing TRApool
Load balancing sendiri dilakukan dengan formula additional dan reducting. Additional dimaksudkan penambahan resource pada destination pool yang dituju untuk mengurangi load yang lebih. Sedangkan reducting adalah pengurangan load pada pool yang sudah melebihi batas 70% agar TRApool tidak mengalami congest atau pada status alarm halted.
- Formula additional AMRFR: ( )
1. Nilai delta Per_Used :
2. Nilai Load balancing :
Dari nilai load balancing di dapat 12,81 channel namun diambil nilai pembulatan yaitu 13 channel (memudahkan perhitungan).
3. Nilai dan Per_Usednew :
( ) %
- Formula reducting AMRHR:
1. Nilai TRA Availnew :
2. Nilai : 3. Nilai : % %
Nilai dari perhitungan terlihat pada tabel 3.4 , nilai ini kemudian di eksekusi dalam balancing load dengan menggunakan command pada citrix.
3.3.4 Eksekusi dengan Citrix
Proses eksekusi terakhir adalah dengan MML command pada aplikasi Citrix. Command yang digunakan adalah :
RRTBI:DEV=RTTG1D-13120&&-13151,FORCE;
RRTCC:DEV=RTTG1D-13120&&-13151,CHRATE=AMRHR,SPV=13;
RRTBE:DEV=RTTG1D-13120&&-13151;
Command RRTBI atau Radio Transmission Manual Blocking of Transcoder Device Initiate dimaksudkan untuk memblok device TRApool yang akan dieksekusi.
RRTCC, Radio Transmission Transcoder Configuration Change yaitu command untuk perubahan channel rate dan supervisor atau numbering jenis codec yang digunakan.
RRTBE, Radio Transmission Manual Blocking of Transcoder Device End dimana digunakan untuk disable proses block device dan menunjukkan proses telah selesai.
3.4 Adding Capacity TRApool
Untuk proses adding capacity dilakukan dengan cara memasukkan board CSPB 2.0 ke subrack BSC tersebut. Pertama-tama data TRApool di query untuk melihat kapasitas yang masih available dan yang sudah dipakai. Dari hasil query terlihat kapasitas tiap pool nya sehingga dapat dilakukan perhitungan berapa channel yang akan ditambahkan, dari jumlah propose penambahan channel pada pools yang ada dapat diketahui berapa board yang akan di insert-kan pada subrack BSC tersebut.
Tabel 3.5 Kapasitas TRA POOL BOMB1
Keterangan :
Tra avail, used, idle : number Per used idle : percentage
Pada table 3.5 terlihat presentage yg di gunakan (Per_Used) pada BSC sangat tinggi. Nilainya AMRFHR dan HR semua di atas 70%. Sehingga hal ini tidak mungkin dilakukan load balancing, maka di lakukan penambahan board / adding capacity.
Gambar 3.3 Performance Utilisasi BOMB1
Jika dilihat pada gambar 3.3 pada kurva biru, terlihat bahwa kapasitas TRA yang digunakan sudah hampir mencapai kapasitas yang available (garis merah), selain itu proses load balancing tidak mungkin dilakukan karena hal tersebut belum dapat membuat load traffic yang terus masuk dapat di handle
dengan baik sehingga akan menimbulkan congest. Oleh karena itu perlu dilakukan adding capacity.
Dalam proses penambahan kapasitas TRApool perlu diperhatikan hal – hal sebagai berikut :
1. Jumlah board TRA yang sudah digunakan di BSC tersebut, sehingga dapat diketahui berapa board yang bisa ditambahkan.
2. Type board CSPB yang compatible.
3. Skenario penambahan resource di tiap pool yang ada. Utamakan untuk pool yang sudah mencapai atau melebihi 70%.
3.4.1 Type Board CSPB
Ada beberapa type TRA board yang digunakan, yaitu: 1. CSPB 1.0
Board ini mampu menghandle 192 speech channel dan mendukung codec EFR, FR, HR dan AMR HR.
2. CSPB 1.1
Board ini mampu menghandle 192 speech channel dan mendukung codec EFR, FR, HR dan AMR (HR, FR dan WB).
3. CSPB 2.0
Board ini mampu menghandle 384 speech channel dan mendukung codec EFR, FR, HR dan AMR (HR, FR dan WB).
Penambahan kapasitas TRApool dengan menambahkan board CSPB 2.0 dimana board tersebut mampu menampung 384 speech channel dan mendukung hampir semua speech codec EFR, FR, HR dan AMR (HR, FR dan WB). Selain itu juga dikarenakan device TRA yang digunakan compatible dengan CSPB 2.0.
Setelah melakukan penambahan board CSPB, perlu diketahui pula kapasitas yang di BSC tersebut.
Dalam proses adding capacity dilakukan pada BOMB1 dikarenakan kapasitas yang sudah sangat kurang. Penambahan kapasitas TRApool lebih diutamakan pool AMRHR dan HR dikarenakan nilai Per_Used > 70%.
1. Kapasitas pada pool AMRHR
0,23 ( ) ( )
Jumlah board CSPB sebesar 2381 : 384 = 6,2 6 board CSPB 2.0 ( ) % %
2. Penambahan kapasitas pada pool HR
( )
( ) Jumlah board CSPB sebesar 1 board
( )
Tabel 3.5 Hasil Adding Capacity BOMB1
Dari table 3.5 terlihat perubahan nila TRA_Avail dan Per_used yang sudah dilakuakan perhitungan sesuai dengan formula reducting . Untuk dua pool tersebut membuat nilai Per_Used masing-masing pool menjadi dibawah 70%. Pool AMRHR sendiri sudah memakai kapasitas baru sebanyak 2382 channel atau sekitar 6 board CSPB 2.0 dan jika dilihat untuk pool HR membutuhkan alokasi sebesar 81 channel jadi cukup dengan penambahan 1 board (CSPB 2.0).
Tabel 3.6 Alert TRA per BSC setelah Load Balancing dan Adding Capacity
Table 3.6 adalah hasil alert pada SCTP setelah di lakukan load balancing dan adding capacity, pada BMLG2 dan BOMB1 yang sebelumnya status alertnya Halted sudah berubah menjadi Active. Hal ini di artikan bahwa sudah tidak ada masalah dalam komunikasi suara pada area tersebut.
