ANALISIS DAN PERANCANGAN
Pada bab ini penulis memaparkan analisis permasalahan yang diangkat yang disajikan dengan diagram dan flowchart serta dipaparkan juga perancangan sistem yang akan dibangun, baik yang berupa perangkat keras ataupun perangkat lunak, lokasi pengujian, cara melakukan pengujian dan bentuk topologi.
3.1. Analisis
Pada penelitian ini akan dibangun sebuah jaringan komputer dengan model
MANET. MANET akan dibangun dengan dua buah protokol routing secara bergantian, yaitu B.A.T.M.A.N-adv dan Babel. Dua algoritma tersebut dibandingkan dan dianalisa kinerjanya dengan lima buah parameter sehingga dapat diketahui protokol routing mana yang paling baik.
3.1.1. Analisis Masalah
▸ Baca selengkapnya: sebutkan jenis protokol penunjang voip apa saja
(2)Saat ini sudah sangat banyak protokol MANET yang dapat digunakan sehingga membuat administrator menjadi sedikit bingung memilih protokol routing
mana yang paling baik dan tepat untuk digunakan dengan layanan komunikasi suara (VoIP) yang akan diimplementasikan pada MANET.
Masalah yang sudah dijelaskan di atas dapat digambarkan dengan menggunakan diagram Ishikawa (fishbone diagram) seperti pada gambar 3.1 berikut ini:
Gambar 3.1 Diagram Ishikawa Analisis Masalah
3.1.2. Analisis Kebutuhan
Analisis kebutuhan sistem meliputi analisis kebutuhan fungsional dan analisis kebutuhan non-fungsional.
3.1.2.1. Kebutuhan Fungsional
1. MANET dengan protokol routing BATMAN-adv atau Babel dapat mencari jalur terbaik untuk mengirimkan paket tanpa terjadi routing loop.
2. MANET dengan protokol routing B.A.T.M.A.N-adv atau Babel menggunakan
bandwidth yang terkecil, nilai delay, jitter, packet loss yang juga terkecil dan nilai MOS yang terbesar.
3. MANET dapat di-monitoring atau divisualisasikan untuk melihat topologi yang sedang terjadi.
4. Suara yang dihasilkan bisa didengar, baik di pemanggil dan di penerima.
3.1.2.2. Kebutuhan Non-Fungsional Sistem
Untuk mendukung kinerja MANET, sebaiknya dapat melakukan hal-hal berikut: 1. Setiap node pada MANET dapat diaktifkan dengan mudah baik bagi
administrator maupun end-user sehingga mempercepat pembangunan MANET.
2. Bisa digunakan pada semua notebook yang memiliki wireless interface.
3. Suara yang dihasilkan jernih dan berkualitas baik di pemanggil maupun di penerima.
3.1.3. Pemodelan
Pada penelitian ini digunakan Use Case Diagram dan flowchart sebagai cara untuk melakukan pemodelan dalam merancang pengujian protokol terbaik pada MANET untuk layanan VoIP. Dalam pengujian ini, terdapat 2 jeni pengguna, yaitu end-user
dan administrator, dimana masing-masing memiliki fungsi yang berbeda.
3.1.3.1. Use Case Diagram
Use case diagram akan menjelaskan apa saja yang akan dikerjakan di dalam node-node dalam MANET. Use case diagram akan merepresentasikan bagaimana interaksi antara penggunadengan node. Untuk mengidentifikasikan apa saja aktordan use case
yang terlibat pada MANET ini, perlu dijawab beberapa pertanyaan berikut ini: 1. Siapa yang menggunakan MANET?
Jawaban: End user dan administrator
2. Siapa yang diperlukan untuk melaksanakan pengujian pada MANET? Jawaban: End user dan administrator
3. Apa saja yang dapat dilakukan end-user pada MANET? Jawaban: Melakukan komunikasi dengan node lain.
4. Apa saja yang dapat dilakukan administrator pada MANET?
Jawaban: Melakukan pemantauan kualitas VoIP dan melihat topologi yang terajadi.
Pada gambar 3.2 dan 3.3 diperlihatkan diagram use case dari masing-masing pengguna yaitu end user dan administrator terhadap pengujian kualitas VoIP pada MANET.
Gambar 3.3 Use CaseAdministrator Pengujian Kualitas VoIP Protokol B.A.T.M.A.N-adv dan Babel
3.1.3.2. Flowchart Pengujian
3.2. Perangkat Keras yang Digunakan
Seperti yang sudah disebutkan sebelumnya pada subbab 1.3 bahwa penelitian ini akan menggunakan 10 buah notebook yang akan dijadikan sebagai node pada MANET yang akan dibangun. 10 buah notebook yang digunakan memiliki spesifikasi yang heterogen atau berbeda-beda satu sama lain dan semua notebook yang digunakan sudah memiliki interface wireless yang nantinya akan digunakan sebagai
transreceiver.
10 node yang akan digunakan memiliki spesifikasi yang terbilang bagus pada saat skripsi ini ditulis, yaitu rata-rata memiliki processor Intel Core i3 dan Core i5, RAM rata-rata 4GB dan harddisk rata-rata diatas atau sama dengan 500GB sehingga sudah sangat layak untuk digunakan dalam pengujian ini.
3.3. Perangkat Lunak yang Digunakan
Ada beberapa macam perangkat lunak yang digunakan termasuk diantaranya adalah sistem operasi, protokol routing, tools pendukung yang akan digunakan untuk melakukan kontrol terhadap protokol routing dan untuk mem-visualisasikan topologi, VoIP server, VoIP klien (softphone) dan VoIP monitoring. Berikut ini adalah detil dari setiap pengkat lunak yang digunakan pada penelitian ini.
3.3.1. Sistem Operasi
Pada penelitian ini, setiap node klien akan menggunakan sistem operasi Ubuntu Dekstop versi 12.04 LTS (Long Term Support) dengan versi kernel
3.5.0-23-generic. Sedangkan pada node yang dijadikan server VoIP akan dipasangkan sistem operasi Ubuntu Server versi 12.04 LTS dengan kernel yang sama dengan node klien. Penulis memilih versi LTS karena masa support-nya yang paling panjang dibanding versi yang bukan LTS, yaitu sampai 5 tahun sejak versi tersebut dirilis.
3.3.2. Protokol Routing
Sesuai dengan permasalahan yang diangkat pada penelitian ini, protokol routing yang akan digunakan pada masing-masing node ada dua, yaitu B.A.T.M.A.N dan Babel. Untuk protokol routing B.A.T.M.A.N akan digunakan B.A.T.M.A.N-adv versi 2013.4.0. Karena paket protokol routing B.A.T.M.A.N belum tersedia pada repository
Ubuntu, maka harus diunduh secara manual langsung pada situs resminya http://www.open-mesh.org/projects/open-mesh/wiki/Download. Skrip kode sumber protokol B.A.T.M.A.N tidak serta merta bisa langsung digunakan, namun harus melakukan proses kompilasi dan menggunakan beberapa dependency yang dibutuhkan.
Sedangkan untuk protokol Babel akan digunakan Babel daemon (babeld) versi 1.1.1-1. Tidak Sama seperti B.A.T.M.A.N-adv, protokol routing Babel sudah tersedia di repository Ubuntu dan bisa langsung digunakan dengan beberapa baris skrip untuk mengaktifkannya.
3.3.3. Tools Pendukung
melakukan konfirmasi apakah topologi sudah sesuai dengan yang diharapkan, hal ini terkait dengan dua skenario yang telah dibahas sebelumnya.
3.3.3.1. Batctl
Masing-masing tool pendukung berbeda antara protokol B.A.T.M.A.N dan Babel. Pada B.A.T.M.A.N, tool pendukung yang akan digunakan adalah batctl dengan versi debian-2011.4.0-2. Tool ini sudah tersedia pada repository Ubuntu, dimana fungsi yang bisa diberikan oleh tool ini adalah melakukan beberapa perintah yang berjalan pada layer 2 (Physical), seperti melakukan ping, traceroute dan tcpdump. Fungsi lain dari tool ini adalah untuk melihat semua node yang sedang aktif pada MANET yang menggunakan protokol B.A.T.M.A.N-adv. Kemudian, tool batctl ini juga bisa digunakan untuk melakukan generate topologi yang sedang berjalan atau aktif saat sekarang yang diekspor dalam formatPortable Network Graphics (PNG). Gambar 3.5 memperlihatkan sebuah contoh topologi yang dihasilkan batctl.
3.3.3.2. Babelweb
Untuk tool pendukung protokol routing Babel, penulis menggunakan tool bernama babelweb versi 0.3.0. Berbeda dari tool batctl, tool ini tidak ada di repository Ubuntu, untuk mendapatkannya penulis harus mengunduh kode sumbernya langsung dari
http://gabriel.kerneis.info/software/files/babelweb-0.3.0.tar.gz. Tool ini berfungsi untuk melakukan mapping topologi yang sedang terjadi saat sekarang secara realtime. Jika tool batctl melakukan ekspor ke format PNG untuk melihat topologi yang sedang terjadi dan mengharuskan pengguna mengetikkan sebuah command untuk mendapatkan sebuah file PNG, lain halnya dengan babelweb. Pada babelweb pengguna akan disuguhkan sebuah interface berbasis web yang memperlihatkan semua node yang menggunakan protokol Babel pada MANET beserta hubungannya dengan node lain. Semua node tersebut akan berubah setiap 4 detik jika terjadi perubahan kualitas link pada node. Gambar 3.6 memperlihatkan contoh topologi yang dihasilkan babelweb.
3.3.4. Perangkat Lunak VoIP
Jika ditinjau dari perangkat lunak, untuk membangun sebuah layanan VoIP, ada 2 jenis perangkat lunak yang dibutuhkan. Pertama perangkat lunak yang akan berfungsi sebagai pemanggil dan penerima panggilan dan yang kedua akan bertindak sebagai penghubung antara satu node dengan node lainnya. Dengan kata lain, ada perangkat lunak untuk klien dan perangkat lunak untuk server.
3.3.4.1. VoIP Klien (Softphone)
VoIP klien (dalam hal ini software/softphone) adalah sebuah software yang dipasangkan pada node klien yang digunakan untuk dapat memanggil dan menerima panggilan, baik berupa sambungan komputer ke komputer, komputer ke IP Phone, komputer ke smartphone atau lainnya. Softphone ini berupa komponen yang melakukan dial nomor telepon VoIP atau untuk menerima telepon. Softphone akan berhubungan langsung dengan user. Sudah banyak jenis softphone gratis yang bisa langsung diunduh pada situs resminya. Jenis softphone yang dapat digunakan adalah berikut:
a. Jenis softphone SIP, misalnya Linphone, SJPhone, X-Lite dan Ekiga. b. Jenis softphone IAX, misalnya Idefisk dan laxLite.
c. Jenis softphone H.323, misalnya Netmeeting dan Ekiga.
Pada penelitian ini, penulis akan menggunakan softphone Linphone dengan versi 3.5.2. Alasan penulis memilih Linphone sebagai softphone karena dari beberapa
softphone yang bisa dipasang ke mesin dengan sistem operasi Ubuntu, Linphone adalah softphone yang penggunaannya sangat mudah, tampilannya sederhana, ukuran yang kecil dan bersifat open source.
3.3.4.2. VoIP Server (Softswitch)
VoIP Server (Softswitch) berfungsi sebagai penghubung antar softphone. Softswitch
(mengarahkan tujuan data suara). Ada dua pilihan VoIP server yang bisa digunakan, yaitu open source dan non-open source. VoIP server open source dapat diperoleh dengan mengunduh langsung pada situs resminya. Beberapa contoh VoIP server yang
bersifat open source antara lain Asterisk (http://www.asterisk.org), OpenSER (http://www.openser.org), SER (http://www.iptel.org/ser/) atau Yate
(http://yate.null.ro). Sedangkan VoIP server yang non-open source dapat diperoleh di situs Axon (http://http://www.nch.com.au/pbx) atau OnDo SIP Server (http://www.brekeke.com) dengan membayar sesuai dengan harga yang ditawarkan.
Pada penelitian, ini penulis menggunakan VoIP server Asterisk dengan versi 1.8.10.1. Alasan penulis memilih Asterisk sebagai VoIP server adalah bahwa Asterisk yang sudah banyak dibuktikan handal dan stabil dalam melakukan tugasnya. Konfigurasi yang sederhana dan sifatnya yang open source juga menjadi pilihan utama penulis.
3.3.5. Perangkat Lunak Monitoring
Untuk mengetahui kualitas VoIP yang diukur berdasarkan dari 4 parameter perbandingan yang bersifat objektif (1 bersifat subjektif) yang sudah disebutkan pada subbab 1.3, dibutuhkan perangkat lunak bantuan yang khusus difungsikan untuk melakukan hal tersebut.
Untuk melakukan monitoring delay, jitter, dan packet loss digunakan sebuah perangkat lunak berbasis web, yaitu VoIP Monitor dengan versi 6.11.2013. Perangkat lunak ini bersifat open source yang bisa langsung diunduh dari situs resminya di www.voipmonitor.org. Alasan penulis menggunakan perangkat lunak ini adalah karena setelah penulis mencari informasi beberapa perangkat lunak yang bisa digunakan untuk monitoring VoIP, VoIP Monitoring adalah yang paling mendukung dengan sistem operasi Linux khususnya Ubuntu, meskipun membutuhkan beberapa
Sedangkan untuk analisa penggunaan bandwidth, penulis menggunakan perangkat lunak BitMeterOS dengan versi 0.7.5. Perangkat lunak ini bersifat gratis yang tersedia untuk sistem operasi Windows, Linux dan Mac OS yang bisa langsung diunduh dari situs resminya http://codebox.org.uk/pages/bitmeteros/downloads. Alasan penulis memilih perangkat lunak ini adalah karena dengan tampilan GUI-nya yang berbasis web, perangkat lunak ini memberikan laporan penggunaan bandwidth
yang tergolong lengkap dan bisa langsung di ekspor dalam format CSV.
3.4. Lokasi Pengujian
Lokasi pengujian adalah tempat dimana pengujian sistem akan dilakukan. Lokasi pengujian akan sangat mempengaruhi kinerja dari media wireless, karena media wireless yang digunakan pada penelitian ini merupakan media yang sangat mudah dipengaruhi oleh situasi atau keadaan sekitar. Sinyal dari sebuah wireless interface
bisa terganggu oleh beberapa hal seperti dinding, air, manusia, tumbuhan, dan lain sebagainya.
Lokasi pengujian yang penulis pilih adalah di gedung perkuliahan S1 Ilmu Komputer Universitas Sumatera Utara (USU), dimana pada gedung ini terdapat 3 lantai. Penulis memilih lokasi pengujian di gedung tersebut karena beberapa hal, yaitu penulis yang merupakan mahasiswa S1 Ilmu Komputer USU, terdiri dari banyak ruangan kelas yang akan membuat jarak jangkauan node satu dengan node lainnya bisa semakin jauh, serta banyaknya penghalang yang berupa sekat-sekat berupa dinding dan kaca yang bisa melemahkan gelombang elektromagnetik yang dihasilkan
interface wireless dari notebook, sehingga pengujian dengan menggunakan 10
notebook akan semakin mendekati seperti penggunaan di kondisi riil yang akan membuat angka hasil pengujian akan semakin realistis dan ketersediaan sumber daya listrk untuk notebook yang memiliki ketahanan baterai lemah.
lokasi pengujian dan sekaligus digambarkan peletakan seluruh notebook yang akan dijadikan sebagai node pada penelitian ini.
Dari gambar 3.7 terlihat bahwa node sudah diposisikan di titik-titik yang satu sama lainnya tidak terlalu jauh dan juga tidak terlalu dekat sehingga wireless interface
masing-masing notebook masih bisa terhubung ke notebook terdekat. Penulis memberikan penanda untuk setiap notebook, yaitu berupa nomor mulai dari 1 sampai dengan 10, dimana nomor 1 adalah node yang digunakan sebagai server VoIP.
Posisi-posisi notebook yang diletakkan berlainan tempat tersebut bertujuan untuk melakukan pengujian MANET dengan model partial connected. Sedangkan untuk melakukan pengujian full connected, seluruh notebook akan diletakkan pada satu ruangan yang sama, sehingga seluruh notebook bisa terhubung satu sama lain sesuai dengan sifat MANET full connected. Ruangan yang penulis pilih untuk melakukan pengujian full connected adalah ruangan Kelas Basic gedung S1 Ilmu Komputer USU yang memang cukup luas. Pengaturan tata letak node dapat dilihat pada gambar 3.8 di bawah ini.
3.5. Parameter Kualitas VoIP
Untuk menentukan kualitas atau Quality of Servise (QoS) dari VoIP, digunakan 5 hal yang akan dijadikan parameter perbandingan. 5 parameter tersebut adalah sebagai berikut:
a. Penggunaan bandwidth
Penggunaan bandwidth adalah banyaknya bandwidth yang digunakan untuk beberapa saat yang ditentukan dan diukur dalam kecepatan (rate) dalam satuan
bit per second (bps) atau kilobyte per second (KBps). Parameter ini adalah salah satu yang paling penting mengingat jaringan MANET adalah jaringan yang menggunakan media nirkabel yang tidak terlalu kaya throughput.
b. Delay
Delay adalah waktu yang dibutuhkan data untuk menempuh jarak dari asal ke tujuan. Delay dapat dipengaruhi oleh jarak, jenis media, atau waktu proses.
c. Jitter
Jitter atau variasi kedatangan paket, adalah hal yang diakibatkan oleh variasi-variasi dalam panjang antrian, dalam waktu pengolahan data, dan juga dalam waktu penghimpunan ulang paket-paket di akhir perjalanan paket. Jitter
lazimnya disebut variasi delay. Delay antrian pada router dan switch dapat menyebabkan jitter.
d. Packet loss
Packet Loss merupakan suatu parameter yang menggambarkan suatu kondisi yang menunjukkan jumlah total paket yang hilang, dapat terjadi karena
e. Mean Opinion Score (MOS)
Metode ini merupakan metode yang digunakan untk menentukan kualitas suara dalam jaringan IP yang berdasarkan standar International Telecommunication Union (ITU) yaitu ITU-T P.800. MOS merupakan opini dari pengguna yang bersifat subjektif, karena standar kualitas suara bagi setiap orang berbeda-beda. Nilai yang diberikan mulai dari 1 sampai 5. Nilai MOS dihasilkan dengan cara merata-ratakan hasil penilaian sejumlah pengguna terhadap kualitas VoIP yang dihasilkan. Setiap pengguna diminta untuk menilai kualitas suara menggunakan skema rating sebagai berikut: 1 = Sangat Buruk, 2 = Buruk, 3 = Cukup Baik, 4 = Baik, 5 = Sangat Baik.
3.6. Mekanisme dan Skenario Pengujian
Setelah sistem dipersiapkan, proses selanjutnya adalah melakukan pengujian. Sebelumnya sudah disebutkan bahwa pengujian akan dilakukan dengan 2 skenario umum yang berbeda, yaitu pada saat MANET mengalami kondisi full connected dan kondisi partial connected.
Pengujian yang akan penulis lakukan adalah berdasarkan parameter yang telah disebutkan sebelumnya, yaitu penggunaan bandwidth, delay, jitter, packet loss dan MOS. Namun, sebelum melakukan pengujian 5 parameter tersebut, penulis juga akan melakukan pengujian verifikasi protokol.
3.6.1. Verifikasi Topologi
3.6.2. Pengujian Penggunaan Bandwidth, Delay, Jitter dan Packet Loss
Baik pada MANET full connected maupun partial connected penulis akan melakukan prosedur yang sama:
3.6.2.1. Pengujian Penggunaan Bandwidth
Untuk pengujian penggunaan bandwidth akan dilakukan sebanyak 3 sesi. Pada setiap sesi akan diberikan beban yang berbeda-beda, dimana beban yang dimaksud adalah berupa panggilan dari satu node ke node lainnya. Lama pengamatan dari setiap sesi adalah 60 detik. Setiap detik bandwidth yang digunakan akan dicatat, dan kemudian akan dirata-ratakan. Pengujian ini dilakukan bergantian mulai dari B.A.T.M.A.N-adv dengan full connected, Babel full connected, B.A.T.M.A.N-adv partial connected, dan Babel partial connected. Berikut ini adalah tabel 3.1 yang menunjukkan metode pengujian penggunaan bandwidth.
Tabel 3.1 Metode Pengujian Penggunaan Bandwidth
3.6.2.2. Pengujian Delay, Jitter, dan Packet Loss
Untuk pengujian delay, jitter, dan packet loss akan dilakukan dengan banyak sesi yang sama dengan pengujian penggunaan bandwidth,perbedaannya adalah masing-masing sesi akan dilakukan pengujian sebanyak 5 kali yang masing-masing berdurasi 30 detik.
Pengujian 1 Sesi
Node 3 dan 9 adalah node yang menjadi objek penilaian. Node 3 akan menghubungi node 9 selama 30 detik. Nilai dari delay, jitter, dan packet loss akan muncul pada perangkat lunak VoIP Monitor setelah komunikasi diputus. Nilai yang muncul kemudian dicatat oleh administrator. Hal yang sama dilakukan sebanyak 5 kali.
Pengujian 2 Sesi
Hal yang sama pada 1 sesi akan dilakukan pada 2 sesi, namun perbedaannya adalah adanya penambahan beban oleh node 5 yang berkomunikasi dengan node 10. Selama pengujian 2 sesi ini, komunikasi node 5 dan 10 tidak akan pernah diputuskan sampai pengujian ke 5 dari 2 sesi selesai.
Pengujian 3 Sesi
Pada pengujian 3 sesi, tetap dilakukan 5 kali percobaan, namun beban yang diberikan di 2 sesi akan ditambah dengan komunikasi yang terjadi dari node 2 ke node
7, sehingga pada pengujian sesi ini terjadi 3 komunikasi sekaligus.
Tabel 3.2 Metode Pengujian Delay, Jitter, dan Packet Loss
Caller Called Caller Called
BATMAN
untuk mendapatkan nilai akhir untuk parameter MOS ini.
Dalam pengujian MOS ini, penulis akan menggunakan skenario partial connected. Alasan penulis melakukan pengujian MOS ini dengan skenario partial connected agar pengujian menyerupai kondisi rill, dimana antar pengguna yang berada di ruangan atau tempat yang berbedalah yang biasanya akan menggunakan media komunikasi untuk berinteraksi.
akan melakukan komunikasi selama 60 detik dan kemudian memberikan nilai terhadap kualitas VoIP yang mereka rasakan.
IMPLEMENTASI DAN PENGUJIAN
Pada bab 4 ini penulis memaparkan bagaimana implementasi dari sistem dan juga nilai-nilai dari setiap parameter hasil pengujian kualitas VoIP yang dilakukan pada MANET yang sudah dibangun menggunakan protokol B.A.T.M.A.N-adv dan Babel dalam 2 skenario, yaitu full connected dan partial connected.
4.1. Implementasi Sistem
Pada implementasi sistem, penulis akan melakukan instalasi seluruh perangkat lunak yang dibutuhkan pada setiap node. Untuk mendapatkan paket-paket yang dibutuhkan oleh sistem operasi Ubuntu baik perangkat lunak utama maupun dependencies-nya, penulis mengambil dari repository lokal yang telah penulis siapkan pada media
harddisk eksternal sehingga proses pengambilan paket. Berikut ini adalah hal-hal yang penulis lakukan:
a. Melakukan instalasi Ubuntu Desktop 12.04 LTS pada 9 notebook. b. Melakukan instalasi Ubuntu Server 12.04 LTS pada 1 buah notebook.
c. Melakukan instalasi protokol B.A.T.M.A.N-adv dan Babel, dependencies dan
tools untuk kebutuhan protokol routing yang sudah disebutkan sebelumnya pada seluruh node termasuk node yang akan bertindak sebagai server.
d. Melakukan instalasi dan konfigurasi Asterisk, VoIP monitoring dan bandwidth monitoring beserta dependencies-nya pada nodeserver.
e. Melakukan instalasi Linphone pada semua node klien.
f. Melakukan konfigurasi protokol B.A.T.M.A.N-adv dan Babel pada seluruh
4.1.1. Pengalamatan
Protokol B.A.T.M.A.N-adv dan Babel memiliki perbedaan dalam pengalamatan, dimana pada protokol routing Babel pengalamatan logika, baik IPv4 atau IPv6 mutlak dibutuhkan, sedangkan pada protokol B.A.T.M.A.N-adv, walaupun tidak perlu dilakukan pengalamatan logika, protokol routing tetap bisa berjalan. Hal ini dikarenakan setiap node dapat saling terhubung dengan menggunakan MAC Address
sebagai karakteristik protokol routing BATMAN-adv yang bekerja di layer 2. Namun karena layanan VoIP membutuhkan IP Address, maka setiap node akan diberikan pengalamatan logika yaitu IPv4.
Pengalamatan logika pada setiap node akan diberikan secara manual yang digabungkan dengan skrip aktifasi protokol routing. IP Address yang diberikan memiliki rentang dari 10.10.1.1/24 sampai 10.10.1.10/24, dimana oktet terakhir dari IP Address disamakan dengan penomoran pada setiap node yang sudah dibuat sebelumnya. Jadi, untuk node server penulis memberikan IP Address 10.10.1.1/24. Penulis tidak menggunakan pengalamatan otomatis menggunakan Dynamic Host Configuration Protocol (DHCP) agar lebih mudah dalam melakukan kontrol dari setiap node, dimana salah satunya adalah jika ada node yang bermasalah, misalnya belum terkoneksi akan mudah untuk melakukan troubleshoot.
4.1.2. Instalasi Protokol
#!/bin/bash
echo "Mencopy file bash konfigurasi protokol" sleep 2
cp /media/ADAM-KURNIAWAN/SUMBER/file-konfigurasi/*-manet.sh /usr/local/sbin
chmod 755 /usr/local/sbin/*-manet.sh
clear
sleep 2
4.1.3. Pendaftaran Akun VoIP
Untuk bisa memanfaatkan layanan VoIP yang diberikan oleh server, masing-masing pengguna harus didaftarkan pada server VoIP. Pada Asterisk pendaftaran akun dilakukan pada file sip.conf yang berada di direktori /etc/asterisk dan masing-masing pengguna yang sudah didaftarkan harus diberikan ekstensi yang digunakan untuk penanganan panggilan masuk atau keluar. Pemberian ekstensi ini berada di file extensions.conf yang juga berada di direktori /etc/asterisk. Berikut ini adalah 9 akun yang akan didaftarkan pada Asterisk untuk penelitian ini:
Tabel 4.1 Daftar Akun Pengguna Layanan VoIP
No type context username secret host Node
b. Context adalah penanda atau pendefenisian sebuah user yang akan dimasukkan pada filedialplanextension.conf.
c. Username adalah nomor yang akan dipanggil untuk memulai komunikasi. d. Secret adalah password kata kunci yang digunakan saat memasukkan akun ke
perangkat lunak Linphone.
e. Host adalah alamat mesin pengguna, apabila ditentukan biasanya akan berupa IP Address, digunakan dynamic karena setiap user bisa menggunakan IP
f. Nodeadalah notebook yang akan menggunakan akun dan field ini tidak ada di
file konfigurasi.
4.1.4. Aktifasi Protokol
Untuk mengaktifkan protokol B.A.T.M.A.N-adv dan Babel pada setiap node, ada beberapa perintah yang harus ketikkan di mode terminal. Beberapa perintah tersebut penulis buat dalam sebuah skrip bash dengan tujuan untuk memudahkan pengguna, baik end-user maupun administrator untuk melakukan aktifasi protokol routing
B.A.T.M.A.N-adv dan Babel. Skrip bash tersebut penulis letakkan pada direktori
/usr/local/sbin/ agar bisa diakses dari manapun dengan status root. Berikut ini adalah isi skrip bash tersebut.
#!/bin/bash
clear
#Nama interface Wi-Fi
IFACE=[interface nirkabel node, mis: wlan0]
#Nama essid harus sama pada semua node ESSID=adammanet
#Channel yang digunakan CHANNEL=1
#MAC Address salah satu node dan harus sama pada semua node CELLID=aa:bb:cc:dd:ee:ff
#IP Address dan netmask tidak boleh sama pada tiap node IPADD=[IP Address node, mis: 10.10.1.1]
echo "Menonaktifkan enkripsi wireless interface" iwconfig $IFACE enc off
echo "Mengaktifkan mode jaringan ad-hoc"
iwconfig $IFACE mode ad-hoc essid $ESSID ap $CELLID channel $CHANNEL
echo "Memuat modul B.A.T.M.A.N kedalam kernel" modprobe batman-adv
echo "Konfigurasi intercae virtual dengan IP Adress=$IPADD dan netmask=$NETMASK"
ifconfig bat0 $IPADD netmask $NETMASK up
echo "Set originator interval ke 1000 ms" batctl it 1000
echo "ESSID $ESSID pada inteface $IFACE selesai" echo "B.A.T.M.A.N siap digunakan!"
iwconfig $IFACE mode ad-hoc essid $ESSID ap $CELLID channel $CHANNEL
echo "Mengaktifkan kembali wireless interface" ifconfig $IFACE up $IPADD netmask $NETMASK
echo "Menghapus IP Address" ip addr del $IPADD/24 dev $IFACE
echo "Stop MANET selesai" fi
4.2. Analisis Data
Berikut ini adalah data yang berhasil didapatkan dari beberapa skenario dan model
yang sudah penulis lakukan.
4.2.1. Verifikasi Topologi
Gambar 4.1 Visualisasi Topologi Full Connected B.A.T.M.A.N-adv
Pada gambar 4.1 diatas diperlihatkan bahwa node dengan MAC Address
Gambar 4.2 Visualisasi Topologi Partial Connected B.A.T.M.A.N-adv
Sedangkan hasil visualisasi protokol routing Babel yang dihasilkan pada penelitian ini dapat dilihat pada gambar 4.3 dan 4.4 berikut ini.
Gambar 4.3 Visualisasi Topologi Full Connected Babel
Gambar 4.4 Visualisasi Topologi Partial Connected Babel
Hasil visualisasi pada gambar 4.3 dan 4.4 untuk routing protocol Babel di atas diambil pada node server. Jadi, untuk node yang berwarna merah muda dengan legend Me adalah node server, sedangkan node dengan legendNeighbours adalah node-node
klien yang terhubung langsung dengan node server, dan node dengan legend Others
Dari gambar 4.1, 4.2, 4.3, dan 4.4 memperlihatkan bahwa semuda node yang terpasang protokol routing B.A.T.M.A.N-adv dan Babel sudah bisa berkomunikasi dengan node lainnya dengan skenario yang diinginkan. Pada gambar 4.1 terlihat bahwa skenario full connected sudah terjadi menggunakan protokol routing
B.A.T.M.A.N-adv, dimana satu node sudah terhubung ke semua node lainnya secara langsung, begitu juga dengan gambar 4.3 yang menggunakan protokol routing Babel.
Sedangkan pada gambar 4.2 diperlihatkan bahwa skenario partial connected
juga sudah terjadi yang dihasilkan oleh protokol routing B.A.T.M.A.N-adv, dimana tidak semua node terhubung secara langsung ke semua node lainnya, namun harus melalui node tertentu yang dianggap sebagai tetangga dengan kualitas link terbaik. Hal yang sama juga terjadi pada skenario partial connected yang menggunakan protokol
routing Babel yang diperlihatkan pada gambar 4.4.
Waktu yang dibutuhkan oleh masing-masing protokol routing untuk mencapai status konvergen tidak sama, dimana Babel memakan waktu yang lebih lama dari B.A.T.M.A.N-adv. Hal ini penulis amati dari masing-masing skenario yang penulis lakukan. B.A.T.M.A.N-adv dapat mencapai status konvergensi kurang dari 1 menit untuk 10 node, sedangkan Babel lebih dari 1 menit.
Gambar 4.5 Visualisasi Topologi Full Connected Babel Berstatus Konvergen
Pada skenario partial connected protokol routing Babel, penulis mengamati bentuk topologinya selalu berubah-ubah dan sangat lama untuk mencapai status konvergen. Namun, walaupun butuh waktu yang lama, pengiriman paket tetap bisa dilakukan. Berbeda dengan protokol routing B.A.T.M.A.N-adv yang memiliki bentuk topologi yang stabil baik di skenario full connected, maupun skenario partial connected.
4.2.2. Hasil Pengujian Penggunaan Bandwidth
Berikut ini adalah data-data yang berhasil diambil dalam pengujian penggunaan
Tabel 4.2 Pengujian Bandwidth Node Server Skenario Full Connected
Sesi Download (KBps) Upload (KBps)
B.A.T.M.A.N-adv Babel B.A.T.M.A.N-adv Babel
0 0,66 0,20 0,10 0,01
1 0,64 0,19 0,08 0,01
2 0,67 0,19 0,09 0,01
Gambar 4.6 Grafik Penggunaan Bandwidth Server Skenario Full Connected
Berdasarkan hasil pengujian penggunaan bandwidth untuk layanan VoIP yang terjadi pada node server yang tertera pada tabel 4.2 dan gambar 4.6, terlihat bahwa protokol routing Babel menggunakan lebih sedikit bandwidth dari pada protokol
routing B.A.T.M.A.N-adv. Selisih bandwidth yang terjadi antara B.A.T.M.A.N-adv dan Babel dapat dilihat pada tabel 4.3 di bawah ini.
Tabel 4.3 Selisih Bandiwdth BATMAN-adv dan Babel Full Connected Sesi Download (KBps) Upload (KBps)
0 0,46 0,09
1 0,45 0,07
Data perbedaan selisih penggunaan bandwidth pada tabel 4.3 menandakan bahwa konsep dari Ad-Hoc sudah bekerja, karena untuk menghubungi node tujuan dilakukan secara langsung, dimana server hanya digunakan untuk melakukan otentikasi terhadap akun VoIP yang hanya dilakukan pada awal pemanggilan.
Sedangkan untuk pengujian penggunaan bandwidth pada skenario partial connected dapat dilihat pada tabel 4.4 dan gambar 4.7 berikut ini. Untuk data keseluruhan penggunaan bandwidth skenario partial connected dapat dilihat pada lampiran 2 untuk B.A.T.M.A.N-adv dan lampiran 4 untuk Babel.
Tabel 4.4 Pengujian BandwidthNode Server Skenario Partial Connected
Sesi Download (Kbps) Upload (Kbps)
B.A.T.M.A.N-adv Babel B.A.T.M.A.N-adv Babel
0 11,33 2,19 5,61 1,38
1 328,69 272,59 360,24 305,84
2 547,89 462,12 606,10 486,60
Gambar 4.7 Grafik Penggunaan Bandwidth Server Skenario Partial Connected
Dari tabel 4.4 dan gambar 4.7 dapat dilihat bahwa pengujian partial connected
pada 1 sesi dan 2 sesi lebih besar dari pada penggunaan bandwidth download, sedangkan jika dilihat pada 0 sesi, dimana pada sesi ini tidak terdapat panggilan, penggunaan bandwidth download lebih besar dari penggunaan bandwidth upload. Hal ini memperlihatkan bahwa konsep dari MANET yang menganut sistem multi hop
sudah berjalan, dimana node server yang sengaja diletakkan diantara node lain, membuatnya menjadi node lompatan bagi node lain, yang memungkinkan nilai upload
pada node server lebih besar dari download. Selain itu, didapati pula fakta bahwa banyaknya sesi berbanding lurus dengan penggunaan bandwidth, dimana semakin banyak sesi atau panggilan yang dilakukan, semakin besar pula bandwidth yang digunakan.
Adapun selisih bandwidth yang terjadi antara B.A.T.M.A.N-adv dan Babel dapat dilihat pada tabel 4.5 di bawah ini.
Tabel 4.5 Selisih Bandiwdth BATMAN-adv dan Babel Skenario Partial Connected Sesi Download (KBps) Upload (KBps)
0 9,14 4,22
1 56,10 54,40
2 85,77 119,51
4.2.3. Hasil Pengujian Delay
Berikut ini adalah data-data yang berhasil diambil dalam pengujian kualitas VoIP untuk parameter delay pada skenario full connected untuk protokol B.A.T.M.A.N-adv dan Babel. Untuk data hasil keseluruhan percobaan dapat dilihat pada lampiran 5.
Tabel 4.6 Pengujian Delay Skenario Full Connected Sesi B.A.T.M.A.N-adv (ms) Babel (ms)
1 54 21
2 0 35
Gambar 4.8 Grafik Perbandingan Delay Skenario Full Connected
Pada tabel 4.6 dan gambar 4.8 di atas diperlihatkan data hasil pengujian delay
pada skenario full connected. Dapat dilihat bahwa BATMAN-adv memiliki nilai delay
yang cenderung lebih kecil dibandingkan dengan Babel. Walaupun pada pengujian pada 1 sesi BATMAN-adv lebih besar sekitar 33 ms, namun untuk pengujian 2 sesi dan 3 sesi BATMAN-adv memiliki nilai yang lebih kecil dengan selisih 35 ms untuk 2 sesi komunikasi dan 75,4 ms untuk 3 sesi komunikasi.
Sedangkan untuk pengujian delay dengan skenario partial connected dapat dilihat pada tabel 4.7 dan gambar 4.9 berikut ini. Untuk data hasil keseluruhan percobaan dapat dilihat pada lampiran 6.
Tabel 4.7 Pengujian Delay Skenario Partial Connected Sesi B.A.T.M.A.N-adv (ms) Babel (ms)
1 3.079 813,6
2 5.563,6 10.400,2
Gambar 4.9 Grafik Perbandingan Delay Skenario Partial Connected
Pada tabel 4.7 dan gambar 4.9 dapat dilihat bahwa perbedaan nilai delay dari layanan VoIP yang terjadi pada partial connected jauh lebih besar dari delay pada skenario full connected. Pada gambar 4.9 terlihat juga bahwa terbedaan nilai delay
antara protokol B.A.T.M.A.N-adv dan Babel tidak stabil, dimana pada 1 sesi protokol Babel memiliki nilai yang lebih kecil dari B.A.T.M.A.N-adv dengan selisih 2.265,4 ms, sedangkan pada 2 sesi, protokol routing B.A.T.M.A.N-adv lebih kecil dengan selisih 4.836,6 ms dan pada 3 sesi nilai delay protokol Babel kembali lebih kecil dari B.A.T.M.A.N-adv dengan selisih yang tidak terlalu besar, yaitu 308 ms. Namun, yang jelas terlihat adalah nilai delay dari protokol routing B.A.T.M.A.N-adv dan Babel terus naik dari sesi 1 sampai sesi 3.
4.2.4. Hasil Pengujian Jitter
Tabel 4.8 Pengujian Jitter Skenario Full Connected Sesi B.A.T.M.A.N-adv (ms) Babel (ms)
1 3,6 2,2
2 1,0 2,8
3 2,5 4,8
Gambar 4.10 Grafik Perbandingan Jitter Skenario Full Connected
Dari data yang terpapar pada tabel 4.8 dan gambar 4.10 terlihat bahwa nilai
jitter yang terjadi pada skenario full connected memiliki pola yang sama dengan nilai
delay pada full connected, yaitu pada 1 sesi, protokol Babel memiliki nilai yang lebih kecil dari pada B.A.T.M.A.N-adv dengan selisih 1,4 ms, sedangkan untuk 2 sesi dan 3 sesi B.A.T.M.A.N-adv memiliki nilai yang lebih kecil, dimana pada 2 sesi B.A.T.M.A.N-adv memiliki jitter sekitar 1,8 ms lebih kecil dan pada 3 sesi B.A.T.M.A.N-adv lebih kecil sekitar 2,17 ms.
Tabel 4.9 Pengujian Jitter Skenario Partial Connected Sesi B.A.T.M.A.N-adv (ms) Babel (ms)
1 14,3 11,9
2 32,3 21,2
3 47,5 38,13
Gambar 4.11 Grafik Perbandingan Jitter Skenario Partial Connected
Pada pengujian jitter dengan skenario partial connected yang dapat dilihat pada tabel 4.9 dan gambar 4.11 terlihat bahwa hal yang terjadi pada pengujian delay
skenario partial connected juga terjadi pada pengujian jitter skenario partial connected, yaitu nilai jitter berbanding lurus dengan banyaknya sesi komunikasi yang terjadi, baik untuk protokol B.A.T.M.A.N-adv maupun Babel.
4.2.5. Hasil Pengujian Packet Loss
Berikut ini adalah data-data yang berhasil diambil dalam pengujian kualitas VoIP untuk parameter packet loss pada skenario full connected untuk protokol B.A.T.M.A.N-adv dan Babel. Untuk data hasil keseluruhan percobaan dapat dilihat pada lampiran 5.
Tabel 4.10 Pengujian Packet Loss Skenario Full Connected Sesi B.A.T.M.A.N-adv (%) Babel (%)
1 19,87 9,904
2 0 9,904
3 9,94 29,78
Gambar 4.12 Grafik Perbandingan Packet Loss Skenario Full Connected
Terlihat pada tabel 4.10 dan gambar 4.12 bahwa pola yang terjadi pada pengujian delay dan jitter untuk skenario full connected juga terjadi pada pengujian
packet loss skenario full connected, yaitu pada 1 sesi, Babel memiliki nilai packet loss
Sedangkan untuk pengujian packet loss pada skenario partial connected dapat dilihat pada tabel 4.11 dan gambar 4.13 berikut ini. Untuk data hasil keseluruhan percobaan dapat dilihat pada lampiran 6.
Tabel 4.11 Pengujian Packet Loss Skenario Partial Connected Sesi B.A.T.M.A.N-adv (%) Babel (%)
1 4,042 0,29
2 19,348 14,328
3 37,564 35,388
Gambar 4.13 Grafik Perbandingan Packet Loss Skenario Partial Connected
Dapat dilihat pada tabel 4.11 dan gambar 4.13 diatas bahwa pada skenario
4.2.6. Hasil Pengujian Mean Opinion Score (MOS)
Berikut ini adalah hasil pengujian dari protokol B.A.T.M.A.N-adv dan Babel dengan skenario partial connected menggunakan metode yang sudah ditentukan sebelumnya.
Tabel 4.12 Hasil Pengujian MOS Skenario Partial Connected Pengguna ke Nilai Yang Diberikan
B.A.T.M.A.N-adv Babel
1 4 4
2 4 4
3 3 4
4 3 3
5 3 4
6 4 3
7 3 3
8 4 4
9 4 4
10 3 3
Rata-rata 3,5 3,6
KESIMPULAN DAN SARAN
Pada bab 5 ini akan disimpulkan, mana protokol yang terbaik dari 2 protokol, yaitu B.A.T.M.A.N-adv dan Babel yang suda diuji. Pada bab ini juga disajikan saran-saran yang bermanfaat sebagai masukan bagi pengembangan MANET yang lebih baik terutama untuk layanan VoIP.
5.1. Kesimpulan
Dari data yang telah didapatkan dalam pengujian kualitas VoIP yang berjalan diatas MANET yang menggunakan protokol routing B.A.T.M.A.N-adv dan Babel untuk 2 skenario yang berbeda, yaitu full connected dan partial connected yang diukur dengan menggunakan 5 buah parameter sebagai tolok ukur, yaitu penggunaan bandwidth,
delay, jitter, packet loss dan MOS, didapatkan kesimpulan sebagai berikut:
1. Pengujian menggunakan 2 skenario, yaitu full connected dan partial connected
memberikan bukti bahwa konsep Ad Hoc sudah bekerja dengan baik dan memberikan nilai untuk penggunaan bandwidth, delay, jitter, dan packet loss
yang bisa dijadikan sebagai parameter perbandingan kualitas VoIP antara protokol routing B.A.T.M.A.N-adv dan Babel pada MANET.
mempengaruhi penggunaan bandwidth di sisi server dan didapati fakta bahwa pada partial connected penggunaan bandwidth upload lebih besar daripada
download. Selisih bandwidthdownload kedua protokol pada partial connected
untuk 1 sesi sekitar 9,14 KBps, 2 sesi sekitar 56,10 KBps, dan 3 sesi sekitar 85,77 KBps sedangkan perbedaan bandwidth upload yang terjadi pada 1 sesi sekitar 4,22 KBps, 2 sesi sekitar 54,40 KBps, dan 3 sesi sekitar 119,51 KBps. 3. Pengujian delay, jitter, dan packet loss untuk full connected memiliki pola
yang sama untuk tiap sesi, yaitu pada 1 sesi B.A.T.M.A.N-adv menggunakan nilai yang lebih besar dari Babel sedangkan pada 2 sesi dan 3 sesi B.A.T.M.A.N-adv lebih kecil dari Babel. Perbedaan delay yang terjadi pada
full connected pada 1 sesi sekitar 33 ms, 2 sesi sekitar 35 ms, dan 3 sesi sekitar 75,4 ms. Perbedaan jitter yang terjadi pada full connected pada 1 sesi sekitar 1,4 ms, 2 sesi sekitar 1,8 ms, dan 2,175 ms pada 3 sesi. Sedangkan perbedaan
packet loss yang terjadi pada full connected pada 1 sesi sekitar 9,97%, pada 2 sesi sekitar 9,90%, dan 19,84% pada 3 sesi.
4. Pengujian delay, jitter, dan packet loss pada partial connected tidak memiliki pola, namun hal yang juga terjadi adalah jumlah sesi mempengaruhi besarnya nilai parameter.
5. Pada pengujian delay skenario full connected, didapat bahwa selisih yang terjadi pada Babel dan B.A.T.M.A.N-adv tidak beraturan, dimana pada 1 sesi
delay Babel lebih kecil dengan selisih sekitar 2265,4 ms, pada 2 sesi delay
Babel lebih besar dengan selisih sekitar 4836,6 ms, dan pada 3 sesi nilai delay
Babel kembali lebih kecil dengan selisih sekitar 308 ms.
6. Pengujian jitter dan packet loss skenario partial connected memiliki perbedaan nilai yang stabil, dimana Babel selalu memiliki nilai yang lebih kecil dari B.A.T.M.A.N-adv baik pada 1 sesi, 2 sesi, maupun 3 sesi. Selisih jitter yang terjadi pada partial connected pada 1 sesi sekitar 2,4 ms, 2 sesi sekitar 11,1 ms, dan 3 sesi sekitar 9,375 ms. Sementara untuk pengujian packet loss
skenario partial connected selisih yang terjadi pada 1 sesi sekitar 3,75 ms, 2 sesi sekitar 5,02 ms, dan 3 sesi sekitar 2,18 ms.
8. Dari keseluruhan hasil pengamatan delay, jitter dan packet loss yang sudah dilakukan dapat disimpulkan bahwa pada MANET yang dipasang layanan VoIP, protokol B.A.T.M.A.N-adv memiliki kinerja yang lebih baik untuk ketiga parameter tersebut pada skenario full connected, sedangkan pada partial connected B.A.T.MA.N-adv hanya unggul pada parameter delay.
5.2. Saran
Adapun saran yang dapat penulis berikan berdasarkan hasil analisa dan kesimpulan adalah sebagai berikut:
1. Pada penelitian selanjutnya diharapkan menggunakan lebih banyak node. 2. Pada penelitian selanjutnya diharapkan node yang digunakan bukan
merupakan end device seperti notebook, namun menggunakan wireless router
dengan jangkauan yang lebih jauh dimana klien bisa menggunakan notebook
atau smartphone.
