Perancangan dan Implementasi Pengaturan Source Rate untuk Mengatasi Kongesti pada Studi Kasus Transmisi Data Radar

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)

1

Perancangan dan Implementasi Pengaturan Source Rate untuk Mengatasi Kongesti pada Studi Kasus Transmisi Data Radar Hermawan Winata, Dwi Sunaryono, dan Suhadi Lili Jurusan Teknik Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember Jl. Arief Rahman Hakim, Surabaya 60111 Indonesia e-mail: [email protected] Abstrak—Transmisi data radar memerlukan pengiriman tepat waktu agar informasinya tidak menjadi basi. Data yang diperoleh dari radar mengandung informasi yang sensitif terhadap waktu, yaitu laporan posisi objek yang terdeksi. Jika datang terlambat di klien, data tersebut menjadi basi dan kurang berguna karena objek mungkin sudah berpindah tempat. Sebuah situs radar menerima banyak data dari beberapa radar dan memprosesnya untuk mendapatkan gambaran yang lebih menyeluruh akan sebuah daerah. Selanjutnya hasil proses tersebut perlu didistribusikan ke situs radar lain atau ke sebuah tampilan. Banyak data radar yang harus didistribusikan merupakan akumulasi data dari semua radar yang terhubung sehingga memerlukan sambungan dengan lebar pita yang memadai. Tanpa adanya infrastruktur yang mencukupi, tidak semua data dapat dikirimkan ke klien sehingga diperlukan adanya prioritas pengiriman. Di dalam artikel ini ditawarkan sebuah protokol pada lapisan aplikasi yang dapat menghindari kongesti tetapi tetap memanfaatkan lebar pita secara maksimal dan tidak mengirimkan data basi. Protokol yang dibuat berdasarkan protokol DCCP. Untuk menjaga relevansi informasi, data akan dipilih berdasarkan nilai prioritas. Relevansi informasi akan dikuantifikasi dan diurutkan ke dalam priority queue sebelum dikirimkan. Sistem akan diuji dengan menggunakan pengujian throughput dan pengujian kebenaran. Hasil pengujian menunjukkan bahwa sistem berhasil mencegah kongesti dan mampu menjaga relevansi informasi yang dikirimkan. Kata Kunci—DCCP, kongesti, prioritas pengiriman, source rate control.

I. PENDAHULUAN

R

ADAR, singkatan dari RAdio Detection And Ranging, merupakan sistem pendeteksi objek dengan menggunakan gelombang radio untuk mengetahui arah, ketinggian, dan/atau kecepatan objek tersebut [1]. Radar bekerja dengan cara memancarkan gelombang radio dan menerima pantulan balik setelah gelombang tersebut memantul dari permukaan sebuah objek. Radar memiliki cakupan wilayah terbatas dengan jangkauan maksimum hingga 463 km [2]. Untuk mendapatkan gambaran yang menyeluruh akan suatu wilayah yang luas, misalnya mencakup wilayah negara, dibutuhkan integrasi data dari beberapa radar. Komunikasi data dalam skala nasional ini akan secara signifikan meningkatkan lalu lintas data, terutama ketika jumlah objek yang terdeteksi sangat banyak. Pengiriman data radar memiliki karakteristik mutu layanan yang berbeda dengan aplikasi lainnya, seperti transfer berkas

ataupun video melalui jaringan [3]. Kebutuhan akan mutu layanan dapat diuraikan menjadi 4 parameter [4] yaitu kehandalan, delay, jitter, dan bandwidth. Berdasarkan parameter-parameter tersebut, aplikasi radar memiliki tuntutan mutu layanan untuk kehandalan sedang, tingginya tuntutan akan delay, tuntutan jitter rendah, dan tuntutan bandwidth sedang. Data yang dikirimkan, karena bersifat time-sensitive, memerlukan delay rendah agar data yang diterima bukan data basi. Kehandalan pengiriman data tidak terlalu ketat meskipun integritas data harus dipertahankan. Data yang rusak akan dibuang dan diminta kembali untuk dikirim ulang. Kebutuhan aplikasi akan jitter termasuk rendah yang berarti kedatangan data dalam interval yang tidak teratur tidak berpengaruh pada aplikasi. Tuntutan terhadap bandwidth tidak terlalu tinggi karena adanya keterbatasan infrastruktur sehingga aplikasi diharapkan mampu menyesuaikan throughput dengan memilah data yang akan dikirim. Berdasarkan kebutuhan masing-masing aplikasi, pengiriman data melalui internet dapat menggunakan protokol transpor yang berbeda-beda. Protokol transpor yang paling sering digunakan adalah UDP (Universal Datagram Protocol) dan TCP (Transmission Control Protocol). Protokol UDP tepat digunakan ketika aplikasi membutuhkan ketepatan waktu pengiriman data dan aplikasi bersifat toleran akan rusak dan tidak urutnya data. Sebaliknya, protokol TCP digunakan ketika aplikasi tidak mentolerir adanya data yang hilang/rusak serta menginginkan data tiba berurutan dan tuntutan akan pengiriman data real-time rendah. Mengacu pada mutu layanan yang diinginkan, protokol TCP tidak cocok digunakan karena pengiriman ulang data yang hilang akan menyebabkan data menjadi basi ketika sampai di penerima. UDP, karena tidak mengimplementasikan congestion control, akan menyebabkan data hilang ketika terjadi kongesti [5]. Oleh sebab itu, diperlukan sebuah protokol yang dibangun di atas UDP untuk menangani kongesti dan menambah kehandalan pengiriman data. Pada penulisan artikel ini, penulis menawarkan modul pengaturan source rate yang diimplementasikan berdasarkan DCCP, Datagram Congestion Control Protocol. Modul ini diharapkan dapat meminimalkan hilangnya data akibat kongesti dan memaksimalkan throughput.

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print) II. TINJAUAN PUSTAKA A. DCCP DCCP, singkatan dari Datagram Congestion Control Protocol adalah sebuah protokol transpor yang mengimplementasi koneksi datagram dua arah secara unicast dan memiliki congestion control. DCCP memiliki kemiripan dengan TCP dalam hal inisiasi koneksi (handshaking), pengiriman data, dan penutupan koneksi. Selain itu, DCCP juga memiliki pengukuran RTT, penomoran paket yang dikirim, dan pengiriman ACK (ACKnowledgement) untuk paket yang diterima. Secara umum, dapat dikatakan bahwa DCCP adalah TCP tanpa reliability dan bytestream semantics atau UDP dengan handshake, congestion control, dan acknowledgement [6]. DCCP didesain agar memiliki overhead seminimal mungkin yaitu dalam hal ukuran header paket dan state yang dimiliki. Hal itu menyebabkan fungsionalitas DCCP terbatas dan mengijinkan fungsionalitas tambahan seperti Forward Error Correction (FEC) dan semi-reliability diimplementasikan pada lapisan atas DCCP. DCCP memiliki fitur tambahan yang mirip dengan TCP SACK (Selective ACKnowledgement) yaitu ACK vector. Dengan menggunakan ACK vector, dapat diperoleh gambaran lebih lengkap mengenai paket yang berhasil diterima oleh penerima. Selain itu, karena bersifat redundan, ACK vector menyebabkan DCCP mampu mentolerir paket ACK yang hilang. B. Congestion Control Congestion control merupakan sebuah algoritma untuk mencegah jaringan terbanjiri oleh laju lalu lintas data. Secara umum, pendekatan untuk menangani kongesti dapat dilakukan dengan mendeteksi kongesti dan memperlambat pengiriman. Mekanisme congestion control yang digunakan DCCP memiliki kemiripan dengan yang dimiliki oleh TCP, kecuali dalam satuan yang digunakan. Pengiriman DCCP dilakukan dalam satuan paket/datagram bukan byte. Kongesti dapat terjadi ketika laju penerimaan lebih cepat daripada laju pengiriman sehingga memaksa jaringan untuk menyimpan data yang diterima. Bila hal ini terus berlangsung, jaringan akan segera kehabisan kapasitas penyimpanan dan terpaksa membuang paket yang datang. Kongesti yang tidak segera ditangani akan memperparah kondisi jaringan sehingga tidak secara efisien mengantarkan data. Untuk memaksimalkan penggunaan bandwidth dan menghindari kongesti, DCCP menggunakan variabel cwnd untuk membatasi jumlah paket yang dikirimkan. Nilai cwnd berubah-ubah dalam 3 tahap. Tahap awal atau setelah timeout, cwnd memiliki nilai awal kecil dan menjadi dua kali lipatnya setiap RTT (round trip time). Tahap ini disebut slow start. Selain cwnd, digunakan variabel ssthresh yang merupakan estimasi bandwidth. Tahap kedua dan ketiga adalah congestion avoidance dan fast retransmit. Mekanisme congestion control DCCP mengadopsi protokol AIMD (Additive Increase Multiplicative Decrease) [7] yang menggunakan 2 parameter, α dan β. TCP mendefinisikan nilai

2

α sebesar 1 dan β 0,5. Pada saat cwnd lebih dari sama dengan ssthresh, nilai cwnd ditambah α tiap RTT hingga kongesti dideteksi. Tahap ini dinamakan congestion avoidance. Ketika kongesti dideteksi melalui timeout, cwnd akan dikembalikan ke nilai awal dan nilai ssthresh dibagi dua. Kongesti juga dapat dideteksi dengan adanya duplicate ack yang berarti sejumlah paket dengan sequence number lebih besar diterima lebih dulu. Ketika hal ini terjadi, ssthresh menyimpan nilai cwnd dan nilai cwnd berubah menjadi hasil kali cwnd dengan 1-β. C. Pengukuran RTT TCP menyalakan sebuah timer untuk setiap segmen yang dikirim dan jika ACK (Acknowledgement) belum diterima hingga batas waktu timer tersebut, maka terjadi timeout. Interval waktu sejak pengiriman hingga timeout itu disebut retransmission timeout (RTO). DCCP, karena tidak mendefinisikan pengiriman ulang, mengganti istilah retransmission timeout menjadi transmission timeout. Bedanya, jika RTO digunakan untuk mengirimkan kembali paket yang hilang, transsmission timeout digunakan untuk mengirim paket selanjutnya. Namun, penghitungan nilai keduanya sama-sama berasal dari pengukuran RTT. Nilai RTO diperoleh melalui pengukuran RTT yang terjadi setelah Ack diterima. TCP selalu mengirimkan ACK setiap kali data diterima sehingga selang waktu antara pengiriman sebuah segmen hingga ACK untuk segmen itu diterima dapat digunakan sebagai sampel RTT. Interval waktu tersebut, selain dapat diketahui melalui timer yang dijalankan setiap paket dikirim, dapat juga dihitung melalui timestamp echo, yaitu semua paket ACK mencantumkan timestamp pengiriman paket yang di-ACK. Dari beberapa sampel RTT yang bervariasi, kemudian dilakukan estimasi RTT untuk menentukan nilai RTO. Pada mulanya TCP menghitung nilai RTO hanya berdasarkan rata-rata berbobot dari sampel RTT. Selanjutnya, rata-rata deviasi juga dievaluasi sesuai [8]. D. Rasio ACK Berbeda dengan TCP yang tidak memiliki algoritma penanganan kongesti pada reverse path, DCCP (Datagram Congestion Control Protocol) mengatur kecepatan pengiriman ACK dengan fitur ini. Rasio ACK menandakan jumlah paket minimum yang harus diterima sebelum ACK dikirim. Semakin tinggi rasio ini kecepatan pengiriman ACK semakin lambat. Rasio ACK ini ditingkatkan ketika dideteksi adanya kongesti pada reverse path dan diturunkan ketika sejumlah ACK yang berurutan berhasil diterima tanpa rusak atau hilang.

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)

3

Gambar 2. Blok diagram arsitektur sistem distributor dan display.

Gambar 1. Diagram transisi state pada DCCP.

Berdasarkan [9], rasio ACK harus memenuhi 3 batasan: merupakan bilangan bulat, tidak boleh lebih dari cwnd/2 dibulatkan ke atas kecuali nilai 2 selalu diperbolehkan, dan bernilai 2 atau lebih untuk cwnd berukuran 4 atau lebih. Ketika dideteksi adanya ACK yang hilang, rasio menjadi dua kali lipat lebih besar. Untuk setiap cwnd/(R2-R) cwnd data berturut-turut yang berhasil diterima klien, nilai rasio berkurang 1. Penggunaan rasio ACK mengharuskan delayed ACK juga diimplementasikan. Ketika paket data yang diterima tidak sampai sebanyak rasio ACK, timer delayed ACK akan aktif dan mengakibatkan ACK tetap dikirim. Interval dari delayed Ack pada sebagian besar implementasi adalah 200 milidetik. E. State-state DCCP Sama seperti TCP, DCCP memiliki beberapa state yang dapat dilihat pada Gambar 1. Deskripsi dan algoritma yang dijalankan di setiap state dapat dilihat di [6]. F. Double-Ended Priority Queue Double-Ended Priority Queue (DEPQ) merupakan sebuah priority queue yang tidak hanya mengijinkan pengguna mengakses elemen teratas tetapi juga elemen terbawah. Struktur data ini dapat digunakan untuk membatasi ukuran priority queue—data yang masuk ketika kapasitas tidak mencukupi mengharuskan adanya data yang dibuang terlebih dahulu. Fungsi-fungsi yang dapat digunakan antara lain FindMin, FindMax, DeleteMin, DeleteMax, dan Insert. Berdasarkan evaluasi yang dilakukan [10], interval heap merupakan implementasi yang paling efisien untuk DEPQ. G. ASTERIX 48 ASTERIX—akronim

dari

All

Purpose

STructured

Eurocontrol SuRveillance Information EXchange— merupakan sebuah standar pertukaran informasi dari radar menuju ATC (Air Traffic Control/Pemandu Lalu Lintas Udara) dan antar-ATC. ATC bertugas untuk mencegah tabrakan antarpesawat udara, mengatur arus lalu lintas, dan memberikan informasi yang dibutuhkan pilot. ASTERIX mendefinisikan struktur data dari pesan yang dikirimkan melalui jaringan komunikasi, mulai dari encoding setiap bit informasi hingga pengelompokan informasi ke dalam blok-blok data [11]. Hingga tahun 1980, setiap Administrasi Nasional membuat format sendiri-sendiri untuk mengirimkan data radar ke pusat ATC. Selain merupakan usaha yang redundan, hal ini mempersulit pertukaran data radar melintasi batas negara. Kebutuhan akan format data yang sama menyebabkan lahirnya ASTERIX yang terus dikembangkan hingga sekarang dan digunakan secara luas. Berdasarkan jenis data yang ditransmisikan, terdapat beberapa kategori ASTERIX. Dalam solusi yang ditawarkan di artikel ini, akan digunakan ASTERIX kategori 48 yang sesuai untuk transmisi monoradar target reports dari radar. III. DESAIN DAN ANALISIS A. Deskripsi Umum Sistem Dalam artikel ini, dibuat sebuah modul yang menangani pengiriman data radar dengan memprioritaskan data yang akan dikirim. Banyaknya data radar yang masuk dan medium perantara atau infrastruktur yang memiliki keterbatasan bandwidth mengakibatkan tidak semua data dapat dikirimkan. Sebelum dapat memilih data pesawat mana yang harus didahulukan, perlu dipertimbangkan terlebih dahulu apa saja yang menjadi penentu nilai prioritas. Prioritas yang didahulukan antara lain pesawat militer, pesawat dengan predictability rendah, dan pesawat yang belum terkirim sebelumnya. Modul yang dibuat juga diharapkan mampu menambah kehandalan pengiriman data. Kehandalan yang dimaksud tidak seperti kehandalan yang dimiliki oleh TCP, semua informasi

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)

4

Gambar 3. Diagram blok source rate control.

Byte offset

0 0 4

1 Jenis paket

2 Sequence Number (32 bits)

Acknowledgement Number (32 bits)

16 20 Bit

Timestamp (64 bits)

20 bytes

8 12

3

Timestamp (cont.) ACK ratio / ACK vector (24 bits) ASTERIX 48 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 26 27 28 29 30 31

Gambar 4. Struktur header SRMessage.

wajib diterima secara urut. Informasi mengenai data yang tidak berhasil diterima oleh penerima menyebabkan data tersebut masuk kembali ke dalam buffer pengiriman. Jika kemudian jumlah data dengan prioritas lebih tinggi dari data yang akan dikirim ulang membengkak dan memenuhi buffer pengiriman, data tersebut batal dikirim ulang. B. Perancangan Arsitektur Arsitektur program secara keseluruhan dapat dilihat pada Gambar 2. Modul yang dibuat dalam artikel ini diberi warna biru. Distributor akan mendapat masukan ASTERIX dan menyaringnya hingga hanya ASTERIX 48 yang akan diterima. Plot dari ASTERIX 48 kemudian akan diasosiasikan menjadi track oleh modul Tracker1. Selanjutnya Tracker akan mengirimkan sejumlah track yang ter-update kepada source rate control untuk didistribusikan kepada display dalam bentuk SRMessage. SRMessage merupakan format pesan yang tersusun atas header protokol dan data track dengan format ASTERIX 48. Selanjutnya, display akan menerima data tersebut dan mengirimkan umpan balik yang diperlukan ke distributor juga dalam bentuk SRMessage. Distributor dan display dapat berjalan di mesin yang berbeda. 1

Modul Tracker dibuat oleh Ferry Fernandez Wijaya dalam [12]

C. Perancangan Nilai Prioritas Priority queue mengurutkan objek-objek yang dimiliki berdasarkan nilai objek tersebut atau berdasarkan hasil sebuah fungsi pembanding. Nilai prioritas yang digunakan dalam pengurutan diperoleh dari pembobotan nilai-nilai karakteristik sebuah track dengan penjabaran pada (1).

prioritas   m   err   dt

(1)

Persamaan (1) merupakan cara mengkuantifikasi relevansi informasi sebuah track. Terdapat beberapa variabel, yaitu variabel prioritas yang merupakan hasil yang dicari, m merupakan sebuah Boolean apakah pesawat tersebut militer atau bukan, err merupakan nilai predictability pesawat tersebut, dan dt berisi selisih waktu sekarang dengan waktu klien berhasil menerima track tersebut. Berdasarkan hasil percobaan, diperoleh kombinasi α, β, dan γ yaitu bernilai 0,3;0,5;0,2 dan jumlah ketiganya adalah 1. D. Perancangan Data SRMessage sebagai pesan yang dipertukarkan memiliki header seperti ditunjukkan Gambar 4. Header ini memiliki ukuran total 20 byte. Susunan informasi yang terkandung di dalamnya dapat dijelaskan sebagai berikut. Jenis paket menempati byte pertama. Setelah itu, terdapat sequence number dan acknowledgement number berukuran 4 byte. Data berikutnya berisi timestamp berukuran 8 byte. Timestamp ini akan diisi oleh waktu pengiriman untuk jenis paket SRMessage-Response, SRMessage-DataAck, dan SRMessageSync. Untuk jenis paket SRMessage-Ack dan SRMessageSyncAck, timestamp akan berisi waktu pengiriman paket data yang memicu pengiriman paket ini (timestamp echo). Tiga byte terakhir berisi nilai rasio ACK jika paket berasal dari server atau berisi ACK vector jika berasal dari klien. Setelah header, terdapat data dalam format ASTERIX 48 jika paket

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print)

5

Tabel 1. Perbandingan total nilai error data Rekaman 1 antara pengiriman dengan prioritas dan tanpa prioritas dalam berbagai kondisi jaringan.

Gambar 5. Throughput data Rekaman 1 ketika bandwidth 256 byte/detik dengan menggunakan modul yang dibuat.

berjenis SRMessage-DataAck. E. Perancangan Blok-Blok Fungsional Diagram blok dari fungsionalitas source rate control dapat dilihat pada Gambar 3. Blok-blok fungsional yang diberi warna kuning merupakan blok fungsional dari DCCP. Blok fungsional yang dibuat dapat dijabarkan sebagai berikut. 1) Blok Priority Distributor Blok ini bertugas memberikan nilai prioritas kepada sebuah track yang akan dikirim sesuai (1) untuk menentukan letaknya di dalam priority queue. Masukan dari blok ini adalah sebuah track yang baru di-update atau yang akan dikirim ulang sebagai keluaran blok Reliability System. 2) Blok Packet Discarder Blok ini bertugas membuang track basi dan mengirimkan sejumlah track. Selain menerima jumlah track yang boleh dikirim dari blok Congestion Control, blok ini juga menerima nomor urut track yang akan dikirim dari blok Reliability System untuk mempermudah paket tersebut dilacak (hilang atau berhasil diterima). 3) Blok Congestion Control Blok ini berfungsi mengatur banyaknya track yang boleh dikirimkan dalam suatu waktu. Jumlah track merupakan keluaran dari blok ini sementara masukannya adalah latency dari pengukuran RTT dan jumlah paket hilang dari blok Reliability System. 4) Blok Reliability System Blok ini bertugas untuk memberikan nomor urut pengiriman kepada blok Packet Discarder dan memproses umpan balik dari penerima. Hasil proses tersebut adalah statistik kondisi jaringan yaitu banyaknya paket yang hilang dan yang diterima. Selain itu, dihasilkan juga identitas track yang hilang di blok ini. Banyaknya paket yang hilang sebagai indikasi kongesti akan mempengaruhi blok Congestion Control sementara identitas track yang hilang akan diberikan kepada Priority Distributor untuk memasukkan kembali track itu ke dalam priority queue. 5) Blok Session Manager Blok ini bertugas menjaga session komunikasi data antara klien dengan server. Track akan dibungkus dalam header SRMessage sebelum dikirim ke klien. Paket SRMessage yang diterima dari klien akan diolah sehingga diperoleh latency dan nomor-nomor paket yang hilang. IV. HASIL PENGUJIAN Pengujian dilakukan dengan memutar ulang rekaman dari

Kondisi jaringan Delay 200 milidetik Bandwidth 256 byte/detik Persentase paket hilang 10%

Total Nilai Error Fungsi Prioritas prioritas acak 844.767,147 852.505,011 657.857,526 841.405,322 843.164,868 843.179,899

hasil tangkapan radar. Rekaman ini, diberi nama Rekaman 1, memiliki durasi dua puluh menit. A. Pengujian Performa Pengujian performa dilakukan dengan menggunakan emulator jaringan dummynet dan sniffing tool Wireshark untuk mengetahui apakah throughput berhasil dioptimalkan. Gambar 5 merupakan grafik throughput ketika bandwdith diatur menjadi 256 byte/detik. Dari Gambar 5 dapat disimpulkan bahwa penggunaan bandwidth berhasil dimaksimalkan tanpa menimbulkan kongesti. B. Pengujian Kebenaran Pengujian kebenaran ini dilakukan untuk mengetahui apakah dengan adanya pengiriman berdasarkan prioritas, kinerja sistem lebih baik daripada tanpa adanya prioritas. Untuk mencapai tujuan tersebut, dilakukan perbandingan berdasarkan total nilai error antara posisi prediksi dengan posisi sebenarnya dari radar. Nilai error setiap track dapat diperoleh dari (1). Perbandingan total nilai error dilakukan dengan membandingkan sistem pengiriman berdasarkan prioritas menggunakan (1) dan yang berdasarkan prioritas acak. Hasil dari pengujian ini dapat dilihat pada Tabel 1. Di Tabel 1, total nilai error fungsi prioritas lebih sedikit dibandingkan dengan yang menggunakan prioritas acak sehingga dapat disimpulkan pengiriman berdasarkan fungsi prioritas lebih baik daripada tanpa prioritas. Selain itu, dapat disimpulkan bahwa modul source rate control bekerja dengan lebih baik dalam kondisi bandwidth yang dibatasi dibandingkan ketika terdapat delay atau persentase paket hilang. Hal tersebut dapat dilihat dari selisih total nilai error ketika bandwidth dibatasi lebih signifikan daripada ketika terdapat delay dan kemungkinan paket hilang. V. KESIMPULAN Dari hasil perancangan, implementasi, dan pengujian, penulis mengambil kesimpulan sebagai berikut. 1. Relevansi informasi sebuah track berhasil dikuantifikasi melalui pemberian bobot 2 informasi, yaitu informasi jenis pesawat udara dan informasi nilai predictability pesawat tersebut. Hasil kuantifikasi tersebut, jika digunakan sebagai penentu tingkat prioritas pengiriman, terbukti lebih baik dibandingkan dengan tanpa adanya prioritas pengiriman, dilihat dari total nilai error-nya pada pengujian kebenaran. Prioritas pengiriman juga dapat disimpulkan lebih baik

JURNAL TEKNIK POMITS Vol. 2, No. 1, (2013) ISSN: 2337-3539 (2301-9271 Print) ketika bandwidth terbatas daripada ketika delay dan adanya persentase paket hilang. 2. Modul source rate control berhasil diimplementasikan dengan algoritma congestion control milik TCP. Dari hasil pengujian throughput, dapat disimpulkan bahwa modul yang dibuat berhasil menggunakan kapasitas maksimum bandwidth. 3. Arsitektur perangkat lunak berhasil diimplementasi dengan menerapkan dua pola perancangan, yaitu pola perancangan State dan Strategy. 4. Implementasi modul di atas UDP berhasil dilakukan dengan mengimplementasi DCCP sesuai [6] yang merupakan ekstensi UDP. UCAPAN TERIMA KASIH Penulis H.W. mengucapkan terima kasih secara khusus kepada PT. Infoglobal Teknologi Semesta yang telah memberikan fasilitas serta dukungan hingga artikel ini selesai ditulis dan juga kepada keluarga, dosen pembimbing, dosen dan staff jurusan Teknik Informatika ITS, serta semua pihak yang telah membantu penulisan artikel ini. DAFTAR PUSTAKA [1]

Larry Gilman. (2004) "Radar" in Encyclopedia in Espionage, Intelligence, and Security. [Online]. http://www.encyclopedia.com/doc/1G2-3403300634.html [2] Christian Wolff. Radartutorial.eu. [Online]. http://www.radartutorial.eu/01.basics/rb02.en.html [3] Tarun Banka, Aditya Maroo, Anura P. Jayasumana, V. Chandrasekar, Nitin Bharadwaj, and SathishKumar Chittibabu, "Radar Networking: Considerations for Data transfer Protocols and Network Characteristics," Proc. of AMS IIPS for Meteorology, Oceanography, and Hydrology, American Meteorological Society (AMS), 2005. [4] Andrew S. Tanenbaum, Computer Networks, 4th ed. Upper Saddle River, New Jersey: Prentice Hall, 2003. [5] Sangeetha L. Bangolae, Anura P. Jayasumana, and V. Chandrasekar, "Gigabit Networking: Digitized Radar Data and Beyond," Proc. IEEE International Conference on Communications (ICC'03), vol. I, pp. 684688, May 2003. [6] Eddie Kohler, Mark Handley, and Sally Floyd, "Datagram Congestion Control Protocol (DCCP)," IETF RFC 4340, 2006. [7] Sally Floyd, Mark Handley, and Jitendra Padhye, “A Comparison of Equation-Based and AIMD Congestion Control”, May 2000. [8] W. Richard Stevens and Fall Kevin R., TCP/IP Illustrated, Vol. 1: The Protocols, 2nd ed. United States of America: Addison-Wesley, 2012, 651-654. [9] Sally Floyd and Eddie Kohler, "Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2: TCP-like Congestion Control," IETF RFC 4341, 2006. [10] M. Ziaur Rahman, Rezaul Alam Chowdhury, and M. Kaykobad, "Improvements in Double Ended Priority Queues," International Journal of Computer Mathematics, vol. CXXX, no. 9, pp. 1121-1129, September 2003. [11] The European Organisation for the Safety of Air Navigation EUROCONTROL. (2013) EUROCONTROL Web site. [Online]. http://www.eurocontrol.int/services/asterix [12] Ferry Fernandez Wijaya, “Perancangan dan Implementasi Model Regresi Sebagai Solusi Untuk Asosiasi Plot Dengan Track yang Digunakan Pada Sistem Primary Surveillance Radar Secara Real-Time,” Institut Teknologi Sepuluh Nopember, Surabaya, Undergraduate Thesis 2013.

6