BSM 460 KABLOSUZ ALGILAYICI AĞLAR 1
BSM 460 KABLOSUZ ALGILAYICI AĞLAR 4. Hafta NESNELERİN İNTERNETİ UYGULAMA PROTOKOLLERİ 2
IoT Kullanılan Protokoller Nesnelerin internetinde IEEE, ETSI gibi organizasyonların en sık tanımladığı protokoller, 3
IoT Kullanılan Protokoller 4
Genişletilebilir Mesajlaşma ve Durum Protokolü (Extensible Messaging and Presence Protocol, XMPP) XMPP, genişletilebilir işaretleme dili (XML) tabanında, gerçek zamanlı sayılabilecek, mesajlaşma, durum yönetimi ve istek-yanıt hizmetleri için geliştirilmiş bir uygulama protokolüdür. XMPP, Internet Engineering Task Force (IETF) tarafından yayımlanan RFC 3920 ve RFC 3921 ile tanımlanmıştır. Jeremie Miller tarafından 1999 yılında anında mesajlaşma hizmeti için ortaya konulmuştur. Başlangıçta Jabber olarak bilinir. XMPP, gerek iki sunucu, gerekse iki istemci arasında, P2P (Peer-to-Peer) haberleşme olanağı sağlayabilen ve birbirlerine bağlanabilen servisler arasında otonom ağlar oluşturabilmektedir. XMPP, istemciler arasında veri iletimi için, XML paket formatını kullanan gerçek zamanlı iletişim protokolüdür. XMPP, internet üzerinden anlık mesaj gönderimi ile kullanıcıların birbirleri ile haberleşmesine izin verir. 5
XMPP Adresleme XMPP ağı üzerindeki her varlık JID (jabber kimliği) olarak adlandırılan tek bir adrese sahiptir. Bir JID kimliği, user@domain/resource (kullanıcı@alanadı.com/kaynak) yapısında, yerel ad, alan adı ve kaynak bildirimlerine sahiptir. Her XMPP kimliğinde bulunması gereken alan adı alanı, tüm XMPP ağı içerisinde o varlığa ait alt ağı tanımlamak için kullanılır. Kullanıcı adı ve alan adı alanının bileşkesiyle (kullanıcı@alanadı.com) elde edilen jid yapısı, çıplak (bare) jid olarak isimlendirilir. Kaynak bildirimi ise, bir kullanıcının farklı istemciler üzerinden bağlantı kurabildiği durumlarda hangi istemcinin hangi kaynağı kullandığını tanımlamak için tanımlanmaktadır. Bir jabber kimliğini oluşturan bu üç bileşenin yer aldığı adres yapısı tam (full) jid olarak isimlendirilir. Temel olarak bare jid XMPP federasyonundaki o kullanıcıyı ifade ederken, full jid anlık oturumu ifade etmektedir. 6
XMPP Sinyalleşme Genel olarak bir XMPP sinyalleşme süreci yapısal olarak şu şekildedir: Sunucu ile uzun ömürlü TCP bağlantının kurulması, XML akışlarının başlatılması, Çeşitli XML şemalarının paylaşımı, Sunucu üzerinde istemci kimliğinin doğrulanması, Kaynak seçiminin sağlanması, Anında mesajlaşma süreci öncesi kullanıcı listelerinin alınması ve ilk durumun sunucuya bildirimi şeklinde gerçekleşir. Halil Arslan ın Dr. Tezinden Alınmıştır. 7
XMPP Paket Yapıları XMPP sinyalleşme gerçekleştirildikten sonra bağlantı üzerinden XMPP de tanımlı XML paket yapıları üzerinden iletişim akışı sürdürülür. XML paket yapıları XML Stanza olarak isimlendirilir. XMPP de XML paket formatı 3 temel tanımlama alanına sahiptir. mesaj (<message>), kullanıcılar (istemci) arasında her türlü bilgiyi aktarmak için kullanılabilir. durum (<presence>), bir kullanıcının XMPP ağında varlığını kontrol eder ve raporlar. Kısaca XMPP ağındaki bir kullanıcının çevrimiçi, meşgul, çevrimdışı gibi durumlarını yönetmek için kullanılan paket yapısıdır. Böylece kullanıcıların birbirlerinin erişilebilirliğini kontrol edebilmeleri sağlanır. bilgi/sorgu (<iq>) istemci-sunucu arasında iletilmek istenen bir verinin, mesaj ya da durum paket yapılarına uymadığı durumlarda bilgi/sorgu paketi olarak kullanılması için tasarlanmıştır. Bilgi/sorgu paketleri genel olarak istek/cevap paketi olarak konumlandırılmıştır. Bu paket yapısı özelleştirilerek, protokolün genişletilebilirliği sağlanır. Bu paket yapısı özellikle HTTP mimarisinde kullanılan GET, POST, PUT vb. yöntemlerinde olduğu gibi istek-yanıt etkileşimini sağlamaya yönelik iş akışları için bir yapı sağlamaktadır. Bu paket yapılarının her biri sunucu tarafından farklı yönlendirildiği gibi istemciler tarafından da farklı işlenir. 8
XMPP Paket Yapıları XMPP paket yapıları, alıcılar tarafından paketin nasıl işleneceğini belirleyen öznitelik:değer tanımlamalarından oluşur. XMPP paket yapıları 5 farklı özniteliğe sahiptir. Kime (to) özniteliği, ilgili paketinin alıcısını tanımlayan JID dir. Kimden (from) özniteliği, ilgili paketin kim tarafından gönderildiğini tanımlayan JID dir. Bir istemci kimden özniteliği olmayan bir paket alırsa bu paketin istemcinin bağlı olduğu sunucudan geldiğini kabul eder. Ancak sunucuya gelen bir XMPP paketinde kimden alanı geçersiz yada tanımlanmamışsa bu durumda sunucu istemciye geçersiz kimden (<invalid-from/>) cevabı dönecektir. Kimlik (id) özniteliği, XMPP paketlerinde oluşan cevap paketlerinin eşleştirilmesinde/kimliklendirilmesinde yardımcı olmak için bilgi/sorgu (iq) paketi hariç seçimli olarak kullanılır. Tip (type) özniteliği, mesaj (<message>), durum (<presence>) ve bilgi/sorgu (<iq>) paketlerinin içeriği yada amacı hakkında bilgiler ifade etmektedir. Üç tip paket yapısı için ortak olan tip özniteliği hata (error) değeridir. Tip (type) özniteliğinin alabileceği değerler bu üç paket yapısı için ayrı ayrı özelleştirilmiş anlamlar ifade etmektedir XML dil (xml:lang) özniteliği, XML karakterlerinin varsayılan dilini ifade eder. XML dil tanımı, alt etiketler tarafından değiştirilebilir. Bu özniteliğin hiç tanımlanmadığı durumlarda sunucunun varsayılan dil tanımı kullanılır. 9
Messega Queue Telemetry Transport (MQTT) MQTT, nesnelerin interneti ya da makineler arası haberleşmede kullanılan mesajlaşma protokolüdür. 1999 yılında IBM ve Arcom (bugün Eurotech) tarafından tanıtılmış ancak 2013 te OASIS standartlaştırmıştır. MQTT, gömülü sistemler ve network (bulut) bağlantısını sağlamayı amaçlamaktadır. Diğer bir değişle küçük cihazlardan oluşan ağları bulut üzerinden kontrol etmeyi ve izlemeyi sağlar. MQTT, yayınlama (publisher) ve abone (subscriber) olma mantığına dayanan telemetri mesajlaşma protokolüdür. MQTT protokolünün öne çıkan özellikleri arasında mesajları saklayabilme ve bağlantı kurulduğunda tekrar gönderebilme yeteneğidir. MQTT, TCP protokolünün üzerine kurulmuştur. MQTT mesajları 3 farklı servis kalitesi seviyesine (QoS) göre iletilmektedir. Best Effort, At Least Once, Exactly Once MQTT in iki türü vardır: MQTT v3.1 MQTT-SN (MQTT for Sensor Network) 10
Messega Queue Telemetry Transport (MQTT) MQTT, abone (subscriber), yayımcı (Publisher) ve sunucudan (broker) oluşur. MQTT mimarisinde cihazlar, bir MQTT broker kullanarak mesaj yayımlayabilir ya da mesaj dinlemek için kayıt olabilir. Mesaj, konu (topic) ve bilgi/yük (payload) iki ana kısımdan oluşur. Publisher belirli bir konuda mesaj yayımlar, mesajı sadece abone olanlar alır. Mosquitto HiveMQ Mosca Örneğin bir sensör belirli aralıklarla ölçüm değerlerini yayımlar, bu sensöre abone olanlar bu mesajı alır. 11
Messega Queue Telemetry Transport (MQTT) MQTT minimum mesaj boyutu 2 bayttır. Message Type alanı, CONNECT, CONNACK, PUBLISH, SUBSCRIBE mesaj türünü gösterir. DUP, mesajın kopyalandığını (duplicate) gösteren bayraktır. QoS Level, yayımlanan mesajın hangi QoS seviyesinde iletileceğini gösterir. QoS 0, mesaj iletilmeyebilir, minimum trafik. QoS 1, gönderilen mesaj kendi veritabanında saklanır ve tekrar tekrar gönderilebilir. Mesaj kesin iletilir, birden fazla iletilebilir. QoS 2, QoS 1 ile benzer ancak mesaj iletimi gerçekleştiğinde bir cevap bilgisi alınır. Mesaj tek seferde ve kesin iletilir. Maksimum trafik. Retain, son alınan publish mesajı sunucuya bilgilendirir ve yeni aboneye ilk mesaj olarak iletilir. Remaining Length, mesajın kalan boyutunu gösterir. Header kısmı, protokol versiyonu vb. bilgileri içerir. Payload kısmı, topic, mesaj, kullanıcı, şifre gibi bilgileri içerir. 12
Messega Queue Telemetry Transport (MQTT) Sağlık (health care), energy metre, izleme (monitoring), Facebook bildirim gibi çok sayıda uygulama MQTT kullanır. MQTT, genel karakteristikleri Asenkron protokoldür, Bire bir, birden çoğa, çoktan çoğa bağlantı sağlar. Broker temelli haberleşme mekanizmasına sahiptir. Topic e dayalı adresleme vardır. Güvenlik olarak SSL/TLS destekler. En az kaynak kullanımını hedefler. Milisaniyeler seviyesinde bir haberleşme sunar. TCP/IP bağlantı türünü kullanır. Varsayılan port 1883 tür. TCP/IP protokolünün yazılabildiği Linux, Windows, Android, ios, MacOS işletim sistemlerinde çalışır. 13
Sınırlanmış Uygulama Protokolü (Constrained Application Protocol, CoAP) CoAP, HTTP fonksiyonlarının üstündeki REST (Representational State Transfer) e dayalı bir web transfer protokolüdür. REST, HTTP üzerinden istemci ve sunucular arasında veri değişimini basitleştirir. HTTP deki GET, PUT, POST, DELETE metotları kullanılır. Kısaca CoAP, HTTP benzeri UDP üzerinden kullanılan düşük ağırlıklı (lightweight) bir protokoldür. Milisaniyeler seviyesinde P2P haberleşme sunar. CoAP mimarisi 14
İleri Mesaj Kuyruklama Protokolü (Advanced Message Queuing Protocol, AMQP) AMQP, mesaj yönlendirme odaklanan IOT için açık standart uygulama protokolüdür. Kuyruk yapılarına sahip sunucular (broker) ile yayımcı (Publisher) ve abonelere (subscriber) hizmet sunan, büyük veri yapıları ile haberleşme sağlayan bir protokoldür. 3 farklı seviyedeki (at-most-once/best effort, at-least-once, exactly once delivery) mesaj ulaştırma garantisi ile güvenilir haberleşme sunar. AMQP de haberleşme exchanges ve mesaj kuyrukları ile sağlanır. Exchanges mesajları uygun kuyruğa yönlendirir. Bu yönlendirme önceden tanımlanmış kurallar ve koşullara göre gerçekleştirilir. AMQP, noktadan noktaya haberleşmenin yanısıra publish/subcribe haberleşme modelini de destekler. AMQP mimarisi 15
İleri Mesaj Kuyruklama Protokolü (Advanced Message Queuing Protocol, AMQP) AMQP, ulaşım katmanı olarak TCP kullanır. Bu katmanın üzerine mesajlaşma katmanını tanımlar. AMQP iki tür mesaj kullanır. Bare mesaj: Gönderici kaynaklı mesajlar. Annotated mesaj: Alıcıda görülen mesaj. AMQP haberleşme milisaniyeler süresinde gerçekleşir. Minimum paket boyutu 60 bayttır. MQTT gibi asenkron bir protokoldür. 16
Representational State Transfer (REST) Web tabanlı uygulamalarda yaygın olarak kullanılır. HTTP üzerinden POST, GET, DELETE metotları ile iletişimi gerçekleştirir. İstemci (client) / Sunucu (server) yapısında eşe-eş (P2P) haberleşme yapısına sahiptir. Ulaşım katmanı olarak TCP kullanır. Servis kalitesi desteği yoktur. Güvenlik https Mesaj formatında başlık ASCII yapısında, yük/data (payload) ise XML, JSON, HTML yapısındadır. Diğer protokollere göre daha fazla güç, kaynak ve veri kullanır. 17
Veri Dağıtım Servisi (Data Distribution Service, DDS) DDS, Object Management Group (OMG) tarafından gerçek zamanlı M2M haberleşmesi için geliştirilmiştir. DDS, daha az katman, daha az iş yükü gibi avantajlar sunar. DDS, publish-subcribe protokolüdür. Mikrosaniyeler seviyesinde haberleşme ile gerçek zamanlı iletişimi destekler. Publish-Subscribe yapısındaki MQTT, ve AMQP protokolünden farklıları daha çok QoS desteği sunar. Güvenli, acil/ivedi, öncelikli, güvenilir gibi haberleşme kriterlerini dikkate alarak 23 QoS seviyesi/politikası sağlar. Ulaşım katmanı olarak UDP ve TCP nin her ikisini de destekler. DDS iki katmanlı mimariye sahiptir. Data-Centric Publish-Subscribe (DCPS): Abonelere bilginin ulaştırılmasından sorumludur. Data-Local Reconstruction Layer (DLRL): Opsiyonel bir katmandır ve DCPS fonksiyonlarının yerine getirilmesini sağlar. Dağıtık nesneler arasında dağıtık verinin paylaşılmasını kolaylaştırır. Güvenlik olarak SSL/TLS ile Datagram TLS (DTLS) destekler. İçerik farkında yönlendirme özelliği vardır (Payload inceleme). 18
Veri Dağıtım Servisi (Data Distribution Service, DDS) Topics: Veri dağıtım konuları Data Writers: Veri üreticileridir. Publisher ile birlikte göndericiyi oluşturur. Data Readers: Veri tüketiciler/alıcılardır. Subscriber ile birlikte alıcıyı oluşturur. Topics, Data Readers/Writers QoS politikaları ile konfigüre edilir. Topic Topic Topic Domain Participant Data Reader Data Writer Data Writer Data Reader Data Reader Data Writer Subscriber Publisher Subscriber Publisher Data Domain 19
Veri Dağıtım Servisi (Data Distribution Service, DDS) Topics, Publisher ile subscriber arasındaki bağlantıdır. Topic, Name ve Type alanlarından oluşur. Name, alan (domain) içerisindeki tektir (unique). Birden fazla topic, aynı tipe sahip olabilir. Domain name Topic ID 35 MySensor İçerik farkında abonelikler için multitopics, ve content-filtered topics gibi yapılar sağlar. Type name AnalogSensor string sensor_id [ key ] float value 20
Veri Dağıtım Servisi (Data Distribution Service, DDS) DDS desteklenen servis kalitesi (QoS) politikalarının bir kısmı Latency_Budget: Uçtan uca kabul edilebilir gecikmeleri tanımlar. Time_Based_Filter: Yavaş tüketiciler ile hızlı üreticiler arasında değişime aracılık eder. Resource_Limits: Servis tarafından kullanılan kaynakları kontrol eder. Reliability: Verinin gerçek zamanlı ulaştırılmasını sağlar. History: Ulaştırılan verinin içeriğini (değerlerini) kontrol eder. DDS Kavramsal Model 21
IoT Uygulama Protokollerinin Karşılaştırılması Nesnelerin internetinde IEEE, ETSI gibi organizasyonların en sık tanımladığı protokoller, 22
KAYNAKLAR A. Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, M. Ayyash, Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications, IEEE Communication Survey&Tutorials, vol. 17 (4), 2347-2376,2015. L. Atzori, A. Iera, G. Morabito, The Internet of Things: A Survey, Computer Networks, vol. 54, 2787-2805, 2010. Halil Arslan, Doktora Tezi, SAÜ Fen Bilimleri Enstitüsü, 2016 www.mqtt.org https://www.oasis-open.org/committees/tc_cat.php?cat=iot 23