• Tidak ada hasil yang ditemukan

BAB IV PENGUJIAN DAN ANALISIS

N/A
N/A
Protected

Academic year: 2021

Membagikan "BAB IV PENGUJIAN DAN ANALISIS"

Copied!
15
0
0

Teks penuh

(1)

BAB IV

PENGUJIAN DAN ANALISIS

Dalam bab ini dilakukan pengujian dan analisis/verifikasi kesesuaian simulator dibanding dengan sistem nyatanya. Ada dua aspek yang dibandingkan, yaitu kesesuaian urutan proses dan kesesuan karakteristik masukan/keluaran simulator simulator

IV.1 Skenario Pengujian

Untuk melakukan verifikasi kedua aspek di atas, skenario yang dilakukan adalah seperti ditunjukkan dalam Gambar 4.1

Buffer (q) : tak terbatas

Laju kedatangan (λ) =1 - Jumlah panggilan (c)

c/t =λ - Perioda (t)

Komponen-komponen delay :

- Call-admission delay (tadm)

- Call-setup delay (tsup)

- Call clearing delay (tclr)

- Call Occupancy (tocc)

Laju kedatangan (λ) =36

MASUKAN

(inisiasi simulator) SKENARIO PERCOBAAN

KELUARAN

PENGUJIAN & ANALISIS

PENGUJIAN KARAKTERISTIK MASUKAN

(TRAFFIC GENERATOR) à Kesesuaian dg Model Poisson

• Waktu antar kedatangan

t e t

f( )=

λ

−λ

PENGUJIAN KARAKTERISTIK KELUARAN :

- Call admission delay (tadm)

- Call setup delay (tsup)

- Call clearing delay (tclr)

- Call occupancy (tocc)

• Kesesuaian dengan model antrianM/G/1

) 1 ( 2 2 ρ λ − + =M M D

(2)

IV.2 Pengujian

Dalam pengujian berikut, dilakukan percobaan dengan menjalankan program simulasi sebanyak 36 kali seperti skenario yang ditunjukkan pada Gambar 4.1. Setiap percobaan diberikan inisiasi (masukan) harga C (jumlah panggilan) dan T (perioda waktu) untuk setiap skenario (I, II dan III). Dalam tiap percobaan harga C dan T masing-masing skenario dipilih sedemikian rupa, sehingga memberikan harga laju kedatangan total λ = (λ1 + λ2 + λ3

1. Setelah program simulator dibuka, akan tampil menu inisiasi untuk memasukkan data jumlah panggilan dan perioda pengamatan, kapasitas buffer seperti diperlihatkan pada Gambar 4.2

) = 1 pada percobaan 1, λ = 2 pada percobaan 2 dan seterusnya hingga λ = 36 pada percobaan ke 36. Hal ini dimaksudkan untuk memberikan kenaikan beban (intensitas trafik/laju kedatangan) pada Softswitch secara bertahap agar dapat diteliti respon/performansi dari Softswitch (yang direpresentasikan oleh parameter delay atau lama waktu proses yang dialami sebuah panggilan dalam Softswitch). Adapun tahap-tahap percobaan tersebut adalah sebagai berikut :

(3)

76

2. Sebelum simulator dijalankan, dilakukan verifikasi karakteristik sumber trafik secara visual dengan menekan button View pada masing-masing skenario seperti nampak pada Gambar 4.3

Gambar 4.3 Pengecekan karakteristik sumber trafik

3. Simulator kemudian dijalankan dengan menekan button Start Simulation dan akan nampak seperti Gambar 4.4

(4)

Inisiasi/masukan (N, T)

Tampilan progress pesan protokol File-file hasil pencatatan detail proses panggilan, (1 file per-panggilan), lihat contoh Gambar 4.3

Tampilan (animasi) pemakaian bandwidth, rekap jml panggilan yang sedang berlangsung : Informasi progress

panggilan (dinamika proses tiap

panggilan)

Gambar 4.4 Tampilan saat simulator sedang berjalan

4. Jika simulator telah selesai memproses seluruh panggilan, baik untuk sesi

signaling maupun sesi bicara, maka akan didapat sjumlah file txt (Wordpad)

sebanyak jumlah yang telah diproses. Sebagai contoh dapat dilihat pada Gambar 4.5 (merupakan sebagian dari sebuah file txt) hasil pencatatan data panggilan Skenario I

(5)

78 Waktu terjadinya permintaan panggilan

(tanggal dan jam) Panggilan SKENARIO I (dari pelanggan Access

Gateway-a ke pelanggan Access Gateway B)

No tlp pemanggil (saat pemanggil baru mengangkat handset) untuk duverifikasi oleh Softswitch

Nama protokol (MEGACO) dan pesan yang dikirim (Notify)

Alamat IP (source/destination) yaitu dari AG ke Softswitch

dan seterusnya seperti telah dibahas pada Bab III Pesan baasan (acknowledgement) dari Softswitch

bahwa pesan Notify telah diterima dengan bai

Pesan/perintah dari Softswitch ke Access Gateway-A untuk menyiapkan port RTP setelah Softswitch menganalisis nomor tujuan dan memeriksa otoritas pemanggil (pelanggan A)

Acknowledgement dari Access Gateway-A atas pesan/perintah sebelumnya (pesan Modify dari Softswitch)

[2008-7-26 2:46:6:513][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 [2104077] [2008-7-26 2:46:6:513][SKENARIO1 ] MEGACO Reply Notify 172.16.0.1 172.16.0.2 [PROCESSING]Notify Reply => 733 [CALLADMISSION]Notify Reply => 733 [2008-7-26 2:46:6:700][SKENARIO1 ] MEGACO Modify 172.16.0.1 172.16.0.2 [2008-7-26 2:46:6:700][SKENARIO1 ] MEGACO Reply Modify 172.16.0.2 172.16.0.1 [2008-7-26 2:46:7:886][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 2212633

Gambar 4.5 Contoh (sebagian) data hasil pencatatan dari sebuah panggilan Skenario I (hasil capture oleh simulator)

(6)

Tahapan di atas diulang untuk setiap inisiasi percobaan dengan laju kedatangan tertentu yang dinaikkan secara bertahap sebanyak 36 kali percobaan sesuai skenario pada Gambar 4.1. Dari 36 kali percobaan tersebut, total jumlah panggilan sebanyak 677 panggilan (677 buah file txt/wordpad). Sebagai sampel/contoh, pada Lampiran C diperlihatkan hasil record file wordpad dari proses panggilan, masing-masing dari Skenario I, II dan III untuk kondisi pelanggan tujuan bebas maupun sibuk. Data sebanyak 677 file tersebut kemudian diproses (direkap dalam sebuah Tabel seperti contoh sampel pada Lampiran-D)

IV.3Analisis dan Verifikasi

Setelah diperoleh hasil seperti pada Lampiran D, selanjutnya dilakukan uji verifikasi simulator dari dua aspek, pertama dari segi kesesuaian urutan proses panggilan, kedua, dari segi akurasi karakteristik masukan (generator trafik) dan karakteristik keluaran (delay) meliputi call admission delay, call set-up delay, call clearing delay dan call occupancy.

IV.3.1Analisis Urutan Proses Panggilan

Metoda yang digunakan adalah membandingkan hasil pencatatan proses komunikasi simulator dengan urutan proses komunikasi berdasarkan urutan mekanisme protokol komunikasi. Yaitu dengan pemetaan (maping) antara data hasil pencatata proses panggilan simulator dengan gambar standar proses komunikasi standar (call flow). seperti Gambar 4.6, yang meupakan hasil call record sebagian (sampel) proses pada Skenario I.

(7)

80 [2008-7-27 23:28:17:247][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 [2111035] [2008-7-27 23:28:17:247][SKENARIO1 ] MEGACO Reply Notify 172.16.0.1 172.16.0.2 [PROCESSING]Notify Reply => 375 [CALLADMISSION]Notify Reply => 375 [2008-7-27 23:28:17:278][SKENARIO1 ] MEGACO Modify 172.16.0.1 172.16.0.2 [2008-7-27 23:28:17:278][SKENARIO1 ] MEGACO Reply Modify 172.16.0.2 172.16.0.1 [2008-7-27 23:28:18:557][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 2250810 [2008-7-27 23:28:18:557][SKENARIO1 ] MEGACO Reply Notify 172.16.0.1 172.16.0.2 [PROCESSING]Notify Add => 94 [2008-7-27 23:28:18:635][SKENARIO1 ] MEGACO Add 172.16.0.1 172.16.0.2 [2008-7-27 23:28:18:635][SKENARIO1 ] MEGACO Reply Add 172.16.0.2 172.16.0.1 1. Notify Off hook 2. Reply 3. Modify 5. Notify Digits 6. Reply 7. Add 8. Reply 11. Modify 12. Reply Dial Tone 4. Reply

User (A) Access Gateway (A)

0222100000 172.16.0.2 Ringing Tone

Gambar 4.6 Pemetaan data hasil capture simulator ke dalam

IV.3.2 Analisis Karakteristik Masukan (Traffic Generator)

Pengujian dilakukan terhadap pola distribusi waktu antar kedatangan[25] dimana data waktu antar kedatangan tersebut harus berdistribusi eksponensial negatif. Dari data percobaan senbanyak 677 panggilan atau data waktu antar kedatangan sebanyak 641 data (Lampiran-E, setelah dilakukan pengelompokan data berdasarkan rentang (kelas), diperoleh gambar Grafik seperti Gambar 4.7 berikut

(8)

Gambar 4.5 Verifikasi distribusi waktu antar kedatangan generator trafik

Berdasarkan gambar tersebut, dapat disimpulkan, bahwa generator trafik memiliki karakteristik berdistribusi eksponensial negatif.

IV.3.3 Analisis Karakteristik Keluaran (delay) pada Softswitch

Validasi ini dimaksudkan unuk menguji, sejuah mana akurasi keluaran simulator (Softswitch) dibanding sistem nyatanya. Metoda yang digunakan adalah metoda analitik dimana Softswitch dipandang sebagai sistem antrian yang akan diverifikasi dengan model antrian M/G/1. Yang diverifikasi adalah hasil keluaran simulator (komponen

delay tadm, tcsu, tclr dan tocc) sebagai fungsi dari laju kedatangan (λ) dengan hasil

(9)

82

Gambar 4.6 Proses validasi akurasi simulator

Komponen delay (lama waktu proses) pada Softswitch seperti diperlihatkan pada Gambar 4.6.b terdiri dari :

a. Call admission delay b. Call setup delay c. Call clearing delay d. Call occupancy

Pendefinisian komponen-komponen delay tsb dipetakan pada gambar flow diagram Lampiran F dimana dalam simulator dilakukan pencatatan waktunya pada file txt (contoh sampel pada Lampiran-C. Sebagai penjelasan metoda penentuan tiap komponen

delay berikut diambil contoh sampel seperti diperlihatkan pada Gambar 4.6 yang

merupakan sampel dari bagian Skenario I.

- Dari Gambar 4.6 (b), call admission delay merupakan selisih waktu antara message Notify (no 1) dengan message Modify (no 3). Menurut hasil pencatatan simulator (Gambar 4.6 (a)) = selisih waktu (baris 21 – baris 3) = (23:12:18:278) – (23:12:17:247) = 69 ms.

(10)

83

- Contoh lainnya adalah call setup delay = selisish waktu (baris 100 – baris 38) = (23:28:18:869) - (23:28:18:557) = 312 ms 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 100 101 102 103 104 105 [2008-7-27 23:28:17:247][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 [2111035] [2008-7-27 23:28:17:247][SKENARIO1 ] MEGACO Reply Notify 172.16.0.1 172.16.0.2 [PROCESSING]Notify Reply => 375 [CALLADMISSION]Notify Reply => 375 [2008-7-27 23:28:17:278][SKENARIO1 ] MEGACO Modify 172.16.0.1 172.16.0.2 [2008-7-27 23:28:17:278][SKENARIO1 ] MEGACO Reply Modify 172.16.0.2 172.16.0.1 [2008-7-27 23:28:18:557][SKENARIO1 ] MEGACO Notify 172.16.0.2 172.16.0.1 2250810 [2008-7-27 23:28:18:869][SKENARIO1 ] MEGACO Reply Modify 172.16.0.3 172.16.0.1 1. Notify Off hook 2. Reply 3. Modify 5. Notify Digits 6. Reply 7. Add 8. Reply 11. Modify 12. Reply Dial Tone 4. Reply

User (A) Access Gateway (A)

0222100000 172.16.0.2 Ringing Tone

jam menit detik mili detik

(a) (b)

Gambar 4.6 Analisis delay pada Softswitch simulator

(a). File txt keluaran hasil simulasi (b). Diagram call flow

Demikian seterusnya, kelima komponen delay tersebut (termasuk lama bicara dan waktu antar kedatangan) diperoleh dengan cara yang sama untuk setiap panggilan, dimana jumlah panggilan dari 36 percobaan sebanyak 677 panggilan. Tiap panggilan datanya dicatat dan disimpan dalam sebuah file txt. Selanjutnya file txt tersebut diolah dengan menggunakan pemrograman php dan basis data MySQL. Hasilnya direkap dalam Tabel dengan format seperti pada Gambar 4.7. Sampel hasil rekap dapat dilihat pada Lampiran-D

(11)

84 1 Notify 2 Reply 30 Reply 1 Notify 2 Reply 8 Reply 1 IAM 2 IAM 32 RLC 1 IAM 2 IAM 20 RLC 1 INVITE 2 INVITE 12 200 OK 1 INVITE 2 INVITE 8 ACK 2 3 1 S2 S3 PERCOBAAN KE : BUFFER : JML PANGG : PERIODA : SI BU K C a ll-c le a ring (ms) So fts w -o c c (ms) Ca ll d u ra ti o n (ms) SI BU K BEBAS SI BU K BEBAS No Wa k tu < j-m -d -m d > S KE NARI O S T AUS US E R ( B) BEBAS P ANG G IL AN KE 1 N ama p esan In te r a rr ti m e (ms)

PESAN DELAY (SOFTSWITCH) CALL (USER)

M essag e (ms) Cal l-ad mi s (ms) Cal l-set u p (ms)

(12)

IV.3.4 Analisis Perbandingan Delay Hasil Simulasi dan Model Antrian M/G/1

Dari percobaan yang dilakukan sebanyak 36 kali percobaan (dari λ=1 sampai λ=36), selanjutnya dilakukan analisis perbandingan komponen-komponen delay hasil percobaan (simulasi) dengan delay menurut hasil kalkulasi menggunakan formula model antrian M/G/1 persamaan (1) pada Bab II

) 1 ( 2 2

ρ

λ

− + =M M D

Dalam tesis ini menggunakan notasi :

) 1 ( 2 1 1 2

ρ

µ

λ

µ

−       + = sys t

Dengan menggunakan Tabel Delay hasil simulasi pada Lampiran G1, akan dihitung harga tsys berdasarkan model M/G1 dengan mengambil contoh untuk call setup delay

(tsys_csu

µ

1

) untuk λ=5, sebagai berikut :

Harga diambil harga terkecil diantara seluruh harga tsys. dengan alasan saat beban

rendah tsys.→ µ

1

. dalam hal ini untuk call setup delay dari tabel Lamiran G, didapat

µ 1 = 104 ms, maka ) 1 ( 2 1 1 tsys_csu

ρ

µ

µ

λ

µ

−             + =

( )

( )

(

5

)

104 40 5 104 − + =

(13)

86

CALL ADMISSION DELAY

0 200 400 600 800 1000 1200 1400 1600 1800 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 c a llin g ra t e (c a ll/ min) adm is si on de lay ( m s) Simulator Teoritik (M/G/1) AVARAGE : 108 ms DEVIATION : 24%

Gambar 4.8 (a) Perbandingan kurva call admission delay simulasi dengan model M/G/1

CALL SET UP DELAY

0 500 1000 1500 2000 2500 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 3132 3334 3536 3738 3940 C a llin g ra t e (c a ll/ min) C a ll s e t u p de lay ( m s) Teoritik (M/G/1) Simulator AVARAGE : 184 ms DEVIATION : 4%

(14)

CALL CLEARING DELAY 0 200 400 600 800 1000 1200 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 c a llin g ra t e (c a ll/ min) C a ll c le a rin g d e la y ( m s) Simulator Teoritik (M/G/1) AVARAGE : 176 ms DEVIATION : 89%

Gambar 4.8 (c) Perbandingan kurva call clearing delay simulasi dengan model M/G/1

OCCUPATION PER CALL

0 500 1000 1500 2000 2500 3000 3500 4000 4500 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 O c c u pat ion ( m s) Simulator Teoritik (M/G/1) AVARAGE : 467 ms DEVIATION : 22%

(15)

88

Dari gambar tersebut diantara keempat komponen delay yang sesuai dengan model M/G/1 adalah call setup delay dimana deviasi hasil simulasi terhadap hasil perhitungan dibawah 5%. Untuk komponen call admission dan call occupancy deviasi masing-masing 24% dan 22%. tetapi trend kenaikan masih prorortsional. Sedangkan untuk call

clearing, trend masih mengikuti namun deviasi cukup besar, yakni 89%. Hal ini

disebabkan karena distribusi kedatangan call clearing tidak mengikuti eksponensial negatif seperti Gambar 4.9 sebagai berikut :

DISTRIBUSI WAKTU ANTAR PEMBUBARAN (detik)

0 50 100 150 200 250 300 350 400 450 1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61

Gambar

Gambar  4.1 Skenario pengujian
Gambar  4.3 Pengecekan karakteristik sumber trafik
Gambar  4.4 Tampilan saat simulator sedang berjalan
Gambar  4.5 Contoh (sebagian) data hasil pencatatan dari sebuah panggilan Skenario I  (hasil capture oleh simulator)
+7

Referensi

Dokumen terkait

Gambar 4.16 Hasil Capture Data HTTP Bandwidth 256 kbps Dari hasil statistik diatas, diperoleh throughput, packet loss, dan delay.. Perhitungannya adalah sebagai

Pengujian kemiringan dilakukan dengan cara mengukur tingkat keberhasilan pengolahan data kecepatan sudut gyroscope menjadi kemiringan untuk mendeteksi posisi pengguna

Hal ini sesuai dengan teori yang ada, yaitu metode tunneling memungkinkan perangkat IPv6 untuk dapat saling berkomunikasi meskipun berada pada jaringan IPv4,

Analisa trafik pada sistem rugi ini, telah dilakukan secara mendalam oleh Erlang dengan kesimpulan utama adalah bahwa proses kedatangan panggilan adalah sesuai dengan

Selanjutnya heater mengalami mati-hidup dalam periode waktu berkisar 10 menit dimana temperature pada termokopel posisi 1 ini cenderung stabil pada nilai 31,5 ºC selama periode

Lalu apabila user menekan tombol menembak pada saat pilihan jenis permainan (Gambar 4.17), maka akan keluar tampilan seperti pada Gambar 4.18 dimana user memilih tingkat

Dari hasil pengamatan grafik yang diperoleh dengan bantuan aplikasi Wireshark, nilai rata-rata packet loss untuk layanan audio streaming server Shoutcast sebesar

Tahap 3a merupakan stimulus musik lembut dan tahap 3b merupakan stimulus musik keras, oleh karena itu secara teoritis komponen simpatik (LF) akan meningkat dan