Bölüm 77: Sensör Ağlarında Yönlendirme ve IP

Komşunun seni ne kadar iyi duyduğuna bakarak. Bu bölümün ilk yarısı o bakışın nasıl bir yönlendirmeye dönüştüğünü, ikinci yarısı ise ağın internete hangi dille bağlandığını anlatıyor. İkinci sorunun cevabı kısa: internetin kendi diliyle, IPv6 ile.

42. bölümde OSPF gibi protokollerin her router’a bütün ağın haritasını dağıttığını görmüştün. On kilobayt RAM’li, zamanının %99’unu uykuda geçiren bir düğüm bütün haritayı tutamaz ve harita güncellemelerini dinlemek için uyanık da kalamaz. Sensör ağında yönlendirmenin başka ilkelere dayanması gerekiyor.

Önce kablolu ağda hiç düşünmediğin bir soru: iki komşu arasındaki bağlantı var mı, yok mu?

Bağlantı var ya da yok değil

Kabloda bir bağlantı ya çalışır ya çalışmaz. Kablosuz ağda ise iki düğüm arasındaki bağlantı bir olasılık. Paketlerin %95’ini taşıyan iyi bir bağlantı olabilir, %40’ını taşıyan kötü bir bağlantı da. Sekme sayısını en aza indiren bir yönlendirme, en uzaktaki ve en zayıf komşulara atlayarak bu yüzden kötü sonuç veriyor. İki sekme kısa görünür ama her paket defalarca yeniden gönderiliyorsa enerji ve zaman olarak üç iyi sekmeden pahalıya gelir.

2003’te önerilen ETX (expected transmission count) bu gözleme bir sayı verdi: bir paketin bir bağlantıdan başarıyla geçmesi için beklenen gönderim sayısı. İleri yöndeki teslim oranı d_i, geri yöndeki (onayların döndüğü yön) teslim oranı d_g ise:

ETX = 1 / (d_i × d_g)

Her iki yönde de kusursuz bir bağlantının ETX’i 1. İleri yönde paketlerin yarısını düşüren bir bağlantınınki 2. Bir yolun maliyeti, üstündeki bağlantıların ETX’lerinin toplamı. Sensör ağlarında sonradan gelen hemen her yönlendirme protokolü bu ölçüyü ya da bir türevini kullanıyor.

Veri merkezli ilk denemeler

En basit yöntem taşkın: her düğüm duyduğu her paketi bir kez daha yayar. Çalışır ama bedeli ağırdır. 1999’da SPIN’i tanıtan makale taşkının üç kusurunu adlandırdı: aynı paketin kopyalarının bir düğüme defalarca gelmesi, komşu düğümlerin aynı bölgeyi ölçtüğü için aynı veriyi göndermesi ve düğümlerin kendi enerjilerinden habersiz davranması. SPIN’in cevabı önce veriyi değil tanımını göndermek oldu. Düğüm “şu bölgenin şu saatteki sıcaklığı bende var” diye kısa bir duyuru yapıyor, isteyen komşu talep ediyor, veri yalnızca ona gidiyor.

2000’de yayımlanan yönlendirilmiş yayılım (directed diffusion) veri merkezli fikri en açık biçimde uyguladı. Sink ağa bir ilgi yayıyor: “şu bölgede hayvan hareketi görürsen saniyede bir bildir.” İlgi yayılırken her düğüm onu kimden duyduğunu not ediyor ve verinin geri akacağı yönleri, yani eğimleri, kuruyor. Veri bu eğimler boyunca sink’e doğru akıyor. Sink en iyi çalışan yolu “pekiştiriyor”, yani o yoldan daha sık veri istiyor; ötekiler kendiliğinden sönüyor. Hiçbir yerde düğüm adresi geçmiyor; yalnızca verinin özellikleri.

Kümeler ve dönen küme başı: LEACH

2000’de önerilen LEACH, 75. bölümdeki kümeli yapının en bilinen örneği. Zaman turlara bölünüyor. Her turun başında her düğüm, küme başı olup olmayacağına kendisi karar veriyor: 0 ile 1 arasında rastgele bir sayı çekiyor ve sayı bir eşiğin altındaysa o tur küme başı oluyor. Eşik, istenen küme başı oranı p ve tur numarası r ile:

T(n) = p / (1 − p × (r mod 1/p))     son 1/p turda küme başı olmamış düğümler için
T(n) = 0                              ötekiler için

Formülün zekâsı, eşiğin tur ilerledikçe büyümesinde. p = 0,05 ile her 20 tur bir dönem:

Dönemin sonunda eşik 1’e ulaşıyor. O döneme kadar hiç küme başı olmamış her düğüm son turda kesin olarak seçiliyor. Böylece küme başının pahalı işi düğümler arasında sırayla dönüyor ve hiçbir düğüm ötekilerden önce tükenmiyor.

Küme başı olan düğüm bunu duyuruyor; ötekiler sinyalini en güçlü duydukları küme başına katılıyor. Küme başı üyelerine birer zaman dilimi dağıtıyor. Her üye yalnızca kendi diliminde uyanıp ölçümünü veriyor. Küme başı ölçümleri birleştirip tek pakette doğrudan sink’e gönderiyor. Bu son adım LEACH’in sınırı: tek sekmede sink’e ulaşmak geniş bir alanda mümkün olmuyor ve sonraki türevler küme başları arasına çok sekme ekledi.

Konuma göre yönlendirme

Düğümler kendi konumlarını ve hedefin konumunu biliyorsa, bir yönlendirme tablosuna hiç gerek kalmayabilir. 2000’de yayımlanan GPSR’nin kuralı basit: paketi, hedefe coğrafi olarak en yakın komşuya ver. Buna açgözlü iletim deniyor ve tek bilinmesi gereken şey komşuların konumu.

Kuralın takıldığı yer, hedefe kendisinden daha yakın hiçbir komşusu olmayan bir düğüm. Örneğin arada bir göl ya da bir bina varsa. GPSR o noktada çevre kipine geçiyor: paket, engelin kenarı boyunca sağ el kuralıyla dolaştırılıyor. Labirentte eli duvardan ayırmadan yürümek gibi. Hedefe daha yakın bir düğüme varılınca açgözlü iletime dönülüyor. Kuralın doğru çalışması için bağlantı grafiğinin kesişen kenarları olmayan bir alt grafiğe indirgenmesi gerekiyor; yoksa sağ el kuralı döngüye girebilir. Düğümlerin konumlarını nereden bildiğini 78. bölümde göreceksin.

Toplama ağacı: CTP

Pratikte sensör ağlarının trafiği çok sade bir desene uyuyor: bütün düğümler sink’e doğru veri gönderiyor. Bu desene toplama deniyor ve en olgun cevabı bir ağaç. 2009’da yayımlanan CTP (Collection Tree Protocol) her düğüme sink’e giden yolun toplam ETX’ini en küçük yapan komşuyu ebeveyn seçtiriyor.

CTP’nin iki fikri sonradan yaygınlaştı. Birincisi, yönlendirme işaretlerinin sıklığını duruma göre ayarlamak: ağ sakinken işaretler seyrekleşiyor, bir tutarsızlık görülünce hemen sıklaşıyor. Aşağıdaki RPL’de aynı fikrin standartlaşmış hâlini göreceksin. İkincisi, veri paketlerini de yolun sağlamlığını denetlemek için kullanmak. Her veri paketi göndereninin sink’e olan maliyetini taşıyor. Bir düğüm, kendi maliyetinden düşük maliyet taşıyan bir paketi “çocuğundan” alırsa bir döngü oluştuğunu anlıyor ve onarımı başlatıyor.

Sonuçlar ikna ediciydi. 20 ile 310 düğüm arasında değişen, yedi farklı donanım ve altı farklı bağlantı katmanı içeren on iki deney ağının hepsinde CTP paketlerin %90’ından fazlasını teslim etti; birçok deneyde oran %99,9’du. Yönlendirme işaretleri eski yönteme göre %73 azaldı.

IP küçük cihaza iniyor: 6LoWPAN

Uzun süre sensör ağları kendi adresleme ve ağ katmanlarıyla kuruldu ve internete bir geçitte çevrilerek bağlandı. 2000’lerin ortasında IETF’te başka bir fikir güç kazandı: IP’yi düğümün kendisine kadar indirmek. Böylece bir sensöre, 71. bölümde yazdığın türden bir soketle uçtan uca konuşulabilecekti.

Önünde iki engel vardı. 38. bölümdeki IPv6, her bağlantının en az 1.280 baytlık paketleri taşıyabilmesini şart koşuyor. 75. bölümdeki 802.15.4 frame’i ise en fazla 127 bayt. Üstelik IPv6 başlığı 40, UDP başlığı 8 bayt; sıkıştırılmadan gönderilse küçük frame’in üçte biri daha veri taşımadan gidiyor.

2007’de yayımlanan 6LoWPAN (RFC 4944), 802.15.4 ile IPv6 arasına ince bir uyum katmanı koydu. 1.280 baytlık bir datagramı küçük frame’lere bölüp karşıda yeniden birleştiren bir parçalama başlığı getirdi. 2011’deki RFC 6282 ise asıl kazancı sağladı: başlıkları, iki tarafın zaten bildiği bilgiye dayanarak sıkıştırmak.

En iyi durumda 40 baytlık IPv6 başlığı 2 bayta iniyor. Adreslerin gönderilmemesi 23. bölümde gördüğün bir gerçeğe dayanıyor: arayüz kimliği MAC adresinden türetilmişse, alıcı onu zaten frame’in başlığında görüyor. UDP portları da sıkışabiliyor; 61616 ile 61631 arasındaki portlar dörder bitle yazılıyor.

RPL: kayıplı ağlar için yönlendirme

IP’li bir sensör ağının yönlendirme protokolü 2012’de yayımlanan RPL (RFC 6550). Adını yazan çalışma grubunun adı her şeyi anlatıyor: düşük güçlü ve kayıplı ağlar üzerinde yönlendirme.

RPL ağı, internete bağlanan sınır router’ında köklenen bir yapı olarak kuruyor. Bu yapı bir ağaçtan biraz fazlası: yönlü, döngüsüz ve kökü hedef alan bir çizge. Kısaltmasıyla DODAG. Her düğümün bir ebeveyn kümesi var ve bunlardan biri tercih edilen ebeveyn. Kuruluşu adım adım izlemek, kuralları tek tek okumaktan kolay:

Kurulumun ortasında rank duruyor: bir düğümün köke uzaklığını anlatan bir sayı. Kökün rank’ı 256 ve köke uzaklaştıkça büyüyor. Rank’ın nasıl hesaplanacağını ağın seçtiği amaç fonksiyonu belirliyor. En basiti sekme sayısına bakıyor, yaygın olanı yukarıdaki ETX’e. Kuralın can alıcı kısmı şu: bir düğüm, rank’ı kendisininkinden küçük olmayan bir komşuyu ebeveyn seçemez. 42. bölümdeki uzaklık vektörü protokollerinin sayarak sonsuza gitme sorunu, iki düğümün birbirini yol olarak göstermesinden çıkıyordu. Rank kuralı bu döngüyü baştan yasaklıyor.

Kökten yayılan duyuru mesajının adı DIO. Asıl ustalık bu mesajların ne sıklıkla gönderildiğinde. RPL, 2011’de ayrıca standartlaşan Trickle zamanlayıcısını kullanıyor. Her düğümün bir aralığı var; aralık en kısa değerinden başlıyor, varsayılanda 8 milisaniye. Her aralıkta düğüm rastgele bir anda DIO göndermeye hazırlanıyor. Ama o aralıkta komşularından kendisininkiyle tutarlı yeterince DIO duymuşsa, varsayılanda 10 tane, göndermekten vazgeçiyor. Her aralığın sonunda aralık ikiye katlanıyor. Varsayılan ayarla 20 katlamadan sonra yaklaşık 2,3 saate ulaşıyor.

Sonuç iki uçlu bir davranış. Ağ sakinken DIO’lar saatte bir bile gönderilmiyor ve neredeyse hiç enerji harcanmıyor. Bir tutarsızlık görüldüğünde, örneğin bir düğüm ebeveynini kaybettiğinde, aralık hemen en kısa değerine dönüyor ve ağ birkaç saniye boyunca yoğun biçimde konuşup kendini onarıyor. Sessizlik ucuz, onarım hızlı.

DIO’lar yalnızca köke doğru giden yolu kuruyor. Kökten bir düğüme inmek, örneğin bir vanaya komut göndermek için ters yönde bilgi gerekiyor. Düğümler kendilerini DAO mesajıyla yukarıya bildiriyor. RPL burada iki kip sunuyor:

• Depolayan kip. Her düğüm kendi alt ağacındaki hedefleri tabloda tutuyor. İki düğüm arasındaki trafik ortak ataya kadar çıkıp oradan iniyor.
• Depolamayan kip. Ara düğümler hiçbir şey tutmuyor; bütün bilgi kökte. Kök, aşağı giden paketin başlığına izlenecek yolun tamamını yazıyor. Belleği birkaç kilobayt olan düğümler için daha uygun, bedeli her paketin kökten geçmesi.

Uygulama katmanı: CoAP ve MQTT

IP düğüme kadar indiyse, web de inebilir mi? HTTP bu küçük cihazlar için ağır: metin başlıkları uzun, altında bağlantı kuran ve durumu tutan bir TCP var. 2014’te yayımlanan CoAP (RFC 7252), HTTP’nin mimarisini koruyup yükünü attı. Aynı yöntemler var: GET, PUT, POST, DELETE. Aynı mantıkta yanıt kodları var: 2.05 “içerik”, 4.04 “bulunamadı”. Ama her şey ikili ve sıkıştırılmış, taşıma da UDP.

RFC’nin kendi örneği, bir sıcaklık sensörüne yapılan istek ve cevabı:

İstek (16 bayt):  40 01 7d 34 bb 74 65 6d 70 65 72 61 74 75 72 65
                  │  │  └─┬─┘ │  └─────── "temperature" ────────┘
                  │  │    │   └ seçenek: Uri-Path, 11 bayt
                  │  │    └ ileti kimliği 0x7d34
                  │  └ kod 0.01 = GET
                  └ sürüm 1, onaylı (CON), token yok

Cevap (11 bayt):  60 45 7d 34 ff 32 32 2e 33 20 43
                  │  │  └─┬─┘ │  └── "22.3 C" ───┘
                  │  │    │   └ yükün başladığını gösteren 0xFF
                  │  │    └ aynı ileti kimliği
                  │  └ kod 2.05 = içerik
                  └ sürüm 1, onay (ACK)

Başlığın sabit kısmı 4 bayt. Cevap, isteğin onayının içinde geldiği için ayrı bir gidiş-dönüş harcanmıyor. UDP’nin güvenilirlik vermediği yerde CoAP kendi basit mekanizmasını kuruyor: onaylı bir ileti, onayı gelmezse 2 ile 3 saniye arasında rastgele bir sürenin sonunda yeniden gönderiliyor, bekleme her denemede ikiye katlanıyor ve en fazla dört kez tekrarlanıyor. 71. bölümde UDP soketi için kendi yazdığın yeniden deneme döngüsünün standartlaşmış hâli. Bir de gözlem seçeneği var: istemci bir kaynağa bir kez abone oluyor ve sensör, değer değiştikçe cevabı kendisi gönderiyor. Varsayılan port 5683.

İkinci yaygın dil MQTT, başka bir soruya cevap veriyor. 1999’da IBM’de, uydu bağlantısı üzerinden petrol boru hattı sensörlerini izlemek için tasarlandı; 2014’te OASIS standardı oldu. İstek-yanıt değil yayın-abone modeli kullanıyor. Aradaki bir broker’a sensörler tarla/3/nem gibi başlıklarla veri yayımlıyor, ilgilenenler başlığa abone oluyor. Gönderen, verisini kimin okuduğunu bilmiyor. TCP üstünde çalışıyor ve teslim için üç seviye sunuyor: en fazla bir kez, en az bir kez, tam olarak bir kez. Bağlantısı beklenmedik biçimde kopan bir cihaz için önceden bırakılmış bir “vasiyet” mesajı da yayımlanabiliyor.

Özet

• Kablosuz bağlantı bir olasılıktır: ETX, bir paketin geçmesi için beklenen gönderim sayısıdır. Yolun maliyeti sekme sayısı değil, ETX’lerin toplamıdır.
• Veri merkezli yönlendirme adres değil ilgi taşır: SPIN önce tanımı, yönlendirilmiş yayılım ilgiyi yayar ve en iyi yolu pekiştirir.
• LEACH küme başını döndürür: tur ilerledikçe büyüyen eşik, her düğümün dönem içinde bir kez küme başı olmasını sağlar.
• 6LoWPAN IPv6’yı 127 baytlık frame’e sığdırır: parçalar ve sıkıştırır. En iyi durumda 40 baytlık başlık 2 bayta iner.
• RPL köke yönelik bir DODAG kurar: rank kuralı döngüyü yasaklar, Trickle sessizliği ucuz ve onarımı hızlı yapar, DAO aşağı yönde yolu açar.
• CoAP küçük cihazın HTTP’si, MQTT yayın-abone postanesi: ilki 4 baytlık başlıkla UDP üstünde, ikincisi bir broker üzerinden TCP’de.

Ölçüm köke vardı. Ama “22.3 C” tek başına neyi söylüyor? Bu sıcaklığın ne zaman ölçüldüğünü bilmiyorsan bir olayın hangi sırayla geliştiğini göremezsin. Nerede ölçüldüğünü bilmiyorsan yangının hangi köşede başladığını söyleyemezsin. Saatleri birbirinden kayan ve GPS’i olmayan düğümler, zamanı ve konumu nereden biliyor?