analisis unjuk kerja protokol routing ...repository.usd.ac.id/32960/2/145314032_full.pdfiii halaman...

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

2019

PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

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

YOGYAKARTA

2019


iii

HALAMAN PERSETUJUAN

SKRIPSI



OPORTUNISTIK

Oleh:

Krisna Ardian

(145314032)

Telah disetujui oleh:

Dosen Pembimbing,

Bambang Soelistijanto, Ph.D.

Tanggal,…..Januari 2019


iv

HALAMAN PENGESAHAN

SKRIPSI


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,

Sudi Mungkasi, S.Si.,M.Math.Sc.,Ph.D.


v

MOTTO

Pilihan hanya ada di tanganmu

sekarang atau tidak sama sekali - Krisna Ardian


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,

Krisna Ardian


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:



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,

Krisna Ardian


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.

Dari hasil penelitian yang di dapat Delegation Forwarding mengurangi beban copy

di jaringan dengan tetap mempertahankan jumlah pesan yang terkirim dijaringan.


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.

In this study, we analyzed using performance matrix delivered message

percontact, total copy message percontact, average latency percontact, delivery

centrality, carried message to destination. From simulation result, we conclude

delegation forwarding reduce message copy in network and incrase number of

message in the network.


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.

7. Serta seluruh pihak yang mendukung secara langsung maupun tidak

langsung saya ucapkan terimakasih.


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

Krisna Ardian


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

ABSTRACT ........................................................................................................... ix

KATA PENGANTAR ............................................................................................ x

DAFTAR ISI ......................................................................................................... xii

BAB I PENDAHULUAN ....................................................................................... 1

1.1 Latar belakang ............................................................................................. 1

1.2 Rumusan Masalah ....................................................................................... 2

1.3 Tujuan Penelitian ........................................................................................ 2

1.4 Manfaat Penlitian ........................................................................................ 2

1.5 Batasan Masalah.......................................................................................... 2

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

3.1 Parameter Simulasi.................................................................................... 10


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


4.5 Perbandingan Delivery Centrality pada Protokol PROPHET dan PROPHET


4.6 Perbandingan Carried Message pada Protokol PROPHET dan PROPHET


BAB V KESIMPULAN DAN SARAN ............................................................... 24

5.1 Kesimpulan ............................................................................................... 24

5.2 Saran .......................................................................................................... 24

DAFTAR PUSTAKA ........................................................................................... 25

LAMPIRAN .......................................................................................................... 26


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.

Protokol Routing PROPHET (Probabilistic Routing Protocol using

History of Encounters and Transitivity) adalah protokol probabilistik

berdasarkan metrik probabilitas bertemu node lain serta transitivity-nya[1].

Ketika node memiliki probabilitas bertemu node tujuan lebih besar dari node

sebelumnya maka node tersebut dapat menjadi node yang baik sebagai relay

ke node tujuan sehingga node tersebut akan dititipkan pesan oleh node


2

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

Batasan masalah pada penelitian ini adalah sebagai berikut:


3

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

Penarikan kesimpulan terhadap hasil yang telah dianalisis dengan

acuan parameter unjuk kerja yang telah di tentukan.


http://www.shigs.co.uk/index.php?page=traces

4

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

Bab ini berisi kesimpulan yang didapat dari hasil analisis data

simulasi.


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

Pada gambar 2.1.1 adalah mekanisme Store-Carry-Forward yang dimana S adalah

source yang akan mengirim pesan kepada node D yang


6

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

Mekanisme delegation fowarding pada gambar 2.2.1, yang

dimana ketika node A dengan nilai DP 0.3 memiliki pesan M1 yang belum

pernah di kirim sebelumnya dan bertemu dengan node C dengan nilai DP 0.6

maka, node A akan meneruskan pesan kepada node C yang memiliki nilai DP

lebih tinggi dari node A, kemudia node A akan mencatat bahwa pesan M1

pernah di kirim kepada node yang memiliki nilai DP 0.6. Kemudian ketika

node A (DP = 0.3) bertemu dengan node U (DP = 0.4) yang memiliki nilai

DP lebih tinggi daripada node A, pesan tidak akan langsung di teruskan, tetapi

node A akan melakukan check nilai DP pada pesan M1 yang pernah di kirim

sebelumnya dan membandingkan dengan node U, ketika node U tidak lebih


7

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

𝑃(𝑎,𝑏)=𝑃(𝑎,𝑏)𝑜𝑙𝑑 𝑥 𝛾𝑘

Dalam delivery predictability juga memiliki ciri lain berupa

transitive dalam penyampaian pesan. Kondisi semisal node A sering

bertemu node B dan node B sering bertemu node C, maka node A dan


8

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

S


9

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

besar dibanding node C. Maka node source akan mem forward pesan kepada node

yang punya probability bertemu node destination lebih besar yaitu node A.


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

PROTOKOL

JUMLAH

NODE

AREA SIMULASI

(m)

Haggle3-

Infocom5

Prophet & Prophet

DF 41 1000 x 1000

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

TTL 1440 menit & 876001 menit


11

MOVEMENT ROUTING

PROTOKOL

JUMLAH

NODE

AREA SIMULASI

(m)

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

Parameter ini digunakan untuk mengahui node mana saja yang selalu

dipilih dan dianggap terbaik di dalam jaringan, untuk meneruskan

pesan sampai kepada destination.


12

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

Pengujian dilakukan dengan mengguanakn data parameter simulasi serta dengan

menggunakan model pergerakan manusia yang sudah di jabarkan . Kemudian hasil

dari data yang di dapatkan berdasarkan report dan matriks unjuk kerja yang

digunakan


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,

Protokol

Routing

Message

Delivered

Total Copy

Message

Latency

Average

Prophet 3359 118708 25815,2403

ProphetDF 3216 55585 27004,9294


14

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

0

500

1000

1500

2000

2500

3000

3500

4000

TOTA

L M

ESSA

GE

DEL

IVER

ED

CONTACT

MESSAGE DELIVERED PERCONTACT: INFOCOM5

prophet prophet Delegation Forwarding


15

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

2000

4000

6000

8000

10000

12000

14000

16000

18000

50

0

35

00

65

00

95

00

12

50

0

15

50

0

18

50

0

21

50

0

24

50

0

27

50

0

30

50

0

33

50

0

36

50

0

39

50

0

42

50

0

45

50

0

48

50

0

51

50

0

54

50

0

57

50

0

60

50

0

63

50

0

66

50

0

69

50

0

72

50

0

75

50

0

78

50

0

81

50

0

84

50

0

Tota

l Del

iver

ed M

essa

ge

Contact

Message Delivered:Reality MIT

Prophet Prophet Delegation Forwarding


16

4.3 Perbandingan Total Copy Message pada Protokol PROPHET dan


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

20000

40000

60000

80000

100000

120000

140000

160000

50

0

15

00

25

00

35

00

45

00

55

00

65

00

75

00

85

00

95

00

10

50

0

11

50

0

12

50

0

13

50

0

14

50

0

15

50

0

16

50

0

17

50

0

18

50

0

tota

l co

py

mes

sage

contact

Total Copy message:Infocom5


0

5000000

10000000

15000000

20000000

25000000

30000000

50

0

40

00

75

00

11

00

0

14

50

0

18

00

0

21

50

0

25

00

0

28

50

0

32

00

0

35

50

0

39

00

0

42

50

0

46

00

0

49

50

0

53

00

0

56

50

0

60

00

0

63

50

0

67

00

0

70

50

0

74

00

0

77

50

0

81

00

0

84

50

0

Tota

l Co

py

Mes

sage

Contact

Total Copy Message:Reality MIT

prophet Delegation Forwarding


17

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


Gambar 4.4.1 Grafik Average Latency PerContact Haggle Infocom 5

0

2,000,000,000

4,000,000,000

6,000,000,000

8,000,000,000

10,000,000,000

12,000,000,000

14,000,000,000

16,000,000,000

50

0

35

00

65

00

95

00

12

50

0

15

50

0

18

50

0

21

50

0

24

50

0

27

50

0

30

50

0

33

50

0

36

50

0

39

50

0

42

50

0

45

50

0

48

50

0

51

50

0

54

50

0

57

50

0

60

50

0

63

50

0

66

50

0

69

50

0

72

50

0

75

50

0

78

50

0

81

50

0

84

50

0

Ave

rage

Lat

ency

(Se

con

d)

Contact

Average Latency :Reality MIT


0

50,000,000

100,000,000

150,000,000

200,000,000

250,000,000

300,000,000

50

0

15

00

25

00

35

00

45

00

55

00

65

00

75

00

85

00

95

00

10

50

0

11

50

0

12

50

0

13

50

0

14

50

0

15

50

0

16

50

0

17

50

0

18

50

0Late

ncy

ave

rage

(se

con

d)

contact

Latency average percontact:infocom5

prophet Delegation Forwarding


18

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


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.

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

Tota

l Rel

ay M

essa

ge

Node Id

Delivery Centrality :Infocom5

prophet


19

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

Tota

l Rel

ay M

essa

ge

Node Id

Delivery Centrality :Infocom5

Delegation Forwarding


20

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

0

500

1000

1500

2000

2500

3000

3500

0 4 8 11 14 17 20 26 29 33 37 40 43 46 49 52 55 58 62 65 69 72 75 78 81 84 89 92 95

Tota

l Rel

ay M

essa

ge

Node ID

Delivery Centrality:Reality MIT

prophet

0

500

1000

1500

2000

2500

3000

3500

0 4 8 11 14 17 20 26 29 33 37 40 43 46 49 52 55 58 62 65 69 72 75 78 81 84 89

Tota

l Rel

ay M

essa

ge

Node ID

Delivery Centrality:Reality MIT



21

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


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

-50

50

150

250

350

450

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 31 33 35 37 39

Tota

l Car

ried

Mes

sage

To

Des

tin

atio

n

Node Id

Carried Message To Destination:Infocom 5

prophet


22

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

50

100

150

200

250

300

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 31 33 35 37 39

Tota

l Car

ried

Mes

sage

To

Des

tin

atio

n

Node Id

Carried Message To Destination:Infocom 5


0

200

400

600

800

1000

1200

1400

1600

0 3 6 9 12151821252831343740434649525558616468717477808387909396

Tota

l Car

ried

Mes

sage

To

Des

tin

atio

n

Node Id

Carried Message To Destination :Reality MIT

Prophet


23

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

200

400

600

800

1000

1200

1400

1600

1800

0 3 6 9 12151821252831343740434649525558616468717477808387909396

Tota

l Car

ried

Mes

sage

To

Des

tin

atio

n

Node Id

Carried Message To Destination :Reality MIT



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

kekurangan dari delegation forwarding


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.


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)) {

beta = s.getDouble(BETA_SETTING);


27

} 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;



28

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,

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


29

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;

}

public boolean isFinalDest(Message m, DTNHost aHost) {


30

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) {

return m.getTo() == hostReportingOld;


31

}

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();

}

/**

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


32

* 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;

protected static final double DEFAULT_BETA = 0.25;


33

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)) {

pinit = s.getDouble(P_INIT_SETTING);


34

} else {

pinit = DEFAULT_P_INIT;

}

if (s.contains(SECONDS_IN_UNIT_S)) {

secondsInTimeUnit = s.getInt(SECONDS_IN_UNIT_S);

} else {

secondsInTimeUnit = DEFAULT_UNIT;

}


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;


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) {

}


35

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;

if (preds.containsKey(h)) {


36

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) {

return m.getTo() != thisHost;


37

}

@Override

public boolean shouldSendMessageToHost(Message m, DTNHost

otherHost) {

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

return true;

}

ProphetDecisionEngineDF de =

getOtherProphetDecisionEngine(otherHost);

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

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

mUtil.put(m.getId(), de.getPredFor(m.getTo()));

return true;

} else {

if (de.getPredFor(m.getTo()) > mUtil.get(m.getId())) {

mUtil.replace(m.getId(), de.getPredFor(m.getTo()));

return true;

} else {

return false;

}

}

} else {

return false;

}

}

@Override

public boolean shouldDeleteSentMessage(Message m, DTNHost

otherHost) {


38

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);

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


39

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

#%%DecisionEngineRouter.rng%%


40

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

Group.msgTtl = 1440


41

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

Events2.interval = 58, 62


42

#Events2.interval = 290, 310


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/

#Report classes to load


43

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

btInterface.scanInterval = 120


44

#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

#36 Haggle Cam


45

#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.time = 0, 15167416

#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


46

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

Report.report10 = MessageStatsReportperTime


analisis unjuk kerja protokol routing ...repository.usd.ac.id/32960/2/145314032_full.pdfiii halaman...

Documents