ANALISIS UNJUK KERJA PROTOKOL ROUTING PROPHET MENGGUNAKAN DELEGATION FORWARDING DI JARINGAN OPORTUNISTIK SKRIPSI Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer Program Studi Teknik Informatika

59 

Loading....

Loading....

Loading....

Loading....

Loading....

Teks penuh

(1)

ANALISIS UNJUK KERJA PROTOKOL ROUTING PROPHET MENGGUNAKAN DELEGATION FORWARDING DI JARINGAN

OPORTUNISTIK

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat Memperoleh Gelar Sarjana Komputer Program Studi Teknik Informatika

Disusun Oleh: KRISNA ARDIAN

NIM: 145314032

PROGRAM STUDI TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA YOGYAKARTA

(2)

ii

ANALYSIS OF DELEGATION FORWARDING ON PROPHET PROTOCOL IN OPPORTUNISTIC NETWORK

A THESIS

Presented as Partial Fulfillment of Requirements to Obtain Sarjana Komputer Degree in Informaticts Engineering Department

By:

KRISNA ARDIAN NIM: 145314032

INFORMATIC ENGINNERING STUDY PROGRAM INFORMATICTS ENGINEERING DEPARTMENT

FACULTY SCIENCE AND TECHNOLOGY SANATA DHARMA UNIVERSITY

(3)

iii

HALAMAN PERSETUJUAN

SKRIPSI

ANALISIS UNJUK KERJA PROTOKOL ROUTING PROPHET MENGGUNAKAN DELEGATION FORWARDING DI JARINGAN

OPORTUNISTIK

Oleh: Krisna Ardian

(145314032)

Telah disetujui oleh:

Dosen Pembimbing,

(4)

iv

HALAMAN PENGESAHAN

SKRIPSI

ANALISIS UNJUK KERJA PROTOKOL ROUTING PROPHET MENGGUNAKAN DELEGATION FORWARDING DI JARDINGAN

OPORTUNISTIK

Dipersiapkan dan ditulis oleh:

Krisna Ardian 145314032

Telah dipertahankan di depan panitia penguji Pada tanggal 16 Januari 2019

Dan dinyatakan memenuhi syarat

Susunan Panitia Penguji

Nama Lengkap Tanda Tangan

Ketua : Puspaningtyas Sanjoyo Adi, S.T.,M.T ………... Sekretaris : Henricus Agung Hernawan ,S.T.,M.Kom ………... Penguji : Vittalis Ayu, M.Cs. ………... Anggota : Bambang Soelistijanto, Ph.D. ………...

Yogyakarta,…..Januari 2019 Fakultas Sains dan Teknologi

Universitas Sanata Dharma Dekan,

(5)

v MOTTO

Pilihan hanya ada di tanganmu

sekarang atau tidak sama sekali

(6)

vi

PERNYATAAN LEMBAR KEASLIAN KARYA

Saya menyatakan dengan sesungguhnya bahwa di dalam skripsi yang saya tulis ini tidak memuat karya atau bagian karya orang lain, kecuali yang telah disebutkan dalam kutipan daftar pustaka, sebagaimana layaknya karya ilmiah.

Yogyakarta, 3 Januari 2018 Penulis,

(7)

vii

LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH UNTUK KEPENTINGAN AKADEMIS

Yang bertanda tangan di bawah ini, saya mahasiswa Universitas Sanata Dharma:

Nama : Krisna Ardian NIM : 145314032

Demi pengembangan ilmu pengetahuan, saya memberikan kepada Perpustakaan Universitas Sanata Dharma karya ilmiah yang berjudul:

ANALISIS UNJUK KERJA PROTOKOL ROUTING PROPHET MENGGUNAKAN DELEGATION FORWARDING DI JARINGAN

OPORTUNISTIK

Beserta perangkat yang diperlukan (bila ada). Dengan demikian saya memberikan kepada Perpustakaan Universitas Sanata Dharma hak untuk menyimpan, mengalihkan dalam bentuk media lain, mengolahnya dalam bentuk angkalan data, mendistribusikannya secara terbatas, dan mempublikasikannya di Internet atau media lain untuk kepentingan akademis tanpa meminta ijin dari saya maupun memberikan royalty kepada saya selama tetap mencantumkan nama saya sebagai penulis.

Demikian pernyataan ini saya buat dengan sebenarnya.

Yogyakarta, 3 Januari 2018 Penulis,

(8)

viii ABSTRAK

Jaringan Oportunistik merupakan kondisi jaringan dimana komunikasi dapat terjadi tanpa adanya infrastruktur jaringan. Tanpa adanya infrastruktur jaringan node yang selalu berpindah menyebabkan pengiriman pesan menjadi hal yang sulit. Untuk memaksimalkan pesan yang sampai digunakan routing protocol PROPHET (Probabilistic ROuting Protocol using History of Encounters and Transitivity). Protokol ini merupakan protokol probabilistik yang berdasarkan

metrik probabilitas bertemu node lain yang disebut delivery predictability/DP. Pada pergerakan manusia beban jaringan menjadi sangat tinggi. Delegation Forwarding merupakan teknik forwarding yang akan di terapkan di PROPHET. Delegation Forwarding digunakan untuk memperbaiki kekurangan forwarding pada protokol ini.

Pada penelitian ini penulis akan melakukan pengujian dengan menggunakan matriks unjuk kerja delivered message percontact, total copy message percontact, average latency percontact, delivery centrality, carried message to destination.

(9)

ix ABSTRACT

Opportunistic network is a network condition where communication can occur without any network infrastructure. Message delivery in mobile network is difficult because of the node always move. Therefore, the success rate to destination used PROPHET(Probabilistic ROuting Protocol using History of Encounters and Transitivity) routing protocol. This protocol is a probabilistic protocol based on

probability metrics in this protocol called delivery predictability/DP. In human movement the network load becomes very high. Delegation Forwarding is a technique which will be applied in PROPHET. Delegation Forwarding used for improve forwarding in PROPHET.

(10)

x

KATA PENGANTAR

Puji dan syukur penulis panjatkan kepada Tuhan Yang Maha Esa, oleh karena rahmatnya yang melimpah penulis dapat menyelesaikan tugas akhir dengan tepat waktu. Saya selaku penulis menyadari tugas akhir dapat terselesaikan dengan bantuan dan bimbingan dari berbagai pihak secara langsung maupun tidak langsung. Maka pada kesempatan ini, selaku penulis mengucapkan terimakasih sebesar-besarnya kepada:

1. Tuhan Yang Maha Esa, karena atas bimbingannya penulis dapat menyelesaikan tugas akhir.

2. Kepada keluarga tercinta, Bapak Didi Suhardi dan Ibu Sri Satiti dan saudara perempuan saya yang selalu mendukung dalam doa, dan motivasi.

3. Kepada Ex-Fly Host Rafelino Claudius Kelen, Junandus Sijabat, Fabianus Asto Nugroho yang sudah menjadi keluarga selama perkuliahan, selalu mendukung, memberi motivasi, serta menemani dalam penyelesaikan tugas akhir.

4. Bapak Bambang Soelistijanto, S.T., M.Sc., Ph.D. selaku dosen pembimbing tugas akhir yang telah membimbing, memberi ilmu, serta pengalaman dalam menyelesaikan tugas akhir.

5. Seluruh teman-teman seperjuangan di lab TA jarkom yang menemani penulis dalam menyelesaikan tugas akhir.

6. Kepada Agustinus Indriyadi yang menemani penulis dalam

mendapatkan “chicken dinner” dan semangatnya dalam mengerjakan

tugas akhir.

(11)

xi

Saya selaku penulis menyadari bahwa tulisan ini belum sempurna, maka kritik dan saran sangat kami harapkan demi menyempurnakan tulisan ini. Akhir kata penulis ucapkan terimakasih semoga tulisan ini bermanfaat bagi semua pihak.

Penulis

(12)

xii DAFTAR ISI

HALAMAN JUDUL ... i

HALAMAN PERSETUJUAN ... iii

HALAMAN PENGESAHAN ... iv

MOTTO ... v

PERNYATAAN LEMBAR KEASLIAN KARYA ... vi

LEMBAR PERSETUJUAN PUBLIKASI KARYA ILMIAH ... vii

ABSTRAK ... viii

1.6 Metodelogi Penelitian ... 3

1.7 Sistematika Penulisan ... 4

BAB II LANDASAN TEORI ... 5

2.1 Jaringan Oportunistik ... 5

2.2 Delegation Forwarding... 6

2.3 Protokol Routing PROPHET ... 7

2.3.1 Delivery Predictability ... 7

2.3.2 Strategi pengiriman pesan (forwarding strategies) ... 8

BAB III PERCANGAN SIMULASI ... 10

(13)

xiii

3.2 Skenario Simulasi ... 10

3.3 Matrik Unjuk Kerja ... 11

3.3.1 Delivered Message PerContact ... 11

3.3.2 Total Copy Message PerContact ... 11

3.3.3 Average Latency PerContact... 11

3.3.4 Delivery Centrality ... 11

3.3.5 Carried Message to Destination ... 12

3.4 Desain Alat Uji ... 12

BAB IV PENGUJIAN DAN ANALISIS ... 13

4.1 Pergerakan Manusia ... 13

4.1.1 Haggle3-Infocom5 ... 13

4.1.2 Reality MIT ... 13

4.2 Perbandingan Message Delivered pada Protokol PROPHET dan PROPHET Delegation Forwarding ... 14

4.3 Perbandingan Total Copy Message pada Protokol PROPHET dan PROPHET Delegation Forwarding ... 16

4.4 Perbandingan Average Latency pada Protokol PROPHET dan PROPHET Delegation Forwarding ... 17

4.5 Perbandingan Delivery Centrality pada Protokol PROPHET dan PROPHET Delegation Forwarding ... 18

4.6 Perbandingan Carried Message pada Protokol PROPHET dan PROPHET Delegation Forwarding ... 21

BAB V KESIMPULAN DAN SARAN ... 24

5.1 Kesimpulan ... 24

5.2 Saran ... 24

DAFTAR PUSTAKA ... 25

(14)

1 BAB I PENDAHULUAN

1.1 Latar belakang

Mobile Ad-hoc Network (MANET) adalah salah satu dari teknologi

wireless yang sedang di kembangkan untuk memenuhi kebutuhan manusia saat ini karena sifatnya yang bergerak (mobile) dan tidak memerlukan infrastruktur. Cara yang dilakukan MANET adalah dengan membuat setiap node agar dapat berperan sebagai pengirim pesan, router, dan penerima pesan (bertindak sebagai relay). MANET akan bekerja dengan baik jika seluruh node dapat terhubung dan saling meneruskan pesan dari satu node ke node lainnya sampai menemukan tujuan pesan tersebut, dengan tanpa adanya gangguan yang menyebabkan pesan tidak terkirim. Sifat dari node yang bergerak setiap saat sehingga topologi dapat berubah kapanpun,dan akan ada fase dimana node yang sudah terhubung menjadi tidak terhubung satu sama lain. Untuk menyelesaikan berbagai masalah dari MANET maka terciptalah sebuah solosi yaitu Delay Tolerant Network (DTN / OppNet).

Delay Tolerant Network (DTN) adalah kelas turunan dari MANET. DTN sendiri di asumsikan tidak ada end-to-end-path atau setiap node tidak terhubung secara terus menerus. DTN memiliki keunggulan yaitu dapat mentolelrir adanya jeda waktu sampainya pesan dari pengirim kepada tujuan. Jaringan DTN memiliki system store-carry-forward, dimana setiap node menyimpan pesan dalam buffer, kemudian meneruskan pesan menuju tujuan (destination). Tantangan dari DTN sendiri adalah bagaimana cara untuk menemukan jalur komunikasi yang dapat mengoptimalkan unjuk kerja.

(15)

sebelumnya. Bertemunya node dengan keterkaitannya dengan node lain yang disebut transitivity. Dalam menentukan node yang dapat men-relay pesan, PROPHET menggunakan probalistik metrik yang disebut dengan Delivery predictability (DP)[1]. Berdasarkan nilai DP inilah protocol PROPHET akan menentukan node yang baik untuk mengantarkan pesan ke node tujuan. Transitivity juga menjadi nilai yang mempengaruhi nilai DP dari sebuah node. Namun dalam beberapa kasus ditemui unjuk kerja protokol PROPHET yang buruk, seperti pada pergerakan yang real seperti pergerakan manusia. Penyebabnya ialah sifat transitivity yang tidak bekerja dengan baik pada pergerakan manusia. Untuk itu dibutuhkan strategi forwarding baru yaitu Delegation Forwarding (DF).

Pada penelitian ini akan dibahas tentang bagaimana penerapan Delegation Forwarding(DF) di protokol routing PROPHET, sehingga proses

forwarding pada PROPHET bisa lebih efisien.

1.2 Rumusan Masalah

Berdasarkan latar belakang, rumusan masalah yang ditemukan adalah seberapa efektif delegation forwarding untuk mengatasi masalah forwarding pada PROPHET.

1.3 Tujuan Penelitian

Tujuan dari penelitian ini adalah mengetahui serta menganalisis kelebihan maupun kekurangan protokol routing PROPHET dan PROPHET menggunakan delegation forwarding dalam melakukan forward message.

1.4 Manfaat Penlitian

Hasil dari penelitian ini diharapkan dapat digunakan sebagai bahan pertimbangan dalam mengembangkan protokol routing dalam komunikasi pada jaringan oportunistik.

1.5 Batasan Masalah

(16)

1. PROPHET routing digunakan sebagai landasan utuh penelitian 2. Delegation forwarding diterapkan pada PROPHET

3. Menggunakan The One Simulator

4. Metrik unjuk kerja adalah delivered message, total copy message, average latency, delivery centrality, carried message to destination

1.6 Metodelogi Penelitian

Metode yang dilakukan dalam penelitian ini adalah sebagai berikut: 1. Studi Literatur

Mencari dan mengumpulkan referensi dan menerapkan teori untuk mendukung tugas akhir antara lain: Teori jaringan oportunistik, teori routing protokol Prophet, teori delegation forwarding dan dokumentasi the one simulator.

2. Pengumpulan Bahan Penelitian

Dataset yang akan digunakan untuk melakukan penelitian telah tersedia di Internet pada alamat

[4]http://www.shigs.co.uk/index.php?page=traces. 3. Pembuatan Alat Uji

Perancangan sistem dilakukan dengan menerapkan delegation forwarding pada routing protokol PROPHET sehingga ujuk kerja dapat teridentifikasi dari hasil yang ditunjukan.

4. Analisi Data Simulasi

Mengolah data dari hasil simulasi, untuk diproses kemudian dianalisis sesuai dengan parameter ujuk kerja.

5. Penarikan Kesimpulan

(17)

1.7 Sistematika Penulisan BAB I: PENDAHULUAN

Bab ini berisi tentang latar belakang masalah, Rumusan masalah, Tujuan penelitian, Batasan masalah, Metodologi penelitian, dan Sistematika penulisan.

BAB II: LANDASAN TEORI

Bab ini berisi tentang penjelasan dari beberapa teori yang antara lain adalah jaringan oportunistik, jaringan oportunistik, routing protokol Prophet, dan algoritma delegation forwarding.

BAB III: PERANCANGAN SIMULASI

Bab ini berisi tentang perencanaan scenario simulasi yang akan dikerjakan dalam tugas akhir ini.

BAB IV: PENGUJIAN DAN ANALISIS

Bab ini berisi pelaksanaan simulasi dan analisis data hasil simulasi. BAB V: KESIMPULAN DAN SARAN

(18)

5 BAB II LANDASAN TEORI

2.1 Jaringan Oportunistik

Jaringan Oportunistik adalah sebuah turunan dari kelas MANET yang ditandai dengan tidak ada end-to-end path dan ditambah dengan node yang terus-terusan bergerak. Jaringan Oportunistik memungkinan jaringan dapat mentolerir kondisi delay yang tinggi dan jalur yang selalu berubah setiap saat, oleh sebab itu jaringan oportunistik dapat diterapkan pada kondisi jaringan yang extreme. Contohnya adalah kondisi delay yang tinggi, koneksi yang sering terputus, pergerakan yang cepat, dan drop yang tinggi.

Sebuah node di jaringan Oportunistik akan masuk ke dalam jangkauan area tertentu yang dimana terdapat beberapa node, sehingga node dapat saling berkomunikasi dan dapat melakukan pertukaran pesan di masing-masing buffer, bahkan node dapat memutuskan untuk meneruskan pesan ke beberapa node lainnya sehingga pesan dapat sampai ke tujuan. Mekanisme tersebut adalah store-carry and forward di tunjukan pada gambar 2.1.1.

Gambar 2.1.1 Mekanisme Store-Carry-Forward pada jaringan oportunistik

(19)

menjadi sebagai destination karena tidak tersedianya end-to-end-path maka di butuhkannya node lain untuk menjadi sebagai relay node agar pesan dapat sampai ke destination [1].

2.2 Delegation Forwarding

Delegation forwarding (DF) adalah algoritma yang diterapkan pada mekanisme forwarding, dimana paket hanya dititipi kepada node yang memiliki predictability lebih tinggi dari node yang akan meneruskan pesan dan node penerus pesan sebelumnya[3]. Pesan akan di kirim secara keseluruhan dari node ke node lainnya pada saat waktu kontak interval, setelah itu kedua node menyimpan salinan pesan.

Gambar 2.2.1 Mekanisme Delegation Forwarding berbasis predictability

(20)

tinggi daripada nilai utility pesan tersebut sebelumnya pesan tidak akan di teruskan.

2.3 Protokol Routing PROPHET

Protokol Routing PROPHET Merupakan protokol probabilistik yang berdasarkan pada metrik probabilitas bertemu dengan node lain serta transitivity-nya. Transitivity sendiri adalah kondisi dimana sebuah node dapat menjadi relay atau node perantara untuk menyampaikan pesan dari node lain.

untuk menghitung probabilitas bertemunya satu node dengan node lain diperlukan probabilistik metrik yang disebut delivery predictability

2.3.1 Delivery Predictability

Ada tiga tahap dalam menghitung Delivery Predictability. Tahap pertama melakukan update pada setiap node ketika node bertemu node lainnya. Jika node sering bertemu, maka dikategorikan sebagai node yang memiliki Delivery Predictibility tinggi dalam penyampaian pesan. Untuk menghitung Delivery Predictibility ditunjukkan pada rumus berikut.

Rumus 2.3.1 menghitung update metric Rumus dimana 𝑃𝑖𝑛𝑖𝑡 ∈ [0,1]

𝑃(𝑎,𝑏)=𝑃(𝑎,𝑏)𝑜𝑙𝑑+(1 − 𝑃(𝑎,𝑏)𝑜𝑙𝑑)𝑥𝑃𝑖𝑛𝑖𝑡

Jika node yang sudah bertemu tetapi terlampau lama untuk bertemu kembali, maka dianggap sebagai node yang kurang baik dalam penyampaian pesan. Kondisi seperti ini akan membuat nilai delivery predictability pada node harus berkurang (age, menua). Untuk menghitung aging ditunjukkan pada rumus berikut.

Rumus 2.3.2 menghitung aging 𝑃(𝑎,𝑏)=𝑃(𝑎,𝑏)𝑜𝑙𝑑 𝑥 𝛾𝑘

(21)

node C besar kemungkinan memiliki keterikatan dalam penyampaian pesan. Jika nilai kedekatan node A ke node C lebih besar dibanding node A ke node B, maka pesan akan di kirimkan ke node C langsung, tetapi jika nilai kedekatan node A ke node B lebih besar, maka pesan akan dikimkan ke node C lewat perantara node B.

Rumus 2.3.3 menghitung transitivity 𝑃(𝑎,𝑐)=𝑃(𝑎,𝑐)𝑜𝑙𝑑+(1 − 𝑃(𝑎,𝑐)𝑜𝑙𝑑) 𝑥 𝑃(𝑎,𝑏) 𝑥 𝑃(𝑏,𝑐) 𝑥 𝛽

Gambar 2.3.1 ilustrasi metric trasitivity pada PROPHET

2.3.2 Strategi pengiriman pesan (forwarding strategies)

Strategi pengiriman pesan yang digunakan oleh protokol PROPHET adalah saat dua node bertemu, maka pesan dikirimkan ke node lain jika delivery probability node lain tersebut lebih tinggi untuk membawa pesan ke node destination.

b

a

c

P(a,b) P(b,c)

P(a,c)

c

a

b

(22)

Gambar 2.3.2 ilustrasi forwarding strategis PROPHET

Ilustrasi pada gambar 2.3.2 node source S akan mengirimkan pesan kepada node destination B. saat node S bertemu dengan node A dan node C dalam jaringan, maka node akan saling bertukar metrik probability mereka untuk bertemu dengan node destination. Dalam hal ini probability node A bertemu node destination B lebih

(23)

10 BAB III

PERCANGAN SIMULASI

3.1 Parameter Simulasi

Pada penelitian ini, memiliki beberapa parameter simulasi yang bersifat tetap dan digunakan dengan nilai yang sama pada simulasi yang berbeda. Parameter-parameter berikut adalah:

Tabel 3.1.1 Parameter Utama Simulasi 3.2 Skenario Simulasi

Dalam penelitian ini, skenario yang digunakan adalah pergerakan real atau pergerakan manusia, antara lain adalah:

MOVEMENT ROUTING

Tabel 3.2.1 Skenario Prophet Haggle3-Infocom5

Parameter Nilai

Routing Protokol Prophet & Prophet DF

Movement Model Haggle 3 - Infocom 5 & Reality Mining MIT Waktu Simulasi 950400 & 16981816

Buffer Size 20MB

(24)

MOVEMENT ROUTING

Reality MIT Prophet & Prophet

DF 97 1000 x 1000

Tabel 3.2.2 Skenario pergerakan Reality MIT 3.3 Matrik Unjuk Kerja

Setelah melakukan simulasi maka selanjutnya perhitungan matriks dengan parameter unjuk kerja sebagai berikut:

3.3.1 Delivered Message PerContact

Parameter ini digunakan untuk melakukan evaluasi keberhasilan pengiriman pesan yang di lakukan oleh protokol routing.

3.3.2 Total Copy Message PerContact

Parameter ini digunakan untuk mengevaluasi jumlah sebaran pesan yang di lakukan oleh protokol routing.

Rumus 3.3.1 = 𝑗𝑢𝑚𝑙𝑎ℎ 𝑟𝑒𝑙𝑎𝑦𝑒𝑑 𝑚𝑒𝑠𝑠𝑎𝑔𝑒 − 𝑗𝑢𝑚𝑙𝑎ℎ 𝑝𝑒𝑠𝑎𝑛 𝑡𝑒𝑟𝑘𝑖𝑟𝑖𝑚

3.3.3 Average Latency PerContact

Parameter ini digunakan untuk mengetahui rata-rata yang dibutuhkan pesan dari source sampai ke destination.

Rumus 3.3.2 = (𝑤𝑎𝑘𝑡𝑢 𝑝𝑒𝑠𝑎𝑛 𝑡𝑒𝑟𝑘𝑖𝑟𝑖𝑚 −𝑤𝑎𝑘𝑡𝑢 𝑝𝑒𝑠𝑎𝑛 𝑑𝑖𝑏𝑢𝑎𝑡)

𝑗𝑢𝑚𝑙𝑎ℎ 𝑝𝑒𝑠𝑎𝑛 𝑡𝑒𝑟𝑘𝑖𝑟𝑖𝑚

3.3.4 Delivery Centrality

(25)

3.3.5 Carried Message to Destination

Untuk mengukur dan melihat berapa banyak jumlah sebuah node membawakan pesan sampai ke destination.

3.4 Desain Alat Uji

(26)

13 BAB IV

PENGUJIAN DAN ANALISIS

Untuk melakukan evaluasi unjuk kerja dari routing protokol PROPHET dan PROPHET DF, maka dilakukan pengujian. Pengujian dilakukan dengan menggunakan rancangan simulasi yang sudah dijabarkan pada bab III. Data yang diperoleh dari hasil simulasi yang dibangkitkan oleh report kemudian menjadi bahan untuk analisis.

4.1 Pergerakan Manusia 4.1.1 Haggle3-Infocom5

Dataset ini berisi data pertemuan antar partisipan pada konferensi IEEE Infocom di

Miami. Setiap partisipan diberi device (iMotes) yang digunakan untuk mencatat data pertemuan antar partisipan. Dari 50 partisipan yang dipilih, device yang menghasilkan data yang valid dan dapat digunakan untuk melakukan penelitian sebanyak 41 device. Durasi simulasi pada dataset ini adalah 254150 detik, sekitar 2.94 hari.

Tabel 4.1.1 Hasil perbandingan protokol PROPHET dan PROPHETDF pada pergerakan Haggle3-Infocom5

4.1.2 Reality MIT

Dataset ini berisi data pertemuan antar pelajar dari 2 fakultas

di Universitas MIT. Jumlah partisipan yang digunakan dalam simulasi ini sebanyak 75 pelajar Fakultas Media Laboratory dan 25 pelajar dari Fakultas Business. Durasi simulasi pada dataset ini adalah sekitar 1 tahun akademik. Dari 100 partisipan yang dipilih,

Prophet 3359 118708 25815,2403

(27)

device yang menghasilkan data yang valid dan dapat digunakan untuk

melakukan penelitian sebanyak 97 device.

Tabel 4.1.2 Hasil perbandingan protokol PROPHET dan PROPHETDF pada pergerakan Reality MIT

4.2 Perbandingan Message Delivered pada Protokol PROPHET dan PROPHET Delegation Forwarding

Gambar 4.2.1 Grafik Message Delivered PerContact Haggle Infocom5 Protokol

Routing

Message

Delivered Total Copy Message

Latency Average

Prophet 8090 27634331 1479010,863

ProphetDF 16869 604624 1365932,897

(28)

Gambar 4.2.2 Grafik Message Delivered PerContact Reality MIT

Pada gambar 4.2.1 PROPHET dengan pergerakan haggle lebih unggul dibandingkan dengan PROPHETDF dikarenakan mekanisme dari PROPHET hanya mengirim pesan ke destination tanpa harus melihat dari beban resources di jaringan. Sementara itu di PROPHETDF total pesan yang sampai di destination lebih rendah karena mekanisme delegation forwarding hanya mengirim pesan kepada node dengan nilai delivery predictability yang paling tinggi saja, sehingga proses pengiriman pesan bertumpu pada node tertentu. Namun mekanisme delegation forwarding (gambar 4.2.2) di pergerakan reality lebih unggul

dibandingkan dengan PROPHET, karena mekanisme dengan hanya mengirimkan pesan yang memiliki delivery predictability yang paling tinggi di pergerakan reality, sehingga pengiriman pesan menjadi lebih maksimal. Semakin banyaknya sebaran node di jaringan maka probabilitas terkirimnya pesan ke destination lebih besar, dalam gambar 4.2.1 terlihat pesan yang sampai di destination lebih kecil karena jumlah node yang terbatas.

0

12500 15500 18500 21500 24500 27500 30500 33500 36500 39500 42500 45500 48500 51500 54500 57500 60500 63500 66500 69500 72500 75500 78500 81500 84500

(29)

4.3 Perbandingan Total Copy Message pada Protokol PROPHET dan PROPHET Delegation Forwarding

Gambar 4.3.1 Grafik Total Copy Message PerContact Haggle Infocom5

Gambar 4.3.2 Grafik Total Copy Message PerContact Reality MIT

Namun karena hanya memilih nilai delivery predictability yang tinggi saja, berdampak pada total copy message lihat gambar 4.3.1 dan 4.3.2 . Beban total copy message delegation forwarding lebih baik karena memiliki total copy message yang rendah dibandingan dengan PROPHET. Sedangkan pada PROPHET mekanisme

0

1500 2500 3500 4500 5500 6500 7500 8500 9500

10500 11500 12500 13500 14500 15500 16500 17500 18500

to

11000 14500 18000 21500 25000 28500 32000 35500 39000 42500 46000 49500 53000 56500 60000 63500 67000 70500 74000 77500 81000 84500

(30)

forwarding tidak menghapus pesan sebelum buffer penuh. Hal tersebut mempengaruhi total copy message yang naik di jaringan.

4.4 Perbandingan Average Latency pada Protokol PROPHET dan PROPHET Delegation Forwarding

Gambar 4.4.1 Grafik Average Latency PerContact Haggle Infocom 5

0

12500 15500 18500 21500 24500 27500 30500 33500 36500 39500 42500 45500 48500 51500 54500 57500 60500 63500 66500 69500 72500 75500 78500 81500 84500

Av

1500 2500 3500 4500 5500 6500 7500 8500 9500 10500 11500 12500 13500 14500 15500 16500 17500 18500

(31)

Gambar 4.4.2 Grafik Average Latency PerContact Reality MIT

Tingginya jumlah total copy message dalam PROPHET pada gambar 4.4.1 dan 4.4.2 membuat pesan tersebar lebih banyak di jaringan. Hal itu terjadi karena mekanisme forwarding dari PROPHET, Sedangkan delegation forwarding memiliki rata-rata latency relatif lebih lama. Hal tersebut terjadi karena mekanisme yang hanya menitipi pesan kepada node yang memiliki utility lebih tinggi dari pada node sebelumnya, sehingga pesan akan terus disimpan sampai node tersebut bertemu dengan destination.

4.5 Perbandingan Delivery Centrality pada Protokol PROPHET dan PROPHET Delegation Forwarding

Gambar 4.5.1 Grafik Delivery Centrality PROPHET Haggle Infocom 5

pada gambar 4.5.1 terlihat lebih merata dan total relay ditiap-tiap node menjadi lebih tinggi. Hal ini disebabkan oleh mekanisme forwarding PROPHET yang memiliki DP yang tinggi terhadap node destination, meski node tersebut belum pernah bertemu secara langsung, sehingga total relay menjadi naik dan total delivered message pada gambar 4.2.1 lebih tinggi.

(32)

Gambar 4.5.2 Grafik Delivery Centrality PROPHET Delegation Forwarding Haggle Infocom 5

Pada gambar 4.5.2 terlihat bahwa PROPHETDF sebaran pesannya tidak merata, mekanisme forwarding berbasis delegation forwarding hanya akan selalu memilih node dengan delivery predictability tertinggi untuk meneruskan pesan sebelumnya. Dampak yang dapat di lihat jumlah copy message yang rendah di jaringan dapat di lihat di gambar 4.3.1 dan 4.3.2

0 100 200 300 400 500 600 700

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38

T

o

ta

l Re

lay

Me

ss

age

Node Id

Delivery Centrality :Infocom5

(33)

Gambar 4.5.3 Grafik Delivery Centrality PROPHET Reality MIT

Jika dibandingkan delivery centrality di pergerakan haggle dan pergerakan rality MIT pada gambar 4.5.3 PROPHET memiliki node yang menjadi node hub node lebih banyak, walaupun ada beberapa node yang memiliki beban relay yang lebih tinggi dibanding dengan node lain tetapi tetap menjadi relay.

Gambar 4.5.4 Grafik Delivery Centrality PROPHET Reality MIT

(34)

Pada gambar diatas menunjukan bahwa dampak dari delegation forwarding yang hanya akan ada beberapa node saja yang di anggap memiliki nilai DP tertinggi yang akan dititipi pesan. Dampak lain yaitu tinggi waktu pengiriman pesan di jaringan yang dapat dilihat di gambar 4.4.1 dan 4.4.2

4.6 Perbandingan Carried Message pada Protokol PROPHET dan PROPHET Delegation Forwarding

Gambar 4.6.1 Grafik Carried Message PROPHET Haggle Infocom 5

Pada gambar 4.6.1 pengiriman pesan ke destination lebih merata namun pada akhir pengiriman pesan PROPHET terlihat menjadi lebih terbebani, namun pesan yang sampai di destination lebih banyak dari pada PROPHETDF yang dapat dilihat digambar 4.2.1

Carried Message To Destination:Infocom 5

(35)

Gambar 4.6.2 Grafik Carried Message PROPHET Delegation Forwarding Haggle Infocom 5

Karena sifat dari delegation forwarding hanya menitipkan pesan ke node yang memiliki delivery predictability yang tinggi Node pembawa pesan langsung ke destination terlihat lebih bertumpu pada beberapa node yang menyebabkan delivery

ke destination menjadi lebih sedikit dibandingkan dengan PROPHET, selain itu node di dataset Haggle yang hanya berjumlah 41 tidak efektif untuk PROPHETDF.

Gambar 4.6.3 Grafik Carried Message PROPHET Reality MIT

0

Carried Message To Destination:Infocom 5

Delegation Forwarding

0 3 6 9 12151821252831343740434649525558616468717477808387909396

T

Carried Message To Destination :Reality MIT

(36)

Dalam dataset Reality MIT PROPHET akan terus mengirimkan pesan dengan jumlah node yang terlampau banyak. Sifat transitivity dari PROPHET akan membuat DP node dalam jaringan tidak sesuai dengan kondisi sebenarnya. Akibatnya PROPHET akan kurang maksimal dalam membawa pesan ke destination yang berakibat juga pada jumlah copy yang tinggi

Gambar 4.6.4 Grafik Carried Message PROPHET Delegation Forwarding Reality MIT

Dengan bertambahnya jumlah node dan durasi simulasi yang lebih panjang pada dataset Reality MIT , membuat node yang terbebani lebih semakin terlihat. Dapat dilihat dari gambar diatas menunjukkan kelemahan dari delegation forwarding yang hanya bertumpu pada node yang memliki nilai DP tertinggi

0

0 3 6 9 12151821252831343740434649525558616468717477808387909396

T

Carried Message To Destination :Reality MIT

(37)

24 BAB V

KESIMPULAN DAN SARAN

5.1 Kesimpulan

Setelah melakukan pengujian dan analisis pada data hasil simulasi, kesimpulan yang didapat adalah sebagai berikut:

 Routing protokol PROPHET dalam perhitungan DP dan sifat transitivity menghasilkan perhitungan yang tidak sesuai, sehingga banyak dari node dalam jaringan memiliki DP yang tinggi terhadap destination tetap dikirimkan yang berakibat meningkatnya jumlah copy pesan di dalam jaringan.

 Dengan menggunakan delegation forwarding masalah jumlah copy pesan dalam jaringan dapat teratasi begitu pula dengan membaiknya pesan yang sampai di destination.

 Routing berbasis delegation forwarding jika jumlah node dalam jaringan sedikit akan menyebabkan kurangnya maksimal pengiriman pesan yang disebabkan oleh bertumpunya pada node dengan nilai DP tertinggi.

5.2 Saran

Dengan mekanisme delegation forwarding, menitipi pesan ke node yang memiliki DP tinggi membuat waktu pesan sampai di tujuan menjadi sedikit lebih lama. Oleh karena itu diharapkan pada penelitian selanjutanya mekanisme delegation forwarding memperhatikan waktu pesan di jaringan untuk memperbaiki

(38)

25

DAFTAR PUSTAKA

[1] Lindgen, A., Doria, A. & Schelen, O., “Probabilistic Routing in intermittenly

Connected Network”. Mobile Computing and Commun. Review, vol.7, no.3, july 2003.

[2] Z. Zhang, "Routing in Intermittently Connected Mobile Ad Hoc Networks and Delay Toleran Networks: Overview and Challenges," IEEE Communications Surveys & Tutorials, vol. 8, no. 1, pp. 24-37, 2006.

[3] V.erramilli, M. Crovella, A. Chaintreau, and C. Diot, "Delegation forwarding," in Proc. of ACM MOBIHOC 2008.

[4] Orlinski, Matthew, “Encounter traces for the ONE simulator”, [online] diakses di : http://www.shigs.co.uk/index.php?page=traces.2018. [5] Eagle, Nathan & Pentland, Alex (Sandy). “A Community Resource for

Archiving Wireless Data At Dartmouth” [online] diakses di :

http://crawdad.org/mit/reality/20050701/, The mit/reality dataset (v. 2005- 07-01),2018.

(39)

26 LAMPIRAN

1. Prophet Decesion Engine

public class ProphetDecisionEngine implements RoutingDecisionEngine {

protected final static String BETA_SETTING = "beta";

protected final static String GAMMA_SETTING = "gamma";

protected final static String P_INIT_SETTING = "initial_p";

protected final static String SECONDS_IN_UNIT_S =

"secondsInTimeUnit";

protected static final double DEFAULT_P_INIT = 0.75;

protected static final double DEFAULT_GAMMA = 0.98;

protected static final double DEFAULT_BETA = 0.25;

protected static final int DEFAULT_UNIT = 1;

protected double beta;

protected double gamma;

protected double pinit;

protected double lastAgeUpdate;

protected int secondsInTimeUnit;

/**

* delivery predictabilities

*/

private Map<DTNHost, Double> preds;

public ProphetDecisionEngine(Settings s) {

if (s.contains(BETA_SETTING)) {

(40)

} else {

beta = DEFAULT_BETA;

}

if (s.contains(GAMMA_SETTING)) {

gamma = s.getDouble(GAMMA_SETTING);

} else {

gamma = DEFAULT_GAMMA;

}

if (s.contains(P_INIT_SETTING)) {

pinit = s.getDouble(P_INIT_SETTING);

} else {

pinit = DEFAULT_P_INIT;

}

if (s.contains(SECONDS_IN_UNIT_S)) {

secondsInTimeUnit = s.getInt(SECONDS_IN_UNIT_S);

} else {

secondsInTimeUnit = DEFAULT_UNIT;

}

preds = new HashMap<DTNHost, Double>();

this.lastAgeUpdate = 0.0;

}

public ProphetDecisionEngine(ProphetDecisionEngine de) {

beta = de.beta;

gamma = de.gamma;

pinit = de.pinit;

secondsInTimeUnit = de.secondsInTimeUnit;

(41)

this.lastAgeUpdate = de.lastAgeUpdate;

}

public RoutingDecisionEngine replicate() {

return new ProphetDecisionEngine(this);

}

public void connectionUp(DTNHost thisHost, DTNHost peer) {

}

public void connectionDown(DTNHost thisHost, DTNHost peer) {

}

public void doExchangeForNewConnection(Connection con, DTNHost

peer) {

DTNHost myHost = con.getOtherNode(peer);

ProphetDecisionEngine de = getOtherProphetDecisionEngine(peer);

Set<DTNHost> hostSet = new HashSet<DTNHost>(this.preds.size()

+ de.preds.size());

hostSet.addAll(this.preds.keySet());

hostSet.addAll(de.preds.keySet());

this.agePreds();

de.agePreds();

// Update preds for this connection

double myOldValue = this.getPredFor(peer),

peerOldValue = de.getPredFor(myHost),

myPforHost = myOldValue + (1 - myOldValue) * pinit,

(42)

preds.put(peer, myPforHost);

de.preds.put(myHost, peerPforMe);

// Update transistivities

for (DTNHost h : hostSet) {

myOldValue = 0.0;

peerOldValue = 0.0;

if (preds.containsKey(h)) {

myOldValue = preds.get(h);

}

if (de.preds.containsKey(h)) {

peerOldValue = de.preds.get(h);

}

if (h != myHost) {

preds.put(h, myOldValue + (1 - myOldValue) * myPforHost *

peerOldValue * beta);

}

if (h != peer) {

de.preds.put(h, peerOldValue + (1 - peerOldValue) *

peerPforMe * myOldValue * beta);

}

}

}

public boolean newMessage(Message m) {

return true;

}

(43)

return m.getTo() == aHost;

}

public boolean shouldSaveReceivedMessage(Message m, DTNHost

thisHost) {

return m.getTo() != thisHost;

}

public boolean shouldSendMessageToHost(Message m, DTNHost

otherHost) {

if (m.getTo() == otherHost) {

return true;

}

ProphetDecisionEngine de =

getOtherProphetDecisionEngine(otherHost);

if (de.getPredFor(m.getTo()) > this.getPredFor(m.getTo()))

return true;

return false;

}

public boolean shouldDeleteSentMessage(Message m, DTNHost

otherHost) {

return false;

//true single copy

}

public boolean shouldDeleteOldMessage(Message m, DTNHost

hostReportingOld) {

(44)

}

private ProphetDecisionEngine

getOtherProphetDecisionEngine(DTNHost host) {

MessageRouter otherRouter = host.getRouter();

assert otherRouter instanceof DecisionEngineRouter : "This router

only works "

+ " with other routers of same type";

return (ProphetDecisionEngine) ((DecisionEngineRouter)

otherRouter).getDecisionEngine();

}

private void agePreds() {

double timeDiff = (SimClock.getTime() - this.lastAgeUpdate)

/ secondsInTimeUnit;

if (timeDiff == 0) {

return;

}

double mult = Math.pow(gamma, timeDiff);

for (Map.Entry<DTNHost, Double> e : preds.entrySet()) {

e.setValue(e.getValue() * mult);

}

this.lastAgeUpdate = SimClock.getTime();

}

/**

(45)

* host doesn't exist.

*

* @param host The host to look the P for

* @return the current P value

*/

public double getPredFor(DTNHost host) {

agePreds(); // make sure preds are updated before getting

if (preds.containsKey(host)) {

return preds.get(host);

} else {

return 0;

}

}

}

2. ProphetDecisionEngine Delegation Forwarding

public class ProphetDecisionEngineDF implements

RoutingDecisionEngine {

protected final static String BETA_SETTING = "beta";

protected final static String GAMMA_SETTING = "gamma";

protected final static String P_INIT_SETTING = "initial_p";

protected final static String SECONDS_IN_UNIT_S =

"secondsInTimeUnit";

public static final String T_SETTING = "t";

public static final String TMIN_SETTING = "t_min";

protected static final double DEFAULT_P_INIT = 0.75;

protected static final double DEFAULT_GAMMA = 0.98;

(46)

protected static final int DEFAULT_UNIT = 30;

protected double beta;

protected double gamma;

protected double pinit;

protected double lastAgeUpdate;

protected int secondsInTimeUnit;

/**

* delivery predictabilities

*/

private Map<DTNHost, Double> preds;

private Map<String, DTNHost> saveM;

protected Map<String, Double> mUtil;

public ProphetDecisionEngineDF(Settings s) {

if (s.contains(BETA_SETTING)) {

beta = s.getDouble(BETA_SETTING);

} else {

beta = DEFAULT_BETA;

}

if (s.contains(GAMMA_SETTING)) {

gamma = s.getDouble(GAMMA_SETTING);

} else {

gamma = DEFAULT_GAMMA;

}

if (s.contains(P_INIT_SETTING)) {

(47)

} else {

pinit = DEFAULT_P_INIT;

}

if (s.contains(SECONDS_IN_UNIT_S)) {

secondsInTimeUnit = s.getInt(SECONDS_IN_UNIT_S);

} else {

secondsInTimeUnit = DEFAULT_UNIT;

}

preds = new HashMap<DTNHost, Double>();

saveM = new HashMap<String, DTNHost>();

this.lastAgeUpdate = 0.0;

}

public ProphetDecisionEngineDF(ProphetDecisionEngineDF de) {

beta = de.beta;

gamma = de.gamma;

pinit = de.pinit;

secondsInTimeUnit = de.secondsInTimeUnit;

preds = new HashMap<DTNHost, Double>();

saveM = new HashMap<String, DTNHost>();

mUtil = new HashMap<String, Double>();

this.lastAgeUpdate = de.lastAgeUpdate;

}

public RoutingDecisionEngine replicate() {

return new ProphetDecisionEngineDF(this);

}

public void connectionUp(DTNHost thisHost, DTNHost peer) {

(48)

public void connectionDown(DTNHost thisHost, DTNHost peer) {

}

public void doExchangeForNewConnection(Connection con, DTNHost

peer) {

DTNHost myHost = con.getOtherNode(peer);

ProphetDecisionEngineDF de =

getOtherProphetDecisionEngine(peer);

Set<DTNHost> hostSet = new HashSet<DTNHost>(this.preds.size()

+ de.preds.size());

hostSet.addAll(this.preds.keySet());

hostSet.addAll(de.preds.keySet());

this.agePreds();

de.agePreds();

// Update preds for this connection

double myOldValue = this.getPredFor(peer),

peerOldValue = de.getPredFor(myHost),

myPforHost = myOldValue + (1 - myOldValue) * pinit,

peerPforMe = peerOldValue + (1 - peerOldValue) * de.pinit;

preds.put(peer, myPforHost);

de.preds.put(myHost, peerPforMe);

// Update transistivities

for (DTNHost h : hostSet) {

myOldValue = 0.0;

peerOldValue = 0.0;

(49)

myOldValue = preds.get(h);

}

if (de.preds.containsKey(h)) {

peerOldValue = de.preds.get(h);

}

if (h != myHost) {

preds.put(h, myOldValue + (1 - myOldValue) * myPforHost *

peerOldValue * beta);

}

if (h != peer) {

de.preds.put(h, peerOldValue + (1 - peerOldValue) *

peerPforMe * myOldValue * beta);

}

}

}

public boolean newMessage(Message m) {

return true;

}

@Override

public boolean isFinalDest(Message m, DTNHost aHost) {

return m.getTo() == aHost;

}

@Override

public boolean shouldSaveReceivedMessage(Message m, DTNHost

thisHost) {

(50)

}

@Override

public boolean shouldSendMessageToHost(Message m, DTNHost

otherHost) {

if (de.getPredFor(m.getTo()) > this.getPredFor(m.getTo())) {

if (!mUtil.containsKey(m.getId())) {

public boolean shouldDeleteSentMessage(Message m, DTNHost

(51)

return false;

//true single copy

}

@Override

public boolean shouldDeleteOldMessage(Message m, DTNHost

hostReportingOld) {

return m.getTo() == hostReportingOld;

}

private ProphetDecisionEngineDF

getOtherProphetDecisionEngine(DTNHost host) {

MessageRouter otherRouter = host.getRouter();

assert otherRouter instanceof DecisionEngineRouter : "This router

only works "

+ " with other routers of same type";

return (ProphetDecisionEngineDF) ((DecisionEngineRouter)

otherRouter).getDecisionEngine();

}

private void agePreds() {

double timeDiff = (SimClock.getTime() - this.lastAgeUpdate)

/ secondsInTimeUnit;

if (timeDiff == 0) {

return;

}

double mult = Math.pow(gamma, timeDiff);

(52)

e.setValue(e.getValue() * mult);

//System.out.println(e.setValue(e.getValue() * mult));

}

this.lastAgeUpdate = SimClock.getTime();

}

/**

* Returns the current prediction (P) value for a host or 0 if entry for the

* host doesn't exist.

*

* @param host The host to look the P for

* @return the current P value

*/

public double getPredFor(DTNHost host) {

agePreds(); // make sure preds are updated before getting

if (preds.containsKey(host)) {

return preds.get(host);

} else {

return 0;

}

}

}

3. Haggle 3 Infocom 5 Report

#Scenario information

Scenario.name Prophet_DF_HAGGLE_TTL_1_HARIi

Scenario.simulateConnections = false

Scenario.updateInterval = 1

(53)

Scenario.endTime = 274883

#987529 Haggle Cam

#274883 Haggle

#16981816 Reality

Report.warmup = 1

Scenario.nrofHostGroups = 1

#Interfaces informations

btInterface.type = SimpleBroadcastInterface

btInterface.transmitSpeed = 250k

btInterface.transmitRange = 10

btInterface.scanInterval = 120

#Group Information

## Buffer Size : 200 messages of 10 K ~ 2M

Group.bufferSize = 20M

##ProphetRouter

Group.router = DecisionEngineRouter

#DecisionEngineRouter.decisionEngine =

decisionengine.ProphetDecisionEngine

DecisionEngineRouter.decisionEngine =

decisionengine.ProphetDecisionEngineDF

DecisionEngineRouter.t = 1

DecisionEngineRouter.t_min = 0.4

## TTL 24 hours=1440, 1 week= 10080, 3 weeks= 30240,1 month =

43800, 12 hour = 720

(54)

Group.nrofInterfaces = 1

Group.interface1 = btInterface

#Group1 Information

Group1.groupID = A

Group1.waitTime = 10, 30

Group1.speed = 0.8, 1.4

Group1.nrofHosts = 41

#36 Haggle Cam

#41 Haggle

#97 Reality

Group1.nodeLocation = 10, 10

Group1.movementModel = StationaryMovement

#StationaryMovement gerak diam

#How many event generator

Events.nrof = 2

## Trace information

Events1.class = ExternalEventsQueue

Events1.filePath = Haggle3-Infocom5.txt

#Events1.filePath = Haggle4-Cam-Imote.csv

#RealityConnectionTraceRevised.txt

#Haggle4-Cam-Imote.csv

#Haggle3-Infocom5.txt

#RealityConnectionTraceFinal.txt

## Message creation parameters

Events2.class = MessageEventGenerator

(55)

#Events2.interval = 290, 310

#Events2.interval = 580, 620

Events2.time = 0, 231683

#97, 103

# 25,30 (~120 texts/hour)

#290, 310 (~12 texts/hour)

# 580, 620 (~ 6 texts/hour)

Events2.size = 10k

## range of message source/destination address

Events2.hosts = 0,40

# 0, 35 Haggle Cam

# 0,40 Haggle

# 0,96 Reality

Events2.prefix = M

# World's size for Movement Models without implicit size (width, height;

meters)

MovementModel.worldSize = 100, 100

# seed for movement models' pseudo random number generator (default =

0)

MovementModel.rngSeed = 2

#ReportsInformations

Report.nrofReports = 10

Report.reportDir = reports/Prophet/DF/

(56)

Report.report1 = MessageStatsReport

Report.report2 = DeliveryCentralityReport

Report.report3 = LatencyPerContact

Report.report4 = CarriedMessageToDestinationReport

Report.report5 = MessageCopyReportperContact

Report.report6 = ReceiveMessage

Report.report7 = BufferOccupancyReport

Report.report8 = BufferOccupancyPerTime

Report.report9 = MessageStatsReportperContact

Report.report10 = MessageStatsReportperTime

4. Reality MIT Report

#Scenario information

Scenario.name = Prophet_BIASA_REALITY_TTL_2_BULAN

Scenario.simulateConnections = false

Scenario.updateInterval = 1

Scenario.endTime = 16981816

#987529 Haggle Cam

#274883 Haggle

#16981816 Reality

Report.warmup = 1

Scenario.nrofHostGroups = 1

#Interfaces informations

btInterface.type = SimpleBroadcastInterface

btInterface.transmitSpeed = 250k

btInterface.transmitRange = 10

(57)

#Group Information

## Buffer Size : 200 messages of 10 K ~ 2M

Group.bufferSize = 20M

##ProphetRouter

Group.router = DecisionEngineRouter

DecisionEngineRouter.decisionEngine =

decisionengine.ProphetDecisionEngine

#DecisionEngineRouter.decisionEngine =

decisionengine.ProphetDecisionEngineDF

DecisionEngineRouter.beta = 0.25

DecisionEngineRouter.gamma = 0.98

DecisionEngineRouter.initial_p = 0.75

DecisionEngineRouter.secondsInTimeUnit = 1000

DecisionEngineRouter.t = 1

DecisionEngineRouter.t_min = 0.4

## TTL 24 hours=1440, 1 week= 10080, 3 weeks= 30240,1 month =

43800,2 month = 876001, 12 hour = 720

Group.msgTtl = 876001

Group.nrofInterfaces = 1

Group.interface1 = btInterface

#Group1 Information

Group1.groupID = A

Group1.waitTime = 10, 30

Group1.speed = 0.8, 1.4

Group1.nrofHosts = 97

(58)

#41 Haggle

#97 Reality

Group1.nodeLocation = 10, 10

Group1.movementModel = StationaryMovement

#StationaryMovement gerak diam

#How many event generator

Events.nrof = 2

## Trace information

Events1.class = ExternalEventsQueue

Events1.filePath = RealityConnectionTraceFinal.txt

#Events1.filePath = Haggle4-Cam-Imote.csv

#RealityConnectionTraceRevised.txt

#Haggle4-Cam-Imote.csv

#Haggle3-Infocom5.txt

#RealityConnectionTraceFinal.txt

## Message creation parameters

Events2.class = MessageEventGenerator

Events2.interval = 580, 620

#Events2.interval = 290, 310

#Events2.interval = 580, 620

Events2.time = 0, 15167416

#97, 103

# 25,30 (~120 texts/hour)

#290, 310 (~12 texts/hour)

# 580, 620 (~ 6 texts/hour)

Events2.size = 10k

(59)

Events2.hosts = 0,96

# 0, 35 Haggle Cam

# 0,40 Haggle

# 0,96 Reality

Events2.prefix = M

# World's size for Movement Models without implicit size (width, height;

meters)

#MovementModel.worldSize = 100, 100

MovementModel.worldSize = 100, 100

# seed for movement models' pseudo random number generator (default =

0)

MovementModel.rngSeed = 2

#ReportsInformations

Report.nrofReports = 10

Report.reportDir = reports/Prophet/biasa/std pabrik

#Report classes to load

Report.report1 = MessageStatsReport

Report.report2 = DeliveryCentralityReport

Report.report3 = LatencyPerContact

Report.report4 = CarriedMessageToDestinationReport

Report.report5 = MessageCopyReportperContact

Report.report6 = ReceiveMessage

Report.report7 = BufferOccupancyReport

Report.report8 = LastHopMessageReport

Report.report9 = MessageStatsReportperContact

Figur

Gambar 2.1.1 Mekanisme Store-Carry-Forward pada jaringan
Gambar 2 1 1 Mekanisme Store Carry Forward pada jaringan . View in document p.18
Gambar 2.2.1 Mekanisme Delegation Forwarding berbasis predictability
Gambar 2 2 1 Mekanisme Delegation Forwarding berbasis predictability . View in document p.19
Gambar 2.3.1 ilustrasi metric trasitivity pada PROPHET
Gambar 2 3 1 ilustrasi metric trasitivity pada PROPHET . View in document p.21
Gambar 2.3.2 ilustrasi forwarding strategis PROPHET
Gambar 2 3 2 ilustrasi forwarding strategis PROPHET . View in document p.22
Tabel 3.2.1 Skenario Prophet Haggle3-Infocom5
Tabel 3 2 1 Skenario Prophet Haggle3 Infocom5 . View in document p.23
Tabel 3.2.2 Skenario pergerakan Reality MIT
Tabel 3 2 2 Skenario pergerakan Reality MIT . View in document p.24
Tabel 4.1.1 Hasil perbandingan  protokol PROPHET dan PROPHETDF pada
Tabel 4 1 1 Hasil perbandingan protokol PROPHET dan PROPHETDF pada . View in document p.26
Tabel 4.1.2 Hasil perbandingan  protokol PROPHET dan PROPHETDF pada
Tabel 4 1 2 Hasil perbandingan protokol PROPHET dan PROPHETDF pada . View in document p.27
Gambar 4.2.2 Grafik Message Delivered PerContact Reality MIT
Gambar 4 2 2 Grafik Message Delivered PerContact Reality MIT . View in document p.28
Gambar 4.3.1 Grafik Total Copy Message PerContact Haggle Infocom5
Gambar 4 3 1 Grafik Total Copy Message PerContact Haggle Infocom5 . View in document p.29
Gambar 4.4.1 Grafik Average Latency PerContact Haggle Infocom 5
Gambar 4 4 1 Grafik Average Latency PerContact Haggle Infocom 5 . View in document p.30
Gambar 4.5.1 Grafik Delivery Centrality PROPHET Haggle Infocom 5
Gambar 4 5 1 Grafik Delivery Centrality PROPHET Haggle Infocom 5 . View in document p.31
Gambar 4.5.2 Grafik Delivery Centrality PROPHET Delegation Forwarding
Gambar 4 5 2 Grafik Delivery Centrality PROPHET Delegation Forwarding . View in document p.32
Gambar 4.5.3 Grafik Delivery Centrality PROPHET Reality MIT
Gambar 4 5 3 Grafik Delivery Centrality PROPHET Reality MIT . View in document p.33
Gambar 4.6.1 Grafik Carried Message PROPHET Haggle Infocom 5
Gambar 4 6 1 Grafik Carried Message PROPHET Haggle Infocom 5 . View in document p.34
Gambar 4.6.2 Grafik Carried Message PROPHET Delegation Forwarding Haggle
Gambar 4 6 2 Grafik Carried Message PROPHET Delegation Forwarding Haggle . View in document p.35
Gambar 4.6.4 Grafik Carried Message PROPHET Delegation Forwarding Reality
Gambar 4 6 4 Grafik Carried Message PROPHET Delegation Forwarding Reality . View in document p.36

Referensi

Memperbarui...