ANALISIS UNJUK KERJA PROTOKOL ROUTING RAPID DI JARINGAN OPORTUNISTIK SKRIPSI

PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

ANALISIS UNJUK KERJA PROTOKOL ROUTING RAPID DI JARINGAN OPORTUNISTIK

SKRIPSI

DIAJUKAN UNTUK MEMENUHI SALAH SATU SYARAT MEMPEROLEH GELAR SARJANA KOMPUTER PROGRAM STUDI TEKNIK INFORMATIKA

OLEH: ALEXANDER DWI RYO SUBROTO WIDHIYANTO 125314114

PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI UNIVERSITAS SANATA DHARMA YOGYAKARTA 2016


PERFOMANCE ANALIYSIS OF RAPID ROUTING PROTOCOL IN OPPORTUNISTIC NETWORK

A THESIS

PRESENTED AS PARTIAL OF REQUIREMENTS TO OBTAIN SARJANA KOMPUTER DEGREE IN INFORMATICS ENGINEERING DEPARTMENT

BY: ALEXANDER DWI RYO SUBROTO WIDHIYANTO 125314114

INFORMATICS ENGINEERING STUDY PROGRAM DEPARTMENT OF INFORMATICS ENGINEERING FACULTY OF SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVEERSITY YOGYAKARTA 2016

ii


HAT,AMAN PBRSETUJUAIT SKRIPSI ANAtISffi I,INJUKKAR.TAPROTOKOL RO{/fiInTG RAPID DI JARINGAN OPORTUNISTIK

{ :t'hp *n$rftcrlhiri

#

#t s

Nrffir4n*

*

-B ff sf iT::*. R ^-*.1,. ts srfsu,CIrcua I G"roi't'r,4tr ft ;;* d" '*tc --i E AF

IlosenPcmblm

Bambang $oelistijanto, $.T., M,Sc., ph.D.

ill

ranesnLi l ?o16 t,-/4


IIALAMAN PT,NGESAHAN

SKRIPSI ANALISTS T}NJUK KERJA PROTOKOI, ftO.t/ruN#RAPIn

I'I

JARINGAI\I O PORTUN ISTIK

Dipersiapkan dan ditntis olsh: Alexander rlwi Rya subrots widhiyanto NIM. 125314tr4 Telnh dipertahanknn di depan panitin psnguji Padn hoggei 23 Agustus 2016 Dan dinyatakan memenuhi syarat SusunanPanitia Penguji

Namn Lengkap

Ketua

Tnnda Tnngnn

.'. :..

Sekrefaris

Anggotn

F'aladtasSninsdrn Teknolngp UniVef$ibsSa*eA'Fhurrou Dekan,

sir$,Si.,M.Mnt, Ph.D

lv



MOTTO

Rajin Pangkal Pandai, Nabung Pangkal Kaya.

vi



ABSTRAK Delay Tolerant Network (DTN) adalah jaringan dengan skema routing yang menantang dengan kepadatan node yang jarang dan konektivitas intermiten. Dalam tugas akhir ini dilakukan perbandingan dua protokol routing DTN, yaitu protokol routing RAPID dan Epidemic. Hal ini dilakukan untuk mengetahui unjuk kerja protokol routing RAPID dengan menggunakan The ONE simulator. Unjuk kerja jaringan yang diukur adalah delivery probability, average delay, overhead ratio, message drop, average buffer occupancy. Parameter dan skenario berdasarkan luas area tetap dengan jumlah TTL, node dan buffer yang bertambah. Hasil penelitian menunjukan protokol routing RAPID lebih unggul jika dibandingkan dengan protokol routing Epidemic ketika pada model pergerakan shortest path map based. Hal ini karena pergerakan tersebut menggunakan jalur berbasis map yang menguntungkan protokol routing RAPID untuk menjalankan algoritma contol channel untuk mengetahui gambaran jaringan global, yang kemudian pengetahuan dari contol channel digunakan oleh algoritma inference dalam mendefinisikan utilitas dalam melakukan replikasi. Sehingga meningkatkan perfoma dengan delivery probability dan average delay yang baik dibandingkan dengan Epidemic. Begitu juga dari sisi overhead ratio dan message drop yang kecil.

Kata Kunci: Delay Tolerant Networ, RAPID, Epidemic, simulator, delivery probability, average latency, overhead ratio, message drop dan average buffer occupancy.

viii


ABSTRACT Delay Tolerant Network (DTN) is a network with a challenging routing scheme with a rare density of nodes and intermittent connectivity. This final project compares two DTN routing protocols; RAPID routing protocol

and

Epidemic routing protocol. This was done to know how the performance of RAPID routing protocol using The ONE simulator. The measurement of the network perfomance are delivery probability, average delay, overhead ratio, message drop, and average a buffer occupancy. Parameter and scenario are based on fixed capacious of area with the increase of nodes, TTL and buffer. The result shows that RAPID routing protocol is more superior than the Epidemic protocol especially on the movement model of the shortest path map based. This because of that movement using map-based path which are profitable to RAPID routing protocol to execute the contol channel algorithm that describe the global network, then knowledge of the contol channel used by the inference algorithms in defining utility to do replication. So it increased the perfomance with delivery probabality and good average delay compared with the Epidemic routing protocol. Also in terms of overhead ratio and a small message drop.

Keywords: Delay Tolerant Networ, RAPID, Epidemic, simulator, delivery probability, average latency, overhead ratio, message drop dan average buffer occupancy.

ix



DAFTAR ISI

ANALISIS UNJUK KERJA PROTOKOL ROUTING RAPID DI JARINGAN OPORTUNISTIK ......................................................................................................i HALAMAN PERSETUJUAN ................................................................................ iii HALAMAN PENGESAHAN ................................................................................. iv PERNYATAAN KEASLIAN ..................................................................................v MOTTO................................................................................................................... vi LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS ............................................................................. vii ABSTRAK ............................................................................................................ viii KATA PENGANTAR ............................................................................................ ix DAFTAR ISI ........................................................................................................... xi DAFTAR TABEL ................................................................................................. xiv DAFTAR GAMBAR ............................................................................................ xvi BAB I PENDAHULUAN ....................................................................................... 1 1.1 1.2 1.3 1.4 1.5 1.6

Latar Belakang................................................................................1 Rumusan Masalah ...........................................................................2 Tujuan Penelitian ............................................................................2 Batasan Masalah .............................................................................2 Metodelogi Penelitian ......................................................................3 Sistematika Penulisan ......................................................................4

BAB II LANDASAN TEORI ................................................................................. 5 2.1 Jaringan Nirkabel (Wireless) .................................................................5 2.1.1 Mobile Ad Hoc Network (MANET)..................................................5 2.1.2. Karakteristik Ad Hoc .....................................................................6 2.1.3 Aplikasi Jaringan Ad Hoc ...............................................................6 2.2 Opportunistic Networks ........................................................................6 2.2.1 Karakteristik Jaringan Oportunistik ..................................................9 2.3 Protokol Routing...............................................................................10 2.4 Protokol Routing RAPID ...................................................................11 2.4.1 Model Sistem ..............................................................................11 2.4.2 Desain RAPID ............................................................................12

xi


2.4.3 The selection algorithm ................................................................13 2.4.4 Inference Algorithm .....................................................................13 2.4.5 Control Channel ..........................................................................15 2.5 Protokol Routing Epidemic .................................................................19 2.6 The Opportunistic Network Environment Simulator .............................21 2.6.1 Fungsi The ONE simulator ...........................................................21 BAB III PERANCANGAN SIMULASI JARINGAN ......................................... 22 3.1 Parameter Simulasi ............................................................................22 3.2 Skenario Simulasi ..............................................................................23 3.2.1 Tabel Skenario ............................................................................23 3.3 Parameter Kinerja .............................................................................23 3.3.1 Delivery Probability .....................................................................23 3.3.2 Average Delay .............................................................................24 3.3.3 Overhead Ratio ...........................................................................24 3.3.4 Message Drop .............................................................................24 3.3.5 Average Buffer Occupancy............................................................24 3.4 Model Pergerakan ..............................................................................25 3.4.1 Random Waypoint........................................................................25 3.4.2 ShortestPath Map Based Movement ..............................................25 BAB IV PENGUJIAN DAN ANALISA .............................................................. 29 4.1 ShortestPathMapBasedMovement .......................................................29 4.1.1 Penambahan TTL ........................................................................29 4.1.2 Penambahan Node .......................................................................32 4.1.4 Penambahan Buffer ......................................................................35 4.2 Random Waypoint .............................................................................38 4.2.1 Penambahan TTL ........................................................................38 4.2.2 Penambahan Node .......................................................................41 4.2.3 Penambahan Buffer ......................................................................44 4.3. Perbandingan Protokol Routing RAPID terhadap Protokol Routing Epidemic ...............................................................................................47 4.3.1 Penambahan TTL ........................................................................47 4.3.2 Penambahan Node .......................................................................53 4.3.3 Penambahan Buffer ....................................................................58 BAB V KESIMPULAN DAN SARAN ................................................................ 64 5.1 Kesimpulan ......................................................................................64

xii


5.2 Saran................................................................................................64 DAFTAR PUSTAKA ........................................................................................... 65 LAMPIRAN .......................................................................................................... 66

xiii


DAFTAR TABEL Tabel 2.1 Daftar variabel yang umum digunakan .............................................. 13 Tabel 3.1 Parameter tetap dalam skenario ......................................................... 22 Tabel 3.2 Skenario A dengan Penambahan TTL ............................................... 23 Tabel 3.3 Skenario B dengan Penambahan Node ............................................. 23 Tabel 3.4 Skenario C dengan Penambahan Buffer ............................................ 23 Tabel 4.1 ShortestPath Map Based Movement: Hasil Pengujian Penambahan Jumlah TTL ................................................................................. 29 Tabel 4.2 ShortestPath Map Based Movement: Hasil Pengujian Penambahan Jumlah Node ................................................................................ 32 Tabel 4.3 ShortestPath Map Based Movement: Hasil Pengujian Penambahan Jumlah Buffer .............................................................................. 35 Tabel 4.4 Random Waypoint: Hasil Pengujian Penambahan Jumlah TTL ................................................................................................................... 38 Tabel 4.5 Random Waypoint: Hasil Pengujian Penambahan Jumlah Node .................................................................................................................. 41 Tabel 4.6 Random Waypoint: Hasil Pengujian Penambahan Jumlah Buffer ................................................................................................................ 44 Tabel 4.7 Hasil perbandingan penambahan TTL terhadap delivery probability. ........................................................................................... 47 Tabel 4.8 Hasil perbandingan penambahan TTL terhadap average delay. .................................................................................................... 48 Tabel 4.9 Hasil perbandingan penambahan TTL terhadap overhead ratio. ................................................................................................... 50

xiv


Tabel 4.10 Hasil perbandingan penambahan TTL terhadap message drop. ..................................................................................................... 51 Tabel 4.11 Hasil perbandingan penambahan node terhadap Delivery Probability. .......................................................................................... 53 Tabel 4.12 Hasil perbandingan penambahan node terhadap average delay. .................................................................................................... 54 Tabel 4.13 Hasil perbandingan penambahan node terhadap overhead ratio. .................................................................................................. 55 Tabel 4.14 Hasil perbandingan penambahan node terhadap message drop. ..................................................................................................... 57 Tabel 4.15 Hasil perbandingan penambahan buffer terhadap Delivery Probability. .......................................................................................... 58 Tabel 4.16 Hasil perbandingan penambahan buffer terhadap average delay. .................................................................................................... 59 Tabel 4.17 Hasil perbandingan penambahan buffer terhadap overhead ratio. ................................................................................................... 61 Tabel 4.18 Hasil perbandingan penambahan buffer terhadap message drop. ..................................................................................................... 62

xv


DAFTAR GAMBAR Gambar 2. 1 Metode Store and Forward ............................................................. 8 Gambar 2.2 Letak Bundle Layer .......................................................................... 9 Gambar 2.3 Paket yang ditujukan ke buffer Z untuk node yang berbeda ............ 18 Gambar 2.4 Dependensi delay antar paket yang ditujukan ke node Z ................. 18 Gambar 2.5 Posisi paket i dalam antrian paket diperuntukkan untuk Z............... 19 Gambar 2.6 Skema cara kerja Epidemic .............................................................. 20 Gambar 2.7 Tampilan awal The ONE Simuator .................................................. 14 Gambar 3.1 Model Pergerakan Random Waypoint ............................................. 25 Gambar 3.2 Model Pergerakan ShortestPath Map Based.................................... 26 Gambar 3.3 Model pergerakan ............................................................................. 27 Gambar 3.4 Snapshoot jaringan node 126 dengan model pergerakan ShortestPathMapBased ........................................................................................ 27 Gambar 3.5 Snapshoot jaringan node 126 dengan model pergerakan Random Waypoint ................................................................................................ 28 Grafik 4.1 ShortestPathMapBased: Grafik Penambahan TTL Terhadap Unjuk Kerja Jaringan. .......................................................................................... 30 Grafik 4.2 ShortestPathMapBased: Grafik Pengaruh Penambahan TTL (60 Menit) Terhadap Average Buffer Occupancy ........................................ 31 Grafik 4.3 ShortestPathMapBased: Grafik Pengaruh Penambahan TTL (480 Menit) Terhadap Average Buffer Occupancy ...................................... 31 Grafik 4.4 ShortestPathMapBased: Grafik Penambahan Node Terhadap Unjuk Kerja Jaringan ........................................................................... 33 Grafik 4.5 ShortestPathMapBased: Grafik Pengaruh Penambahan Node (50) Terhadap Average Buffer Occupancy. ............................................... 34

xvi


Grafik 4.6 ShortestPathMapBased: Grafik Pengaruh Penambahan Node (150) Terhadap Average Buffer Occupancy. ............................................. 34 Grafik 4.7 Shortest Path Map Based: Grafik Pengaruh Penambahan Buffer Terhadap Average Buffer Occupancy ....................................................... 36 Grafik 4.8 ShortestPathMapBased: Grafik Pengaruh Penambahan Buffer (10 MB) Terhadap Average Buffer Occupancy. ...................................... 37 Grafik 4.9 ShortestPathMapBased: Grafik Pengaruh Penambahan Buffer ( 70MB) Terhadap Average Buffer Occupancy. ...................................... 37 Grafik 4.10 Random Waypoint: Grafik Penambahan buffer Terhadap Unjuk Kerja Jaringan. .......................................................................... 39 Grafik 4.11 Random Waypoint: Grafik Pengaruh Penambahan TTL Terhadap Average Buffer Occupancy ................................................................. 40 Grafik 4.12 Random Waypoint: Grafik Pengaruh Penambahan TTL Terhadap Average Buffer Occupancy. ................................................................. 40 Grafik 4.13 Random Waypoint: Grafik penambahan Node Terhadap Unjuk Kerja Jaringan ........................................................................................... 42 Grafik 4.14 Random Waypoint: Grafik Pengaruh Penambahan Node Terhadap Average Buffer Occupancy. ................................................................. 43 Grafik 4.15 Random Waypoint: Grafik Pengaruh Penambahan Node Terhadap Average Buffer Occupancy. ................................................................. 43 Grafik 4.16 Random Waypoint: Grafik Penambahan Buffer Terhadap Unjuk Kerja Jaringan ........................................................................................... 45 Grafik 4.17 Random Waypoint: Grafik Pengaruh Penambahan Buffer Terhadap Average Buffer Occupancy .................................................................. 46 Grafik 4.18 Random Waypoint: Grafik Pengaruh Penambahan Buffer

xvii


Terhadap Average Buffer Occupancy ................................................................. 46 Gambar 4.19 Grafik perbandingan pada penambahan TTL terhadap Delivery Probability. ............................................................................................ 47 Gambar 4.20 Grafik perbandingan pada penambahan TTL terhadap average delay. ...................................................................................................... 49 Gambar 4.21 Grafik perbandingan pada penambahan TTL terhadap overhead ratio. ..................................................................................................... 50 Gambar 4.22 Grafik perbandingan pada penambahan TTL terhadap message drop. ....................................................................................................... 52 Gambar 4.23 Grafik perbandingan pada penambahan node terhadap delivery probability. ............................................................................................. 53 Gambar 4.24 Grafik perbandingan pada penambahan node terhadap average delay. ...................................................................................................... 54 Gambar 4.25 Grafik perbandingan pada penambahan node terhadap overhead ratio. ..................................................................................................... 56 Gambar 4.26 Grafik perbandingan pada penambahan node terhadap message drop. ....................................................................................................... 57 Gambar 4.27 Grafik perbandingan pada penambahan buffer terhadap delivery probability. ............................................................................................. 58 Gambar 4.28 Grafik perbandingan pada penambahan buffer terhadap average delay. .................................................................................................................... 60 Gambar 4.29 Grafik perbandingan pada penambahan buffer terhadap overhead ratio. ..................................................................................................... 61 Gambar 4.30 Grafik perbandingan pada penambahan buffer terhadap message drop. ....................................................................................................... 62

xviii


BAB I PENDAHULUAN 1.1 Latar Belakang Jaringan komputer saat ini berkembang sangat pesat dari jaringan kabel ke jaringan nirkabel. Jaringan nirkabel merupakan salah satu teknologi jaringan yang menggunakan udara sebagai perantara untuk berkomunikasi. Jaringan nirkabel ini dibagi menjadi dua yaitu jaringan nirkabel berbasis infrastruktur dan jaringan nirkabel tanpa memerlukan infrastruktur yang disebut Mobile Ad Hoc Network (MANET). Dalam MANET ini setiap node dalam jaringan dapat bertindak sebagai penyedia router (relay) untuk penghubung dengan node yang lain, sehingga semua node pada jaringan bertanggungjawab dalam proses komunikasi dan transportasi data. Beberapa skema jaringan routing MANET telah dikembangkan untuk jaringan dengan skema routing yang menantang dengan kepadatan node yang jarang dan konektivitas intermiten. Jaringan tersebut disebut sebagai Delay Tolerant Network (DTN). Contoh jaringan ini mencakup jaringan di daerah yang belum dikembangkan adanya koneksi Internet, jaringan sensor pemantauan alam dan bidang militer. DTN menerapkan metode store-carry-forward, yang berarti sebuah paket data saat melewati node-node perantara (ex. router) akan disimpan terlebih dahulu sebelum diteruskan. Hal ini untuk mengantisipasi seandainya node berikutnya tidak dapat dijangkau (mati) atau ada kendala yang lain. Selama proses pengiriman informasi node akan melakukan proses store-carryforward sampai pada tujuan pengiriman informasi. Dalam mekanisme pengiriman informasi DTN memiliki beberapa protokol routing. Diantaranya adalah protokol routing Resource Allocation Protocol for Intentional DTN (RAPID) dan protokol routing Epidemic. Protokol routing RAPID merupakan protokol yang menangani masalah alokasi sumber daya berbasis utilitas. Sebuah paket yang diarahkan dengan melakukan replikasi sampai salinan mencapai tujuan. Sedangkan pada protokol routing Epidemic setiap kali node pengirim bertemu dengan node 1


lainya maka pertama kali yang dilakukan adalah bertukar summary vector, untuk mengidentifikasi pesan apakah node yang baru ditemui sudah mempunyai pesan yang dibawa node pengirim atau tidak, jika tidak maka node pengirim akan meneruskan salinan pesan yang dibawa. Paket akan terus disalin dari satu node ke node lain sampai TTL pesannya berakhir. Pesan dan unique identifier akan disimpan dalam buffer node. Dengan demikian, pesan tersebut menyebar ke seluruh jaringan hingga sampai ke node tujuan. Kedua protokol routing tersebut memiliki mekanisme yang berbeda dalam proses routing. Sehingga dalam penelitian ini, penulis akan menganalisis unjuk kerja

protokol routing DTN yakni protokol routing

RAPID dengan protokol routing Epidemic sebagai pembandingnya di jaringan oportunistik. Pengujian dilakukan dengan memvariasikan penambahan TTL pesan, penambahan node dan penambahan buffer. 1.2 Rumusan Masalah Berdasarkan latar belakang masalah, maka rumusan masalah yang didapat adalah analisis unjuk kerja protocol routing RAPID terhadap protokol routing Epidemic di jaringan oportunistik. 1.3 Tujuan Penelitian Adapun tujuan dari tugas akhir ini adalah mengetahui kelebihan dan kekurangan protokol routing RAPID terhadap protokol routing Epidemic di jaringan oportunistik yang diukur dengan metrik unjuk kerja, yaitu delivery probability, average latency, overhead ratio, message drop dan average buffer occupancy. 1.4 Batasan Masalah Dalam pelaksanaan tugas akhir ini, masalah dibatasi sebagai berikut: 1. Menggunakan protokol routing RAPID dan protokol routing Epidemic. 2. Parameter yang digunakan adalah delivery probability, average latency, overhead ratio, message drop dan average buffer occupancy. 3. Simulator yang digunakan adalah The Opportunistic Network Environment simulator (The ONE Simulator).

2


1.5 Metodelogi Penelitian Adapun metologi penelitian dan langkah-langkah yang digunakan dalam pelaksanaan tugas akhir ini adalah sebagai berikut: 1. Studi Literatur a. Teori MANET b. Teori Opportunistic Network c. Teori protokol routing RAPID dan protokol routing Epidemic d. Teori tentang delivery probability, average latency, overhead ratio, message drop dan average buffer occupancy. e. Teori ONE simulator f. Tahap-tahap dalam membangun simulasi. 2. Perancaangan Dalam tahap ini penulis merancang skenario sebagai berikut: a. Penambahan dalam jumlah TTL pesan. b. Penambahan dalam jumlah buffer. c. Penambahan dalam jumlah node. 3. Pembangunan Simulasi dan Pengumpulan Data. Simulasi jaringan oportunistik pada tugas akhir ini menggunakan The ONE Simulator. 4. Analisis Data. Dalam tahap ini penulis menganalisis hasil pengukuran yang diperoleh pada proses simulasi. Analisis dihasilkan dengan melakukan pengamatan dari beberapa kali pengukuran yang menggunakan parameter simulasi yang berbeda. 5. Penarikan Kesimpulan Penarikan kesimpulan didasarkan pada beberapa perfomance metric yang diperoleh pada proses analisis data.

3


1.6 Sistematika Penulisan Dalam penyusunan tugas akhir ini, penulis membagi sistematika penyusunan sebagai berikut: BAB I PENDAHULUAN Bab ini berisi latar belakang, rumusan masalah, tujuan penelitian, batasan masalah, metodologi penelitian, dan sistematika penulisan.

BAB II LANDASAN TEORI Bagian ini berisi mengenai dasar teori yang digunakan penulis dalam menyusun tugas akhir ini.

BAB III PERANCANGAN SIMULASI JARINGAN Bab ini berisi mengenai perancangan kerja dalam melakukan analis serta parameter-parameter yang digunakan.

BAB IV PENGUJIAN DAN ANALISA Bab ini berisi mengenai tahap-tahap pengujian simulasi dan analisis data simulasi jaringan.

BAB V KESIMPULAN DAN SARAN Bab ini berisi tentang beberapa kesimpulan yang didapat dan saran-saran atas pengujian dan analisis simulasi data yang dilakukan sebelumnya.

4


BAB II LANDASAN TEORI 2.1 Jaringan Nirkabel (Wireless) Jaringan nirkabel merupakan salah satu teknologi jaringan yang menggunakan udara sebagai perantara untuk berkomunikasi. Jaringan nirkabel menggunakan standart Institute of Electrical and Electronics Engineers 802.11 atau IEEE 802.11. IEEE merupakan organisasi yang mengatur standar mengenai teknologi nirkabel. Frekuensi kerja jaringan nirkabel adalah 2,4 GHz, 3,7 GHz dan 5GHz. Topologi pada jarigan nirkabel ini dibagi menjadi dua yaknik topologi nirkabel dengan berbasis infrastruktur (access point) dan topologi nirkabel tanpa

memanfaatkan

infrastruktur.[1]

Jaringan

wireless

infrastruktur

kebanyakan digunakan untuk memperluas jaringan LAN atau untuk berbagai jaringan agar dapat terkoneksi ke Internet. Untuk membangun jaringan infrastruktur diperlukan sebuah perangkat yaitu wireless access point untuk menghubungkan client yang terhubung dan manajemen jaringan nirkabel. Jaringan nirkabel dengan mode Ad-hoc tidak membutuhkan perangkat tambahan seperti access point, yang dibutuhkan hanyalah wireless adapter pada setiap komputer yang ingin terhubung. Ad-hoc pada dasarnya adalah jaringan yang diperuntukkan untuk keperluan sementara. 2.1.1 Mobile Ad Hoc Network (MANET) Mobile Ad hoc Network (MANET) merupakan sebuah jaringan nirkabel yang terdiri dari beberapa node yang tidak memerlukan infrastruktur. Setiap node pada jaringan ini bersifat mobile. Setiap node dalam jaringan dapat berperan sebagai host dan router yang berfungsi sebagai penghubung antara node yang satu dengan node yang lainnya. MANET melakukan kominukasi secara peer to peer menggunakan routing dengan cara multihop. Informasi yang akan dikirimkan disimpan dahulu dan diteruskan ke node tujuan melalui node perantara. Ketika topologi mengalami perubahan karena node bergerak, maka perubahan topologi harus diketahui oleh setiap node. [2]

5


2.1.2. Karakteristik Ad Hoc Beberapa karakteristik dari jaringan ini adalah: a.

Otonomi dan tanpa infrastruktur, MANET tidak bergantung kepada infrastruktur atau bersifat terpusat. Setiap node berkomunikasi secara distribusi peer-to-peer.

b.

Topologi jaringan bersifat dinamis, artinya setiap node dapat bergerak bebas, (random mobility) dan tidak dapat diprediksi.

c.

Scalability, artinya MANET bersifat tidak tetap atau jumlah node berbeda di tiap daerah.

d.

Sumberdaya yang terbatas, baterai yang dibawa oleh setiap mobile node mempunyai daya terbatas, kemampuan untuk memproses terbatas, yang pada akhirnya akan membatasi layanan dan aplikasi yang didukung oleh setiap node.

2.1.3 Aplikasi Jaringan Ad Hoc Karakteristik jaringan ad hoc yang dinamis membuat jaringan ini dapat diaplikasikan di berbagai tempat. Selain itu tidak diperlukan adanya infratstruktur, membuat jaringan ini daat dibentuk dalam situasi apapun. Beberapa contoh aplikassi jaringan ad hoc adalah untuk operasi militer, keperluan komersial dan untuk membuat personal area network.[3]. Pada operasi militer, jaringan ad hoc digunakan untuk mempermudah akses informasi antar personil militer. Jaringan ini juga dapat digunakan pada situasi yang sifatnya darurat misalnya banjir atau gempa bumi, atau dapat juga digunkan untuk sebuah acara seperti konser musik. Untuk jarak yang pendek atau kurang dari 10 meter komunikasi secara ad hoc dapat terjalin pada berbagai macam perangkat seperti telepon seluler dan laptop. 2.2 Opportunistic Networks Delay Tolerant Network, artinya jaringan komputer yang toleran atau tidak mempermasalahkan waktu tunda. Pada jaringan dengan DTN, meskipun waktu tunda dalam jaringan cukup tinggi, jaringan DTN tetap dapat bekerja [4]. Konsep DTN pertama kali diperkenalkan oleh Kevin Fall dalam makalah ilmiahnya yang berjudul “A Delay-Tolerant Network Architecture for Challenged Internets” [4]. Dalam makalah tersebut, Kevin menyatakan bahwa

6


DTN merupakan arsitektur yang cocok pada jaringan yang “menantang” (challenged). Maksud dari “menantang” disini adalah jaringan yang penuh dengan masalah, seperti delay yang lama, koneksi yang sering terputus dan tingkat error yang tinggi. Contoh jaringan yang menantang antara lain: -

Jaringan luar angkasa (Interplanetary Network), konsep jaringan yang memungkinkan akses Internet di luar angkasa.

-

Military AdHoc Network. Pasukan militer sering kali ditempatkan di daerah-daerah terpencil yang tidak berpenghuni dan tidak ada koneksi memadai. Misalkan di perbatasan Indonesia dengan Papua Nugini, atau di pulau-pulau terluar Indonesia. Konsep DTN dapat digunakan untuk membangun jaringan komputer dalam keadaan seperti ini.

-

Jaringan Sensor/Aktuator, contohnya pada penerapan Wireless Sensor Network (WSN). Dari beberapa contoh jaringan yang disebutkan di atas, alasan utama

terciptanya

konsep

DTN

adalah

untuk

komunikasi

luar

angkasa

(Interplanetary Network). Oleh karena itu, pada perkembangan DTN saat ini, NASA (lembaga peneliti luar angkasa AS) selalu ikut berperan besar. Pada komunikasi luar angkasa, jelas tidak akan dapat dilakukan dengan protokol TCP/IP. Komunikasi luar angkasa memiliki karakter delay pengiriman yang lama (akibat jarak yang jauh) dan koneksi end-to-end yang tidak selalu ada (bahkan tidak pernah). Misalkan pada pengiriman data dari stasiun bumi ke sebuah kendaraan luar angkasa (Hover) di Mars. Pengiriman data ini memerlukan beberapa satelit dan stasiun luar angkasa sebagai router. Koneksi end-to-end hampir mustahil dibangun sehingga pengiriman data dengan TCP/IP tidak mungkin dilakukan. Yang memungkinkan adalah mengirim data secara bertahap dari satu node ke node berikutnya, kemudian disimpan. Selanjutnya dapat diteruskan ke node berikutnya setelah ada koneksi.

7


Bagaimana DTN dapat bekerja pada jaringan yang penuh dengan hambatan seperti koneksi sering terputus dan tingkat delay yang tinggi? Jawabannya adalah pada penggunaan metode store and forward. Metode store and forward berarti sebuah paket data saat melewati node-node perantara (ex. router) akan disimpan terlebih dahulu sebelum diteruskan. Hal ini untuk mengantisipasi seandainya node berikutnya tidak dapat dijangkau (mati) atau ada kendala yang lain. Ilustrasi konsep store and forward ditunjukkan dalam Gambar 2.2

Gambar 2. 1 Metode Store and Forward Pada Gambar 2.2 menunjukan proses pengiriman data dari node A dengan tujuan akhir node D. Saat melewati node B dan node C sebagai perantara, data disimpan terlebih dahulu sebelum dikirimkan apabila koneksi dengan node berikutnya telah siap. Metode store and forward memiliki konsekuensi yaitu setiap node harus memiliki media penyimpanan (storage). Storage digunakan untuk menyimpan data apabila koneksi dengan node berikutnya belum tersedia. Dalam DTN, proses store and forward dilakukan pada sebuah layer tambahan yang disebut bundle layer, dan data yang tersimpan sementara disebut dengan bundle. Bundle layer adalah sebuah layer tambahan untuk memodifikasi paket data dengan fasilitas-fasilitas yang disediakan DTN. Bundle layer terletak langsung di bawah layer aplikasi. Dalam bundle layer, data dari layer aplikasi akan dipecah-pecah menjadi bundle. Bundle inilah yang akan dikirim ke transport layer untuk diproses lebih lanjut. Letak bundle layer ditunjukkan dalam Gambar 2.3.

8


Gambar 2.2 Letak Bundle Layer Gambar 2.3 menunjukan penerapan DTN pada jaringan. Perlu diketahui bahwa DTN tidak hanya beroperasi di jaringan TCP/IP. Protokol-protokol pada layer di bawah bundle layer bisa protokol apa saja, tergantung kondisi jaringan. Oleh karena itu, salah satu fungsi DTN adalah dapat menjadi perantara jaringan yang berbeda protokol. 2.2.1 Karakteristik Jaringan Oportunistik Beberapa karakteristik dari jaringan ini adalah: a. Pemutusan Tidak ada koneksi antara jumlah node. b. Intermittent Connectivity Jika tidak ada jalur end-to-end antara source dan destination maka komunikasi dengan menggunakan protokol TCP/IP tidak bisa dilakukan. c. Waktu Tunda Tinggi Tunda (delay) didefinisikan sebagai end-to-end delay antara node. Delay tinggi terjadi karena jumlah pemutusan antara node. d. Low Data Rate Data Rate adalah tingkat yang menggambarkan jumlah pesan yang disampaikan dibawah jangka waktu tertentu. Low Data Rate terjadi karena penundaan yang lama antara transmisi.

9


e. High Error Rate Jika kesalahan bit terjadi pada link, maka data membutuhkan koreksi kesalahan untuk kemudian dikirim ulang keseluruhan paket yang dapat menyebabkan lalulintas jaringan semakin tinggi. Untuk mentransmisikan semua paket, dibutuhkan lalulintas jaringan yang lebih. f. Sumber Daya yang Terbatas Delay Tolerant Network (DTN) memiliki kendala pada sumber daya. Hal ini membutuhkan desain protokol untuk mengefesienkan sumber daya. Dengan kata lain, penggunaan node harus mengkonsumsi sumber daya perangkat keras secara terbatas seperti CPU, memori (RAM) dan baterai. Misalnya, di WSNs, node dapat ditempatkan di lingkungan terbuka selama bertahun-tahun sebelum data dikumpulkan, dan karenanya membutuhkan node untuk mengelola penggunaan energi tiap node. Selain itu, protokol routing yang baik akan mempengaruhi sumber dari beberapa node. Sebagai contoh, node dapat memilih untuk mengalihkan beberapa bundel mereka untuk disimpan ke node lain untuk membebaskan memori atau untuk mengurangi biaya transmisi. g. Long or Variable Delay Setiap node memiliki buffer sendiri untuk pesan store, hal ini dapat menyebabkan pemutusan panjang antrian delay. Waktu delay yang panjang merupakan efek dari intermittent connectivity dan dapat menyebabkan waktu delay yang cukup panjang antara source dan destinantion. 2.3 Protokol Routing Protokol routing merupakan aturan dalam routing protokol dalam proses pengiriman dan pertukaran data (berupa blok-blok data) dari sebuah node ke node yang lain dalam jaringan. Delay Tolerant Network adalah sekumpulan node yang bergerak (mobile node) yang didalamnya terdapat kemampuan untuk berkomunikasi secara wireless dan juga dapat mengakses jaringan. Perangkat tersebut dapat berkomunikasi dengan node yang lain selama masih berada dalam jangkauan perangkat radio. Node yang bersifat

10


sebagai penghubung digunakan untuk meneruskan paket dari source ke destination. Sebuah jaringan wireless akan mengorganisir dirinya sendiri dan beradaptasi dengan sekitarnya. Ini berarti jaringan tersebut dapat terbentuk tanpa sistem infrastruktur. Perangkat pada jaringan ini harus mampu mendeteksi keberadaan perangkat lain untuk melakukan komunikasi dan berbagi informasi. Routing merupakan perpindahan informasi diseluruh jaringan dari node source ke node destination dengan minimal satu node berperan sebagai perantara. Routing bekerja pada layer 3 (lapisan jaringan). Routing dibagi menjadi 2 bagian. Yang pertama adalah protokol routing yang berfungsi untuk menentukan bagaimana node berkomunikasi dan membagikan informasi dengan node lainnya yang memungkinkan node source untuk memilih rute yang optimal ke node destination dalam sebuah jaringan komputer (fungsi utama dari routing pada DTN adalah mencari jalur dari node source ke node destination). Protokol routing menyebarkan informasi pertama kali ke node tetangganya, kemudian ke seluruh jaringan. Setelah mendapatkan routing informasi maka setiap node menyusun routing algoritma. Sedangkan algoritma routing berfungsi untuk menghitung secara matematis jalur yang optimal berdasarkan informasi routing yang dimiliki oleh semua node. 2.4 Protokol Routing RAPID 2.4.1 Model sistem Model DTN sebagai satu set mobile node. Dua node mentransfer paket data satu sama lain ketika dalam satu radio. Selama transfer, pengirim membuat replikasi paket sementara dengan tetap mempertahankan salinan. Sebuah node dapat memberikan paket ke node tujuan secara langsung atau melalui node perantara, tetapi paket tidak terfragmentasi. Terdapat batasan penyimpanan dan transfer bandwidth yang tersedia untuk node. Node tujuan diasumsikan memiliki kapasitas yang cukup untuk menyimpan paket yang akan disampaikan. Pertemuan node diasumsikan berumur pendek (shortlived).

11


2.4.2 Desain RAPID RAPID merupakan sebuah protokol routing DTN yang dimaksudkan dapat mengoptimalkan routing metrik tertentu seperti minimizing average delay atau minimizing missed deadlines. Sehingga menjadi pembaharuan untuk DTN routing yang menangani masalah alokasi sumber daya dengan menerjemahkan metrik routing menjadi per-paket utilitas yang menentukan bagaimana paket harus direplikasi didalam sistem. Sebuah paket yang diarahkan dengan melakukan replikasi sampai salinan mencapai tujuan. Pertanyaan kuncinya adalah diberikan bandwidth yang terbatas, bagaimana seharusnya paket direplikasi dalam jaringan sehingga dapat mengoptimalkan routing metric tertentu. Pada kesempatan mentransfer, ia bereplikasi terhadap paket yang secara lokal menghasilkan peningkatan di utilitas tertinggi. Sebagai contoh routing metrik seperti meminimalkan average delay paket. Kesesuaian utilitas Ui dari paket i adalah negatif dari rata-rata delay paket i, yaitu waktu i telah dihabiskan, di dalam sistem dan tambahan delay yang diharapkan sebelum i sampai tujuan.

Ui menunjukan peningkatan Ui

dengan melakukan replikasi i dan si menurunkan ukuran dari i. Kemudian RAPID mereplikasi paket dengan nilai terbesar dari

terhadap paket yang

ada di dalam buffer, dengan kata lain paket ber-marjinal terbesar. [5] Secara umum, Ui didefinisikan sebagai kontribusi yang diharapkan dari i untuk perutean metric yang diberikan. Sebagai contoh, metrik untuk meminimalkan average delay diukur dengan menjumlahkan paket delay. Dengan demikian, pengertian dari utilitas paket adalah delay yang diharapkan itu sendiri. Jadi, RAPID adalah lokal heuristik berdasarkan optimasi utilitas marjinal, yaitu, peningkatan yang diharapkan dalam utilitas per unit sumber daya yang digunakan secara lokal. [6] Utilitas marjinal heuristik memiliki beberapa sifat yang diinginkan. Utilitas marjinal mereplikasi paket ke node rendah ketika (i) paket memiliki banyak replika, atau (ii) node adalah pilihan yang buruk sehubungan dengan metrik routing yang, atau (iii)sumber daya yang digunakan tidak memberikan manfaat. Sebagai contoh, jika node saling bertemu secara merata, maka paket i dengan 6 replika memiliki utilitas marjinal lebih rendah jika dibandingkan

12


dengan paket j yang hanya 2 replika. Di sisi lain, jika node tidak dapat memenuhi tujuan j dalam waktu yang lama, maka i dapat mengambil prioritas di atas j. RAPID memiliki tiga komponen inti: algoritma selection, algoritma inference, dan control channel. Algoritma selection digunakan untuk menentukan paket-paket yang akan mereplikasi pada kesempatan transfer yang diberikan utilitas mereka. Algoritma inference digunakan untuk memperkirakan utilitas dari paket tertentu routing metric. control channel menyebarkan metadata yang diperlukan oleh algoritma inference.[6] 2.4.3 The selection algorithm Protokol RAPID mengeksekusi ketika dua node berada dalam jangkauan radio dan saling menemukan. Protokol merupakan simetrik, tanpa hilangnya generality, dan mendeskripsikan bagaimana node X menentukan paket yang akan ditranfer pada node Y.(merujuk pada kotak algoritma RAPID) RAPID juga mengadaptasi batasan storage untuk yang sedang transit data. Jika node kekurangan semua storage yang tersedia, paket dengan utilitas yang terendah akan dihapus terlebih dahulu sebagai kontribusi pada perfoma. Namun source tidak akan menghapus paketnya sebelum ia menerima ack untuk paket.[6] 2.4.4 Inference algorithm Selanjutnya, menjelaskan mengenai bagaimana protocol routing RAPID dapat mendukung metrik tertentu menggunakan algoritma untuk menyimpulkan utilitas. Tabel 2 mendefinisikan variabel yang relevan. Tabel 2.1 Daftar variabel yang umum digunakan D (i)

Rata-rata delay dari paket i = T(i) + A(i)

T (i)

Waktu sejak pesan i dibuat

a (i)

Variabel acak menentukan sisa waktu untuk memberikan i

A (i)

Rata-rata sisa waktu = E[a(i)]

Mxz

Variabel acak yang menentukan waktu pertemuan antara node X dan Z

13


2.4.4.1 Metrik 1: Meminimalkan Average Delay Untuk meminimalkan average delay paket dalam jaringan, definisi dari utilitas paket dirumuskan sebagai berikut: Ui = -D(i)

(1)

Selama rata-rata delay paket merupakan kontribusi dari perfomance matrik. Dengan demikian, protokol berupaya untuk mereplikasi paket yang replikasinya mengurangi delay dengan semua paket yang ada di dalam buffer.

2.4.4.2 Metrik 2: Meminimalkan Missed Deadlines (batas waktu yang hilang) Untuk meminimalkan jumlah paket yang kehilangan deadline, utilitas didefinisikan sebagai probabilitas paket yang akan disampaikan dalam: (2) Dimana L(i) merupakan masa hidup paket. Paket yang kehilangan deadline nya tidak dapat meningkatkan performa dan diberikan nilai 0. Marginal utiliti adalah peningkatan probabilitas dari paket yang akan disampaikan adalah dalam jangka waktu, jadi protokol akan mereplikasi paket yang menghasilkan peningkatan tertinggi dari semua paket yang ada di dalam buffer.

2.4.4.3 Metrik 3: Minimalkan atau Menurunkan Maximum Delay Untuk memperkecil maksimum delay dari paket dalam jaringan, didefinisikan Ui sebagai berikut; (3) Dimana S menunjukan sekumpulan paket dalam buffer X. Dengan demikian Ui negatif dari rata-rata delay jika i merupakan paket dengan delay maksimal dari semua paket yang dipegang atau dimiliki dari Y. Jadi replikasi berguna hanya untuk paket yang memiliki dengan delay maksimum. Untuk menghemat algoritma routing, RAPID mengkomputasi utilitas paket yang delay-nya maksimum, yaitu selama paket dengan maksimum delay dipertimbangkan untuk direplikasi, utilitas dari sisa paket dihitung ulang dengan rumus 3.

14


2.4.5 Control Channel RAPID menggunakan control channel untuk bertukar acknowledgments atas paket yang disampaikan serta metadata tentang setiap paket dari pertukaran sebelumnya. Untuk setiap paket yang dihadapi i, RAPID menyimpan daftar node yang membawa replika dari i, dan untuk setiap replika diperkirakan waktu untuk pengiriman langsung. Metadata untuk paket yang tersampaikan akan dihapus ketika ack diterima. Untuk efisiensi, node RAPID merawat waktu pertukaran metadata terakhir dengan node yang sedang berpasangan. Node hanya mengirim informasi tentang paket yang informasinya berubah sejak pertukaran terakhir, yang mengurangi ukuran dari pertukaran. Sebuah node RAPID mengirimkan informasi berikut saat terhubung dengan node lain:  Rata-rata ukuran dari transfer  Rata-rata waktu bertemu dengan beberapa node  Daftar paket yang terkirim sejak pertukarn terakhir  Untuk semua paket dengan delivery delay yang sudah di update berdasar pada penggunaan buffer.  Informasi tentang paket lain jika diubah sejak pertukaran terakhir dengan node lain. Ketika menggunakan control channel, node hanya memiliki pandangan sistem yang tak sempurna. Informasi yang diperbanyak mungkin sudah usang karena disebabkan jumlah replika, perubahan dalam delivery delay atau jika paket yang dikirimkan tetapi tidak dinyatakan untuk disebarkan. Walaupun informasi yang diterima delay dan tidak akurat, mekasnisme pada RAPID control channel dikombinasikan dengan algoritma replikasi berbasis utilitas, secara signifikan meningkatkan perfoma routing RAPID.

15


Secara ringkas, protokol routing dapat dijelaskan seperti dibawah ini. Protokol RAPID (X, Y): 1. Initialization: Mendapatkan metadata dari Y tentang paket dalam buffer dan metadata yang dikumpulkan

Y setelah beberapa pertemuan

sebelumnya. 2. Direct delivery: Memberikan paket yang ditentukan untuk Y diurutan penurunan utilitas mereka. 3. Replication: Untuk setiap paket i dalam buffer simpul X a. Jika i sudah dalam buffer Y (seperti yang ditentukan dari metadata), maka i diabaikan. b. Memperkirakan utilitas marjinal, δUi, mereplikasi i ke Y. c. Mereplikasi paket dalam urutan penurunan 4. Termination: Transfer berakhir ketika keluar dari jangkauan radio.

2.4.6 Estimating Delivery Delay Bagaimana RAPID mengestimasi average delay dengan rumus 1 dan 3, atau probabilitas delivery paket dalam batas waktu rumus 2? Rata-ra delivery delay adalah waktu rata-rata minimal sampai beberapa node dengan replika paket menyampaikan paket tersebut; jadi node butuh pengetahuan node yang mana telah memiliki replika paket dan rata-rata kapan mereka bertemu dengan tujuan. Untuk mengestimasi average delay dengan diasumsikan bahwa paket disampaikan secara langsung ke tujuan dengan mengabaikan replikasi. Estimasi tersebut tidak sepele bahkan dengan akurat gambaran bagian sistem global yang akurat. Untuk meringankan eksposisi, kita mengenalkan algoritma estimasi dari RAPID dengan seseolah tahudari bagian keseluruhan sistem, dan kemudian mengenalkan implementasi praktis terdistribusi. 2.4.6.1 Algorithm Estimate Delay Cara kerja algoritma estimasi delay sebagai berikut. Tiap node X mempertahankan antrian terpisah paket Q yang diperuntukkan untuk tiap node Z diurutkan dalam urutan menurun dari T(i) atau waktu sejak dibuat urutan di mana mereka akan disampaikan secara langsung(dalam langkah 2 protokol

16


RAPID). Langkah kedua dalam estimasi delay menghitung distribusi keterlambatan untuk pengiriman paket oleh X, seakan X adalah satu-satunya node yang membawa replika i. Langkah 3 menghitung minimum di semua replika sesuai distribusi delay, sebagai sisa waktu (i) adalah waktu sampai beberap node menemui Z. Estimasi delay membuat asumsi idependen lebih sederhana yang pada umumnya tidak dimiliki. berdasar gambar 2.3, contoh menunjukkan posisi replika paket dalam antrian node yang berbeda; paket dengan letter yang sama dan indeks berbeda adalah replika. Semua paket yang memiliki tujuan ke Z dan setiap antrian diurutkan secara T(i). Menganggap bahwa ukuran dari setiap kesempatan transfer adalah satu paket. Paket b dapat dikirimkan dalam dua cara: (i) jika W bertemu Z, atau (ii) salah satu X dan Y bertemu Z dan kemudian salah satu X dan Y bertemu Z lagi. Dependensi delay ini dapat diilustrasikan menggunakan grafik dependensi seperti yang dilustrasikan pada gambar 2.4. vertex menyesesuaikan ke replika paket. Tepian dari saah satu node menunjukkan suatu dependensi antara delay dari paket yang bersangkutan atau sesuai. Ingat bahwa MXY adalah variabel acak yang mewakili waktu pertemuan antara X dan Y.

17


Estimasi delay mengabaikan semua dependensi non vertikal sebagai contoh, mengestimasikan distribusikan waktu pengiriman dari b sebagai berikut: min(MWZ,MXZ +MXZ, MYZ +MYZ) Sedangkan distribusi sebenarnya min(MWZ, min(MXZ,MYZ) + min(MXZ,MYZ)) Meskipun, secara umum, asumsi independen mengembangkan estimasi delay, ia membuat implementasi bahwa: (i) simple –mengkomputasi estimasi yang akurat terutama ketika transfer tidak berukuran unit; dan (ii) didistribusikandalam praktik, RAPID tidak memiliki pandangan global, tetapi rata-rata delay dapat diimplementasikan dengan menggunakan control channel yang kecil.

Gambar 2.3 Paket yang ditujukan ke buffer Z untuk node yang berbeda

Gambar 2.4 Dependensi delay antar paket yang ditujukan ke node Z.

18


Algoritma Estimate Delay(X, Q,Z): Node X dengan satu set paket Q ke tujuan Z memperkirakan waktu, A (i), sampai paket i

Q dikirim ke Z sebagai berikut:

1. Pengurutan paket di Q dalam urutan penurunan T (i). Dimana b (i) menjadi jumlah ukuran paket yang mendahului, dan B rata-rata peluang transfer dalam byte antara X dan Z (lihat Gambar 1).

Gambar 2.5 Posisi paket i dalam antrian paket diperuntukkan untuk Z. 2. X dengan sendirinya membutuhkan ⌈d(i)/B⌉ Jadilah pertemuan dengan Z untuk memberikan i. Menghitung variabel acak MX (i) untuk yang sesuai delay sebagai berikut: MX(i) = MXZ +MXZ + . . . ⌈d(i)/B⌉ waktu

(4)

3. X1,. . . , Xk ⊇ X adalah himpunan node memiliki replika i. Estimasi sisa waktu (i) sebagai berikut: a(i) = min(MX1 (i), . . . ,MXk (i))

(5)

4. Rata-rata delay D(i) = T(i) + E[a(i)]

2.5 Protokol Routing Epidemic Epidemic routing algorithm diterbitkan oleh Vahdat dan Becker et al. (2000), yang di rancang sebagai algoritma flooding-based forwarding [7]. Tujuan utama protokol routing Epidemic adalah untuk: -

memaksimalkan tingkat pengiriman pesan.

-

meminimalkan pesan delay. Cara kerja protokol routing Epidemic adalah sebagai berikut, setiap kali

node pengirim bertemu dengan node lainya maka pertama kali yang dilakukan adalah bertukar summary vector, untuk mengidentifikasi pesan apakah node yang baru ditemui sudah mempunyai pesan yang di bawa node pengirim atau

19


tidak, jika tidak maka node pengirim akan meneruskan salinan pesan yang dibawa. Paket akan terus disalin dari satu node ke node lain sampai TTL nya berakhir. Pesan dan unique identifier akan di simpan dalam buffer node. Dengan demikian, pesan tersebut menyebar ke seluruh jaringan hingga sampai ke node tujuan. Meskipun tidak ada jaminan pesan tersampaikan, protokol routing Epidemic adalah algoritma yang mampu membuat pendekatan terbaik untuk penyampaian pesan ke node tujuan. Akan tetapi protokol routing Epidemic masih memiliki kekurangan yaitu akan mengakibatkan tidak efisiennya penggunaan sumber daya jaringan seperti konsumsi energi, memori dan bandwith, karena penyampaian salinan pesan yang sama akan menyebar semakin banyak ke dalam jaringan. Epidemic memberikan penyebaran salinan cepat ke dalam jaringan yang tentu saja mengahasilkan waktu pengiriman yang optimal namun jaringan akan kebanjiran data yang menyebabkan kemacetan jaringan.

Gambar 2.6 Skema Cara Kerja Epidemic.

20


2.6 The Opportunistic Network Environment Simulator (The ONE Simulator). 2.6.1 Fungsi The ONE simulator The ONE simulator adalah singkatan dari The Opportunistic Network Environment simulator. The ONE Simulator dibuat menggunakan program java[6]. Fungsi utama the ONE simulator adalah memodelkan pergerakan node, hubungan antar node, routing dan penanganan pesan. Hasil dan analisis didapatkan melalui visualisasi, laporan dan post-processing tools.[8] The ONE Simulator dapat memvisualisasikan hasil simulasi dengan dua cara; melalui tampilan interaktif Graphical User Interface (GUI) dan menggenerate gambar dari informasi yang dikumpulkan pada saat simulasi. Gambar 2.5, menampilkan lokasi node, jalur, hubungan antara node, jumlah pesan yang diterima oleh node, dll. Semua divisualisasikan pada jendela utama. Jika pergerakan map-based yang digunakan, maka semua jalur map akan ditampilkan. Gambar background tambahan (seperti raster, map atau gambar satelit dari area simulasi) di tampilkan dibawah jalur map jika ada.[9]

Gambar 2.7 Tampilan awal The ONE Simuator

21


BAB III PERANCANGAN SIMULASI JARINGAN 3.1 Parameter Simulasi Pada penelitian ini menggunakan beberapa parameter yang bersifat konstan, yang akan digunakan untuk setiap simulasi baik untuk protokol routing RAPID dan protokol routing Epidemic, tabelnya sebagai berikut: Tabel 3.1 Parameter Tetap dalam Skenario Parameter

Nilai

Luas Area Jaringan

4500 x 3400 m

Total waktu Simulasi

12 Jam RandomWaypoint

Model Pergerakan

ShortestPathMapBasedMovement (Peta Helsinki)

Protokol Routing

RAPID; Epidemic

Interface Transmit Range

10 m

Interface Trabsmit Speed

2 Mbps

Node Movement Speed

Min= 1.9 m/s Max= 3.9 m/s

Message Creations Rate

25-35 detik

Message Size

500 KB sampai 1 MB

22


3.2 Skenario Simulasi Skenario simulasi antara kedua protokol routing RAPID dan protokol routing Epidemic menggunakan parameter yang sama akan tetapi nilai TTL, Node dan Buffer yang bervariasi. Kemudian hasil dari pengujian ditampilkan menjadi sebuah tabel grafik. 3.2.1 Tabel Skenario Tabel 3.2 Skenario A dengan Penambahan TTL Skenario

Jumlah TTL (menit)

1A

60; 120; 180; 240; 300; 360; 420; 480

2A

60; 120; 180; 240; 300; 360;

Model Pergerakan ShortestPathMapBased Random Waypoint

420; 480

Tabel 3.3 Skenario B dengan Penambahan Node Skenario

Jumlah Node

Model Pergerakan

1B

50; 75; 100; 125; 150

ShortestPathMapBased

2B

50; 75; 100; 125; 150

Random Waypoint

Tabel 3.4 Skenario C dengan Penambahan Buffer Skenario

Jumlah Buffer (MB)

Model Pergerakan

1C

10; 20; 30; 40; 50; 60; 70

ShortestPathMapBased

2C

10; 20; 30; 40; 50; 60; 70

Random Waypoint

3.3 Parameter Kinerja Ada lima parameter kinerja dalam penelitian akhir ini: 3.3.1 Delivery Probability Delivery Probability adalah jumlah paket data yang sampai ke node tujuan dari jumlah paket yang dihasilkan oleh node asal. Rumus untuk menghitung Delivery Probability:

23


3.3.2 Average Delay Delay yang dimaksud adalah end to end delay. End to end delay adalah waktu yang dibutuhkan paket dalam jaringan dari saat paket dikirim sampai diterima oleh node tujuan. Delay merupakan suatu indikator yang cukup penting untuk perbandingan protokol routing, karena besarnya sebuah delay dapat memperlambat kinerja bagi protokol routing tersebut. Rumus untuk menghitung delay :

3.3.3 Overhead Ratio Overhead ratio adalah ratio antara banyaknya jumlah copy message yang terkirim dibagi dengan copy message yang dibuat. Jika overhead ratio bernilai rendah, makan protokol routing tersebut dapat dikatakan memiliki kinerja yang cukup baik dalam pengiriman paket. Rumus untuk menghitung overhead ratio :

3.3.4 Message Drop Pesan yang di drop dari sebuah node dari 2 kondisi, TTL atau buffer penuh. TTL kondisi dimana masa hidup sebuah pesan sudah habis, buffer penuh kondisi dimana pesan yang ditampung sudah melebihi dari buffer. 3.3.5 Average Buffer Occupancy Average Buffer Occupancy adalah rata-rata jumlah ruang buffer yang dipakai.

24


3.4 Model Pergerakan 3.4.1 Random Waypoint Pada manajemen pergerakan, random waypoint, adalah model acak atau random untuk pergerakan perangkat mobile, dan bagaimana lokasi mereka, kecepatan dan akselerasi berubah setiap saat. Model pergerakan ini untuk kepentingan simulasi ketika protokol jaringan baru akan dievaluasi. Model random waypoint pertama kali diperkenalkan oleh Johnson and Maltz. Pergerakan ini adalah salah satu model pergerakan yang paling populer untuk mengevaluasi protokol routing MANET, karena kesederhanaan dan ketersediaan yang luas.Pada simulasi dengan pergerakan random, mobile node bergerak secara random dan bebas tanpa batasan. Secara lebih spesifik, mengenai tujuan, kecepatan dan arah dipilih secara bebas oleh node. Dalam manajemen mobilitas, petunjuk jalan acak adalah model model acak untuk pergerakan pengguna yang mobile, dan bagaimana lokasi mereka, namun bersuhu akselerasi dan berubah-ubah dari waktu ke waktu.[1] model mobilitas ini digunakan untuk tujuan-tujuan simulasi ketika protokol jaringan baru dievaluasi. Petunjuk Jalan acak pertama kali model yang diajukan oleh Johnson dan Maltz.[2] Ia adalah salah satu model mobilitas yang paling populer[3] untuk mengevaluasi mobile jaringan ad hoc (MANET protokol routing), karena kemudahannya dan ketersediaan luas.

Gambar 3.1 Model Pergerakan Random Waypoint. 3.4.2 ShortestPath Map Based Movement Shortest Path Map-Based Movement

(SPMBM),

pada

awalnya

menempatkan node secara random tetapi memilih destinasi tertentu pada peta atau map dengan menggunakan algoritma Djikstra[6] sampai dengan tujuan akhir shortestpath map based movement. Ketika destinasi dapat dicapai node menunggu untuk beberapa waktu dan memilih tujuan baru. Secara normal semua tempat pada map memiliki probabilitas yang sama untuk dipilih sebagai destinasi selanjutnya, tetapi data map juga dapat memuat POI. Setiap POI dikelompokan pada kelompok

25


POI dan setiap grup node dapat diatur probabilitas untuk memilih POI pada grup tertentu sebagai destinasi selanjutnya. POI sangat berguna untuk pemodelan seperti restorant, tempat wisata dan tempat lain yang orang-orang cenderung berkumpul. Sebagai contoh,

objek random waypoint memberikan jalur zig-zag

sederhana sedangkan Map Based Movement (MBM) membatasi komponen jalur pada segmen jalur yang didefinisikan pada data map. Bagian paket dari map memiliki kelas utilitas yang berdasar pada model pergerakan berbasis map. Kelas SimMap menyediakan mengenai data map dan kelas DijkstraPathFinder dapat digunakan untuk menemukan jalur terpendek diantara dua map node. Kelas PointsOfInterest pada bagiannya untuk membaca data POI dan memilih POI yang sesuai berdasar konfigurasi. (lihat gambat) Kelas Map Based Movement, menurunkan kelas pergerakan default dengan menambahkan fitur peta yang terkait seperti reading dan caching map data.

Model

pergerakan

SPMBM

juga

menggunakan

map

data

dan

DijkstraPathFinder untuk bergerak menggunakan jalur terpendek diatara pemberhentian dan destinasi map lainnya.

Gambar 3.2 Model Pergerakan ShortestPath Map Based

26


Gambar 3.3 Model pergerakan

3.5 Topologi Jaringan Topologi jaringan di dalam Opportunistic Network tidak bisa diprediksi karena topologinya selalu berubah. Perkiraan topologi jaringan dapat dilihat pada gambar di bawah ini.

Gambar 3.4 Snapshoot jaringan node 126 dengan model pergerakan ShortestPathMapBased.

27


Gambar 3.5 Snapshoot jaringan node 126 dengan model pergerakan Random Waypoint.

28


BAB IV PENGUJIAN DAN ANALISA

Untuk membandingkan untuk kerja pada kedua protokol routing RAPID terhadapat protokol routing Epidemic ini akan dilakukan seperti pada tahap pengujian sesuai skenario perencanaan simulasi jaringan pada bab 3 sesuai parameter yang sudah ditentukan. 4.1 ShortestPathMapBasedMovement 4.1.1 Penambahan TTL Tabel 4.1 ShortestPath Map Based Movement: Hasil Pengujian Penambahan Jumlah TTL TTL

Pengujian dengan Pergerakan Shortest Path Map Based Delivery

Average

Overhead

Message

Probability

Delay

ratio

Drop

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

60

0,5812

0,5796

2173,993

2267,8914

36,1973

38,3502

20108

35989

120

0,7724

0,7239

3706,0003

3728,0017

27,5204

32,5146

6786

34532

180

0,8496

0,769

4389,5105

4849,4396

23,8391

31,3787

3040

33991

240

0,8763

0,7621

4687,0957

5554,8095

22,6466

31,0682

455

33301

300

0,8776

0,7744

4736,9742

6259,9808

22,2407

32,2754

0

32284

360

0,8831

0,7649

4691,6243

6648,9839

22,5271

32,7721

0

31198

420

0,8742

0,7478

4605,9542

6719,5273

22,1235

33,6015

0

30893

480

0,877

0,7396

4641,9791

6832,1537

22,152

34,0721

0

30466

29

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

# Messages Dropped

Delivery Probability


60 120 180 240 300 360 420 480 Epidemic Rapid

40000 35000 30000 25000 20000 15000 10000 5000 0 60 120 180 240 300 360 420 480

TTL(menit)

Epidemic Rapid

(1) Delivery Probability

(2) Message Drop

120 Average Delay(m/s)

Overhead Ratio

100 80 60 40 20

TTL(menit)

0 60 120 180 240 300 360 420 480 Epidemic TTL(menit) Rapid

16000 14000 12000 10000 8000 6000 4000 2000 0 60 120 180 240 300 360 420 480 Epidemic Rapid

(3) Overhead Ratio

TTL(menit)

(4) Average Delay

Grafik 4.1 ShortestPathMapBased: Grafik Penambahan TTL Terhadap Unjuk Kerja Jaringan. Grafik 4.1 menunjukan bahwa dengan penambahan TTL, maka delivery probability mengalami peningkatan. Hal ini dikarenakan penambahan TTL memeberikan masa hidup pesan yang lebih panjang, sehingga message drop akan mengalami penurunan ditambah lagi penggunaan buffer yang cukup (lihat grafik 4.2 dan grafik 4.3). Demikian juga dengan overhead ratio akan mengalami penurunan, meskipun dari average delay akan terjadi kenaikan. Hal ini karena

30


dengan menggunakan model pergerakan shortest path map based pencarian jalur dengan algoritma djikstra. Setelah pesan mencapai destination, node akan diam sebentar pada titik point interest tertentu untuk memulai pada tujuan berikutnya.

80 60 40 20 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121

# Buffer Occupancy (%)

Average Buffer Occupancy 100

Epidemic Rapid

Nodes

Grafik 4.2 Shortest Path Map Based: Grafik Pengaruh Penambahan TTL (60 Menit) Terhadap Average Buffer Occupancy


60 40 20 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121


100

Epidemic Rapiid

Nodes

Grafik 4.3 Shortest Path Map Based: Grafik Pengaruh Penambahan TTL (480 Menit) Terhadap Average Buffer Occupancy

31


4.1.2 Penambahan Node Tabel 4.2 Shortest Path Map Based Movement: Hasil Pengujian Penambahan Jumlah Node #Node


Average

Overhead

Message

Probability

Delay

ratio

Drop

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

50

0,6516

0,5912

6968,9871

7379,7687

5,0905

5,8689

755

5031

75

0,7558

0,6667

6652,4502

6942,5599

9,6797

12,9712

792

11539

100

0,8388

0,7257

5630,4013

6487,5168

15,6051

21,9915

494

20946

125

0,8519

0,7428

5232,8336

6552,098

22,2238

32,8763

44

32387

150

0,8875

0,7737

4241,5526

5963,6976

30,2674

45,7172

2

46222

32

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

60000 # Message Dropped



50000 40000 30000 20000 10000

0 50

75

100

125

150

50

# Node

Epidemic Rapid

100

125

150

125

150

# Node

Epidemic Rapid


(2) Message Drop

90 80 70 60 50 40 30 20 10 0


Overhead Ratio

75

9400 7400 5400 3400 1400 -600

50 Epidemic Rapid

75

100

125

150

# Node

50

Epidemic Rapid

(3) Overhead Ratio

75

100 # Node

(4) Average Delay

Grafik 4.4 ShortestPathMapBased: Grafik Penambahan Node Terhadap Unjuk Kerja Jaringan. Grafik 4.4 menunjukkan bahwa dengan penambahan node, maka akan meningkatkan delivery probability secara signifikan untuk kedua protokol. Hal ini disebabkan karena kerapatan node membuat kedua protokol mudah mencari jalur ke node tujuan. Untuk RAPID dengan cara membandingkan utilitas setiap node yang akan menjadi relay, sedangkan untuk Epidemic dengan melakukan

33


salinan pesan terus menerus. Sehingga overhead akan mengalami peningkatan. Kemudian, message drop pada RAPID cenderung kecil dan semakin menurun dibandingkan dengan Epidemic yang mengalami peningkatan, hal ini terjadi dari salinan keseluruh jaringan sedangkan TTL (300 menit) dibatasi. Lalu pengaruh lain pada penambahan jumlah node akan menurunkan average delay kedua


protokol.

Average Buffer Occupancy

100 80 60 40 20 0

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 Epidemic Rapid Nodes

Grafik 4.5 Shortest Path Map Based: Grafik Pengaruh Penambahan Node (50) Terhadap Average Buffer Occupancy.


80

60 40 20 0 1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127 133 139 145


100

Epidemic

Rapid

Nodes

Grafik 4.6 Shortest Path Map Based: Grafik Pengaruh Penambahan Node (150) Terhadap Average Buffer Occupancy.

34


4.1.4 Penambahan Buffer Tabel 4.3 Shortest Path Map Based Movement: Hasil Pengujian Penambahan Jumlah Buffer Buffer


Average

Overhead

Message

Probability

Delay

Ratio

Drop

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

10 MB

0,7387

0,3676

2665,587

3266,618

26,223

69,9739

4807

37279

20 MB

0,8656

0,546

4386,787

4813,203

22,588

46,7663

391

35483

30 MB

0,8752

0,6584

5022,080

5630,840

22,163

38,226

1

33858

40 MB

0,8635

0,7133

5144,041

6319,829

22,606

35,0423

80

32980

50 MB

0,8656

0,7325

5207,505

6352,577

22,352

33,5927

6

32683

60 MB

0,8635

0,7435

5510,156

6584,384

22,751

33,1633

119

32213

70 MB

0,8663

0,7531

5782,575

6609,832

22,779

32,5228

10

32057

35

40000

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

# Messages Dropped



35000 30000 25000 20000 15000 10000 5000 0

10

20

30

40

50

60

10 20 30 40 50 60 70

70

Buffer (MB)

Buffer (MB) Epidemic

Epidemic

Rapid

Rapid (2) Message Drop

120

12000

100

10000

Average Delay(m/s)

Overhead ratio


80 60 40 20

8000 6000 4000 2000 0

0 10

20

30

40

50

60

10 20 30 40 50 60 70

70

Buffer (MB)

Buffer (MB) Epidemic

Epidemic

Rapid

Rapid (3) Overhead Ratio

(4) Average Delay

Grafik 4.7 Shortest Path Map Based: Grafik Pengaruh Penambahan Buffer Terhadap Average Buffer Occupancy Grafik 4.7 menunjukkan bahwa dengan penambahan kapasitas buffer, maka delivery probability kedua protokol mengalami peningkatan, meskipun cenderung stabil. Hal ini dibabkan karena penambahan kapasitas buffer akan memberikan

36


ruang yang lebih untuk menampung pesan. Sehingga pengaruh lain terjadi pada message drop yang akan semakin menurun. Kemudian pada overhead ratio juga akan mengalami penurunan dan pada average delay kedua protokol routing mengalami peningkatan meskipun tidak secara signifikan. Dengan peningkatan buffer tersebut dan penggunaan TTL (300 menit) yang cukup maka average delay akan semakin tinggi karena aktifitas pengiriman akan terus berlangsung.

100 80 60 40 20 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121



Epidemic Rapid

Nodes

Grafik 4.8 ShortestPathMapBased: Grafik Pengaruh Penambahan Buffer (10 MB) Terhadap Average Buffer Occupancy. Average Buffer Occupancy 80 60 40 20 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121


100

Epidemic Rapid

Nodes

Grafik 4.9 ShortestPathMapBased: Grafik Pengaruh Penambahan Buffer ( 70MB) Terhadap Average Buffer Occupancy.

37


4.2 Random Waypoint 4.2.1 Penambahan TTL Tabel 4.4 Random Waypoint: Hasil Pengujian Penambahan Jumlah TTL TTL

Pengujian dengan Pergerakan Random Waypoint Delivery

Message

Probability

Drop

Overhead ratio

Average Delay

RAPID

RAPID

RAPID

Epidemic

RAPID

Epidemic

60

0,0519

0,0718

5659

11150

74,3684

96,2571

2229,5395

2411,56

120

0,1196

0,1579

11002

16528

61,3429

69,5541

4503,8766

4689,41

180

0,1962

0,2317

12722

17322

48

51,8702

6888,108

7039,27

240

0,2625

0,2912

12466

16990

39,7109

42,4225

9382,7505

8995,39

300

0,3178

0,3213

10829

16621

34,1419

38,883

11102,4284

10603,7

360

0,3472

0,3192

8574

15740

32,0217

39,3084

12532,2419

11371,1

420

0,3848

0,3336

6825

15487

29,0213

37,6455

13941,3078

12811,6

480

0,4081

0,3342

4361

15377

27,3384

37,8139

14880,3864

13685,0

38

Epidemic

Epidemic

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

# Messages Dropped



60 120 180 240 300 360 420 480 Epidemic Rapid

40000 35000 30000 25000 20000 15000 10000 5000 0

60 120 180 240 300 360 420 480

TTL(menit)

Epidemic Rapid


(2) Message Drop

120 100

Average Delay(m/s)

Overhead Ratio

TTL(menit)

80 60

40 20 0 60 120 180 240 300 360 420 480 Epidemic TTL(menit) Rapid

16000 14000 12000 10000 8000 6000 4000 2000 0 60 120 180 240 300 360 420 480 Epidemic TTL(menit) Rapid

(3) Overhead Ratio

(4) Average Delay

Grafik 4.10 Random Waypoint: Grafik Penambahan buffer Terhadap Unjuk Kerja Jaringan. Grafik 4.10 menunjukan bahwa dengan penambahan TTL, maka delivery probability kedua protokol mengalami peningkatan meskipun cenderung stabil. Hal ini dikarenakan penambahan TTL memeberikan masa hidup pesan yang lebih panjang, sehingga message drop akan mengalami penurunan ditambah lagi penggunaan buffer yang cukup (lihat grafik 4.7). Demikian juga dengan overhead ratio akan mengalami penurunan. Kemudian average delay mengalami peningkatan secara signifikan. Hal ini dikarena dengan menggunakan model pergerakan random waypoint untuk RAPID kesulitan dalam mencari jalur untuk

39


pengiriman pesan. Sedangkan untuk Epidemic dikarenakan jumlah hop count


100 80 60 40 20 0

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121


yang untuk mencapai tujuan.

Epidemic Rapid

Nodes

Grafik 4.11 Random Waypoint: Grafik Pengaruh Penambahan TTL Terhadap Average Buffer Occupancy

100 80 60 40 20 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121



Epidemic Rapid

Nodes

Grafik 4.12 Random Waypoint: Grafik Pengaruh Penambahan TTL Terhadap Average Buffer Occupancy.

40


4.2.2 Penambahan Node Tabel 4.5 Random Waypoint: Hasil Pengujian Penambahan Jumlah Node Node

Pengujian dengan Pergerakan Random Waypoint Delivery

Average

Overhead

Message

Probability

Delay

Ratio

Drop

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

50

0,1514

0,1911

10261,2846

10027,6837

16,7692

20,8387

3399

5661

75

0,2445

0,2986

10812,8874

10559,0849

24,2857

29,0459

6966

11492

100

0,3295

0,3486

11242,2023

10500,6556

32,8607

45,499

11761

21273

125

0,4199

0,3959

11033,2677

10170,1214

42,5171

62,0606

16126

32789

150

0,5274

0,4486

10747,52

10087,8362

51,9818

81,7771

20212

48293

41

60000

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

# Message Dropped



50000 40000 30000

20000 10000 0

50

75

100

125

150

50

# Node

Epidemic Rapid

Average Delay(m/s)

Overhead Ratio

Epidemic Rapid

100

125

125

150

125

150

(2) Massage Drop

90 80 70 60 50 40 30 20 10 0 75

100 # Node

Epidemic Rapid


50

75

11400 11200 11000 10800 10600 10400 10200 10000 9800 9600 9400 50

150

# Node

Epidemic Rapid

(3) Overhead Ratio

75

100 # Node

(4) Average Delay

Grafik 4.13 Random Waypoint: Grafik penambahan Node Terhadap Unjuk Kerja Jaringan. Grafik 4.13 menunjukkan bahwa dengan penambahan node, maka akan meningkatkan delivery probability secara signifikan untuk kedua protokol. Hal ini disebabkan karena kerapatan node mempengaruhi RAPID dalam memberikan salinan dengan cara membandingkan utilitas dan Epidemic dengan melakukan salinan ke tetangganya terus menerus. Sehingga

overhead akan mengalami

peningkatan. Kemudian, message drop pada RAPID lebih baik dibandingkan

42


dengan Epidemic, meskipun keduanya cenderung mengalami peningkatan secara signifikan. Hal ini dikarenakan TTL (300 menit) dibatasi sedangkan jumlah hop count untuk sampai tujuan akan semakin bertambah. Lalu pengaruh lain pada penambahan jumlah node akan menurunkan average delay kedua protokol.


Average Buffer Occupancy 50 40 30 20 10 0 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 Epidemic Nodes Rapid

Grafik 4.14 Random Waypoint: Grafik Pengaruh Penambahan Node Terhadap Average Buffer Occupancy. Average Buffer Occupancy 80 60 40 20 0 1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103 109 115 121 127 133 139 145


100

Epidemic Rapid

Nodes

Grafik 4.15 Random Waypoint: Grafik Pengaruh Penambahan Node Terhadap Average Buffer Occupancy.

43


4.2.3 Penambahan Buffer Tabel 4.6 Random Waypoint: Hasil Pengujian Penambahan Jumlah Buffer Pengujian dengan Pergerakan Random Waypoint Buffer

Delivery

Average

Overhead

Message

Probability

Delay

Ratio

Drop

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

RAPID

Epidemic

10 MB

0,1616

0,1623

9335,9737

8374,5245

79,0297

95,4684

17642

22588

20 MB

0,2945

0,2493

10332,4398

9323,6574

58,1488

88,6209

20554

31183

30 MB

0,3603

0,2973

10608,8243

9893,3859

50,4335

82,0576

19584

33568

40 MB

0,4048

0,3363

10961,3369

10087,9387

45,0169

74,4644

17917

33865

50 MB

0,4288

0,3493

11146,8725

10043,5059

42,6134

73

17215

34319

60 MB

0,4253

0,376

10986,4375

10298,4519

42,8325

68,2987

16930

33927

70 MB

0,4295

0,3877

11065,5494

10457,2099

42,4402

66,1537

16727

33805

44

1

40000

0,9

35000

0,8 0,7

# Message Drop



0,6 0,5 0,4 0,3 0,2

30000 25000 20000 15000 10000 5000

0,1

0

0

10 20 30 40 50 60 70

10 20 30 40 50 60 70 Epidemic Buffer (MB)

Epidemic

Rapid

Rapid

Message Drop

120

12000

100

10000

Average Delay(m/s)

Overhead Ratio


Buffer (MB)

80 60 40

20

8000 6000

4000 2000 0

0 10 Epidemic Rapid

20

30

40

50

60

10 20 30 40 50 60 70

70

Buffer (MB)

Epidemic Rapid

(3) Overhead Ratio

Buffer (MB)

(4) Average Delay

Grafik 4.16 Random Waypoint: Grafik Penambahan Buffer Terhadap Unjuk Kerja Jaringan Grafik 4.16 menunjukkan bahwa dengan penambahan kapasitas buffer, maka Delivery Probability kedua protokol mengalami peningkatan. Namun juga terjadi peningkatan secara signifikan pada message drop, hal ini dikarena TTL(300 menit) yang terbatas, pesan akan mengalami drop sebelum mencapai tujuan. Kemudian pada overhead ratio akan mengalami penurunan dan pada 45


average delay kedua protokol routing mengalami peningkatan. Dengan peningkatan buffer tersebut dan penggunaan TTL (300 menit) yang cukup maka average delay akan semakin tinggi karena aktifitas pengiriman akan terus


100 80 60 40 20 0

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101 106 111 116 121


berlangsung.

Epidemic Rapid

Nodes

Grafik 4.17 Random Waypoint: Grafik Pengaruh Penambahan Buffer Terhadap Average Buffer Occupancy

80 60 40 20 0 n1 n6 n11 n16 n21 n26 n31 n36 n41 n46 n51 n56 n61 n66 n71 n76 n81 n86 n91 n96 n101 n106 n111 n116 n121



Epidemic Rapid

Nodes

Grafik 4.18 Random Waypoint: Grafik Pengaruh Penambahan Buffer Terhadap Average Buffer Occupancy

46


4.3. Perbandingan Protokol Routing RAPID terhadap Protokol Routing Epidemic 4.3.1 Penambahan TTL a. Delivery Probability Tabel 4.7 Hasil perbandingan penambahan TTL terhadap delivery probability. TTL

Delivery Probability Random Waypoint

ShortestPath Map Based Movement

RAPID

Epidemic

RAPID

Epidemic

60

0,0519

0,0718

0,5812

0,5796

120

0,1196

0,1579

0,7724

0,7239

180

0,1962

0,2317

0,8496

0,769

240

0,2625

0,2912

0,8763

0,7621

300

0,3178

0,3213

0,8776

0,7744

360

0,3472

0,3192

0,8831

0,7649

420

0,3848

0,3336

0,8742

0,7478

480

0,4081

0,3342

0,877

0,7396

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0



(menit)

60 120 180 240 300 360 420 480

60 120 180 240 300 360 420 480 Epidemic Rapid

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0

TTL(menit)

Epidemic Rapid

TTL(menit)

ShortestPath Map Based

Random Waypoint

Gambar 4.19 Grafik perbandingan pada penambahan TTL terhadap Delivery Probability.

47


Gambar 4.19 menunjukan bahwa dengan penambahan TTL maka meningkatkan delivery probability pada kedua protokol routing. Hal ini dikarenakan pesan akan memiliki masa hidup yang lebih panjang dalam proses pengiriman data dari source menuju destination. Ditambah lagi penggunaan buffer yang cukup (lihat grafik 4.1 dan grafik 4.2). Kemudian, terlihat bahwa dengan menggunakan dua model pergerakan yang berbeda maka menghasilkan delivery probability yang berbeda pula. Dimana dengan menggunakan model pergerakan shortestpath map based untuk kedua protokol mengalami peningkatan delivery probability dan cenderung lebih tinggi dari pada menggunakan model pergerakan random waypoint. Secara umum bahwa delivery probability protokol routing RAPID lebih tinggi daripada protokol routing Epidemic pada model pergerakan shortestpath map based karena dengan menggunakan jalur tertentu, membuat perhitungan matrik pada algoritma inference dapat diterapkan dari pada dipergerakan acak. Hal ini dikarenakan pada pergerakan random waypoint menganggap probabilitas semua node sama, sehingga RAPID tidak dapat menerapkan perhitungan metrik untuk melakukan perbandingan utilitas sebelum melakukan replikasi. b. Average Delay Tabel 4.8 Hasil perbandingan penambahan TTL terhadap average delay. TTL (menit)

Average Delay Random Waypoint


RAPID

Epidemic

RAPID

Epidemic

60

2229,5395

2411,56

2173,993

2267,8914

120

4503,8766

4689,41

3706,0003

3728,0017

180

6888,108

7039,27

4389,5105

4849,4396

240

9382,7505

8995,39

4687,0957

5554,8095

300

11102,4284

10603,7

4736,9742

6259,9808

360

12532,2419

11371,1

4691,6243

6648,9839

420

13941,3078

12811,6

4605,9542

6719,5273

480

14880,3864

13685,0

4641,9791

6832,1537

48

16000 14000 12000 10000 8000 6000 4000 2000 0

Average Delay(m/s)

Average Delay(m/s)


60 120 180 240 300 360 420 480 Epidemic TTL(menit) Rapid

16000 14000 12000 10000 8000 6000 4000 2000 0 60 120 180 240 300 360 420 480 Epidemic Rapid

TTL(menit)


Random Waypoint

Gambar 4.20 Grafik perbandingan pada penambahan TTL terhadap average delay. Gambar 4.20 menunjukan bahwa dengan penambahan TTL maka meningkatkan average delay pada kedua protokol routing. Hal ini dikarenakan penambahan TTL membuat pesan memiliki masa hidup yang lebih panjang dalam proses pengiriman data dari source menuju destination. Kemudian, terlihat bahwa dengan menggunakan dua model pergerakan yang berbeda maka menghasilkan average delay yang berbeda pula. Dimana dengan menggunakan model pergerakan random waypoint untuk kedua protokol mengalami peningkatan secara signifikan dan lebih tinggi, dibandingan dengan pergerakan shortestpath map based yang cenderung secara bertahap peningkatannya. Secara umum bahwa average delay protokol routing RAPID lebih baik daripada protokol routing Epidemic ketika pada model pergerakan shortestpath map based karena protokol routing RAPID memiliki metrik meminimalkan average delay protokol RAPID berupaya untuk mereplikasi paket yang replikasinya mengurangi delay dengan semua paket yang ada di dalam buffer. Sebaliknya pada protokol routing Epidemic lebih baik pada pergerakan random waypoint karena bekerja dengan membanjiri jaringan.

49


c. Overhead Ratio Tabel 4.9 Hasil perbandingan penambahan TTL terhadap overhead ratio. TTL (menit)

Overhead Ratio Random Waypoint


RAPID

Epidemic

RAPID

Epidemic

60

74,3684

96,2571

36,1973

38,3502

120

61,3429

69,5541

27,5204

32,5146

180

48

51,8702

23,8391

31,3787

240

39,7109

42,4225

22,6466

31,0682

300

34,1419

38,883

22,2407

32,2754

360

32,0217

39,3084

22,5271

32,7721

420

29,0213

37,6455

22,1235

33,6015

480

27,3384

37,8139

22,152

34,0721

100

100 Overhead Ratio

120

Overhead Ratio

120

80 60 40

80

60 40

20

20

0

0



Random Waypoint


Gambar 4.21 Grafik perbandingan pada penambahan TTL terhadap overhead ratio. Pada gambar 4.21 pada pergerakan random waypoint kedua protokol mengalami penurunan overhead ratio dengan selisih protokol routing Epidemic lebih tinggi daripada protokol routing RAPID. Hal ini dikarenan kinerja dari protokol routing Epidemic yang melakukan salinan ke seluruh jaringan. Dan

50


penurunan overhead terjadi karena dipengaruhi masa hidup pesan (TTL). Kemudian overhead pada pergerakan shortestpath map based kedua protokol cenderung stabil, melainkan tetap lebih tinggi protokol routing Epidemic dari pada protokol routing RAPID. Hal ini karena dengan cara kerja protokol routing Epidemic yang membanjiri jaringan sedangkan pada pergerakan ini menggunakan jalur dan memiliki point of interest (POI) dimana node berkumpul dan melakukan pertukaran pesan dan menyebabkan banyak pesan yang di drop. d. Message Drop Tabel 4.10 Hasil perbandingan penambahan TTL terhadap message drop. TTL (menit)

Message Drop Random Waypoint


RAPID

Epidemic

RAPID

Epidemic

60

5659

11150

20108

35989

120

11002

16528

6786

34532

180

12722

17322

3040

33991

240

12466

16990

455

33301

300

10829

16621

0

32284

360

8574

15740

0

31198

420

6825

15487

0

30893

480

4361

15377

0

30466

51

40000 35000 30000 25000 20000 15000 10000 5000 0

# Messages Dropped

# Messages Dropped


60 120 180 240 300 360 420 480

60 120 180 240 300 360 420 480 Epidemic Rapid

40000 35000 30000 25000 20000 15000 10000 5000 0

TTL(menit)

Epidemic Rapid

Random Waypoint

TTL(menit)


Gambar 4.22 Grafik perbandingan pada penambahan TTL terhadap message drop.

Pada gambar 4.22 menunjukan bahwa penambahan TTL mempengaruhi message yang di drop. Semakin bertambahnya TTL maka akan semakin menurun message yang di drop. Hal ini karena pesan memerlukan masa hidup yang lebih panjang untuk sampai ke destination. Pada pergerakan random waypoint selisih message drop lebih baik protokol routing RAPID, karena pada protokol routing RAPID menggunakan perbandingan utilitas dalam melakukan salinan. Kemudian pada pergerakan shortestpath map based juga lebih baik RAPID, karena protokol routing Epidemic kesulitan dalam melakukan salinan keseluruh jaringan menggunakan jalur sedangkan TTL dibatasi.

52


4.3.2 Penambahan Node a. Delivery Probability Tabel 4.11 Hasil perbandingan penambahan node terhadap delivery probability. Node



Epidemic

RAPID

Epidemic

50

0,1514

0,1911

0,6516

0,5912

75

0,2445

0,2986

0,7558

0,6667

100

0,3295

0,3486

0,8388

0,7257

125

0,4199

0,3959

0,8519

0,7428

150

0,5274

0,4486

0,8875

0,7737

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0



RAPID

50 Epidemic Rapid

75

100

125

150

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 50

# Node

75

100

125

150

# Node Epidemic Rapid


Random Waypoint

Gambar 4.23 Grafik perbandingan pada penambahan node terhadap delivery probability. Gambat 4.23 menunjukkan bahwa dengan penambahan node, maka akan meningkatkan delivery probability secara signifikan untuk kedua protokol. Hal ini disebabkan karena kerapatan node membuat kedua protokol mudah mencari jalur ke node tujuan. Untuk protokol routing RAPID dengan cara membandingkan utilitas setiap node yang akan menjadi relay, sedangkan untuk protokol routing Epidemic dengan melakukan salinan pesan terus menerus hingga sampai pada

53


tujuan, apalagi didukung dengan buffer (70 MB) dan TTL (300 menit) yang cukup. Kemudian, terlihat bahwa dengan menggunakan dua model pergerakan yang berbeda maka menghasilkan delivery probability yang berbeda pula. Dimana dengan menggunakan model pergerakan shortestpath map based untuk kedua protokol mengalami peningkatan delivery probability dan cenderung lebih tinggi dari pada menggunakan model pergerakan random waypoint. Untuk RAPID memberikan pengaruh besar karena dengan adanya jalur memberikan protokol dapat menerapkan perhitungan metrik jauh lebih tepat dibandingkan pergerakan acak. b. Average Delay Tabel 4.12 Hasil perbandingan penambahan node terhadap average delay. Node



Epidemic

RAPID

Epidemic

50

10261,2846

10027,6837

6968,9871

7379,7687

75

10812,8874

10559,0849

6652,4502

6942,5599

100

11242,2023

10500,6556

5630,4013

6487,5168

125

11033,2677

10170,1214

5232,8336

6552,098

150

10747,52

10087,8362

4241,5526

5963,6976

11400 11200 11000 10800 10600 10400 10200 10000 9800 9600 9400


Average Delay(m/s)

RAPID

9400 7400 5400 3400

1400 -600

50 Epidemic Rapid

75

100

125

150

50

75

100

125

# Node

# Node

Epidemic Rapid

Random Waypoint


54

150


Gambar 4.24 Grafik perbandingan pada penambahan node terhadap average delay. Gambar 4.24 menunjukan bahwa dengan bertambahnya node maka akan menurunkan delay untuk kedua protokol. Hal ini dikarenakan semakin rapatnya node dalam jaringan membantu relay node dalam mencapai node tujuan lebih cepat.

Perbedaan telihat bahwa pada pergerkan random waypoint dimana

protokol routing Epiemic memiliki delay yang lebih kecil karena pergerakan secara random akan mendukung kinerja protokol routing Epidemik yang melakukan salinan ke seluruh jaringan. Sedangkan pada pergerakan shortestpath map based, protokol routing RAPID lebih baik karena semakin node rapat, maka mendapatkan jalur terpendek untuk sampai ke tujuan akan semakin cepat dengan berfungsinya

perhitungan

metrik

untuk

meminimalkan

average

delay,

dibandingkan protokol routing Epidemic yang akan kesulitan dengan adanya jalur dalam melakukan pengiriman data menuju destination.

c. Overhead Ratio Tabel 4.13 Hasil perbandingan penambahan node terhadap overhead ratio. Node

Averhead Ratio Random Waypoint


RAPID

Epidemic

RAPID

Epidemic

50

16,7692

20,8387

5,0905

5,8689

75

24,2857

29,0459

9,6797

12,9712

100

32,8607

45,499

15,6051

21,9915

125

42,5171

62,0606

22,2238

32,8763

150

51,9818

81,7771

30,2674

45,7172

55

90 80 70 60 50 40 30 20 10 0

Overhead Ratio

Overhead Ratio


50 Epidemic Rapid

75

100

125

90 80 70 60 50 40 30 20 10 0 50

150

# Node

Epidemic Rapid

Random Waypoint

75

100

125

150

# Node


Gambar 4.25 Grafik perbandingan pada penambahan node terhadap overhead ratio. Gambar 4.25 menunjukan bahwa dengan penambahan node maka menikatkan overhead ratio pada kedua protokol. Terlihat bahwa protokol routing Epidemic memiiki overhead ratio yang lebih tinggi baik pada pergerakan random waypoint ataupun shortestpath map based. Hal ini dikarenakan dengan penambahan node maka jumlah pesan yang akan disalinkan untuk mencapai tujuan juga akan semakin banyak. Berbeda dengan protokol routing RAPID meskipun bertambahnya node, overhead ratio masih lebih kecil terhadap Epidemic, karena sebelum melakukan salinan selalu membandingkan utilitas untuk mengetahui probabilitas pertemuan dengan tujuan, sehingga mempengaruhi jumlah pesan yang akan direplikasi.

56


d. Message Drop Tabel 4.14 Hasil perbandingan penambahan node terhadap message drop. Node

Message Drop Random Waypoint


Epidemic

RAPID

Epidemic

50

3399

5661

755

5031

75

6966

11492

792

11539

100

11761

21273

494

20946

125

16126

32789

44

32387

150

20212

48293

2

46222

60000

60000

50000

50000

# Message Dropped

# Message Dropped

RAPID

40000 30000

20000 10000

40000 30000 20000 10000 0

0 50

75

100

125

50

150

75

100

125

150

# Node

# Node

Epidemic Rapid

Epidemic Rapid

Random Waypoint


Gambar 4.26 Grafik perbandingan pada penambahan node terhadap message drop. Gambar 4.26 menunjukan bahwa penambahan node berdampak pada message drop yang meningkat. Pada protokol routing Epidemic mengalami message drop yang tinggi. Dibandingkan dengan protokol routing RAPID yang lebih rendah untuk kedua pergerakan. Hal ini dikarenakan kemampuan protokol routing Epidemic demi meningkatkan delivery probability dan mengurangi delay, maka membuat salinan ke seluruh jaringan. Sehingga ketika TTL pesan telah

57


habis maka message yang di drop akan banyak sekali, dibandingkan dengan protokol routing RAPID yang mempertimbangkan dalam mengirim pesan sehingga pesan dalam jaringan tidak terlalu banyak, dan ketika TTL pesan habis maka pesan yang di drop juga lebih sedikit dari protokol routing Epidemic. 4.3.3 Penambahan Buffer

a. Delivery Probability Tabel 4.15 Hasil perbandingan penambahan buffer terhadap delivery probability. Buffer (MB)



Epidemic

RAPID

Epidemic

10

0,1616

0,1623

0,7387

0,3676

20

0,2945

0,2493

0,8656

0,546

30

0,3603

0,2973

0,8752

0,6584

40

0,4048

0,3363

0,8635

0,7133

50

0,4288

0,3493

0,8656

0,7325

60

0,4253

0,376

0,8635

0,7435

70

0,4295

0,3877

0,8663

0,7531

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0



RAPID

1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 0 10

10 20 30 40 50 60 70 Epidemic Buffer (MB) Rapid

Epidemic Rapid

RandomMap Waypoint ShortestPath Based

20

30

40

50

60

Buffer (MB)

Shortestpath Map Based

Gambar 4.27 Grafik perbandingan pada penambahan buffer terhadap delivery probability.

58

70


Gambar 4.27 menunjukan bahwa protokol routing RAPID memiliki delivery probability yang stabil dibandingkan protokol routing Epidemic dalam pergerakan shortestpath map based yang mengalami kenaikan secara bertahap. Hal ini dikarenakan dengan penambahan buffer maka ruang penyimpanan akan bertambah sehingga message yang di drop akan berkurang, sehingga meningkatkan pengiriman pesan. Kemudian pada pergerakan ini menggunakan jalur yang menguntungkan protokol routing RAPID dalam mencapai tujuan dalam perhitungan metrik yang lebih tpat untuk diterapkan, dibandingkan dengan protokol routing Epidemic yang bersifat melakukan salinan pesan keseleruh jaringan sedangkan buffer dan TTL dibatasi. Kemudian pada pergerakan random waypoint untuk kedua protokol mengalami kenaikan delivery probability, hanya saja tidak sebesar pada pergerakan shortestpath map based. Hal ini dikarenakan penambahan buffer dan TTL pesan yang dibatasi sedangkan melakukan pergerakan secara acak untuk menuju ke tujuan. b. Average Delay Tabel 4.16 Hasil perbandingan penambahan buffer terhadap average delay. Buffer (MB)



RAPID

Epidemic

RAPID

Epidemic

10

9335,9737

8374,5245

2665,587

3266,618

20

10332,4398

9323,6574

4386,787

4813,203

30

10608,8243

9893,3859

5022,080

5630,840

40

10961,3369

10087,9387

5144,041

6319,829

50

11146,8725

10043,5059

5207,505

6352,577

60

10986,4375

10298,4519

5510,156

6584,384

70

11065,5494

10457,2099

5782,575

6609,832

59

12000

12000

10000

10000

Average Delay(m/s)

Average Delay(m/s)


8000 6000 4000 2000

8000 6000

4000 2000 0

0

10 20 30 40 50 60 70

10 20 30 40 50 60 70 Epidemic Rapid

Buffer (MB)

Buffer (MB) Epidemic Rapid

Random Waypoint


Gambar 4.28 Grafik perbandingan pada penambahan buffer terhadap average delay. Gambar 4.28 menunjukan bahwa terjadi peningkatan delay pada pergerakan random waypoint untuk kedua protokol, dimana protokol routing Epidemic memiliki delay yang lebih rendah dikarenakan protokol routing Epidemic yang selalu melakukan salinan pesan keseluruh jaringan sehingga pesan yang dikirim dapat sampai ke tujuan lebih cepat. Tetapi akibatnya penggunaan buffer yang besar (lihat grafik 4.7 dan 4.8). Sebaliknya pada pergerakan shortestpath map based protokol routing RAPID memiliki delay yang lebih baik dari pada protokol routing Epidemic hal ini dikarenakan protokol ini melakukan salinan dengan membandingkan utilitas pertemuan untuk perhitungan metrik meminimalkan average delay, dan adanya jalur untuk mencari jalur terpendek untuk mencapai tujuan.

60


c. Overhead Ratio Tabel 4.17 Hasil perbandingan penambahan buffer terhadap overhead ratio. Buffer

Overhead Ratio

(MB)

Random Waypoint


Epidemic

RAPID

Epidemic

10

79,0297

95,4684

26,223

69,9739

20

58,1488

88,6209

22,588

46,7663

30

50,4335

82,0576

22,163

38,226

40

45,0169

74,4644

22,606

35,0423

50

42,6134

73

22,352

33,5927

60

42,8325

68,2987

22,751

33,1633

70

42,4402

66,1537

22,779

32,5228

120

120

100

100 Overhead ratio

Overhead Ratio

RAPID

80 60 40

80 60 40 20

20

0

0 10 Epidemic Rapid

20

30

40

50

60

10

70

20

30

40

50

60

70

Buffer (MB)

Buffer (MB) Epidemic Rapid

Random Waypoint


Gambar 4.29 Grafik perbandingan pada penambahan buffer terhadap overhead ratio. Gambar 4.29 menunjukkan bahwa dengan penambahan buffer maka menurunkan overhead ratio untuk kedua protokol pada dua model pergerakan yang berbeda. Hal ini dikarenakan semakin banyak pesan yang dapat dibawa untuk disampaikan ke tujuan dan semakin kecil juga sebuah pesan di copy. Secara

61


umum overhead ratio protokol routing RAPID lebih rendah dari protokol routing Epidemic dilihat dari dua kondisi model pergerkan yang berbeda, hal ini karena cara kerja protokol routing RAPID yang tidak melakukan salinan keseluruh jaringan seperti

yang dilakukan protokol routing Epidemic melainkan

membandingkan utilitas sebelum melakukan salinan pesan, sehingga overhead ratio lebih rendah, terlebih lagi menggunakan pergerakan shortestpath map based yang mengurangi delay dengan bantuan bahwa fungsi prhitungan metrik bisa diterapkan. d. Message Drop Tabel 4.18 Hasil perbandingan penambahan buffer terhadap message drop. Buffer (MB)

Random Waypoint RAPID Epidemic 17642 22588 20554 31183 19584 33568 17917 33865 17215 34319 16930 33927 16727 33805

10 20 30 40 50 60 70

Message Drop ShortestPath Map Based Movement RAPID Epidemic 4807 37279 391 35483 1 33858 80 32980 6 32683 119 32213 10 32057

40000 40000

30000

# Messages Dropped

# Message Drop

35000

25000 20000 15000 10000

35000 30000 25000 20000 15000 10000

5000

5000

0

0

10 20 30 40 50 60 70

10 20 30 40 50 60 70 Epidemic

Buffer (MB)

Buffer (MB)

Epidemic

Rapid

Rapid

Random Waypoint

shortestpath map based

62


Gambar 4.30 Grafik perbandingan pada penambahan buffer terhadap message drop. Pada gambar 4.30 menunjukan bahwa dengan penambahan buffer maka mempengaruhi message yang di drop untuk kedua protokol. Secara umum pada kedua pergerakan protokol routing RAPID dengan message drop yang lebih redah karena sebelum melakukan salinan selalu membandingkan utilitas, terlebih lagi penggunaan TTL yang cukup (300 menit), dibandingkan dengan protokol routing Epidemic yang melakukan salinan ke seluruh jaringan dengan buffer terbatas.

63


BAB V KESIMPULAN DAN SARAN 5.1 Kesimpulan Dari hasil simulasi dan pengujian yang telah dilakukan maka dapat disimpulkan bahwa potokol routing RAPID lebih baik daripada Epidemic pada kondisi skrenario menggunakan pergerakan shortest path map based dengan melakukan variasi penambahan TTL, node dan buffer. Delivery probability potokol routing RAPID mengalami kenaikan lebih tinggi daripada potokol routing Epidemic, karena adanya algoritma minimizing missed deadlines dan minimizing average delay yang mampu menekan delay RAPID menjadi lebih kecil. Namun, protokol routing RAPID mengalami penurunan perfomance ketika diterapkan pada pergerakan random waypoint. 5.2 Saran Penelitian ini melakukan analisis unjuk kerja protokol routing RAPID untuk mengetahui kelebihan dan kekurangannya dengan menggunakan protokol routing Epidemic sebagai pembanding. Untuk pekerjaan selanjutkan dapat melakukan pengujian unjuk kerja RAPID dengan dua tau tiga protokol pembanding seperti Epidemic; Prophet.

64


DAFTAR PUSTAKA

[1]

Schiller, Jochen H., Mobile Communications, Great Britain 2000, Second Edition, 2003.

[2]

Aprillando, A. 2007. Cara Kerja dan Kinerja Protokol Optimized Link State Routing (OLSR) pada Mobile Ad hoc Network (MANET), Tugas Akhir. Jakarta: Fakultas Teknik Unika Atmajaya.

[3]

Mukti, Guido. 2012. Unjuk Kerja Protokol DSR pada Mobile Ad hoc Network dengan simulator NS 2, Tugas Akhir. Yogyakarta: Fakultas Sains Dan Teknologi Universitas Sanata Dharma.

[4]

S. Jain, K. Fall, and R. Patra. Routing in a Delay Tolerant Network. In Proc. ACM Sigcomm, pages 145–158, 2004.

[5]

H. S. Bindra, and A. L. Sangal. Performance Comparison of RAPID, Epidemic and Prophet Routing Protocols for Delay Tolerant Networks. International Journal of Computer Theory and Engineering Vol. 4, No. 2, April 2012.

[6]

A. Balasubramanian, B. N. Levine, and A. Venkataramani.DTN Routing as a Resource Allocation Problem. Technical Report 07-37, UMass Amherst, 2007.

[7]

A. Vahdat and D. Becker. Epidemic Routing for Partially-Connected Ad Hoc Networks. Department of Computer Science Duke University, Durham, 2000.

[8]

A. Keranen, “Opportunistic Network Environment Simulator. Special Assignment Report, Helsinki University of Technology,” Department of Communications and Networking, May 2008.

[9]

Tkk/Comnet. Project page of the ONE simulator. [Online]. Available: http://www.netlab.tkk.fi/tutkimus/dtn/theone, 2016.

65


LAMPIRAN A. Listing Program Listing Program RAPID /* * Copyright 2010 Institute of Telematics, Karlsruhe Institute of Technology (KIT) * Released under GPLv3. See LICENSE.txt for details. * Christoph P. Mayer - mayer[at]kit[dot]edu * Wolfgang Heetfeld * Version 0.1 - released 13. Oct 2010 */ package routing; import java.util.ArrayList; import java.util.Collection; import java.util.Collections; import java.util.Comparator; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.Map.Entry; import routing.RAPID.*; import util.Tuple; import core.*; public class RAPID extends ActiveRouter { private double timestamp; private DelayTable delayTable; private Map hostMapping; private final UtilityAlgorithm ALGORITHM = UtilityAlgorithm.AVERAGE_DELAY; private static final double INFINITY = 99999; public RAPID(Settings s) { super(s); delayTable = null; timestamp = 0.0; hostMapping = new HashMap(); } @Override public void init(DTNHost host, List<MessageListener> mListeners) { super.init(host, mListeners); delayTable = new DelayTable(super.getHost()); } protected RAPID(RAPID r) { super(r); delayTable = r.delayTable; timestamp = r.timestamp; hostMapping = r.hostMapping; } @Override public void changedConnection(Connection con) { if (con.isUp()) { timestamp = SimClock.getTime(); synchronizeDelayTables(con); synchronizeMeetingTimes(con); updateDelayTableStat(con); synchronizeAckedMessageIDs(con); deleteAckedMessages(); doHostMapping(con);

66


delayTable.dummyUpdateConnection(con); } else { double time = SimClock.getTime()timestamp; delayTable.updateConnection(con, time); synchronizeAckedMessageIDs(con); deleteAckedMessages(); updateAckedMessageIds(); synchronizeDelayTables(con); } } private void doHostMapping(Connection con) { DTNHost host = getHost(); DTNHost otherHost = con.getOtherNode(host); RAPID otherRouter = ((RAPID) otherHost.getRouter()); hostMapping.put(host.getAddress(), host); hostMapping.put(otherHost.getAddress(), otherHost); hostMapping.putAll(otherRouter.hostMapping); otherRouter.hostMapping.putAll(hostMapping); } private void updateDelayTableStat(Connection con) { DTNHost otherHost = con.getOtherNode(getHost()); RAPID otherRouter = ((RAPID) otherHost.getRouter()); int from = otherHost.getAddress(); for (Message m : getMessageCollection()) { int to = m.getTo().getAddress(); MeetingEntry entry = otherRouter.getDelayTable().getMeetingEntry(from, to); if (entry != null) { delayTable.getDelayEntryByMessageId(m.getId()).setChan ged(true); } } } private void synchronizeDelayTables(Connection con) { DTNHost otherHost = con.getOtherNode(getHost()); RAPID otherRouter = (RAPID) otherHost.getRouter(); DelayEntry delayEntry = null; DelayEntry otherDelayEntry = null; for (Entry<String, DelayEntry> entry1 : delayTable.getDelayEntries()) { Message m = entry1.getValue().getMessage(); delayEntry = delayTable.getDelayEntryByMessageId(m.getId()); assert(delayEntry != null); otherDelayEntry = otherRouter.delayTable.getDelayEntryByMessageId(m.getId()); if (delayEntry.getDelays() == null) continue; for (Entry> entry : delayEntry.getDelays()) { DTNHost myHost = entry.getKey();

67


Double myDelay = entry.getValue().getKey(); Double myTime = entry.getValue().getValue(); if ((otherDelayEntry == null) || (!otherDelayEntry.contains(myHost))) { otherRouter.updateDelayTableEntry(m, myHost, myDelay, myTime); } else { if (otherDelayEntry.isOlderThan(myHost, delayEntry.getLastUpdate(myHost))) { otherRouter.updateDelayTableEntry(m, myHost, myDelay, myTime); } if ((otherDelayEntry.isAsOldAs(myHost, delayEntry.getLastUpdate(myHost))) && (delayEntry.getDelayOf(myHost) > otherDelayEntry.getDelayOf(myHost))) { otherRouter.updateDelayTableEntry(m, myHost, myDelay, myTime); } } } } } private void synchronizeMeetingTimes(Connection con) { DTNHost otherHost = con.getOtherNode(getHost()); RAPID otherRouter = (RAPID) otherHost.getRouter(); MeetingEntry meetingEntry = null; MeetingEntry otherMeetingEntry = null; for (int i = 0; i < delayTable.getMeetingMatrixDimension(); i++) { for (int k = 0; k < delayTable.getMeetingMatrixDimension(); k++) { meetingEntry = delayTable.getMeetingEntry(i, k); if (meetingEntry != null) { otherMeetingEntry = otherRouter.delayTable.getMeetingEntry(i, k); if (otherMeetingEntry == null){ otherRouter.delayTable.setAvgMeetingTime(i, k, meetingEntry.getAvgMeetingTime(), meetingEntry.getLastUpdate(), meetingEntry.getWeight()); } else { if (otherMeetingEntry.isOlderThan(meetingEntry.getLastUpdate()) ) { otherRouter.delayTable.setAvgMeetingTime(i, k, meetingEntry.getAvgMeetingTime(), meetingEntry.getLastUpdate(), meetingEntry.getWeight()); }

68


if ((otherMeetingEntry.isAsOldAs (meetingEntry.getLastUpdate())) && (meetingEntry.getAvgMeetingTime() > otherMeetingEntry.getAvgMeetingTime())) { otherRouter.delayTable.setAvgMeetingTime(i, k, meetingEntry.getAvgMeetingTime(), meetingEntry.getLastUpdate(), meetingEntry.getWeight()); } } } } } } private void synchronizeAckedMessageIDs(Connection con) { DTNHost otherHost = con.getOtherNode(getHost()); RAPID otherRouter = (RAPID) otherHost.getRouter(); delayTable.addAllAckedMessageIds(otherRouter.delayTabl e.getAllAckedMessageIds()); otherRouter.delayTable.addAllAckedMessageIds(delayTabl e.getAllAckedMessageIds()); assert(delayTable.getAllAckedMessageIds().equals(other Router.delayTable.getAllAckedMessageIds())); } private void deleteAckedMessages() { for (String id : delayTable.getAllAckedMessageIds()) { if (this.hasMessage(id) && !isSending(id)) { this.deleteMessage(id, false); } if (delayTable.getDelayEntryByMessageId(id) != null) assert(delayTable.removeEntry(id)==true); } } @Override public Message messageTransferred(String id, DTNHost from) { Message m = super.messageTransferred(id, from); if (isDeliveredMessage(m)) { delayTable.addAckedMessageIds(id); } return m; } private void updateAckedMessageIds() { ArrayList<String> removableIds=new ArrayList<String>(); for (String id : delayTable.getAllAckedMessageIds()) { Message m = this.getMessage(id); if ((m != null) && (m.getTtl() <= 0)) removableIds.add(id); }

69


if (removableIds.size() > 0) delayTable.removeAllAckedMessageIds(removableIds); } public void updateDelayTableEntry(Message m, DTNHost host, double delay, double time) { DelayEntry delayEntry; if ((delayEntry = delayTable.getDelayEntryByMessageId(m.getId())) == null) { delayEntry = new DelayEntry(m); delayTable.addEntry(delayEntry); } assert((delayEntry != null) && (delayTable.getDelayEntryByMessageId(m.getId()) != null)); if (delayEntry.contains(host)) { delayEntry.setHostDelay(host, delay, time); } else { delayEntry.addHostDelay(host, delay, time); } } @Override public boolean createNewMessage(Message m) { boolean stat = super.createNewMessage(m); if (stat) { updateDelayTableEntry(m, getHost(), estimateDelay(m, getHost(), true), SimClock.getTime()); } return stat; } @Override public int receiveMessage(Message m, DTNHost from) { int stat = super.receiveMessage(m, from); if (stat == 0) { DTNHost host = getHost(); double time = SimClock.getTime(); double delay = estimateDelay(m, host, true); updateDelayTableEntry(m, host, delay, time); ((RAPID) from.getRouter()).updateDelayTableEntry(m, host, delay, time); } return stat; } private double getMarginalUtility(Message msg, Connection con, DTNHost host) { final RAPID otherRouter = (RAPID) (con.getOtherNode(host).getRouter()); return getMarginalUtility(msg, otherRouter, host); } private double getMarginalUtility(Message msg, RAPID router, DTNHost host) { double marginalUtility = 0.0; double utility = 0.0;

70


double utilityOld = 0.0; assert(this!=router); utility = router.computeUtility(msg, host, true); utilityOld = this.computeUtility(msg, host, true); if ((utilityOld == -INFINITY) && (utility != INFINITY)) marginalUtility = (Math.abs(utility) / msg.getSize()); else if ((utility == -INFINITY) && (utilityOld != -INFINITY)) marginalUtility = (Math.abs(utilityOld) / msg.getSize()); else if ((utility == utilityOld) && (utility != -INFINITY)) marginalUtility = (Math.abs(utility) / msg.getSize()); else marginalUtility = (utility - utilityOld) / msg.getSize(); return marginalUtility; } private double computeUtility(Message msg, DTNHost host, boolean recompute) { double utility = 0.0; double packetDelay = 0.0; switch (ALGORITHM) { case AVERAGE_DELAY: { packetDelay = estimateDelay(msg, host, recompute); utility = -packetDelay; break; } case MISSED_DEADLINES: { double lifeTime = msg.getTtl() * 60; double timeSinceCreation = SimClock.getTime() - msg.getCreationTime(); double remainingTime = computeRemainingTime(msg); if (lifeTime > timeSinceCreation) { if (remainingTime < lifeTime timeSinceCreation) utility = lifeTime - timeSinceCreation remainingTime; else utility = 0; } else utility = 0; packetDelay = computePacketDelay(msg, host, remainingTime); break; } case MAXIMUM_DELAY: { packetDelay = estimateDelay(msg, host, recompute); Collection<Message> msgCollection = getMessageCollection(); for (Message m : msgCollection) { if (m.equals(msg)) continue; if (packetDelay < estimateDelay(m, host, recompute)) { packetDelay = 0; break; } } utility = -packetDelay;

71


break; } default: } return utility; } private double estimateDelay(Message msg, DTNHost host, boolean recompute) { double remainingTime = 0.0; double packetDelay = 0.0; if ((recompute) && ((delayTable.delayHasChanged(msg.getId())) || (delayTable.getDelayEntryByMessageId(msg.getId()).getDelayOf (host) == null))) { remainingTime = computeRemainingTime(msg); packetDelay = Math.min(INFINITY, computePacketDelay(msg, host, remainingTime)); updateDelayTableEntry(msg, host, packetDelay, SimClock.getTime()); } else packetDelay = delayTable.getDelayEntryByMessageId(msg.getId()).getDelayOf( host); return packetDelay; } private double computeRemainingTime(Message msg) { double transferTime = INFINITY; double remainingTime = 0.0; remainingTime = computeTransferTime(msg, msg.getTo()); if (delayTable.getDelayEntryByMessageId(msg.getId()) != null) { for (Entry> entry : delayTable.getDelayEntryByMessageId(msg.getId()).getDelays() ) { DTNHost host = entry.getKey(); if (host == getHost()) continue; transferTime = ((RAPID) host.getRouter()).computeTransferTime(msg, msg.getTo()); remainingTime = Math.min(transferTime, remainingTime); } } return remainingTime; } private double computeTransferTime(Message msg, DTNHost host) { Collection<Message> msgCollection = getMessageCollection(); double transferOpportunity = 0; double packetsSize = 0.0; double transferTime = INFINITY; double meetingTime = 0.0; for (Message m : msgCollection) { if (m.equals(msg)) continue; //skip packetsSize = packetsSize + m.getSize();

72


} transferOpportunity = delayTable.getAvgTransferOpportunity(); MeetingEntry entry = delayTable.getIndirectMeetingEntry(this.getHost().getAddress (), host.getAddress()); if (entry == null) transferTime = INFINITY; else { meetingTime = entry.getAvgMeetingTime(); transferTime = meetingTime * Math.ceil(packetsSize / transferOpportunity); } return transferTime; } private double computePacketDelay(Message msg, DTNHost host, double remainingTime) { double timeSinceCreation = 0.0; double expectedRemainingTime = 0.0; double packetDelay = 0.0; expectedRemainingTime = remainingTime; timeSinceCreation = SimClock.getTime() msg.getCreationTime(); packetDelay = timeSinceCreation + expectedRemainingTime; return packetDelay; } @Override public void update() { super.update(); if (isTransferring() || !canStartTransfer()) { return; } if (exchangeDeliverableMessages() != null) { return; } if (tryOtherMessages() != null) { return; } } private Tuple, Double> tryOtherMessages() { List, Double>> messages = new ArrayList, Double>>(); Collection<Message> msgCollection = getMessageCollection(); for (Connection con : getConnections()) { DTNHost other = con.getOtherNode(getHost()); RAPID otherRouter = (RAPID) other.getRouter(); if (otherRouter.isTransferring()) { continue; } double mu=0.0; for (Message m : msgCollection) {

73


if (otherRouter.hasMessage(m.getId())) { continue; } mu=getMarginalUtility(m, con, getHost()); if ((mu) <= 0) { continue; } Tuple<Message, Connection> t1=new Tuple<Message, Connection>(m, con); Tuple, Double> t2=new Tuple, Double>(t1, mu); messages.add(t2); } } delayTable.setChanged(false); if (messages == null) return null; Collections.sort(messages, new TupleComparator1()); return tryTupleMessagesForConnected(messages); } private Tuple, Double> tryTupleMessagesForConnected( List, Double>> tuples) { if (tuples.size() == 0) { return null; } for (Tuple, Double> t : tuples) { Message m = (t.getKey()).getKey(); Connection con = (t.getKey()).getValue(); if (startTransfer(m, con) == RCV_OK) { return t; } } return null; } public DelayTable getDelayTable() { return delayTable; } @Override public RAPID replicate() { return new RAPID(this); } private class TupleComparator1 implements Comparator, Double>> { public int compare(Tuple, Double> tuple1, Tuple, Double> tuple2) { double mu1 = tuple1.getValue(); double mu2 = tuple2.getValue(); if (mu2-mu1 == 0) { return compareByQueueMode((tuple1.getKey()).getKey(), (tuple2.getKey()).getKey()); }

74


else if (mu2-mu1 < 0) { return -1; } else { return 1; } } } private enum UtilityAlgorithm { AVERAGE_DELAY, MISSED_DEADLINES, MAXIMUM_DELAY; } public Map getHostMapping() { return hostMapping; } public double getMeetingProb(DTNHost host) { MeetingEntry entry = delayTable.getIndirectMeetingEntry(getHost().getAddress(), host.getAddress()); if (entry != null) { double prob = (entry.getAvgMeetingTime() * entry.getWeight()) / SimClock.getTime(); return prob; } return 0.0; } }

Kelas DelayEntri.Java /* * Copyright 2010 Institute of Telematics, Karlsruhe Institute of Technology (KIT) * Released under GPLv3. See LICENSE.txt for details. * Christoph P. Mayer - mayer[at]kit[dot]edu * Wolfgang Heetfeld * Version 0.1 - released 13. Oct 2010 */ package routing.RAPID; import java.util.HashMap; import java.util.Set; import java.util.Map.Entry; import core.DTNHost; import core.Message; import core.SimClock; import util.Tuple; public class DelayEntry { private Message msg = null; //HashMap> private HashMap> delays = null; private boolean changed; public DelayEntry(Message msg) { this.msg = msg;

75


this.delays = new HashMap>(); this.changed = false; } public void addHostDelay(DTNHost host, double delay, double time) { assert(!delays.containsKey(host)); delays.put(host, new Tuple(delay, time)); changed = true; } public void addHostDelay(DTNHost host, double delay) { addHostDelay(host, delay, SimClock.getTime()); } public void setHostDelay(DTNHost host, double delay, double time) { assert(delays.containsKey(host)); delays.put(host, new Tuple(delay, time)); changed = true; } public void removeHostDelay(DTNHost host) { delays.remove(host); changed = true; } public Message getMessage() { return msg; } public Set<Entry>> getDelays() { return delays.entrySet(); } public Double getDelayOf(DTNHost host) { if (delays.get(host) == null) return null; return delays.get(host).getKey(); } public boolean isOlderThan(DTNHost host, double time) { if (!contains(host)) return true; return (getLastUpdate(host) < time); } public boolean isAsOldAs(DTNHost host, double time) { if (!contains(host)) return false; return (getLastUpdate(host) == time); } public boolean contains(DTNHost host) { return (getDelayOf(host) != null); } public Double getLastUpdate(DTNHost host) { if (!contains(host)) return null; return (delays.get(host).getValue()); } public void setChanged(boolean changed) { this.changed = changed; } public boolean hasChanged() { return changed;

76


} @Override public boolean equals(Object o) { if (o instanceof DelayEntry) { DelayEntry entry = (DelayEntry) o; boolean status = ((this.msg.compareTo(entry.msg) == 0) && (equalsCheck(entry.delays))); return status; } return false; } private boolean equalsCheck(HashMap> map) { for (Entry> entry : this.getDelays()) { Tuple t = map.get(entry.getKey()); if (t == null) return false; if (!t.getKey().equals(entry.getValue().getKey())) return false; if (!t.getValue().equals(entry.getValue().getValue())) return false; } return true; } public void print() { //Entry> for (Entry> entry : getDelays()) { System.out.println(msg+" \t\t"+entry.getKey()+"\t\t\t"+entry.getValue().getKey()+"\t\ t\t\t"+entry.getValue().getValue()); } } }

Kelas DelayTable.Java /* * Copyright 2010 Institute of Telematics, Karlsruhe Institute of Technology (KIT) * Released under GPLv3. See LICENSE.txt for details. * Christoph P. Mayer - mayer[at]kit[dot]edu * Wolfgang Heetfeld * Version 0.1 - released 13. Oct 2010 */ package routing.RAPID; import java.util.Collection; import java.util.HashMap; import java.util.HashSet; import java.util.Map; import java.util.Set; import applications.PlatoonConfiguration; import java.util.Map.Entry;

77


import import import import

routing.RAPID; core.Connection; core.DTNHost; core.SimClock;

public class DelayTable { private int transferCounter; private double avgTransferOpportunity; private int MATRIX_DIMENSION = 0; private DTNHost host; private HashMap<String, DelayEntry> delayTable; private MeetingEntry[][] meetingEntry; private Set<String> ackedMessageIds; public DelayTable(DTNHost host, int matrixDim) { init(host, matrixDim); } public DelayTable(DTNHost host) { init(host, 5); } private void init(DTNHost host, int matrixDim) { this.host = host; int transmitSpeed = host.getInterfaces().get(0).getTransmitSpeed(); double transmitRange = host.getInterfaces().get(0).getTransmitRange(); double movementSpeed = host.getMovementModel().getAvgSpeed(); double transmitTime = movementSpeed / transmitRange; this.MATRIX_DIMENSION = 0; delayTable = new HashMap<String, DelayEntry>(); meetingEntry = new MeetingEntry[MATRIX_DIMENSION][MATRIX_DIMENSION]; recomputeMatrix(matrixDim); transferCounter = 1; if ((transmitTime==0) || (transmitSpeed==0)) avgTransferOpportunity = 1; else avgTransferOpportunity = (int) (transmitTime * transmitSpeed); ackedMessageIds = new HashSet<String>(); } public void addEntry(DelayEntry entry) { delayTable.put(entry.getMessage().getId(), entry); } public void removeEntry(DelayEntry entry) { removeEntry(entry.getMessage().getId()); } public boolean removeEntry(String id) { return (delayTable.remove(id)!=null); } public DelayEntry getDelayEntryByMessageId(String id) { return delayTable.get(id); } public Set<Entry<String, DelayEntry>> getDelayEntries() { return delayTable.entrySet(); } public void dummyUpdateConnection(Connection con) { final double DUMMY_AVG_MEETING_TIME = 1.0;

78


updateAvgMeetingTime(host.getAddress(), con.getOtherNode(host).getAddress(), DUMMY_AVG_MEETING_TIME, SimClock.getTime(), true); } public void updateConnection(Connection con, double meetingTime) { updateAvgTransferOpportunity(con.getTotalBytesTransferred()) ; updateAvgMeetingTime(host.getAddress(), con.getOtherNode(host).getAddress(), meetingTime); transferCounter++; } public void updateAvgMeetingTime(int from, int to, double meetingTime) { updateAvgMeetingTime(from, to, meetingTime, SimClock.getTime()); } public void setAvgMeetingTime(int from, int to, double meetingTime, double timestamp, int weight) { if ((from >= MATRIX_DIMENSION) || (to >= MATRIX_DIMENSION)) recomputeMatrix(Math.max(from, to)+1); if (meetingEntry[from][to] == null) meetingEntry[from][to] = new MeetingEntry(meetingTime, timestamp); else meetingEntry[from][to].set(meetingTime, timestamp, weight); if (meetingEntry[to][from] == null) meetingEntry[to][from] = new MeetingEntry(meetingTime, timestamp); else meetingEntry[to][from].set(meetingTime, timestamp, weight); } public void updateAvgMeetingTime(int from, int to, double meetingTime, double timestamp) { updateAvgMeetingTime(from, to, meetingTime, timestamp, false); } public void updateAvgMeetingTime(int from, int to, double meetingTime, double timestamp, boolean dummy) { if ((from >= MATRIX_DIMENSION) || (to >= MATRIX_DIMENSION)) recomputeMatrix(Math.max(from, to)+1); if (dummy) { if (meetingEntry[from][to] != null) return; assert (meetingEntry[to][from] == null); meetingEntry[from][to] = new MeetingEntry(meetingTime, timestamp, 0, true); meetingEntry[to][from] = new MeetingEntry(meetingTime, timestamp, 0, true); } else { //create or update entry [from][to] if ((meetingEntry[from][to] == null) || (meetingEntry[from][to].isDummy())) meetingEntry[from][to] = new MeetingEntry(meetingTime, timestamp);

79


else meetingEntry[from][to].update(meetingTime, timestamp); //create or update entry [to][from] if ((meetingEntry[to][from] == null) || (meetingEntry[to][from].isDummy())) meetingEntry[to][from] = new MeetingEntry(meetingTime, timestamp); else meetingEntry[to][from].update(meetingTime, timestamp); } } public int getMeetingMatrixDimension() { return MATRIX_DIMENSION; } public Map getMeetingMap(int from) { HashMap map = new HashMap(); RAPID r = ((RAPID) host.getRouter()); for (int i = 0; i < MATRIX_DIMENSION; i++) { MeetingEntry entry = getIndirectMeetingEntry(from, i); if (entry != null) { assert(r.getHostMapping().containsKey(i)); DTNHost host = r.getHostMapping().get(i); map.put(host, r.getMeetingProb(host)); } } return map; } public int getMeetingCount(int from) { int count = 0; for (int i = 0; i < MATRIX_DIMENSION; i++) { MeetingEntry entry = getMeetingEntry(from, i); if (entry != null) count = count + entry.getWeight(); } return count; } public MeetingEntry getMeetingEntry(int from, int to) { if ((from >= MATRIX_DIMENSION) || (to >= MATRIX_DIMENSION)) return null; return meetingEntry[from][to]; } public MeetingEntry getIndirectMeetingEntry(int from, int to) { MeetingEntry entry = getMeetingEntry(from, to); if (entry != null) return entry; //find an indirect meeting entry (3 hops) if one exists else { MeetingEntry maxEntry = new MeetingEntry(-1, 0); MeetingEntry entry0; MeetingEntry entry1; MeetingEntry entry2; for (int i=0; i<MATRIX_DIMENSION; i++) { if (hasMet(from, i) /*|| hasMeeting(from, i)*/) { //find 2 hop neighbor

80


if (hasMet(i, to) /*|| hasMeeting(i, to)*/) { entry0 = getMeetingEntry(from, i); entry1 = getMeetingEntry(i, to); entry = createMeetingEntry(entry0, entry1); if ((entry.getAvgMeetingTime()*entry.getWeight()) > (maxEntry.getAvgMeetingTime()*maxEntry.getWeight())) { maxEntry = new MeetingEntry(entry); } } //find 3 hop neighbor else { for (int k=0; k<MATRIX_DIMENSION; k++) { if (hasMet(i, k) /*|| hasMeeting(i, k)*/) { if (hasMet(k, to) /*|| hasMeeting(k, to)*/) { entry0 = getMeetingEntry(from, i); entry1 = getMeetingEntry(i, k); entry2 = getMeetingEntry(k, to); entry = createMeetingEntry(entry0, entry1, entry2); if ((entry.getAvgMeetingTime()*entry.getWeight()) > (maxEntry.getAvgMeetingTime()*maxEntry.getWeight())) { maxEntry = new MeetingEntry(entry); } } } } } } } if ((maxEntry.getAvgMeetingTime()*maxEntry.getWeight()) > -1) return maxEntry; } return null; } (to<MATRIX_DIMENSION)) { private boolean hasMet(int from, int to) { if ((from >= MATRIX_DIMENSION) || (to >= MATRIX_DIMENSION)) return false; return (meetingEntry[from][to]!=null); } private double getMinimum(double[] values) { if ((values == null) || (values.length == 0)) return 1; double min = values[0]; for (int i = 1; i < values.length; i++) { min = Math.min(min, values[i]); } return min; } private int getMinimum(int[] values) {

81


if ((values == null) || (values.length == 0)) return 1; int min = values[0]; for (int i = 1; i < values.length; i++) { min = Math.min(min, values[i]); } return min; } private MeetingEntry createMeetingEntry(MeetingEntry ... entries) { if ((entries == null) || (entries.length == 0)) return null; double[] meetingTimes = new double[entries.length]; double[] meetingUpdates = new double[entries.length];; int[] meetingWeights = new int[entries.length];; for (int i = 0; i < entries.length; i++) { meetingTimes[i] = entries[i].getAvgMeetingTime(); meetingUpdates[i] = entries[i].getLastUpdate(); meetingWeights[i] = entries[i].getWeight(); } return (new MeetingEntry(getMinimum(meetingTimes), getMinimum(meetingUpdates), getMinimum(meetingWeights), false)); } private void recomputeMatrix(int dimension) { assert (dimension >= MATRIX_DIMENSION); //create matrix of new dimension MeetingEntry[][] entry = new MeetingEntry[dimension][dimension]; //copy old entries into new matrix for (int i = 0; i < MATRIX_DIMENSION; i++) { for (int k = 0; k < MATRIX_DIMENSION; k++) { entry[i][k] = meetingEntry[i][k]; } } //initialize new entries with 'null' for (int i = MATRIX_DIMENSION; i < dimension; i++) { for (int k = MATRIX_DIMENSION; k < dimension; k++) { entry[i][k] = null; } } MATRIX_DIMENSION = dimension; meetingEntry = entry; } private void updateAvgTransferOpportunity(int transferOpportunity) { this.avgTransferOpportunity = (((transferCounter * this.avgTransferOpportunity) + transferOpportunity) / (transferCounter + 1)); } public double getAvgTransferOpportunity() { return Math.max(avgTransferOpportunity, 0.0000001); } public void addAllAckedMessageIds(Collection<String> ackedMessageIds) {

82


this.ackedMessageIds.addAll(ackedMessageIds); } public Collection<String> getAllAckedMessageIds() { return ackedMessageIds; } public void addAckedMessageIds(String ackedMessageId) { this.ackedMessageIds.add(ackedMessageId); } public void removeAllAckedMessageIds(Collection<String> ackedMessageIds) { this.ackedMessageIds.removeAll(ackedMessageIds); } public void setChanged(boolean changed) { for (Entry<String, DelayEntry> entry : getDelayEntries()) { entry.getValue().setChanged(changed); } } public boolean delayHasChanged(String id) { DelayEntry entry = getDelayEntryByMessageId(id); if (entry == null) return true; return entry.hasChanged(); } public void printDelays() { System.out.println("delay table of DTNHost: "+host); System.out.println("Message\t\t\tDTNHost\t\t\tdelay value\t\t\tlast update time"); for (Entry<String, DelayEntry> entry : getDelayEntries()) { entry.getValue().print(); } } public void printMeetings() { System.out.println("meeting table of DTNHost: "+host); System.out.println("DTNHost Address\t\t\ttimestamp\t\t\taverage meeting time"); int from = host.getAddress(); for (int i = 0; i < getMeetingMatrixDimension(); i++) { if (from != i) { if (getMeetingEntry(from, i) !=null) { System.out.print(i+"\t\t\t\t"); getMeetingEntry(from, i).print(); } else System.out.println(i+"\t\t\t\tnull\t\t\t\tnull"); } } } public void printAckedMessageIds() { System.out.println("acked message ids of DTNHost: "+host); System.out.println("acked message ids"); for (String msgIds : getAllAckedMessageIds()) { System.out.println(msgIds); }

83


} }

Kelas MeetingEntri.Java /* * Copyright 2010 Institute of Telematics, Karlsruhe Institute of Technology (KIT) * Released under GPLv3. See LICENSE.txt for details. * * Christoph P. Mayer - mayer[at]kit[dot]edu * Wolfgang Heetfeld * * Version 0.1 - released 13. Oct 2010 */ package routing.RAPID; import core.SimClock; public class MeetingEntry { private double timestamp; private int weight; private double avgMeetingTime; private boolean dummy; public MeetingEntry(double meetingTime) { this.weight = 0; this.timestamp = 0; this.avgMeetingTime = 0; this.dummy = false; update(meetingTime, SimClock.getTime()); } public MeetingEntry(double meetingTime, double timestamp) { this.weight = 0; this.timestamp = 0; this.avgMeetingTime = 0; this.dummy = false; update(meetingTime, timestamp); } public MeetingEntry(double meetingTime, double timestamp, int weight, boolean dummy) { this.avgMeetingTime = meetingTime; this.timestamp = timestamp; this.weight = weight; this.dummy = dummy; } public MeetingEntry(MeetingEntry entry) { this.avgMeetingTime = entry.avgMeetingTime; this.timestamp = entry.timestamp; this.weight = entry.weight; this.dummy = entry.dummy; } public void set(double meetingTime, double timestamp, int weight) { this.weight = weight; this.timestamp = timestamp; this.avgMeetingTime = meetingTime; }

84


public void update(double meetingTime, double timestamp) { avgMeetingTime = (((weight * avgMeetingTime) + meetingTime) / (weight + 1)); weight++; this.timestamp = timestamp; } public boolean isOlderThan(double time) { return (timestamp < time); } public boolean isAsOldAs(double time) { return (timestamp == time); } public double getAvgMeetingTime() { return avgMeetingTime; } public Double getLastUpdate() { return timestamp; } @Override public boolean equals(Object o) { if (o instanceof MeetingEntry) { MeetingEntry entry = (MeetingEntry) o; return ((this.avgMeetingTime == entry.avgMeetingTime) && (this.timestamp == entry.timestamp)); } return false; } public int getWeight() { return weight; } public boolean isDummy() { return dummy; } public void print() { System.out.println(timestamp+"\t\t\t\t"+avgMeetingTime); } }

Listing Program Epidemic EpidemicRouter.Java /* * Copyright 2010 Aalto University, ComNet * Released under GPLv3. See LICENSE.txt for details. */ package routing; import core.Settings; public class EpidemicRouter extends ActiveRouter { public EpidemicRouter(Settings s) { super(s); //TODO: read&use epidemic router specific settings (if any) } protected EpidemicRouter(EpidemicRouter r) { super(r);

85


//TODO: copy epidemic settings here (if any) } @Override public void update() { super.update(); if (isTransferring() || !canStartTransfer()) { return; // transferring, don't try other connections yet } // Try first the messages that can be delivered to final recipient if (exchangeDeliverableMessages() != null) { return; // started a transfer, don't try others (yet) } // then try any/all message to any/all connection this.tryAllMessagesToAllConnections(); } @Override public EpidemicRouter replicate() { return new EpidemicRouter(this); } }

B. Skenario Skenario Model Pergerakan ShortestPathMapBasedMovement Penambahan TTL ## Scenario settings Scenario.name = SkenarioPenambahanTTL Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups Scenario.nrofHostGroups = 1 # Common settings for all groups Group.movementModel = ShortestPathMapBasedMovement

86


Group.router = [RAPID; EpidemicRouter] Group.bufferSize = 70M Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = [60; 120; 180; 240; 300; 360; 420; 480] Group.routeFile = data/roads.wkt Group.nrofHosts = 126 ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 125,125 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =

data/roads.wkt data/main_roads.wkt data/pedestrian_paths.wkt data/shops.wkt

## Reports - all report names have to be valid report classes # how many reports to load Report.nrofReports = 2 # length of the warm up period (simulated seconds) Report.warmup = 0

87


# default directory of reports (can be overridden per Report with output setting) Report.reportDir = reports/Skenario_1_RAPID # Report classes to load Report.report1 = MessageStatsReport Report.report2 = BufferOccupancyReport ## Default settings for some routers settings ProphetRouter.secondsInTimeUnit = 30 SprayAndWaitRouter.nrofCopies = 6 SprayAndWaitRouter.binaryMode = true ## Optimization settings -- these affect the speed of the simulation ## see World class for details. Optimization.cellSizeMult = 5 Optimization.randomizeUpdateOrder = true ## GUI settings # GUI underlay image settings GUI.UnderlayImage.fileName = data/helsinki_underlay.png # Image offset in pixels (x, y) GUI.UnderlayImage.offset = 64, 20 # Scaling factor for the image GUI.UnderlayImage.scale = 4.75 # Image rotation (radians) GUI.UnderlayImage.rotate = -0.015 # how many events to show in the log panel (default = 30) GUI.EventLogPanel.nrofEvents = 100 # Regular Expression log filter (see Pattern-class from the Java API for RE-matching details) #GUI.EventLogPanel.REfilter = .*p[1-9]<->p[1-9]$

Penambahan Node ## Scenario settings Scenario.name = SkenarioPenambahanNode Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups Scenario.nrofHostGroups = 1 # Common settings for all groups

88


Group.movementModel = ShortestPathMapBasedMovement Group.router = [RAPID; EpidemicRouter] Group.bufferSize = 70M Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = 300 Group.routeFile = data/roads.wkt Group.nrofHosts = [50; 75; 100; 125; 150] ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 49,49 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =



89



Penambahan Buffer ## Scenario settings Scenario.name = SkenarioPenambahanBuffer Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups Scenario.nrofHostGroups = 1 # Common settings for all groups

90


Group.movementModel = ShortestPathMapBasedMovement Group.router = [RAPID; EpidemicRouter] Group.bufferSize = [10; 20; 30; 40; 50; 60; 70] Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = 300 Group.routeFile = data/roads.wkt Group.nrofHosts = 126 ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 125,125 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =



91



Skenario Model Pergerakan Random Waypoint Penambahan TTL ## Scenario settings Scenario.name = SkenarioPenambahanTTL Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups Scenario.nrofHostGroups = 1

92


# Common settings for all groups Group.movementModel = Random Waypoint Group.router = [RAPID; EpidemicRouter] Group.bufferSize = 70M Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = [60; 120; 180; 240; 300; 360; 420; 480] Group.routeFile = data/roads.wkt Group.nrofHosts = 126 ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 125,125 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =


## Reports - all report names have to be valid report classes # how many reports to load Report.nrofReports = 2

93


# length of the warm up period (simulated seconds) Report.warmup = 0 # default directory of reports (can be overridden per Report with output setting) Report.reportDir = reports/Skenario_1_RAPID # Report classes to load Report.report1 = MessageStatsReport Report.report2 = BufferOccupancyReport ## Default settings for some routers settings ProphetRouter.secondsInTimeUnit = 30 SprayAndWaitRouter.nrofCopies = 6 SprayAndWaitRouter.binaryMode = true ## Optimization settings -- these affect the speed of the simulation ## see World class for details. Optimization.cellSizeMult = 5 Optimization.randomizeUpdateOrder = true ## GUI settings # GUI underlay image settings GUI.UnderlayImage.fileName = data/helsinki_underlay.png # Image offset in pixels (x, y) GUI.UnderlayImage.offset = 64, 20 # Scaling factor for the image GUI.UnderlayImage.scale = 4.75 # Image rotation (radians) GUI.UnderlayImage.rotate = -0.015 # how many events to show in the log panel (default = 30) GUI.EventLogPanel.nrofEvents = 100 # Regular Expression log filter (see Pattern-class from the Java API for RE-matching details) #GUI.EventLogPanel.REfilter = .*p[1-9]<->p[1-9]$

Penambahan Node ## Scenario settings Scenario.name = SkenarioPenambahanNode Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups

94


Scenario.nrofHostGroups = 1 # Common settings for all groups Group.movementModel = Random Waypoint Group.router = [RAPID; EpidemicRouter] Group.bufferSize = 70M Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = 300 Group.routeFile = data/roads.wkt Group.nrofHosts = [50; 75; 100; 125; 150] ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 49,49 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =


## Reports - all report names have to be valid report classes # how many reports to load

95


Report.nrofReports = 2 # length of the warm up period (simulated seconds) Report.warmup = 0 # default directory of reports (can be overridden per Report with output setting) Report.reportDir = reports/Skenario_1_RAPID # Report classes to load Report.report1 = MessageStatsReport Report.report2 = BufferOccupancyReport ## Default settings for some routers settings ProphetRouter.secondsInTimeUnit = 30 SprayAndWaitRouter.nrofCopies = 6 SprayAndWaitRouter.binaryMode = true ## Optimization settings -- these affect the speed of the simulation ## see World class for details. Optimization.cellSizeMult = 5 Optimization.randomizeUpdateOrder = true ## GUI settings # GUI underlay image settings GUI.UnderlayImage.fileName = data/helsinki_underlay.png # Image offset in pixels (x, y) GUI.UnderlayImage.offset = 64, 20 # Scaling factor for the image GUI.UnderlayImage.scale = 4.75 # Image rotation (radians) GUI.UnderlayImage.rotate = -0.015 # how many events to show in the log panel (default = 30) GUI.EventLogPanel.nrofEvents = 100 # Regular Expression log filter (see Pattern-class from the Java API for RE-matching details) #GUI.EventLogPanel.REfilter = .*p[1-9]<->p[1-9]$

Penambahan Buffer ## Scenario settings Scenario.name = SkenarioPenambahanBuffer Scenario.simulateConnections = true Scenario.updateInterval = 0.1 # 43200s == 12h Scenario.endTime = 43200 # "Bluetooth" interface for all nodes btInterface.type = SimpleBroadcastInterface # Transmit speed of 2 Mbps = 250kBps btInterface.transmitSpeed = 250k btInterface.transmitRange = 10 # High speed, long range, interface for group 4 highspeedInterface.type = SimpleBroadcastInterface highspeedInterface.transmitSpeed = 10M highspeedInterface.transmitRange = 1000 # Define 6 different node groups

96


Scenario.nrofHostGroups = 1 # Common settings for all groups Group.movementModel = Random Waypoint Group.router = [RAPID; EpidemicRouter] Group.bufferSize = [10; 20; 30; 40; 50; 60; 70] Group.waitTime = 0, 120 # All nodes have the bluetooth interface Group.nrofInterfaces = 1 Group.interface1 = btInterface # Walking speeds Group.speed = 1.9, 3.9 # Message TTL of 300 minutes (5 hours) Group.msgTtl = 300 Group.routeFile = data/roads.wkt Group.nrofHosts = 126 ## Message creation parameters # How many event generators Events.nrof = 1 # Class of the first event generator Events1.class = MessageEventGenerator # (following settings are specific for the MessageEventGenerator class) # Creation interval in seconds (one new message every 25 to 35 seconds) Events1.interval = 25, 35 # Message sizes (500kB - 1MB) Events1.size = 500k,1M # range of message source/destination addresses Events1.hosts = 0,0 Events1.tohosts = 125,125 # Message ID prefix Events1.prefix = M ## Movement model settings # seed for movement models' pseudo random number generator (default = 0) MovementModel.rngSeed = 1 # World's size for Movement Models without implicit size (width, height; meters) MovementModel.worldSize = 4500, 3400 # How long time to move hosts in the world before real simulation MovementModel.warmup = 1000 ## Map based movement -movement model specific settings MapBasedMovement.nrofMapFiles = 4 MapBasedMovement.mapFile1 MapBasedMovement.mapFile2 MapBasedMovement.mapFile3 MapBasedMovement.mapFile4

= = = =


## Reports - all report names have to be valid report classes # how many reports to load

97


Report.nrofReports = 2 # length of the warm up period (simulated seconds) Report.warmup = 0 # default directory of reports (can be overridden per Report with output setting) Report.reportDir = reports/Skenario_1_RAPID # Report classes to load Report.report1 = MessageStatsReport Report.report2 = BufferOccupancyReport ## Default settings for some routers settings ProphetRouter.secondsInTimeUnit = 30 SprayAndWaitRouter.nrofCopies = 6 SprayAndWaitRouter.binaryMode = true ## Optimization settings -- these affect the speed of the simulation ## see World class for details. Optimization.cellSizeMult = 5 Optimization.randomizeUpdateOrder = true ## GUI settings # GUI underlay image settings GUI.UnderlayImage.fileName = data/helsinki_underlay.png # Image offset in pixels (x, y) GUI.UnderlayImage.offset = 64, 20 # Scaling factor for the image GUI.UnderlayImage.scale = 4.75 # Image rotation (radians) GUI.UnderlayImage.rotate = -0.015 # how many events to show in the log panel (default = 30) GUI.EventLogPanel.nrofEvents = 100 # Regular Expression log filter (see Pattern-class from the Java API for RE-matching details) #GUI.EventLogPanel.REfilter = .*p[1-9]<->p[1-9]$

98

ANALISIS UNJUK KERJA PROTOKOL ROUTING RAPID DI JARINGAN OPORTUNISTIK SKRIPSI

Recommend Documents