ANALISIS UNJUK KERJA PROPHET BERBASIS ... tugas akhir, terimakasih atas bimbingan, kritik, saran, waktu dan kesabarannya dalam membimbing penulis hingga akhir. ...

ANALISIS UNJUK KERJA PROPHET BERBASIS PENGGUNAAN

BUFFER DI JARINGAN OPORTUNISTIK

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat

Memperoleh Gelar Sarjana Komputer

Program Studi Teknik Informatika

Oleh :

Feliks Yudha

135314002

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA

YOGYAKARTA

2017

PLAGIAT MERUPAKAN TINDAKAN TIDAK TERPUJI

i

ANALISIS UNJUK KERJA PROPHET BERBASIS PENGGUNAAN

BUFFER DI JARINGAN OPORTUNISTIK

SKRIPSI

Diajukan Untuk Memenuhi Salah Satu Syarat

Memperoleh Gelar Sarjana Komputer

Program Studi Teknik Informatika

Oleh :

Feliks Yudha

135314002

PROGRAM STUDI TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKA

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS SANATA DHARMA

YOGYAKARTA

2017


ii

PERFORMANCE EVALUATION PROPHET ROUTING

PROTOCOL BASED ON USE BUFFER IN OPPORTUNISTIC NETWORK

A THESIS

Presented as Partial Fulfillment of Requirements

To Obtain Sarjana Komputer Degree

In Informatics Engineering Department

By :

Feliks Yudha

135314002

INFORMATIC ENGINEERING STUDY PROGRAM

DEPARTMENT OF INFORMATIC ENGINEERING

FACULTY OF SCIENCE AND TECHNOLOGY

SANATA DHARMA UNIVERSITY

YOGYAKARTA

2017




v

MOTTO

“When life gets you down, you know what you gotta do? Just keep swimming.”

- Dory ( Finding Nemo, Finding Dory)




viii

ABSTRAK

Jaringan Oportunistik merupakan jaringan yang dibangun pada kondisi

berdeda dari jaringan yang dibangun pada umumnya. Jaringan ini lebih sering

dibangun dan dikembangkan pada kondisi yang ekstrim dikarenakan jaringan yang

sering terputus dan berubah dalam segi topologinya. Dengan kondisi seperti ini,

jaringan ini dituntut untuk mampu menyampaikan pesan dari asal (source) ke tujuan

(destination) dengan memanfaatkan sebuah protokol jaringan. Disini penulis akan

menggunakan Protokol PROPHET berbasis buffer dari setiap node sebagai

pembawa pesan. Dengan begitu, penulis akan mengambil parameter seperti,

delivery ratio, overhead ratio, delay, dan drop sebagai bahan analisis dari protokol

ini menggunakan Simulator ONE (Opportunistic Network Environment).

PROPHET berbasis buffer ini dinamakan PROPHETAB (Average Buffer).

Diketahui bahwa pada PROPHET, pesan yang dibawa oleh node akan dikirimkan

berdasarakan probabilitas node. Probabilitas node untuk bertemu node lain bernilai

tinggi akan dipercaya sebagai pembawa pesan yang baik untuk sampai ditujuan. Ini

mengakitbatkan buffer pada node dengan probabilitas tinggi cenderung memiliki

buffer yang tinggi pula. Dengan menggunakan PROPHETAB ini, penulis ingin

menambah kriteria dalam pengiriman pesan sampai ke tujuan dengan pertimbangan

buffer node. Node yang memiliki probabilitas yang tinggi belum tentu menjadi

pembawa pesan yang baik jika memiliki buffer yang tinggi. Dari hasil analisis dan

penelitian diketahui PROPHETAB mampu meminimalisir dari segi overhead ratio

dan Drop pada jaringan dikarenakan PROPHETAB cenderung memilih atau

selektif dalam melakukan pengiriman pesan untuk sampai ke tujuan.

***Kata Kunci : Jaringan Oportunistik, Protokol PROHET, DTN (Delay Tolerant

Network), ONE Simulator, Delivery Ratio, Overhead Ratio, Delay, Drop, Random

Waypoint, Haggle Cambridge Imote.


ix

ABSTRACT

Opportunistic Network is a network which built in network that have

different situation from another network that built in general. This network more

often built and developed in some extreme network situation because the network

is often disconnected and topology changed. In this kind of situation, this network

required to be able to deliver message from source to destination using a network

protocol. In this research, Author will be using based-buffer PROPHET Protocol

from each node as the messenger. That way, Author will take some parameters as

delivery ration, overhead ratio, delay, and drop as an analysis material of this

protocol using Simulator ONE (Opportunistic Network Environment).

This based-buffer PROPHET named PROPHETAB (Average Buffer). It is

known in PROPHET, messages carried by the node will be transmitted bassed on

node’s probality. Probality of node to meet other high value nodes will be trusted

as a good messenger to arrive at. This make high probality node’s buffer tend to

have high buffer. By using this PROPHETAB, the author wants to add the criteria

in sending messages to destination with consideration of buffer node. A high-

probability node may not necessarily be a good messenger if it has a high buffer.

From the results of analysis and research known PROPHETAB able to minimize in

terms of overhead ratio and drop on the network because PROPHETAB tend to

choose or selective in sending messages to get to the destination.

***Keyword : Opportunistic Network, PROHET Protocol, DTN (Delay Tolerant

Network), ONE Simulator, Delivery Ratio, Overhead Ratio, Delay, Drop, Random

Waypoint, Haggle Cambridge Imote.


x

KATA PENGANTAR

Tidak ada kata – kata yang paling indah selain mengucapkan syukur atas

kehidupan yang ku percaya dan kuyakini berasal dari Tuhan. Terimakasih pada-mu

Yesus Kristus dan seluruh malaikat putih dan hitam sehingga penulis dapat

menyelesaikan tugas akhir dengah judul “analisis unjuk kerja prophet berbasis

penggunaan buffer di jaringan oportunistik”. Tugas akhir ini memang merupakan

syarat akhir bagi penulis sebelum resmi mendapatkan gelar sebagai seorang sarjana

di program studi Teknik Informatika Sanata Dharma Yogyakarta.

Selain pada Tuhan, penulis juga ingin berterimakasi pada ciptaan-NYA

yang lain, meliputi pihak – pihak yang telah membantu dan terus mengingatkan

dalam proses penulisan ini. Ucapan terimakasih ini penulis sampaikan kepada :

1. KepadaMU lagi, Tuhan Yesus Kristus, Bunda Maria, Santo Yusuf yang

selalu memberikan berkat dan senantiasa menyertai dalam setiap usaha

hingga selesainya penulisan tugas akhir ini.

2. Ibu penulis, Yuliana sebagai donatur tetap yang selalu setia

memberikan dana selama menjalankan pendidikan dan selalu

memberikan semangat, doa dan waktu untuk mengingatkan penulis

sebagai anak.

3. Bapak Bambang Soelistijanto, S.T., M.Sc., Ph.D. selaku desen

pembimbing tugas akhir, terimakasih atas bimbingan, kritik, saran,

waktu dan kesabarannya dalam membimbing penulis hingga akhir.

4. Bapak Sudi Mungkasi, S.Si., M.Math.Sc.,Ph.D. selaku Dekan Fakultas

Sains dan Teknologi.

5. Ibu Dr. Anastasia Rita Widiarti, M.Kom. selaku Ketua Jurusan Teknik

Informatika Fakultas Sains dan Teknologi Universitas Sanata Dharma

Yogyakarta.

6. Ibu Sri Hartati Wijono, M.Kom. selaku dosen pembimbing akademik

nonaktif, terimakasih atas bimbingan, kritik dan saran yang telah

diberikan kepada penulis.

7. Bapak Puspaningtyas Sanjoyo Adi, S.T., M.T. selaku dosen

pembimbing aktif menggantikan Ibu Sri Hartati Wijono, M.Kom. pada


xi

dua smester akhir, terimakasih atas bimbingan, kritik dan saran yang

telah diberikan kepada penulis.

8. Bapak Alb. Agung Hadhiatma, S.T., M.T. dan Puspaningtyas Sanjoyo

Adi, S.T., M.T. selaku dosen penguji skripsi, terimasih telah

meluangkan waktu dan menguji hasil tugas akhir penulis.

9. Seluruh staf dosen Teknik Informatika Universitas Sanata Dharma

Yogyakarta yang telah memberikan bekal ilmu, terutama dalam bidang

informatika serta pengalaman selama penulis menempuh studi.

10. Seluruh staf Sekretariat Fakultas Sains dan Teknologi atas selaga

informasi dan pelayanan yang telah diberikan demi kelancaran

administrasi penulis.

11. Keluarga di Sosok yang selalu mendukung hingga selesai penulisan

tugas akhir.

12. Seluruh teman – teman Jarkom 2013, Basdat 2013, Komputasi 2013

dan teman – teman yang masih menempuh skripsi, terimasih atas

semangat, kritik dan sarannya sebagai teman seperjuangan

menyelesaikan tugas akhir (Raymond “Orang Mampu”, Hotman

“Budak Ponti’, Mario “Raja Pantai Lengkuas, Andre “Bruno Mars”

Adrian “Contong”, Heri “Drone”, Vinsen Mulyadi, Ardy, Wicak,

Agung, Sulis, Daniel, Ino, Benny “Jenang”, Petra “MMK EI”, Alex,

Jonathan dll) atas kerjasamanya selama penulisan.

13. Seluruh teman – teman Kos Horor (Pang Yayan KH, Johan Men, Adven

Men, ex Adit GMB, ex Andre Nokturnal, ex Hotman KOREM, ex

Make FAR, Deo Kuliah, Yanto Signature) terimakasih atas tempat yang

selalu nyaman dalam menyesaikan kuliah dan penulisan.

14. Seluruh teman – teman Dango (dheialicious “ My Girl Friend”, Bg

Areszaga SKT, Kak Dovi “Dompeng”, Kak Ria, Ona Uno, Firto Em Te

Pe, Reza, Cia “Zebra Kalteng”), terimasih telah memberikan ruang

untuk menikmati suasana Jogja dalam canda gurau.

15. Semua pihak yang membantu dan mendukung dari awal, proses hingga

selesainya penulisan tugas akhir ini.



xiii

DAFTAR ISI

HALAMAN PERSETUJUAN ............................................................................... iii

ABSTRAK ............................................................................................................. vi

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

DAFTAR ISI ........................................................................................................ xiii

DAFTAR TABEL ............................................................................................... xvii

DAFTAR GAMBAR ......................................................................................... xviii

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

1.1. Latar Belakang ......................................................................................... 1

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

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

1.4. Batasan Masalah ......................................................................................... 2

1.5. Metode Penelitian ....................................................................................... 3

1.5.1. Studi Literatur ................................................................................... 3

1.5.2. Perancangan ...................................................................................... 3

1.5.3. Pembangunan Simulasi dan Pengumpulan Data ............................... 3

1.5.4. Analisis dan Simulasi ........................................................................ 3

1.5.5. Penarikan Kesimpulan ...................................................................... 4

1.5.6. Sistematika Penulisan ....................................................................... 4

BAB II ..................................................................................................................... 5

2.1. Mobile Ad hoc Network (MANET) ............................................................ 5

2.2. Jaringan Oportunistik ................................................................................. 6

2.2.1. Karakteristik Pada Jaringan Opportunistic .......................................... 8

2.3. PROPHET (Probabillistic Routing using History of Encounter and

Tansitivity) ........................................................................................................... 9


xiv

2.4. Pergerakan Random Waypoint ................................................................. 11

2.5. Pergerakan Manusia (Haggle4 Cambridge Imote) ................................... 11

2.6. Pergerakan Manusia (MIT) ........................................................................ 12

2.7. Simulator ONE ......................................................................................... 13

BAB III ................................................................................................................. 14

3.1. PROPHET Averrage Buffer (PROPHETAB) .......................................... 14

3.2. Parameter Simulasi ................................................................................... 16

3.4. Parameter Kerja ........................................................................................ 17

BAB IV ................................................................................................................. 20

4.1. Random Waypoint .................................................................................... 20

4.1.1. Penambahan Jumlah Node ................................................................. 20

Gambar 4. 1. Random Waypoint : Dampak penambahan jumlah node terhadap

Buffer Occupancy ................................................................................................. 22











4. 2. Pergerakan Manusia (Haggle4 Cambridge Imote) .................................. 26

Tabel 4.2. Hasil perbandingan pada Pergerakan Manusia (Haggle4 Cambridge

Imote) .................................................................................................................... 26


xv

Gambar 4. 7. Grafik perbandingan Delivery Ratio Pada Pergerakan Manusia

(Haggle4 Cambridge Imote) ................................................................................. 27

Gambar 4. 8. Grafik perbandingan Overhead Ratio Pada Pergerakan Manusia


Gambar 4. 9. Grafik perbandingan Delay Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 28

Gambar 4. 10. Grafik perbandingan Drop. Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 29

Gambar 4. 11. Dampak buffer occupancy Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 30

Tabel 4. 3. Hasil Pengujian Pada Pergerakan Manusia (MIT) .............................. 30


(MIT) ..................................................................................................................... 31


(MIT) ..................................................................................................................... 32

Gambar 4. 14. Grafik perbandingan Delay Pada Pergerakan Manusia (MIT) ...... 32

Gambar 4. 15. Grafik perbandingan Drop Pada Pergerakan Manusia (MIT) ....... 33

Gambar 4. 16. buffer occupancy Pada Pergerakan Manusia (MIT) ...................... 33

BAB V ................................................................................................................... 34

5.1. Kesimpulan ............................................................................................... 34

5.2. Saran ......................................................................................................... 34

DAFTAR PUSTAKA ........................................................................................... 36

LAMPIRAN .......................................................................................................... 37

A. Listing Program PROPHETAB ................................................................. 37

B. Listing Program Buffer Occupacy Report .................................................. 47

C. Skenario Simulasi ...................................................................................... 53


xvi

D. Skenario Simulasi ...................................................................................... 56

E. Skenario Simulasi ...................................................................................... 58


xvii

DAFTAR TABEL

Tabel 3.1. Parameter Simulasi .............................................................................. 16

Tabel 3.2. Skenario penambahan jumlah node pada pergerakan Random Waypoint

............................................................................................................................... 16

Tabel 3.3. Skenario Pergerakan Manusia .............................................................. 17

Tabel 3.4. Skenario Pergerakan Manusia (Haggle4 Cambridge Imote) ............... 17

Tabel 3.5. Skenario Pergerakan Manusia (MIT) ................................................... 17

Tabel 4.1. Hasil Pengujian Penambahan Node pada pergerakan Random Waypoint

............................................................................................................................... 20

Tabel 4.2. Hasil perbandingan pada Pergerakan Manusia (Haggle4 Cambridge

Imote) .................................................................................................................... 26


xviii

DAFTAR GAMBAR

Gambar 2.1. Model Store-Carry-Forward .............................................................. 7

Gambar 2.2. Arsitektur Delay Tolerant Network.................................................... 7

Gambar 2.3. Ilustrasi metrik transitivity pada protokol PROPHET ..................... 10

Gambar 2.4. Ilustrasi Pergerakan Random Waypoint ........................................... 11

Gambar 2.5. Snapshoot Simulator ONE ............................................................... 13

















Gambar 4. 9. Grafik perbandingan Delay Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 28

Gambar 4. 10. Grafik perbandingan Drop. Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 29

Gambar 4. 11. Dampak buffer occupancy Pada Pergerakan Manusia (Haggle4

Cambridge Imote) ................................................................................................. 30


(MIT) ..................................................................................................................... 31


xix


(MIT) ..................................................................................................................... 32

Gambar 4. 14. Grafik perbandingan Delay Pada Pergerakan Manusia (MIT) ...... 32

Gambar 4. 15. Grafik perbandingan Drop Pada Pergerakan Manusia (MIT) ....... 33

Gambar 4. 16. buffer occupancy Pada Pergerakan Manusia (MIT) ...................... 33


1

BAB I

PENDAHULUAN

1.1. Latar Belakang

Jaringan yang kita ketahui dalam kondisi tetap (fixed) memiliki infrastruktur

dalam pembentukkannya. Jaringan dengan infrastruktur merupakan jaringan yang

memanfaatkan perangkat acces poin, router dan pendukung lainnya dan masuk

dalam kategori jaringan kabel (wired) dan nirkabel (wireless) [7].

Dengan semakin pesatnya perkembangan teknologi, maka kebutuhan akan

jaringan semakin kompleks. Jaringan kabel dan nirkabel selalu mampu mengatasi

masalah pada saat keadaannya tetap, tetapi tidak jika perangkat yang kita gunakan

berbasis bergerak (mobile). Penggunaan seperti ini memanfaatkan jaringan nirkabel

selama masing dalam jangkauan radio.

Pada jaringan yang menggunakan infrastruktur masih tetap digunakan.

Permasalahannya sekarang bagaimana jika jaringan yang menggunakan

infrastruktur ini tidak tersedia? Sangat jelas komunikasi akan menjadi terhambat.

Dan bagaimana pengguna dapat tetap melakukan komunikasi dengan

memanfaatkan jaringan nirkabel pada perangkat berbasis mobile?

Dalam mengatasi permasalahan seperti ini telah muncul penemuan yang

memungkinkan kita untuk tetap berkomunikasi yang tidak menggunakan

infrastruktur dalam proses transmisi. Permasalahan selanjutnya terletak pada

perangkat mobile berupa node dan mobilitas pengguna dalam pergerakkannya.

Strategi ini menggunakan MANET (Mobile Ad Hoc Network). Dengan

memanfaatkan node sebagai delivery message dari source menuju destination.

Jaringan komunikasi pada MANET ini tetap bisa terbubung jika node – node

masih berada pada jangkauan radio yang sama. Tetapi jika node keluar dari

jangkauan radio, maka node terlepas dari node pusat yang mengakibatkan terjadi

link failure. Muncul inovasi untuk memperbaiki kinerja MANET pada jaringan

menggunakan Jaringan Opportunistic. Dengan memanfaatkan berbagai macam

routing protocol dalam melakukan delivery message, forwarding hingga sampai ke

destination. Perbedaan mendasar MANET dan Jaringan Oportunistik terletak pada

toleransi jeda tunda penyampaian pesan ke tujuan yang dilakukan pada Jaringan


2

Oportunistik.

Protocol Routing PROPHET (Probalilistic Routing Protocol using History of

Encounter and Transitivity) yang berdasar pada history bertemunya node dengan

keterkainnya dengan node lain yang disebut transitivity. Node akan dipercaya

sebagai relay pesan yang baik jika node tersebut memiliki probalistik pertemuannya

tinggi bertemu node lainnya dan juga berdasar pada transitivity. Terdapat node yang

populer dalam sebuah jaringan, node ini disebut sebagai hub-node. Node yang

dipercaya dapat melakukan delivery message dengan optimal ke destination. Tetapi

jika hub node ini dititipi banyak pesan, maka akan berakibat pada beban kerja hub-

node yang tinggi yang berdampak pada resource karena menangani banyak pesan

yang dititipi.

Dalam permasalahan ini, penulis tertarik untuk menganalisis unjuk kerja

Routing Protocol PROPHET mengunakan parameter kinerja (delivery probability,

overhead ratio, delay dan message drop) dengan average Buffer Occupancy

sebagai kriteria tambahan untuk membantu kinerja delivery predactibility pada

pergerakan Random Waypoint dan pergerakkan manusia (Haggle4 Cambridge

Imote).

1.2. Rumusan Masalah

Berdasarkan latar belakang, pada rumusan masalah ini ingin melihat

sebagaimana efektif parameter kinerja sebuah protocol routing PROPHET

dibandingkan dengan PROPHETAB.

1.3. Tujuan Penelitian

Penelitian ini bertujuan untuk mengetahui dan menganalisis kelebihan dan

kekurangan yang dimiliki protocol routing PROPHET dan PROPHET yang penulis

modifikasi dengan tambahan average buffer occupancy (PROPHETAB) dalam

melakukan forward message berdasarkan pada konsep pada routing PROPHET.

1.4. Batasan Masalah

Batasan masalah dalam penelitian yang dilakukan meliputi :

1. Protocol routing yang digunakan adalah protocol routing PROPHET

2. Protocol Routing PROPHETAB (PROPHET average buffer)


3

3. Menggunakan Pergerakan Random Waypoint dan Pergerakan Manusia

(Haggle4 Cambridge Imote), Pergerakan Manusia (MIT).

4. Performance Metric berupa delivery probability, overhead ratio dan

delay.

1.5. Metode Penelitian

Metode dan langkah dalam penyusunan penelitian ini adalah sebagai

berikut :

1.5.1. Studi Literatur

Mempersiapakan dan mendalami teori pendukung dalam penelitian

meliputi :

a) Teori Routing Protokol PROPHET pada Jaringan Opportunistik

b) Teori pergerakan Random Waypoint dan pergerakan manusia

(Haggle4 Cambridge Imote), pergerakan manusia (MIT).

c) Teori parameter kinerja (delivery ratio, overhead ratio, delay dan

message drop).

d) Pendokumentasian pada ONE Simulator.

1.5.2. Perancangan

a) Menggunakan pergerakkan Random Waypoint, pergerakkan

manusia (Haggle Cambridge Imote), pergerakan manusia (MIT).

b) Jumlah node di set bervariasi pada pergerakkan Random

Waypoint.

c) Ukuran buffer tetap.

1.5.3. Pembangunan Simulasi dan Pengumpulan Data

ONE simulator digunakan dalam penelitian ini dan untuk membentuk

report dalam pengumpulan data sesuai dengan parameter kinerja sebagai

kebutuhan penelitian.

1.5.4. Analisis dan Simulasi

Data yang sudah didapatkan dari hasil simulasi akan diproses kemudian

diamati serta dianalisis sesuai dengan kebutuhan penelitian.


4

1.5.5. Penarikan Kesimpulan

Dalam penarikan kesimpulan mengacu pada hasil analis parameter

kinerja yang sudah ditetapkan dalam penelitian.

1.5.6. Sistematika Penulisan

Berikut adalah sistematika penulisan penelutian Tugas Akhir yang

terbagi dalam beberapa bab dengan susunan sebagai berikut :

BAB I PENDAHULUAN

Bab ini memberikan penjelasan secara umunm mengenai latar

belakang penulisan penelitian tugas akhir.

BAB II LANDASAN TEORI

Bab ini berisikan mengenai penjelasan teori sebagai acuan atau

landasan yang dibutuhkan dalam proses melakukan penelitian sesuai dengan

permasalahan.

BAB III PERENCANAAN SIMULASI JARINGAN

Bab ini memuai deskripsi secara teknis mengenai perencanaan dari

simulasi yang akan dikerjakan dalam tugas akhir.

BAB IV PENGUJIAN DAN ANALISIS

Bab ini berisi pelaksanaan simulasi dan analisis data hasil simulasi

BAB V KESIMPULAN DAN SARAN

Bab ini bersi mengenai kesimpulan dari hasil analisis data simulasi

berdasar pada parameter kinerja serta saran untuk kedepannya dalam proses

pengembangan.


5

BAB II

LANDASAN TEORI

2.1. Mobile Ad hoc Network (MANET)

MANET adalah jaringan tanpa memerlukan infrastruktur. Node pada

MANET bergerak secara mobile. dengan pergerakkan seperti ini node berperan

multi pada jaringan MANET. Kebutuhan host dan router diambil alih oleh setiap

node agar dapat membangun komunikasi.

MANET juga dikatakan sebagai jaringan yang dibentuk sementara oleh

node – node tanpa adanya infrastruktur kabel yang bersifat peer-to-peer yaitu

komunikasi dua node dalam satu hop, Remote-to-Remote sebagai perkembangan

dari peer-to-peer yang tetap menjaga kestabilan rute antara keduanya. MANET

memiliki karakteristrik dalam keberadaannya, meliputi :

a. Topologi yang Dinamis

Bersifar dinamis berarti node dapat bergerak dan berpindah dari satu

tempat ke tempat lainnya yang tidak dapat prediksi. Dengan karateristik

seperti ini, akan berpengaruh besar terhadap topologi jaringan.

b. Otonomi

Dalam penentuan rute yang dipilih, node berperan host dan router

dalam pergerakkannya pada jaringan ini. Node memiliki route-path yang

terbentuk dalam melakukakan relay ke node lainnya.

c. Keterbatasan Bandwith

Kapasitas node dalam berkomunikasi pada jaringan ini berbanding

rendah dibanding dengan kapasitasnya dalam melakukan transmisi data. Ini

dapat mengakibatkan kemacetan (congestion) pada jaringan.

d. Keterbatasan Energi

Dengan sifat mobile seperti ini, node memiliki energi yang terbatas

dalam pergerakkannya. Dengan kata lain, node dilengkapi dengan batrai

sebagai pembangkit agar dapat beroperasi.


6

2.2. Jaringan Oportunistik

Jaringan Oportunistik (OppNet) adalah sebuah jaringan wireless dimana pada

saat konektivitas antara end-to-end tidak dapat diperkirakan, kemudian node nya

bersifat intermittent, dimana node tersebut terkadang terhubung dan juga tidak

terhubung. Ini memungkinkan jaringan oportinistik dibangun dan dapat

berkomunikasi tanpa infrastruktur. Jaringan Oportunistik juga dikenal dengan DTN

(delay Toleran Network) yang merupakan protokol komunikasi yang menyediakan

koneksi dakam keadaan konektivitas end-to-end yang tidak normal dan memiliki

mobilitas yang tinggi. Pada jaringan ini menggunakan skema single coppy dan

multi copy. Pada single copy hanya meneruskan satu pesan dalam jaringan,

sedangkan pada multi copy akan meneruskan banyak pesan dalam jaringan.

Penelitian ini dilakukan dengan tujuan untuk menguji kinerja dari sebuah protokol

routing pada jaringan oportunistik agar dihasilkan solusi yang memadai dan optimal

dalam melakukan pengiriman pesan. Dalam penelitian ini menggunakan routing

protokol PROPHET dengan skema multi copy dalam jaringan.

Jaringan oportunistik merupakan jaringan yang dibangun karena berbagai

macam permasalahan dilingkungan yang berhubungan dan komunikasi. Jaringan

ini cocok di bangun pada jaringan yang menantang. Menantang maksudnya

jaringan yang sering terputus dan memiliki tingkat error yang cenderung tinggi.

Masalah seperti ini dapat kita temukan pada daerah pedalaman yang jauh dari pusat

kota, dimana sudah cukup banyak terdapat penduduk, tetapi belum memiliki

layanan komunikasi yang baik. Jaringan ini juga dapat diterapkan pada daerah

dengan tingkat bencana yang tinggi. Bencana ditidak dapat diprediksi dengan tepat

dan jaringan oportunistik terbentuk sebagai solusi yang akan menjawab agar

komunikasi dapat berjalan dengan baik walaupun terjadi bencana didaerah tersebut.

Terdapat metode store-carry-forward pada DTN yang memungkinkan data

yang dikirimkan melewati node relay, kemudian datanya disimpan sementara

terlebih dahulu sebelum diteruskan ke node relay lainnya. Ini bertujuan untuk

mengantisipasi kondisi dari node lainnya sebagai relay yang sewaktu – waktu dapat

saja mati. Dibawah ini terdapat model store-carry-forward pada DTN.


7

Gambar 2.1. Model Store-Carry-Forward

a. Store : dari setiap node pada DTN ini akan menyimpan pesan

yang masuk.

b. Carry : dari setiap node akan membawa pesan yang masuk

menuju destination dari source ke destination

c. Forward : dari setiap node akan mengirim pesan ke node lainnya

menuju destination setiap kali kontak dilakukan.

Pada Gambar 2.1 menjelaskan ilustrasi node A akan mengirimkan data ke

node D. node B dan node C sebagai node relay bagi node A. Saat melewati node B

dan node C, data dari node A akan disimpan terlebih dahulu selagi menunggu

kesiapan dari node relay selanjutnya. Metode seperti ini mengharuskan setiap node

memili media penyimpanan data sementara sebagai antisipasi jika node relay

selanjutnya dalam kondisi mati. Melihat kondisi sepertini ini, DTN memunculkan

layer yang disebut Bundle Layer dengan tujuan membantu kerja store-carry-

forward dalam mengahadapi rute yang terputus dalam pengiriman data. Node dapat

melakukan store (simpan) dan carry (bawa) data didalam buffer, kemudian

meneruskan data yang dikirim ke node lain.

Gambar 2.2. Arsitektur Delay Tolerant Network


8

2.2.1. Karakteristik Pada Jaringan Opportunistic

a. Pemutusan

Kondisi tidak ada koneksi yang dibangun antara node-node yang

hidup.

b. Intermittent Connectivity

Pada kondisi seperti ini memungkinkan komunikasi end-to-end

dapat dilakukan menggunakan TCP/IP dalam pengiriman data dari

sumber (source) ke tujuan (destination).

c. Waktu Tunda

Waktu tunda (delay) pada DTN tergolong tinggi pada kondisi

tidak ada koneksi antar node.

d. Low Data Rate

Low Data Rate dapat terjadi dikarenakan waktu tunda (delay)

yang terlalu lama pada node-node. Karakter ini memungkinkan kita

mengetahui jumlah data yang dapat sampai dalam jangka waktu

tertentu.

e. Hight Error Rate

Kesalahan yang terjadi saat pengiriman data yang

membutuhkan pengoreksian dan pengiriman ulang data pada jaringan.

Ini dapat menyebabkan kemacetan pada jaringan oleh meningkatnya

pengiriman data karena adanya pengiriman data yang diulang.

f. Sumber Daya yang terbatas

Pada kondisi DTN ini berbasis mobile, berarti setiap node yang

bergerak memerlukan energi atau batrai dalam mendukung

pergerakkanya. Agar dapat bekerja secara efisien harus diimbangi

dengan metode yang tepat dalam membentuk manajemen protokol ini.

g. Long or Variable Delay

Node pada DTN memiliki store untuk menyimpan sementara

pesan yang belum dikirimkan ke node relay lainnya. Jika ini terjadi

dalam waktu tunda (delay) yang terlampau lama, maka akan

menyebabkan pemutusan yang panjang pada rute pengiriman data.


9

2.3. PROPHET (Probabillistic Routing using History of Encounter and

Tansitivity)

Protokol Routing PROPHET merupakan protokol routing yang terbentuk

agar dapat memprediksi probabilitas bertemunya node akan bertemu kembali pada

waktu yang relatif tidak lama. Kemudian terdapat transitivity, kondisi node lain

mempunyai pontensi sebagai node relay atau node perantara pada pengiriman pesan

ke tujuan (destination).

Untuk menghitung probabilitas node bertemu dengan node lainnya pada

jaringan diperlukan sebuah parameter delivery predictability.

a. Perhitungan 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 dimana P𝑖𝑛𝑖𝑡 ∈ [0,1].

P(a,b) = P(a,b)old + (1 – P(a,b)old) x Pinit (1)

Jika node yang sudah bertemu tetapi terlaupau 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 anging ditunjukkan

pada rumus berikut.

P(a,b) = P(a,b)old x γk (2)

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 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.


10

P(a,c) = P(a,c)old + (1 – P(a,c)old) x P(a,b) x P(b,c) x β (3)

Gambar 2.3. Ilustrasi metrik transitivity pada protokol PROPHET

Transitivity pada routing protokol PROPHET seperti Gambar 2.3 ini

menunjukkan untuk mengukur kedekatan node a terhadap node c secara

langsung maupun melaui node b.

Setelah tahap tersebut terpenuhi, selanjutnya pada rumus dibawah ini

menunjukkan penambahan kriteria dalam pengiriman pesan berbasis

buffer. Ini masuk pada tahap membandingkan buffer dari node, hanya

node yang memiliki buffer lebih kecil setelah dibandingkan yang akan

dititipi pesan.

Buffer(a : b) = Buffer(a) > Buffer(b) (4)

b. Strategi pengiriman Pesan

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. Tetapi pada PROPHETAB, selain pesan dikirimkan ke

node lain yang memiiki probabilitas yang lebih tinggi, node yang membawa

pesan juga akan mempertimbangkan buffer size node yang ditemuinya. Pesan

akan dikirimkan jika node memiliki probabilitas yang lebih tinggi dan

memiliki buffer yang kecil dari node yang membawa pesan.


11

2.4. Pergerakan Random Waypoint

Pergerakkan ini beroperasi pada area tetap (fixed) (lihat Gambar 2.4). Model

pergerakkan ini akan memilih tujuan (destination) secara acak, kemudian bergerak

lurus pada kecepatannya yang sudah ditentukan sebelumnya. Jika node sudah

sampai ke tujuan (destination), node akan masuk pada tahap berhenti selama waktu

yang tentukan (pause time). Pada pergerakan ini, predictability untuk bertemu node

lainnya diasumsikan sama atau dengan kata lain dalam pergerakan random

waypoint ini setiap node merupakan relay yang baik dalam penyampaian pesan ke

destination.

Gambar 2.4. Ilustrasi Pergerakan Random Waypoint

2.5. Pergerakan Manusia (Haggle4 Cambridge Imote)

Pergerakkan ini adalah pergerakan yang nyata di lingkungan. Umumnya

pergerakan manusia digunakan untuk mengevalusai protokol routing dalam

pengoperasian. Manusia tidak bergerak secara random, melainkan bergerak sesuai

jadwal dari manusia yang tidak dapat diprediksikan. Node akan mengikuti

pergerakkan manusia hingga sampai ke tujuan tertentu (poin to interest).

Pada Haggle4 Cambridge Imote memiliki spesifikasi data set kontak node

pada sebuah konferensi yang di selenggarakan di Cambridge, Inggris dengan alat

yang digunakan berupa Imotes dan menggunakan interface bluetooth. Dibutuhkan


12

waktu 11 hari dalam melakukan simulasi pada pergerakan haggle4 cambridge

imote dan node di set sebanyak 36 node. Di pergerakan manusia ini, probabilitas

node untuk bertemu dengan node lainnya berdeda – beda. Saat simulasi dijalankan

akan terdapat node yang memiliki probabilitas yang tinggi dibandingkan dengan

node yang lain. Node ini kita kenal sebagai hub-node, dipercaya mampu

menyampaikan pesan dengan baik sampai ke destination.

2.6. Pergerakan Manusia (MIT)

Pada pergerakan ini dibutuhkan waktu selama satu tahun (365 hari) waktu

simulasi atau data di ambil dari antara 4294800 dan 21276000 seconds [5]. Pada

simulasi ini penulis menggunakan waktu simulasi dalam rentang tersebut berjumlah

16981816 yang digunakan dalam rangkaian proses pengambilan data. Berdeda

dengan pergerakan manusia sebelumnya (Haggle4 Cambridge Imote), di

pergerakan manusia (MIT) ini dibutuhkan waktu simulasi yang lebih lama dengan

scope yang lebih besar di bandingkan dengan pergerakan manusia (MIT). Pada

pergerakan manusia (MIT) ini dilakukan pada kampus MIT (Massachusetts

Institute of Technology).

Studi ini terdiri dari seratus ponsel cerdas Nokia 6600 yang telah terpasang dengan

beberapa perangkat lunak yang kami kembangkan serta versi aplikasi konteks dari

Universitas Helsinki [6]. Tujuh puluh lima pengguna adalah pelajar atau fakultas di

MIT Media Laboratory, sementara sisanya 25 orang adalah mahasiswa masuk di

sekolah bisnis MIT Sloan yang bersebelahan dengan laboratorium [6]. Dari tujuh

puluh lima pengguna di laboratorium, dua puluh adalah siswa master masuk dan

lima orang masuk MIT baru. Dengan memanfaatkan fakta bahwa ponsel modern

menggunakan jaringan RF jarak dekat (mis., Bluetooth) dan jaringan RF jarak jauh

(mis., GSM), dan kedua jaringan dapat saling menambah satu sama lain untuk

inferensi lokasi dan aktivitas. Menautkan ID menara seluler untuk menentukan

perkiraan lokasi dan pada saat bersamaan akan mencatat perangkat Bluetooth [6].

Bluetooth adalah protokol nirkabel di kisaran 2,40-2,48 GHz, yang dikembangkan

oleh Ericsson pada tahun 1994 dan diluncurkan pada tahun 1998 sebagai pengganti

kabel serial untuk menghubungkan perangkat yang berbeda [6].


13

Pada penerapannya secara umum pergerakan manusia (MIT) ini terdiri dari 97 node

(devices) [5].

2.7. Simulator ONE

Simulator ONE (Opportunistic Network Environment) adalah pemodelan

yang dilakukan oleh node movement, inter-node contact, routing, dan message

handling. Simulator ONE (Opportunistic Network Environtment) dibangun dengan

menggunakan bahasa Java Programming dalam permodelannya. Hasil dari

permodelan menggunakan ONE berupa visualization, report, post-prossing tools

yang akan dianalisis. Dibawah ini (Gambar 2.5) merupakan screen shoot dari

pergerakan node pada saat Simulator ONE dijalankan dengan GUI.

Gambar 2.5. Snapshoot Simulator ONE


14

BAB III

PERANCANGAN SIMULASI JARINGAN

3.1. PROPHET Averrage Buffer (PROPHETAB)

Protokol ini merupakan peningkatan pada yang dilakukan pada protokol

PROPHET Average Buffer atau PROPHET berbasis buffer pada saat melakukan

forwarding message. Node yang membawa messsage akan lebih selektif dalam

memberikan pesan kepada node lain yang dianggap dapat membawa pesan hingga

sampai ke destination. Jika pada protokol PROPHET dalam melakukan forward

message berdasarkan perhitungan dari rumus Delivery Predictability. Ini akan

mengahasilkan nilai probabilitas dari setiap node yang dianggap memiliki

kemampuan membawa pesan ke destination. Sedangkan pada protokol

PROPHETAB ini, selain melakukam forwarding message dari hasil perhitungan

Delivery Predictability, di PROPOHETAB ini ditambahkan kriteria buffer dalam

melakukan forwarding message. Sederhananya, pada PROPHETAB selain

memiliki probabilitas yang baik dalam penyampaian pesan, maka harus juga

memiliki free buffer size yang baik (kecil) dibandingkan node yang membawa

pesan.

Dalam mengukur buffer akan dilihat jumlah pemakaian rata - rata buffer

setiap node. Dengan cara ini diharapkan mampu meningkatkan PROPHET dalam

segi delivery probability, delay, message drop dan overhead ratio pada skenario

yang ditentukan.

Forwarding Strategi Model PROPHETAB

ALGORITMA PROPHETAB ( PROPHET berbasis buffer)

Ni is in contact with node Nj do

Send summary_vector(Nj)

Receive summary_vector(ni)

Update delivery_preds(Ni)

Update transitive_preds(Ni)

If Delivery_preds(Nj) > delivery_preds(Ni)

If AverrageBufferOccupancy(Nj) < AverrageBufferOccupancy(Ni)

then Forward message to Nj


15

End if

End if

Strategi pengiriman dengan metode jika node penerima memiliki probabilitas

yang tinggi terpilih tetapi memiliki besar rata – rata buffer yang tinggi dari node

pengirim maka pengiriman pesan ke node penerima akan dibatalkan. Sedangkan,

apabila node pengirim nemukan node lain yang memiliki tingkat probabilitas yang

tinggi dari dirinya (node source) dan memiliki rata – rata buffer yang lebih kecil

dari node pengirim maka pesan akan dikirim ke node penerima tersebut.

FLOW CHART PROPHETAB


16

3.2. Parameter Simulasi

Dalam penelitian ini, penulis telah menentukan parameter – parameter dari

simulasi yang bersifat tetap dan parameter ini dipakai pada skenario lainnya yang

akan diujikan. Berikut parameter – parameter tersebut :

Parameter yang digunakan dalam simulasi

Tabel 3.1. Parameter Simulasi

Parameter Nilai

Routing Protokol PROPHET & PROPHETAB

Ukuran Buffer 64 MB

Jangkauan transmisi radio 10 m

Ukuran Pesan 500 kB – 1 MB

Node mobility (pergerakan node)

Random Waypoint, Pergerakan

Manusia (Haggle4 Cambridge

Imote), Pergerakan Manusia

(MIT)

3.3. Skenario Simulasi

Dalam penelitian, skenario menggunakan model pergerakan Random

Waypoint, pergerakan manusia (Haggle4 Cambridge Imote) dan pergerakan

manusia (MIT) untuk mengevaluasi protokol PROPHET dan PROPHET dengan

berbasis buffer (PROPHETAB). Pada Random Waypoint akan dilakukan

penambahan jumlah node dan kecepatan pada skenarionya. Kemudian pada

pergerakan manusia (Haggle4 Cambridge Imote) dan pergerakan manusia (MIT)

akan di jalankan sesuai skenario sesuai data set pada masing masing pergerakan

manusia.

Tabel 3.2. Skenario penambahan jumlah node pada pergerakan Random

Waypoint

Kode

Model

Pergerakan Routing Protokol Jumlah Node

Area Simulasi

(m)

RN.1 Random

Waypoint

PROPHET 25;50;75;100 1000 x 1000

RN.2 PROPHETAB 25;50;75;100 1000 x 1000


17

Setelah menggunakan skenario awal yaitu pergerakan Random Waypoint,

selanjutnya menggunakan mode dari pergerakan manusia (Haggle4 Cambridge

Imote) dan pergerakan manusia (MIT).

Tabel 3.3. Skenario Pergerakan Manusia

Routing Protokol Model Pergerakan

PROPHET Haggle4 Cambridge Imote, MIT

PROPHETAB Haggle4 Cambridge imote, MIT

Tabel 3.4. Skenario Pergerakan Manusia (Haggle4 Cambridge Imote)

Kode

Model


Area Simulasi

(m)

MH.1 Haggle4

Cambridge

Imote

PROPHET 36 1000 x 1000

MH.2 PROPHETAB 36 1000 x 1000

Tabel 3.5. Skenario Pergerakan Manusia (MIT)

Kode

Model


Area Simulasi

(m)

MM.1

MIT

PROPHET 97 1000 x 1000

MM.2 PROPHETAB 97 1000 x 1000

3.4. Parameter Kerja

Dalam penelitian ini, penulis menggunakan tiga parameter kinerja, meliputi:

1. Delivery Probability

Parameter ini digunakan untuk mengetahui probabilitas pengiriman

pesan dengan delivery predictability yang terdapat tahap update, aging dan

transitivity.

𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑝𝑟𝑜𝑏𝑎𝑏𝑖𝑙𝑖𝑡𝑦 =total pesan yang diterima

total pesan yang dikirim


18

2. Delay

Parameter ini digunakan untuk mengetahui seberapa optimal nilai

waktu tunda (delay) pesan dari sumber (source) ke tujuan (destination).

Disini akan mengukur waktu rata – rata antara pesan yang di generate dan

pesan yang diterima oleh destination.

3. Overhead Ratio

Parameter untuk mengetahui seberapa banyak copy pesan pada

jaringan. Ini sangat berpengaruh pada beban jaringan. Jika copy pesan terlalu

banyak, makan dapat mengakibatkan penggunaan resource yang tinggi.

𝑜𝑣𝑒𝑟ℎ𝑒𝑎𝑑 𝑟𝑎𝑡𝑖𝑜 =number of relayed message − number of delivery message

number of delivery message

4. Message Drop

Banyaknya pesan yang didrop ini selain disebabkan oleh buffer yang

hampir atau sudah penuh juga disebabkan oleh TTL (Time To Live) dalam

pesan telah habis sebelum pesan tersebut sampai di destination.


20

0

100000

200000

300000

400000

500000

600000

700000

800000

900000

25 50 75 100 125 150

Dro

p

Jum. Node

ProPhet ProPhetAB

BAB IV

PENGUJIAN DAN ANALISIS

Untuk lebih mengetahui analisis unjuk kerja protokol PROPHETAB terhadap

PROPHET yang dilakukan oleh penulis pada Bab 3, maka pada bab ini akan

ditunjukkan hasil analisis yang sudah dilakukan.

4.1. Random Waypoint

4.1.1. Penambahan Jumlah Node

Tabel 4.1. Hasil Pengujian Penambahan Node pada pergerakan Random

Waypoint

Jlh

Node

Random Waypoint

Delivery Ratio Overhead Ratio Delay Drop

ProPhet ProPhetAB ProPhet ProPhetAB ProPhet ProPhetAB ProPhet ProPhetAB

25 0.3085 0.3045 1.4407 1.2878 8884.4764 8807.6133 45777 44103

50 0.4256 0.4469 5.7245 4.7599 9654.5312 9575.5364 109541 99585

75 0.5271 0.5779 11.2183 8.5104 9919.4980 9737.7728 220887 188859

100 0.6169 0.6848 17.8493 12.8294 10171.1766 9818.7612 384752 312887

125 0.6851 0.7604 25.5669 17.2658 9969.3248 9625.4465 593332 451978

150 0.7386 0.7992 34.7325 21.6643 9898.3804 9534.0249 853764 585991

(a) Delivery Ratio (b) Message Drop

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

25 50 75 100 125 150

Del

iver

y R

atio

(0

-1

)

Jum. Node

ProPhet ProPhetAB


21

8000

8200

8400

8600

8800

9000

9200

9400

9600

9800

10000

10200

10400

25 50 75 100 125 150

Del

ay (

s)

Jum. Node

ProPhet ProPhetAB

(c) Overhead Ratio (d) Delay

Dari hasil penelitian, pada grafik (lihat grafik a) menujukkan dengan

bertambahnya jumlah node maka akan mengakibatkan peningkatan pada delivery

probability. Pada kasus ini delivery probability PROPHETAB lebih tinggi

dibandingkan delivery probability pada PROPHET walaupun tidak begitu jauh

perbedaannya. Ini dikarenakan pada saat node men-generate message maka

semakin banyak relay node yang akan membantu mentransmisikan message. Pada

PROPHET, dalam melakukan forward message tidak mempertimbangkan nilai dari

rata – rata buffer. Ini membuat node yang memiliki probabilitas yang baik akan

cendrung penuh atau dengan kata lain node tersebut menjadi hub node. Sedangkan

pada PROPHETAB memberikan kemungkinan pada node yang membawa message

untuk membandingkan terlebih dalulu nilai rata – rata buffer sebelum melakukan

forward message.

Jika kita lihat pada grafik (lihat grafik b) terdapat perdedaan dalam message

drop. Dengan bertambahnya jumlah node ini membuat drop pada PROPHETAB

cenderung naik, tetapi tidak terlampau tinggi dengan PROPHET dan cukup terlihat

perbedaanya drop dari kedua protokol ini dengan semakin bertambahnya jumlah

node di jaringan. Banyaknya pesan yang di drop ini selain disebabkan oleh buffer

yang hampir atau sudah penuh, juga disebabkan oleh TTL pesan yang telah habis

0

5

10

15

20

25

30

35

40

25 50 75 100 125 150

Ove

rhea

d R

atio

Jum. Node

ProPhet ProPhetAB


22

sebelum pesan tersebut sampai di destination. Inilah alasannya drop dari kedua

protokol cenderung naik saat jumlah node di tingkatkan.


Buffer Occupancy

Gambar 4. 2. Random Waypoint : Dampak penambahan jumlah node

terhadap Buffer Occupancy

0

5

10

15

20

25

30

35

40

45

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

25 Node

Prophet ProphetAB

0

5

10

15

20

25

30

35

40

45

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

50 Node

Prophet ProphetAB


23


Buffer Occupancy


Buffer Occupancy

0

5

10

15

20

25

30

35

40

45

50

0 2 4 6 8 101214161820222426283032343638404244464850525456586062646668707274

75 Node

Prophet ProphetAB

0

10

20

30

40

50

60

0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96 99

100 Node

Prophet ProphetAB


24


Buffer Occupancy


Buffer Occupancy

Overhead ratio pada kedua protokol ini juga cenderung naik saat jumlah node

ditingkatkan seperti pada grafik (lihat grafik c). Dengan menggunakan persyaratan

0

10

20

30

40

50

600 4 8

12

16

20

24

28

32

36

40

44

48

52

56

60

64

68

72

76

80

84

88

92

96

10

0

10

4

10

8

11

2

11

6

12

0

12

4

125 Node

Prophet ProphetAB

0

10

20

30

40

50

60

70

0 5

10

15

20

25

30

35

40

45

50

55

60

65

70

75

80

85

90

95

10

0

10

5

11

0

11

5

12

0

12

5

13

0

13

5

14

0

14

5

150 Node

Prophet ProphetAB


25

berbasis buffer yang kita kenal sebagai PROPHETAB ini membuat overhead ratio

pada PROPHETAB cenderung lebih baik dibandingkan PROPHET. Overhead

ratio berkaitan dengan biaya yang dibebani pada jaringan dan PROPHETAB

mampu menekan biaya yang ditanggung pada jaringan di bandingkan PROPHET.

Pada PROPHETAB tidak semua pesan akan di forward ke node yang ditemuinya

jika syarat dari average buffer tidak terpenuhi. Berdeda dengan PROPHET yang

akan melakukan forward message kepada node yang ditemuinya jika ternyata node

tersebut memiliki probabilitas yang baik. Banyaknya node yang terlampau banyak

dititipi pesan akan membuat jaringan menjadi lebih berat dalam bekerja, ini

membuat overhead ratio pada PROPHET cenderung lebih tinggi dibandingkan

dengan PROPHETAB.

Jika kita lihat grafik (lihat grafik d) pada saat jumlah node 25 sampai 100

node, grafik delay dari kedua protokol cendrung meningkat. Ini disebabkan oleh

saat pesan di generate dan dikirim pada rentang node tersebut, pesan terlampau

lama untuk sampai ke destination. Berbeda halnya jika jumlah node semakin

ditingkatkan sampai 125 node. Tampak bahwa dari jumlah node 125 sampai 150

node, nilai dari delay pada jaringan akan cenderung turun. Ini dikarenakan semakin

banyak relay node yang akan membantu mentransmisikan pesan. Secara garis

besar, PROPHETAB bekerja baik dibandingkan PROPHETpada pergerakan

random waypoint. Memang tidak ada ukuran batasan perbedaan pada hasil grafik

dari kedua protokol ini agar dikatakan baik, tetapi melihat dari grafik di pergerakan

Random Waypoint, kedua protokol ini menunjukkan hasil yang berbeda, walau

tidak tidak menunjukkan perbedaan yang signifikan. Ini dikarenakan pada

pergerakan ini, setiap node merupakan relay yang baik dalam penyampaian pesan

ke destination.


26

4. 2. Pergerakan Manusia (Haggle4 Cambridge Imote)

Tabel 4.2. Hasil perbandingan pada Pergerakan Manusia (Haggle4

Cambridge Imote)

Protokol Routing Delivery

Ratio

Overhead

Ratio Delay Drop

PROPHET 0.5387 24.1667 35704.3413 13860

PROPHETAB 0.4126 14.6204 37638.5195 7019

Pergerakan manusia ini menggunakan data set dari Haggle4 Cambridge

Imote dengan lama waktu simulasi 905400 detik (11 hari) dan jumlah node

sebanyak 36 node sesuai dengan data default dari Haggle4 Cambridge Imote [5].

Pada pergerakan ini terdapat beberapa node yang menjadi hub-node atau node yang

lebih tinggi tingkat popularitasnya dibanding node yang lain dalam segi

penyampaian pesan. Ini mengakibatkan node mejadi sering dititipi pesan karena

dianggap sebagai node yang mampu membawa pesan agar cepat sampai di

destination. Karena terdapat hub-node maka node tersebut akan memiliki buffer

yang tinggi terisi dengan pesan yang dititipi. Oleh karena ini PROPHETAB akan

mengatasinya dengan berbasis penggunaan buffer (average buffer occupacy) saat

bertemu node yang memiliki probabilitas yang baik dan buffer yang lebih kecil saat

melakukan perbandingan, barulah node kemudian melakukan forward message.

Buffer menjadi syarat disamping node yang akan dititipi pesan memiliki tingkat

probabilitas yang tinggi. Walaupun PROPHETAB mempunyai syarat dalam

melakukakn forward message, delivery probability dari PROPHETAB lebih tinggi

dibandingkan pada PROPHETAB. Terdapat perbedaan Delivery Probability dari

rentang 0.5387 pada PROPHET dan 0.4126 pada PROPHETAB (lihat Gambar 4.7).


27


(Haggle4 Cambridge Imote)

Disamping PROPHET memiliki probabilitas yang tinggi dari PROPHETAB,

PROPHETAB mampu mengatasi dalam masalah overhead ratio. Tampak pada

gambar (lihat Gambar 4.8). Ini menjukkan dari segi overhead ratio, protokol

PROPHETAB mampu meminimalisirnya. Ini dikarenakan pada pergerakan

manusia (Haggle4 Cambridge Imote) memiliki scope yang tidak terlalu besar,

hanya 36 node pada sebuah ruang konferensi. Dalam kasus seperti ini memberikan

kemungkinan pada setiap node memiliki probabilitas pernah bertemu dengan node

destination. Sebenarnya pesan dapat dengan cepat sampai ke destination, tetapi

dikarenakan node lebih banyak di relay mengakibatkan overhead ratio menjadi

tinggi dalam jaringan, terutama pada PROPHET yang tidak berbasis buffer saat

melakukan forward message (lihat Gambar 4.8).

0.5387

0.4126

PRO. PRO.AB

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0.55

0.6

0.65

0.7

Del

iver

y R

atio

(0

-1)


28

Gambar 4. 8. Grafik perbandingan Overhead Ratio Pada Pergerakan

Manusia (Haggle4 Cambridge Imote)

Jika kita lihat grafik (lihat gambar 4.9) kedua protokol ini memiliki tingkat

delay yang cenderung sama karena perbedaanya yang sangat tipis jika kita lihat

pada grafik dibawah. Sama seperti sebelumnya, pesan lebih sering di relay dalam

jaringan sebelum sampai ke destination.

Gambar 4. 9. Grafik perbandingan Delay Pada Pergerakan Manusia


Tetapi jika kita lihat pada grafik (lihat Gambar 4.10) walaupun memiliki

delay yang cendung sama, terdapat perdedaan yang cukup nampak dari segi drop.

Disini tampak bahwa PROPHETAB mampu mangatasi masalah drop pada

24.1667

14.6204

PRO. PRO.AB

12

14

16

18

20

22

24

26

Ove

rhea

d R

atio

35704.341337638.5196

PRO. PRO.AB

20006000

1000014000180002200026000300003400038000420004600050000

Del

ay (

s)


29

jaringan, jadi PROPHETAB mampu meminimalisir masalah message drop

dibandingakan dengan PROPHET. Ini dikarenakan pada PROPHETAB cenderung

selektif dalam melakukan forward message saat bertemu node. Jika pada

PROPHET, node yang membawa pesan akan selalu memberikan pesan kepada

node yang memiliki probabilitas yang baik dari dirinya. Sedangkan pada

PROPHETAB, node yang membawa pesan, selain memberikan pesan kepada node

yang memilih probabilitas yang baik saat ditemui, ia juga akan mempertimbangkan

buffer sebagai kriteria tambahan sesuai dengan penelitian yang dilakukan. Dengan

kriteria seperti yang dimiliki oleh PROPHETAB, terlihat (lihat Gambar 4.10)

mampu menekan angka drop pada jaringan dalam melakukan pengiriman pesan.

Gambar 4. 10. Grafik perbandingan Drop. Pada Pergerakan Manusia


Pada PROPHET, drop yang tinggi dibandingkan dengan drop pada PROPHETAB

ini disebabkam oleh TTL pesan yang sudah habis dan juga disebabkan oleh buffer

yang cenderung penuh yang tampak dari beberapa hub-node. Buffer Occupancy

pada kedua protokol ini cendrung memiliki pebedaan (lihat Gambar 4.11). Protokol

PROPHET yang mempertimbangkan buffer dalam melakukan forwarding message

cenderung memiliki buffer yang lebih kecil dibandingkan dengan buffer peda

PROPHET. Iini menjadikan buffer merupakan suatu kriteria yang penting dalam

keberhasilan mengirim pesan dengan tingkat overhead ratio dan drop yang lebih

ekonomis.

13860

7019

PRO. PRO.AB

5000

6000

7000

8000

9000

10000

11000

12000

13000

14000

15000

Dro

p


30

Gambar 4. 11. Dampak buffer occupancy Pada Pergerakan Manusia


Tabel 4. 3. Hasil Pengujian Pada Pergerakan Manusia (MIT)

Protokol Routing Delivery

Ratio

Overhead

Ratio Delay Drop

PROPHET 0.5233 11.1635 35660.7842 31885

PROPHETAB 0.5230 7.3516 35651.7047 22573

Pada pergerakan ini terdapat beberapa node yang menjadi hub-node atau node

yang lebih tinggi tingkat popularitasnya dibanding node yang lain dalam segi

penyampaian pesan. Ini mengakibatkan node mejadi sering dititipi pesan karena

dianggap sebagai node yang mampu membawa pesan agar cepat sampai di

destination. Karena terdapat hub-node maka node tersebut akan memiliki buffer

yang tinggi terisi dengan pesan yang dititipi. Oleh karena ini PROPHETAB akan

mengatasinya dengan PROPHETAB (Average Buffer) atau berbabasis buffer dalam

melakukan forward message. Buffer menjadi syarat disamping node yang akan

dititipi pesan memiliki tingkat probabilitas yang tinggi. Walaupun PROPHETAB

mempunyai syarat dalam melakukan forward message, delivery probability dari

kedua protokol ini cenderung tinggi dan tipis sekali perbedaanya (lihat Gambar

4.12).

0

10

20

30

40

50

0 1 2 3 4 5 6 7 8 9 1011121314151617181920212223242526272829303132333435

Prophet ProphetAB


31

Gambar 4. 12. Grafik perbandingan Delivery Ratio Pada Pergerakan

Manusia (MIT)

Disamping memiliki probabilitas yang sama – sama tinggi, PROPHETAB

mampu mengatasi dalam masalah overhead ratio pada pergerakan manusia (MIT)

ini. Tampak pada gambar (lihat Gambar 4.13). Ini menjukkan dari segi overhead

ratio dalam jaringan yang lebih luas ini, protokol PROPHETAB mampu menekan

biaya yang digunakan dalam proses penyampaian pesan dari source ke destination.

Ini dikarenakan pada pergerakan manusia (MIT) ini dilakukan pada scop yang lebih

luas di bandingkan dengan scope pada pergerakan manusia (Haggle Cambridge

Imote) dan saat melakukan forwarding message pada PROPHETAB juga lebih

selektif dalam melakukannya dengan pertimbangan buffer node yang ditemuinya.

0.5233 0.5230

PRO. PRO.AB

0.2

0.25

0.3

0.35

0.4

0.45

0.5

0.55

0.6

Del

iver

y R

atio

(0

-1)


32

Gambar 4. 13. Grafik perbandingan Overhead Ratio Pada Pergerakan

Manusia (MIT)

Disisi lain, terutama pada delay (lihat gambar 4.14) tidak begitu berdeda antara

kedua protokol pada pergerakan ini. Pada DTN memang mentoleransi tingkat delay

yang tinggi. Semakin tinggi delay, maka mengakibatkan pesan semakin lama

sampai ke tujuan dan juga mengibatkan pesan akan di drop pada jaringan karena

habisnya TTL.

Gambar 4. 14. Grafik perbandingan Delay Pada Pergerakan Manusia (MIT)

Walaupun PROPHET dan PROPHETAB memiliki tinggi yang hampir sama dalam

segi delivery ratio dan delay, tetapi dari segi message drop, PROPHETAB mampu

menekan drop yang ada dijaringan, begitu juga yang terjadi pada overhead ratio

11.1635

7.3516

PRO. PRO.AB

4

5

6

7

8

9

10

11

12

Ove

rhea

d R

atio

35660.7842 35651.7047

PRO. PRO.AB

15000

17500

20000

22500

25000

27500

30000

32500

35000

37500

40000

Del

ay (

s)


33

dari PROPHETAB. Ini dikarenakan pada PROPHETAB tidak akan memberikan

pesan kepada node yang memiliki buffer yang lebih tinggi, untuk memperkecil

kemungkinan pesan akan di drop dalam jaringan. Dengan tingginya drop

mengakibatkan overhead ratio pada PROPHET cenderung lebih tinggi

dibandingkan pada PROPHETAB.

Gambar 4. 15. Grafik perbandingan Drop Pada Pergerakan Manusia (MIT)

Pada gambar (lihat gambar 4.16) ini menunjukkan hasil grafik buffer occupancy

dari kedua protokol. Terlihat bahwa dari kedua protokol ini memiliki beberapa hub

node pada jaringan.

Gambar 4. 16. buffer occupancy Pada Pergerakan Manusia (MIT)

31885

22573

PRO. PRO.AB

19000

20500

22000

23500

25000

26500

28000

29500

31000

32500

34000D

rop

0

5

10

15

20

25

30

35

40

0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78 81 84 87 90 93 96Prophet ProphetAB


34

BAB V

KESIMPULAN

5.1. Kesimpulan

Pada pergerakan Random Waypoint, protokol routing PROPHET dan

PROPHETAB tidak terlalu memberikan kinerja yang mencolok pada delivery ratio,

walaupun pada overhead ratio, delay, dan drop terdapat perbedaan yang tidak

terlalu besar. Terbukti dari hasil yang sudah dilakukan pada skenario penambahan

jumlah node. Ini dikarenakan pada pergerakan Random Waypoint setiap node

diasumsikan memiliki nilai probabilitas yang sama atau dengan kata lain setiap

node merupakan node relay yang baik dalam melakukan penyampaian pesan ke

destination. Sedangkan pada pergerakan manusia (Haggle4 Cambridge Imote) dan

pergerakan manusia (MIT), setiap node memilliki probabilitas yang berbeda – beda

dan terdapat node yang memiliki tingkat popularitas yang tinggi atau yang sering

kita kenal dengan sebutan hub node. Transitivity pada PROPHET dan

PROPHETAB mampu bekerja dengan baik untuk keberhasilan dari kedua routing

protokol ini.

Pada pergerakan manusia (Haggle4 Cambridge Imote) dari segi delivery

ratio dan delay memberikan hasil yang tidak begitu signifikan perbedaannya, tetapi

PROPHETAB di kedua pergerakan ini mampu menekan dari segi overhead ratio

dan message drop kemudian buffer yang lebih kecil.

Pada pergerakan manusia (MIT) dari segi delivery ratio masih lebih baik

pada PROPHET dan delay masih sama tinggi dari kedua protokol ini, tetapi

PROPHETAB di kedua pergerakan ini mampu menekan dari segi overhead ratio

dan message drop kemudian buffer yang lebih kecil. Ini menjadikan routing

protokol PROPHET cocok diterapkan pada kedua pergerakan manusia ini karena

PROPHET berbasis buffer menunjukkan unjuk kerja yang baik dilihat dari tade off

di kedua protokol.

5.2. Saran

Pada PROPHET dan PROPHETAB mampu menunjukkan unjuk kerja yang

nampak pada kedua pergerakan manusia. Untuk penelitian selanjutnya, algoritma

dari protokol ini dapat di kembangkan lebih luas lagi dari segi buffer tetapi pada


35

pergerakan yang lain, diluar pergerakan Random Waypoint dan pergerakan manusia

(Haggle4 Cambridge Imote) dan pergerakan manusia (MIT). Dengan harapan

kedepan, protokol ini mampu bekerja secara optimal.


36

DAFTAR PUSTAKA

[1] Lindgren, A.,Doria, A. & Schelen, O., ”Probailistic Routing Intermittenly

Connected Networks”. Review, vol. 7, no. 3, Juli 2003.

[2] McLean, Alan (2014), “movingAverage.java”, [online] diakses di :

https://gist.github.com/alancmclean/e84f2aae33c695b66fe4, 20 April 2017.

[3] Akeranen (2015), “The Opportunistic Network Environment simulator”

[online] diakses di : https://github.com/akeranen/the-one/tree/v1.6.0, 2 Mei

2017.

[4] Scott, J., Gass, R., Crowcroft, J., Hui, P., Diot, C., Chaintreau, A.,

CRAWDED dataset cambridge/haggle (v. 2009-05-29), [online] diakses di :

http://crawdad.org/~crawdad/cambridge/haggle/20090529/, Mei 2009

[5] Orlinski, Matthew, “Encounter traces for the ONE simulator”, [online]

diakses di : http://www.shigs.co.uk/index.php?page=traces, Juli 2017.

[6] 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), Juli 2017.

[7] Putra, Parta Adi. 2016. ANALISIS ENERGI PROTOKOL PROPHET DI

JARINGAN OPORTUNISTIK. Tugas Akhir. Yogyakarta : Fakultas Sains

dan Teknologi Universitas Sanata Dharma.


http://crawdad.org/mit/reality/20050701/

37

LAMPIRAN

A. Listing Program PROPHETAB

ProphetAB.java

/*

* Copyright 2010 Aalto University, ComNet

* Released under GPLv3. See LICENSE.txt for details.

*/

package routing;

/*

* author Anders Lindgern et al.

* modified by Feliks Yudha

*/

import java.util.ArrayList;

import java.util.Collection;

import java.util.Collections;

import java.util.Comparator;

import java.util.HashMap;

//import java.util.LinkedList;

import java.util.List;

import java.util.Map;

//import java.util.Queue;

import core.Connection;

import core.DTNHost;

import core.Message;

import core.Settings;

import core.SimClock;

import core.Tuple;

/**

* Implementation of PRoPHET router as described in <I>Probabilistic

routing in

* intermittently connected networks</I> by Anders Lindgren et al.


38

*/

public class ProphetAB extends ActiveRouter {

/** delivery predictability initialization constant */

public static final double P_INIT = 0.75;

/** delivery predictability transitivity scaling constant default value */

public static final double DEFAULT_BETA = 0.25;

/** delivery predictability aging constant */

public static final double GAMMA = 0.98;

/** Prophet router's setting namespace ({@value}) */

public static final String PROPHET_NS = "ProphetRouter";

/**

* Number of seconds in time unit -setting id ({@value}). How many

seconds

* one time unit is when calculating aging of delivery predictions. Should

* be tweaked for the scenario.

*/

public static final String SECONDS_IN_UNIT_S = "secondsInTimeUnit";

/**

* Transitivity scaling constant (beta) -setting id ({@value}). Default

* value for setting is {@link #DEFAULT_BETA}.

*/

public static final String BETA_S = "beta";

/** the value of nrof seconds in time unit -setting */

private int secondsInTimeUnit;

/** value of beta setting */

private double beta;

/** delivery predictabilities */

private Map<DTNHost, Double> preds;

/** last delivery predictability update (sim)time */

private double lastAgeUpdate;


39

private double lastRecord = Double.MIN_VALUE;

private int interval = 3600;

private int updateCounter = 0; // new added

private double sum;

private double avgBuffer;

/**

* Constructor. Creates a new message router based on the settings in the

* given Settings object.

*

* @param s

* The settings object

*/

public ProphetAB(Settings s) {

super(s);

Settings prophetSettings = new Settings(PROPHET_NS);

secondsInTimeUnit =

prophetSettings.getInt(SECONDS_IN_UNIT_S);

if (prophetSettings.contains(BETA_S)) {

beta = prophetSettings.getDouble(BETA_S);

} else {

beta = DEFAULT_BETA;

} System.setProperty("java.util.Arrays.useLegacyMergeSort",

"true");

initPreds();

}

/**

* Copyconstructor.

*

* @param r

* The router prototype where setting values are copied from

*/


40

protected ProphetAB(ProphetAB r) {

super(r);

this.secondsInTimeUnit = r.secondsInTimeUnit;

this.beta = r.beta;

initPreds();

}

/**

* Initializes predictability hash

*/

private void initPreds() {

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

}

@Override

public void changedConnection(Connection con) {

// System.out.println(SimClock.getTime()+ " N");

if (con.isUp()) {

DTNHost otherHost = con.getOtherNode(getHost());

updateDeliveryPredFor(otherHost);

updateTransitivePreds(otherHost);

}

}

/**

* Updates delivery predictions for a host.

* <CODE>P(a,b) = P(a,b)_old + (1 - P(a,b)_old) * P_INIT</CODE>

*

* @param host

* The host we just met

*/

private void updateDeliveryPredFor(DTNHost host) {

double oldValue = getPredFor(host);// yourself

double newValue = oldValue + (1 - oldValue) * P_INIT;


41

preds.put(host, newValue);// update

}

/**

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

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

if (preds.containsKey(host)) {// jika nilainya ada preds

return preds.get(host);

} else {

return 0;

}

}

/**

* Updates transitive (A->B->C) delivery predictions.

* <CODE>P(a,c) = P(a,c)_old + (1 - P(a,c)_old) * P(a,b) * P(b,c) * BETA

* </CODE>

*

* @param host

* The B host who we just met

*/

private void updateTransitivePreds(DTNHost host) {

MessageRouter otherRouter = host.getRouter();

assert otherRouter instanceof ProphetAB : "PRoPHET only works " +

" with other routers of same type";

double pForHost = getPredFor(host); // P(a,b)


42

Map<DTNHost, Double> othersPreds = ((ProphetAB)

otherRouter).getDeliveryPreds();

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

if (e.getKey() == getHost()) {

continue; // don't add yourself

}

double pOld = getPredFor(e.getKey()); // P(a,c)_old

double pNew = pOld + (1 - pOld) * pForHost * e.getValue() *

beta;

preds.put(e.getKey(), pNew);

}

}

/**

* Ages all entries in the delivery predictions.

* <CODE>P(a,b) = P(a,b)_old * (GAMMA ^ k)</CODE>, where k is

number of time

* units that have elapsed since the last time the metric was aged.

*

* @see #SECONDS_IN_UNIT_S

*/

private void ageDeliveryPreds() {

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


43

}

/**

* Returns a map of this router's delivery predictions

*

* @return a map of this router's delivery predictions

*/

private Map<DTNHost, Double> getDeliveryPreds() {

ageDeliveryPreds(); // make sure the aging is done

return this.preds;

}

@Override

public void update() {

updatedBuff();

super.update();

if (!canStartTransfer() || isTransferring()) {

return; // nothing to transfer or is currently transferring

}

// try messages that could be delivered to final recipient

if (exchangeDeliverableMessages() != null) {

return;

}

tryOtherMessages();

}

/**

* Tries to send all other messages to all connected hosts ordered by their

* delivery probability

*

* @return The return value of {@link #tryMessagesForConnected(List)}

*/

private Tuple<Message, Connection> tryOtherMessages() {


44

List<Tuple<Message, Connection>> messages = new

ArrayList<Tuple<Message, Connection>>();

Collection<Message> msgCollection = getMessageCollection();

/*

* for all connected hosts collect all messages that have a higher

* probability of delivery by the other host

*/

for (Connection con : getConnections()) {

DTNHost other = con.getOtherNode(getHost());

ProphetAB othRouter = (ProphetAB) other.getRouter();

if (othRouter.isTransferring()) {

continue; // skip hosts that are transferring

}

for (Message m : msgCollection) {

if (othRouter.hasMessage(m.getId())) {

continue; // skip messages that the other one has

}

if (othRouter.getPredFor(m.getTo()) >

getPredFor(m.getTo())) {

// System.out.println(getAvgBuffer());

if (othRouter.getAvgBuffer() < getAvgBuffer()) {//

tambahan

messages.add(new Tuple<Message,

Connection>(m, con));

} else {

continue;

}

}

}

}

if (messages.size() == 0) {


45

// System.out.println("null");

return null;

}

// System.out.println(messages.size());

// sort the message-connection tuples

Collections.sort(messages, new TupleComparator());

return tryMessagesForConnected(messages); // try to send messages

}

/**

* Comparator for Message-Connection-Tuples that orders the tuples by

their

* delivery probability by the host on the other side of the connection

* (GRTRMax)

*/

private class TupleComparator implements Comparator<Tuple<Message,

Connection>> {

public int compare(Tuple<Message, Connection> tuple1,

Tuple<Message, Connection> tuple2) {

// delivery probability of tuple1's message with tuple1's connection

double p1 = ((ProphetAB)

tuple1.getValue().getOtherNode(getHost()).getRouter())

.getPredFor(tuple1.getKey().getTo());

// -"- tuple2...

double p2 = ((ProphetAB)

tuple2.getValue().getOtherNode(getHost()).getRouter())

.getPredFor(tuple2.getKey().getTo());

// bigger probability should come first

if (p2 - p1 == 0) {

/* equal probabilities -> let queue mode decide */


46

return compareByQueueMode(tuple1.getKey(),

tuple2.getKey());

} else if (p2 - p1 < 0) {

return -1;

} else {

return 1;

}

}

}

@Override

public RoutingInfo getRoutingInfo() {

ageDeliveryPreds();

RoutingInfo top = super.getRoutingInfo();

RoutingInfo ri = new RoutingInfo(preds.size() + " delivery

prediction(s)");

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

DTNHost host = e.getKey();

Double value = e.getValue();

ri.addMoreInfo(new RoutingInfo(String.format("%s : %.6f", host,

value)));

}

top.addMoreInfo(ri);

return top;

}

@Override

public MessageRouter replicate() {

ProphetAB r = new ProphetAB(this);

return r;

}

public void setAvgBuffer(double X) {

avgBuffer = X;


47

}

public double getAvgBuffer() {

return avgBuffer;

}

public void updatedBuff() {

if (SimClock.getTime() - lastRecord >= interval) {

lastRecord = SimClock.getTime();

sum += this.getHost().getBufferOccupancy();

updateCounter++; // new added

double X = sum / updateCounter;

setAvgBuffer(X);

B. Listing Program Buffer Occupacy Report

/*

*

*

*/

package report;

/**

* Records the average buffer occupancy and its variance with format:

* <p>

* <Simulation time> <average buffer occupancy % [0..100]> <variance>

* </p>

*

*

*/

import java.text.DecimalFormat;

import java.util.*;

//import java.util.List;

//import java.util.Map;

import core.DTNHost;

import core.Settings;


48

import core.SimClock;

import core.UpdateListener;

public class BufferOccupancyReport extends Report implements

UpdateListener {

/**

* Record occupancy every nth second -setting id ({@value}).

* Defines the interval how often (seconds) a new snapshot of buffer

* occupancy is taken previous:5

*/

public static final String BUFFER_REPORT_INTERVAL =

"occupancyInterval";

/** Default value for the snapshot interval */

public static final int DEFAULT_BUFFER_REPORT_INTERVAL =

3600;

private double lastRecord = Double.MIN_VALUE;

private int interval;

private Map<DTNHost, Double> bufferCounts = new

HashMap<DTNHost, Double>();

private HashMap<DTNHost, ArrayList<Double>> time =new

HashMap<>();

// private HashMap<DTNHost, ArrayList<HashMap<Double,

ArrayList<Double>>>> waktubuffer =new HashMap<>();

private HashMap<DTNHost, ArrayList<HashMap<Double,

Double>>> waktubuffer =new HashMap<>();

private int updateCounter = 0; //new added

public BufferOccupancyReport() {

super();

Settings settings = getSettings();

if (settings.contains(BUFFER_REPORT_INTERVAL)) {

interval =

settings.getInt(BUFFER_REPORT_INTERVAL);


49

} else {

interval = -1; /* not found; use default */

}

if (interval < 0) { /* not found or invalid value -> use default */

interval = DEFAULT_BUFFER_REPORT_INTERVAL;

}

}

public void updated(List<DTNHost> hosts) {

if (isWarmup()) {

return;

}

if (SimClock.getTime() - lastRecord >= interval) {

lastRecord = SimClock.getTime();

printLine(hosts,lastRecord);

updateCounter++; // new added

}

// for (DTNHost ho : hosts ) {

// double temp = ho.getBufferOccupancy();

// temp = (temp<=100.0)?(temp):(100.0);

// if (bufferCounts.containsKey(ho.getAddress())){

// bufferCounts.put(ho,

(bufferCounts.get(ho.getAddress()+temp))/2);

// }else{

// bufferCounts.put(ho, temp);

// }

// }

}

/**

* Prints a snapshot of the average buffer occupancy

* @param hosts The list of hosts in the simulation

*/


50

private void printLine(List<DTNHost> hosts,double waktu) {

/**

double bufferOccupancy = 0.0;

double bo2 = 0.0;

for (DTNHost h : hosts) {

double tmp = h.getBufferOccupancy();

tmp = (tmp<=100.0)?(tmp):(100.0);

bufferOccupancy += tmp;

bo2 += (tmp*tmp)/100.0;

}

double E_X = bufferOccupancy / hosts.size();

double Var_X = bo2 / hosts.size() - (E_X*E_X)/100.0;

String output = format(SimClock.getTime()) + " " + format(E_X) +

" " +

format(Var_X);

write(output);

*/

for (DTNHost h : hosts ) {

double temp = h.getBufferOccupancy();

temp = (temp<=100.0)?(temp):(100.0);

if (bufferCounts.containsKey(h)){

//bufferCounts.put(h,

(bufferCounts.get(h)+temp)/2); seems WRONG

bufferCounts.put(h, bufferCounts.get(h)+temp);

//write (""+ bufferCounts.get(h));

ArrayList<Double> X=time.get(h);

X.add(temp);

time.put(h, X);

// ArrayList<HashMap<Double,

ArrayList<Double>>> Y=waktubuffer.get(h);


51

ArrayList<HashMap<Double, Double>>

Y=waktubuffer.get(h);

HashMap<Double, Double> M=new HashMap<>();

M.put(lastRecord, temp);

Y.add(M);

waktubuffer.put(h, Y);

}

else {

ArrayList<Double> X=new ArrayList<>();

X.add(temp);

bufferCounts.put(h, temp);

time.put(h,X);

ArrayList<HashMap<Double, Double>> Y=new

ArrayList<>();

HashMap<Double, Double> M=new HashMap<>();

M.put(lastRecord, temp);

Y.add(M);

waktubuffer.put(h, Y);

//write (""+ bufferCounts.get(h));

}

}

}

@Override

public void done()

{

String rata_rata="";

for (Map.Entry<DTNHost, Double> entry :

bufferCounts.entrySet()) {

DTNHost a = entry.getKey();

Integer b = a.getAddress();

Double avgBuffer = entry.getValue()/updateCounter;


52

rata_rata=rata_rata+b + "\t" + avgBuffer+"\n";

// write(b + "\t" + avgBuffer);

//write("" + b + ' ' + entry.getValue());

}

String A="";

for(DTNHost key:time.keySet()){

ArrayList<Double> X=time.get(key);

String times="";

DecimalFormat df = new DecimalFormat("#.000");

for(int i=0;i<X.size();i++){

times=times+" "+df.format(X.get(i));

}

A=A+key.getAddress()+" "+times+"\n";

}

String B="";

for(DTNHost key:waktubuffer.keySet()){

ArrayList<HashMap<Double, Double>>

X=waktubuffer.get(key);

String times="";

DecimalFormat df = new DecimalFormat("#.000");

for(int i=0;i<X.size();i++){

HashMap<Double, Double> K=X.get(i);

for(Double keys:K.keySet()){

times=times+" detik : "+keys.toString()+"

buffer : "+df.format(K.get(keys));

}

// times=times+" "+df.format(X.get(i));

}

B=B+key.getAddress()+" "+times+"\n";

}

write(A);


53

write("\n\navgBuffer : ");

write("==================");

write(rata_rata);

write("\n\nwaktuBuffer : ");

write("==================");

write(B);

super.done();

}

C. Skenario Simulasi

Pergerakan Random Waypoint

#

# Default settings for the simulation

#

## Scenario settings

Scenario.name = Feliks_RandomWaypoint

Scenario.simulateConnections = true

Scenario.updateInterval = 0.1

# 43200s == 12h

Scenario.endTime = 950400

btInterface.type = SimpleBroadcastInterface

btInterface.transmitSpeed = 250k

btInterface.transmitRange = 10

highspeedInterface.type = SimpleBroadcastInterface

highspeedInterface.transmitSpeed = 10M

highspeedInterface.transmitRange = 1000

Scenario.nrofHostGroups = 1

Group.movementModel = RandomWaypoint

Group.router = ProphetAB

#Group.router = ProphetRouter

Group.bufferSize = 64M

Group.waitTime = 0, 120


54

Group.nrofInterfaces = 1

Group.interface1 = btInterface

#Group.speed = [0.01,1.50;2.00,3.50;5.00,6.50;7.00,8.50]

#Group.msgTtl = [300;600;900;1200;1500;1800]

Group.speed = 0.5, 1.5

Group.msgTtl = 300

Group.nrofHosts = [25;50;75;100;125;150]

#Group.nrofHosts = [125;150]

#Group.nrofHosts = 25

# group1 (pedestrians) specific settings

Group1.groupID = p

Events.nrof = 1

Events1.class = MessageEventGenerator

Events1.interval = 25,35

#Events1.interval = 25,35

Events1.size = 500k,1M

Events1.hosts = 0,24

Events1.prefix = M

MovementModel.rngSeed = 2

MovementModel.worldSize = 1400, 1000

MovementModel.warmup = 1000

MapBasedMovement.nrofMapFiles = 4

MapBasedMovement.mapFile1 = data/roads.wkt

MapBasedMovement.mapFile2 = data/main_roads.wkt

MapBasedMovement.mapFile3 = data/pedestrian_paths.wkt

MapBasedMovement.mapFile4 = data/shops.wkt

Report.nrofReports = 2

Report.warmup = 0

#Report.reportDir = reports


55

#Report.reportDir =

[reports/proRWP/ttl300;reports/proRWP/ttl600;reports/proRWP/ttl900;reports/pro

RWP/ttl1200;reports/proRWP/ttl1500;reports/proRWP/ttl1800]

#Report.reportDir =

[reports/proRWP/node25;reports/proRWP/node50;reports/proRWP/node75;report

s/proRWP/node100;reports/proRWP/node125;reports/proRWP/node150]

#Report.reportDir = [reports/proRWP/node125;reports/proRWP/node150]

#Report.reportDir = [reports/proRWP/0.02-0.55;reports/proRWP/0.58-

1.11;reports/proRWP/1.13-1.67;reports/proRWP/1.69-2.22]

#Report.reportDir =

[reports/proRWP.AB/ttl300;reports/proRWP.AB/ttl600;reports/proRWP.AB/ttl90

0;reports/proRWP.AB/ttl1200;reports/proRWP.AB/ttl1500;reports/proRWP.AB/tt

l1800]

Report.reportDir =

[reports/proRWP.AB/node25;reports/proRWP.AB/node50;reports/proRWP.AB/n

ode75;reports/proRWP.AB/node100;reports/proRWP.AB/node125;reports/proR

WP.AB/node150]

#Report.reportDir = [reports/proRWP.AB/node125;reports/proRWP.AB/node150]

#Report.reportDir = [reports/proRWP.AB/0.02-0.55;reports/proRWP.AB/0.58-

1.11;reports/proRWP.AB/1.13-1.67;reports/proRWP.AB/1.69-2.22]

#Report.reportDir = reports/proRWP.AB

#Report classes to load

# Report.reportDir = reports

Report.report1 = MessageStatsReport

Report.report2 = BufferOccupancyReport

#Report.report3 = MessageReceivedReport

ProphetRouter.secondsInTimeUnit = 30

Optimization.cellSizeMult = 5

Optimization.randomizeUpdateOrder = true

GUI.UnderlayImage.fileName = data/helsinki_underlay.png

GUI.UnderlayImage.offset = 64, 20


56

GUI.UnderlayImage.scale = 4.75

GUI.UnderlayImage.rotate = -0.015

GUI.EventLogPanel.nrofEvents = 100

# Regular Expression log filter (see Pattern-class from the Java API for RE-

matching details)

#GUI.EventLogPanel.REfilter = .*p[1-9]<->p[1-9]$

D. Skenario Simulasi

Pergerakan Manusia (Haggle4 Cambridge Imote)

#

# settings for the simulation RealityMIT

#


Scenario.name = Feliks_Haggle4_Cam_imote

Scenario.simulateConnections = false







Group.movementModel = StationaryMovement

Group.nodeLocation = 0,1

Group.router = [ProphetRouter;ProphetAB]

#Group.router = ProphetRouters





Group.speed = 0.5, 1.8

Group.msgTtl = 1440


57

Group.nrofHosts = 36

#group1 (pedestrians) specific settings

Group1.groupID = n

Events.nrof = 2

Events1.class = StandardEventReader

Events1.filePath = Haggle4.csv



#Events2.interval = 3600, 3680



#Events2.hosts = 1,1

#Events2.tohosts = 35,35

Events2.hosts = 0,36

Events2.prefix = M


MovementModel.worldSize = 4500, 3400

#MovementModel.worldSize = 1400,1000



Report.warmup = 0

Report.reportDir = [reports/proHaggle;reports/proHaggleAB]


Report.report2 = BufferOccupancyReport

#15 menit


ProphetAB.secondsInTimeUnit = 300

## GUI settings

# GUI underlay image settings


# Image offset in pixels (x, y)


58


# Scaling factor for the image


# Image rotation (radians)


# how many events to show in the log panel (default = 30)



matching details)


E. Skenario Simulasi

Pergerakan Manusia (MIT)

#

# settings for the simulation RealityMIT

#


Scenario.name = Feliks_RealityMIT

Scenario.simulateConnections = false







Group.movementModel = StationaryMovement

Group.nodeLocation = 0,1

#Group.router = ProphetRouter

Group.router = [ProphetRouter;ProphetAB]





59


Group.speed = 0.4,1.8

Group.msgTtl = 1500

Group.nrofHosts = 97

# group1 (pedestrians) specific settings

Group1.groupID = n

Events.nrof = 2

Events1.class = StandardEventReader

Events1.filePath = RealityConnectionTraceFinal.txt



#interval awal yang dipakai 900,915



Events2.hosts = 1,1

Events2.tohosts = 96,96

Events2.prefix = M


MovementModel.worldSize =4500,3400

#MovementModel.worldSize = 1000,1000



Report.warmup = 0

#Report.reportDir = [reports/proReality/ttl300;reports/proRealityBT/ttl300]

#Report.reportDir =

[reports/proReality/ttl300;reports/proReality/ttl600;reports/proReality/ttl900;repor

ts/proReality/ttl1200;reports/proReality/ttl1500;reports/proReality/ttl1800]

#Report.reportDir =

[reports/proRealityBT/ttl300;reports/proRealityBT/ttl600;reports/proRealityBT/ttl

900;reports/proRealityBT/ttl1200;reports/proRealityBT/ttl1500;reports/proReality

BT/ttl1800]


60

Report.reportDir = [reports/proReality;reports/proRealityAB]


Report.report2 = BufferOccupancyReport2

#Report.report2 = DeliveryCentralityReport

#Report.report3 = MessageDelayReport

#Report.report4 = MessageDeliveryReport


ProphetAB.secondsInTimeUnit = 3600

## GUI settings

# GUI underlay image settings


# Image offset in pixels (x, y)


# Scaling factor for the image


# Image rotation (radians)


# how many events to show in the log panel (default = 30)



matching details)



ANALISIS UNJUK KERJA PROPHET BERBASIS ... tugas akhir, terimakasih atas bimbingan, kritik, saran, waktu dan kesabarannya dalam membimbing penulis hingga akhir. ...

Documents