Protokol komunikasi memiliki peran penting pada IoT. Contoh protokol tersebut adalah CoAP, MQTT yang umum digunakan, dan BLE, 6LoWPAN untuk mendukung penggunaan daya yang relatif rendah. Kemudian protokol tersebut didukung media komunikasi berbasis 802.11 dan 802.15.
1. MQTT
OASI melakukan standardisasi sebuah teknologi yang digagas oleh Arlen Nipper dan Andy Stanford pada tahun 2013. Pengembangan MQTT sendiri dimulai pada tahun 1999 oleh keduanya. Tujuan dari pengembangan protokol ini adalah menyediakan mekanisme komunikasi untuk perangkat embedded. Perangkat embedded memiliki sumber daya terbatas, sehingga perlu mekanisme komunikasi yang sesuai dengan karakteristik ini (Banks dan Rahul), 2014). Model komunikasi publish-subscribe menjadi dasar cara kerja MQTT.
A. Pola Publish-Subscribe
Pola komunikasi berbasis publish-subscribe berbeda dengan model client-server. Terlihat pada gambar 1.4 terdapat sensor pH yang publish (mengirim) data ke MQTT broker dan terdapat sebuah laptop yang subscribe (berlangganan) ke MQTT broker.
 |
| Gambar 1.1 Pola Publish-Subscribe pada MQTT |
Dari gambar 1.4, terdiri dari dua komponen utama yaitu :
- MQTT Client yang dapat berfungsi sebagai publisher dan subscriber. Publisher bertugas mengirim pesan berdasarkan sebuah topik dan subscriber berlangganan data berdasarkan sebuah topik.
- MQTT broker berfungsi menampung data sementara dari publisher dan meneruskan data ke siapa yang berlangganan berdasarkan topik.
Dengan adanya broker, menjadikan komunikasi antara publisher dan subscriber berjalan secara tidak langsung. Mekanisme komunikasinya adalah; sebagai publisher akan mengirim payload data sensor disertai sebuah topik "/ PH ". Pada gambar 1.4, "/ PH " adalah contoh sebuah topik yang di dalamnya terdapat sebuah informasi payload berupa data dari node sensor. Data tersebut akan dikirim ke broker untuk ditampung sementara. Peran sebagai subscriber adalah berlangganan topik "/ PH " ke broker. Saat broker menerima pesan dengan topik " / PH " maka akan berlangganan ke siapa saja yang berlangganan. Jika yang berlangganan ada 10 maka akan diteruskan ke 10 pelanggan (subscriber) tersebut.
B. Topic pada MQTT
Topik pada MQTT digunakan oleh broker untuk menandai sebuah pesan, karena yang mengirim pesan ke broker tidak hanya satu atau dua publisher. Dengan adanya topik, broker dapat membagi jalur komunikasi antara publisher dan subscriber. Contoh penulisan sebuah topik adalah " / PH ". Topik ini bersifat case-sensitive. Jadi subscriber harus tepat dalam menuliskan topik yang akan dilanggan baik dalam penulisan huruf besar maupun kecil. Untuk berlangganan topik dapat berlangganan satu topik atau langsung banyak topik sekaligus.
C. QoS
MQTT dikembangkan untuk berjalan di atas TCP / IP dan terdapat mekanisme pengiriman pesan yang digaransi dengan 3 level Quality of Service (QoS). 3 level tersebut menjamin pesan yang dikirim akan sampai ke penerima dengan kesepakatan yang berbeda. Penerima dapat berupa broker jika yang mengirim adalah publisher, dan subscriber jika pesan dikirim dari broker. Penentuan penggunaan QoS level ditentukan oleh pengirim.
QoS level 0 atau disebut juga pengiriman dengan "best-effort". Pesan yang dikirim tidak ada jaminan sampai dan pemberitahuan dari penerima. Pesan yang telah dikirim oleh pengirim tidak disimpan untuk opsi pengiriman ulang. Hal ini yang disebut dengan tidak ada jaminan pesan benar-benar sampai ke penerima. QoS level 2 menjamin pesan yang dikirim sampai ke penerima. Pengirim akan tetap menyimpan pesan yang telah dikirim untuk melakukan pengiriman ulang jika tidak menerima pesan "PUBACK" dari penerima. Jika dalam waktu yang ditentukan pengirim tidak menerima "puback" maka akan terus menerus mengirim ulang pesan sampai mendapat pesan "puback". QoS level 3 merupakan mekanisme yang menjamin pesan benar-benar sampai ke penerima. Saat pesan dikirim ke penerima dan penerima mendapatkan pesan dikirim dengan QoS 2, maka penerima akan membalas dengan pesan "PUBREC" sebagai pemberitahuan ke pengirim bahwa pesan telah sampai. Jika pengirim tidak menerima pesan "PUBREC", maka akan mengirim ulang pesan dengan tanda duplikasi (DUP) sampai mendapatkan pesan konfirmasi dari penerima. QoS level 3 menjadi garansi pengiriman yang tinggi akan tetapi membutuhkan waktu yang lebih lama jika dibanding dengan QoS level 1 (The HiveMQ Team, 2015).
2. CoAP
IETF Contstrained RESTful Environments (CoRE) mengembangkan Constrained Application Protocol (CoAP) sebagai protokol perpesanan pada IoT sesuai dengan konsep REpresentational State Transfer (REST). Dalam bertukar pesan CoAP bekerja seperti HTTP, menggunakan beberapa metode seperti POST, GET, DELETE, dan PUT. Yang membedakan adalah CoAP berjalan di atas protokol UDP dan Header pesan yang lebih kecil merupakan keunggulan CoAP.
Agar sesuai dengan lingkungan IoT, CoAP dikembangkan dengan beberapa fungsi yaitu : disesuaikan dengan karakteristik perangkat dengan sumber daya terbatas. Menggunakan UDP dengan fitur pengiriman yang reliable. Pertukaran pesan dengan overhead rendah, menggunakan URI seperti HTTP, dan fitur keamanan dengan Datagram Transport Layer Security (DTLS). Standar protokol CoAP didokumentasikan dalam FRC 7252 (Shelby, Hartke dan Bormann, 2014).
A. Model Pesan yang digunakan CoAP
Pesan CoAP terdiri dari 4 byte header, token 0-8 byte guna pertukaran pesan, informasi URL, jenis media dan payload. Selain itu, terdapat ID pesan berukuran 16 bit untuk fitur reliability. Reliability pada CoAP diwujudkan dengan mekanisme Confirmable (CON) dan pesan Acknowledgement (ACK). Pesan CON dikirim oleh pengirim dan ACK dikirim oleh penerima. Apabila dalam waktu yang telah ditetapkan pengirim tidak mendapatkan ACK dari penerima maka pesan akan dikirim ulang sampai pengirim mendapatkan ACK. Jika penerima tidak dapat memproses pesan yang didapat maka akan mengirimkan pesan Reset (RST). Sedangkan untuk pesan yang dikirim tanpa fitur reliability, pesan dapat dikirim sebagai Non-confirmable (NON). Jika pesan dikirim sebagai NON penerima tidak perlu mengirim ACK ke pengirim, akan tetapi jika pesan tidak dapat dibaca penerima akan tetap dapat mengirim RST.
B. Request-Response pada CoAP
Seperti yang disinggung sebelumnya, model pengiriman pesan pada CoAP ada dua yaitu CON dan NON. Pada saat mengirim pesan baik CON atau NON harus disertai dengan sebuah request. Request dapat berupa metode yang ada pada HTTP, sebagai contoh GET / Temp. Artinya pesan itu akan meminta informasi terkait topik / Temp. Jika terdapat topik tersebut, maka akan diberikan balasan berupa respons yang dikirim bersamaan dengan ACK. Jika tidak, maka akan dikirim pesan 404, yang artinya pesan yang diminta tidak ada pada server.
Penggunaan CON dan NON berbeda, jika pada gambar 1.5 pengirim dapat memberikan balasan ACK disertai isi pesan dan pesan error. Pada NON pengirim tidak memberikan balasan ACK tapi juga memberikan informasi balasan dengan model NON juga. Artinya pesan dari pengirim sampai atau tidak, pesan berikutnya akan tetap dikirim.
 |
| Gambar 1.2 Pola Request-Response pada CoAP |
 |
| Gambar 1.3 Paket Non-confirmable (NON). |
C. Method pada CoAP
Pesan request dari pengirim dapat berupa beberapa method yang ada pada HTTP. Pesan GET digunakan untuk meminta informasi berdasarkan Unifrom Resource Identifier (URI) yang diakses. Penerima di sini adalah sebuah server, penerima akan memeriksa format permintaan jika accept (sesuai) maka pesan akan diberikan respons sesuai permintaan, jika format permintaan salah maka akan dikirimkan kode 405 (pesan tidak diijinkan). Jenis pesan kedua adalah POST, metode ini digunakan untuk mengirim informasi ke penerima berdasarkan URI server.
D. URI pada CoAP
Skema URI yang digunakan pada CoAP adalah "CoAP:" " / / " host [":" port] path ["?" query]. Skema URI ini untuk mengidentifikasi sumber daya yang akan diakses. Host dapat berupa domain atau IP address dari server CoAP. Port yang umum digunakan untuk CoAP adalah 5683. Path adalah lokasi dimana sumber daya itu ada dan query adalah parameter yang ingin diminta.
3. RESTful Web Services
Protokol komunikasi yang umum digunakan selain CoAP dan MQTT adalah REST atau Representational State Transfer. REST bekerja di atas TCP / IP dan berbasis protokol HTTP. Pada IoT, REST dapat dijadikan standar komunikasi umum dikenal dengan Web Of Things (WoT). WoT dapat digunakan untuk menyeragamkan cara berkomunikasi antarperangkat dalam IoT. Metode yang digunakan pada umumnya adalah GET dan POST. Implementasi REST pada IoT berada pada Layer aplikasi dengan menyediakan antarmuka API untuk menerima data dan membagi data ke aplikasi lainnya.
0 Komentar