Semtech’in 6 km örneğinden güvenilir FUOTA’ya: Mandalina bahçesinde menzil, airtime ve Delta OTA

Bu yazıdaki menzil ve FUOTA süreleri laboratuvar veya saha ölçümünün yerine geçmez. Varsayımlar, gerçek cihaz modeli, anten, bölgesel frekans planı ve kanal koşulları kesinleştirilerek yeniden hesaplanmalıdır.

Özet

İlk bakışta problem basit görünür: LoRa tabanlı bir sensör düğümü mandalina bahçesinden gateway’e veri gönderebiliyor mu? Fakat ürün sahaya çıktığında ikinci ve daha zor bir soru ortaya çıkar: Aynı bağlantı üzerinden yüzlerce kilobaytlık firmware güvenilir biçimde nasıl dağıtılacaktır?

Bu çalışma, Semtech’in teknik özetindeki SF9/125 kHz için yaklaşık 6 km’lik örnek değeri başlangıç noktası alır. Bu değerin yoğun bir mandalina bahçesine neden doğrudan taşınamayacağını açıkladıktan sonra spreading factor (SF) ve bandwidth (BW) arasındaki menzil–veri hızı değiş tokuşunu ele alır. Daha sonra link budget’ın iki cihazın çıkış güçlerini toplamak anlamına gelmediğini açıklar; aktif verici, karşı tarafın alıcı hassasiyeti, anten kazançları ve ortam kayıpları birlikte değerlendirilir. Ardından farklı ürün ortamları arasından mandalina bahçesi seçilir ve anten yüksekliğinin etkisi tartışılır. Son bölümde tam imaj yerine Delta OTA, çok adımlı güncelleme ve sunucu taraflı delta rota seçimi önerilir.

Ana sonuç şudur: FUOTA başarısı yalnızca en uzun menzili bulmaya bağlı değildir. Güvenilir downlink kapasitesi, toplam airtime, duty-cycle, paket kaybı, gateway yerleşimi, bootloader doğrulaması ve güncelleme orkestrasyonu birlikte tasarlanmalıdır.

1. Semtech’in yaklaşık 6 km örneği neden mandalina bahçesinde gerçek bir menzil değildir?

Semtech’in LoRa teknik özetindeki örnek tabloda SF9/125 kHz için yaklaşık 6 km değer verilir. Aynı doküman bu menzil rakamlarının araziye bağlı tahminler olduğunu belirtir (Semtech, LoRa and LoRaWAN: A Technical Overview). Buradaki 6 km, belirli bir modülasyon ayarı ve idealize edilmiş açık alan koşulu için bir referans noktasıdır; mandalina bahçesinde güvenilir iki yönlü menzil garantisi değildir.

Bu farkın başlıca nedenleri şunlardır:

1. Açık arazideki görüş hattı ile ağaç sıraları içindeki NLOS yayılım aynı değildir.
2. Sensör anteninin yere yakın olması, gateway anteninin yüksekte olduğu katalog testinden farklıdır.
3. Üretici menzili belirli SF/BW, paket boyu, anten ve güç koşullarına bağlıdır.
4. Kullanılabilir menzil, iki yönlü bağlantının daha zayıf yönünü ve hedeflenen paket başarı oranını içermelidir.
5. Nem, yağmur, sulama, yaprak yoğunluğu ve sıra yönü mevsim boyunca değişir.

Mandalina ve diğer meyve bahçelerinde yaprak, dal, gövde, sıra geometrisi ve anten yüksekliğinin yol kaybını etkilediği saha çalışmalarıyla incelenmiştir (Vougioukas ve ark., Influence of foliage on radio path losses for WSN planning in orchards; citrus orchard RF deployment study). Bu yüzden Semtech tablosundaki 6 km, saha ölçümünün başlangıç hipotezi olabilir; sonuç değeri olamaz.

Bu makalenin ana sorusu böylece değişir:

Semtech’in 6 km’lik açık alan referansı, yoğun mandalina bahçesinde hangi link margin, paket başarı oranı ve FUOTA airtime’ına dönüşür?

2. SF ve BW menzili nasıl değiştirir?

LoRa fiziksel katmanında spreading factor, verinin chirp sembollerine ne kadar yayıldığını belirleyen parametredir. Semtech’in teknik özetinde SF7–SF12 aralığı için SF yükseldikçe alıcı hassasiyetinin iyileştiği, buna karşılık bit rate ve veri aktarım hızının düştüğü açıklanır (Semtech, LoRa and LoRaWAN: A Technical Overview).

Bu ilişkiyi pratik bir tabloyla özetleyebiliriz:

Mandalina bahçesi için sayısal SF/BW–menzil tablosu

Aşağıdaki tablo, yaklaşık 2,5–4 m yüksekliğinde, yıl boyunca yapraklı, yoğun ve sulanan narenciye bahçesi için bir mühendislik planlama tahminidir. Hücreler menzil (m) / brüt PHY bit rate (kbit/s) biçimindedir; güvenilir tasarımda aralığın alt sınırı esas alınmalıdır. Hesap senaryosu: E22-900M22S/SX1262, 868 MHz, CR 4/5, 0 dBi anten kazancı, 2 dB kablo/konnektör kaybı, 10 dB ek fading/güvenlik payı ve antenin toprağa gömülmemesi (E22-900M22S üretici bilgisi).

PHY bit rate, R_b = SF × (BW / 2^SF) × 4/5 bağıntısından gelir; gerçek uygulama throughput’u değildir. LoRaWAN başlıkları, duty-cycle, bekleme, tekrarlar, fragment metadata’sı ve paket kayıpları kullanılabilir hızı ayrıca düşürür. Menzil sütunları bu RF varsayımlarına dayalı planlama tahminidir; birebir saha ölçümü veya mandalina bahçesi için garanti değildir. SF5–SF6 ile BW250/BW500 sütunları ham LoRa karşılaştırmasıdır; standart EU868 LoRaWAN veri hızlarının dışındaki kombinasyonlar bölgesel parametrelerle ayrıca kontrol edilmelidir.

LoRaWAN bölgesel parametreleri kanal planını, izin verilen data rate’leri, güç sınırlarını ve bölgesel kısıtları tanımlar. Bu nedenle bir SF/BW tablosu, kullanılacak ülkenin ve bandın bölgesel parametreleri ile doğrulanmalıdır (LoRa Alliance RP002 Regional Parameters; güncel yayın listesi için LoRa Alliance Technical Committee Publications).

ADR neden önemlidir?

LoRaWAN Adaptive Data Rate (ADR), ağ sunucusunun bağlantı kalitesine göre cihazın data rate ve çıkış gücünü ayarlamasına imkân verir. Semtech’in ADR açıklamasına göre amaç, bağlantı için gereken link margin’i korurken daha yüksek data rate kullanarak airtime’ı ve ağ kapasitesi tüketimini azaltmaktır (Semtech, Understanding LoRa Adaptive Data Rate).

FUOTA açısından bunun anlamı nettir: Bir cihaz SF12’ye ancak gerçekten ihtiyaç duyuyorsa çıkmalıdır. Bağlantı SF9 veya SF8 ile güvenilir çalışıyorsa daha düşük SF, güncelleme süresini azaltabilir.

3. Link budget: İki cihazın gücü toplanmaz

Konuşmanın kritik düzeltmelerinden biri, Dragino ile E22 çıkış güçlerinin aynı bağlantı hesabında toplanamayacağıdır. Bir RF linkinde her yön ayrı hesaplanır:

Alınan güç =
aktif vericinin çıkış gücü
+ verici anten kazancı
+ alıcı anten kazancı
− kablo/konnektör kayıpları
− yayılım kaybı
− bitki örtüsü, gövde, zemin ve diğer çevresel kayıplar

E22 → Dragino yönünde E22’nin çıkış gücü ve Dragino’nun alıcı hassasiyeti; Dragino → E22 yönünde ise Dragino’nun çıkış gücü ve E22’nin alıcı hassasiyeti kullanılır. Kullanılabilir iki yönlü menzil, bu iki yönün daha zayıf olanı tarafından belirlenir. Alıcı hassasiyeti SF, BW, coding rate ve ölçüm koşullarıyla değiştiği için tek bir “cihaz menzili” değeri vermek teknik olarak eksiktir. LoRa modülasyon parametreleri ile hassasiyet/bit rate arasındaki ilişki için Semtech’in LoRa teknik özetine bakılmalıdır.

Bu makalenin saha hesaplarında Dragino ve E22’nin kesin model numarası, anten tipi, gerçek antene-giden çıkış gücü ve bölgesel izinler sabitlenmeden nominal bir dBm değeri varsayılmamalıdır. Üretici veri sayfaları, saha ölçümünün yerini tutmaz.

4. Neden bitki türünü ayrı bir RF problemi olarak ele aldık?

Aynı radyo ayarı her tarımsal ortamda aynı sonucu vermez. Yaprak, dal, gövde, toprak nemi, sıra geometrisi ve yağış; sinyalin saçılmasını, soğurulmasını ve çok yollu sönümünü etkileyebilir. Meyve bahçelerinde görüş hattının çoğu zaman bulunmadığını ve bitki örtüsünün yol kaybını etkilediğini inceleyen çalışmalar vardır (Vougioukas ve ark., Influence of foliage on radio path losses for WSN planning in orchards).

Bu nedenle önce aşağıdaki ürünleri birer aday senaryo olarak düşündük:

• mısır,
• şeker pancarı,
• domates,
• patates,
• karpuz,
• biber,
• kuru soğan,
• üzüm,
• elma,
• mandalina.

Bu liste küresel üretim sıralaması değildir; sensör ihtiyacı, sulama/EC hassasiyeti, ekonomik değer ve RF ortamının zorluğunu birlikte incelemek için oluşturulmuş mühendislik aday setidir. Her ürün için önce SF/BW kombinasyonlarıyla bir menzil–bit rate tablosu, daha sonra aynı kombinasyonlarla bir FUOTA airtime tablosu oluşturulmuştur. Bu tablolar saha garantisi değil, test planını yönlendiren ilk tahminlerdir.

5. Neden mandalina bahçesi?

Mandalina bahçesi, bu adaylar içinde iyi bir stres testi oluşturur:

• ağaçlar çok yıllık ve yoğun yapraklıdır,
• yapraklar ve dallar yılın önemli bölümünde RF yoluna girebilir,
• düğümler çoğu zaman yere veya gövdeye yakın kurulur,
• gateway ile düğüm arasında birden fazla ağaç sırası bulunabilir,
• sıra boyunca ve sıralar arasındaki yayılım aynı değildir.

Narenciye bahçelerinde düğüm yerleşimi, anten yüksekliği, bitki derinliği ve mesafeyi birlikte inceleyen RF çalışmalarının bulunması, anten yerleşiminin yalnızca “metre cinsinden uzaklık” ile açıklanamayacağını gösterir (citrus orchard RF deployment study). Turunçgil arazilerindeki sensör yerleşimi deneylerinde farklı anten yükseklikleri ve ağaç örtüsü nedeniyle alınan sinyal seviyesinin değiştiği raporlanmıştır (Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling).

Buradaki kritik soru artık “LoRa kaç kilometre gider?” değil, şudur:

Mandalina bahçesindeki her sensör, gateway’e yeterli link margin ile bağlanabiliyor mu ve aynı downlink bağlantısı uzun bir firmware aktarımını tamamlayabiliyor mu?

6. Anten yüksekliği: 1 metre, 5 metre ve 50 santimetre

Gateway’i 1 metreye koymak

Yaklaşık 1 metrelik bir direk, anteni alt gövde ve yaprak katmanının içinde bırakabilir. Bu durumda ağaç sıraları, dal ve yapraklar doğrudan yayılım yoluna girer. Antenlerin birbirini görmesi, gerçek bir Fresnel bölgesinin açık olduğu anlamına gelmez; zemin yansıması ve ağaç sıraları hâlâ baskın olabilir.

Gateway’i 5 metreye koymak

Yaklaşık 5 metre yükseklik, gateway antenini birçok mandalina ağacının tepesine yaklaştırabilir veya çıkarabilir. Bu, sinyalin bahçenin tamamında otomatik olarak görüş hattına kavuştuğu anlamına gelmez; fakat gateway tarafındaki engellenmeyi, yerden kaynaklanan kaybı ve ağaç tepelerinin yatay yol üzerindeki etkisini azaltabilir. Orchard ölçümleri, yaprakların yol üzerindeki etkisinin antenlerin yere veya ağaç tepesine göre konumuna bağlı olabildiğini göstermektedir (orchard foliage path-loss study).

Bu nedenle 5 metrelik direk, tek başına bir “menzil katsayısı” değildir. Direğin faydası şu değişkenlerle birlikte ölçülmelidir:

• gateway’in bahçenin kenarında, merkezinde veya sıra sonunda olması,
• gateway anteninin ağaç sıralarına paralel ya da dik bakması,
• anten kazancı ve düşey radyasyon paterni,
• koaksiyel kablo ve konnektör kaybı,
• arazi eğimi ve zemin yansımaları.

Her iki anteni 50 santimetreye koymak

50 cm yerleşimin cazibesi, anteni üst yaprak örtüsünden uzaklaştırıp gövdeler arasındaki koridoru kullanabilmesidir. Ancak “yaprağa çarpmıyor” varsayımı “açık görüş hattı” demek değildir. Bu yükseklikte:

• gövde ve alt dallar doğrudan engel olabilir,
• zemin yansıması ve nemli toprak kaybı artabilir,
• sıralara dik bağlantı, sıra boyunca bağlantıdan belirgin biçimde kötü olabilir.

Dolayısıyla 50 cm senaryosu, 1 m ve 5 m senaryolarıyla aynı rota üzerinde ölçülmesi gereken deneysel bir alternatiftir; yalnızca teorik bir menzil artışı olarak kabul edilmemelidir. En iyi yerleşim çoğu bahçede sensör antenini sıra koridorunu görecek şekilde konumlandırmak, gateway antenini ise ağaç tepelerine göre yükseltmek ve gerekirse ikinci gateway kullanmaktır. Bu öneri, orchard RF çalışmalarındaki yükseklik ve yön bağımlılığından çıkarılan bir tasarım hipotezidir; sahada doğrulanmalıdır.

7. Telemetri bağlantısı ile FUOTA bağlantısı aynı şey değildir

Bir sensörün birkaç baytlık ölçüm paketini düzenli olarak gönderebilmesi, 1 MB firmware’i aynı ağ üzerinden indirebileceği anlamına gelmez. Telemetri genellikle seyrek uplink’tir; FUOTA ise uzun süreli, çoğunlukla downlink ağırlıklı ve kayıp parçaların tekrarını gerektiren bir işlemdir.

LoRaWAN Class A cihazlar uplink sonrasında iki kısa receive window açar. Class C cihazlar ise gönderim yapmadıkları sürece alıcıyı daha uzun süre açık tutar; bu nedenle büyük downlink aktarımı için geçici Class C kullanımı anlamlıdır (LoRaWAN Specification).

FUOTA, tek bir “firmware paketi gönder” komutundan oluşmaz. LoRa Alliance’ın yapı taşları farklı sorumlulukları ayırır:

• TS004 Fragmented Data Block Transport: Büyük verinin parçalanması ve fragmentation oturumunun yönetimi (TS004-2.0.0).
• TS005 Remote Multicast Setup: Cihazlara geçici multicast ve Class B/Class C dağıtım penceresi programlanması (TS005-2.0.0).
• TS006 Firmware Management Protocol: Firmware ve donanım versiyonu yönetimi, yeniden başlatma ve güncelleme imajı yönetimi (TS006-1.0.0).
• TS007 Multi Package Access: Cihazdaki paketlerin ve kullanılan FPort’ların bildirilmesi; birden fazla komutun daha az downlink ile taşınabilmesi (TS007-1.0.0).

Bu standartların birlikte uygulanması, RF menzilinden bağımsız olarak ayrıca geliştirme ve HIL doğrulaması gerektirir.

8. 1 MB tam firmware’in maliyeti

1 MB’lık tam firmware için kaba bir alt sınır hesabı şöyle yapılabilir:

aktarılacak bit sayısı / teorik bit rate

Örneğin 1 MB ve 5.47 kbit/s değerinde yalnızca PHY aktarım süresi yaklaşık 25,5 dakikadır. %10 kanal kullanımını bir senaryo varsayımı olarak uygularsak teorik alt sınır yaklaşık 4,25 saate çıkar. Bu hesabın içine LoRaWAN başlıkları, TS004 fragment metadata’sı, parite/redundancy, paket kaybı, tekrarlar ve Class C oturum kurulumu dahil değildir. Bölgesel mevzuat ve kanal kullanım sınırı bandın ülkesine göre kontrol edilmelidir (RP002 Regional Parameters).

Bu yüzden FUOTA ayarını yalnızca “en uzun menzil” üzerinden seçmek yanlış hedef olabilir. En iyi ayar, güvenilir link margin ile birlikte toplam airtime’ı en aza indiren ayardır.

9. Delta OTA: Firmware’in tamamını değil farkını taşımak

Delta OTA’da sunucu, cihazın bildirdiği base imaj ile hedef imaj arasındaki farkı gönderir. Cihaz patch’i uygulayarak hedef firmware’i yeniden oluşturur:

cihazdaki base firmware
        +
delta patch
        ↓
hedef firmware
        ↓
SHA-256 ve imza doğrulaması
        ↓
MCUboot test boot ve sağlık onayı

Delta yaklaşımının genel olarak gömülü sistemlerde uygulanabilir olduğuna dair açık kaynak bir örnek, sıralı patch’lerin akışlı (streaming) uygulanabildiğini ve C ile incremental apply desteğinin bellek kısıtlı cihazları hedeflediğini belgeleyen detools projesidir (detools README). Agronode projesinde ise delta oluşturma ve uygulama akışı, base SHA, target SHA, imaj boyutu ve MCUboot yerleşimiyle birlikte proje içinde tanımlanmıştır (Agronode Delta OTA dokümanı, delta uygulama kodu).

Proje dokümanındaki mevcut ölçümlerde yaklaşık 944 KB’lık tam imaja karşılık ardışık release delta’ları yaklaşık 15–53 KB aralığında raporlanmıştır (proje delta OTA dokümanı). Bu ölçüm release içeriğine özgüdür; her sürüm çiftinde aynı oran beklenmemelidir.

Kabaca aynı 5.47 kbit/s PHY değeriyle:

Bu tablo gerçek FUOTA süresi değil, büyüklük karşılaştırmasıdır. Fragmentation, parite, tekrar ve oturum yönetimi eklendiğinde süre artar.

10. Çok eski cihazlar küçük delta adımlarıyla güncellenebilir mi?

Evet, uygun bir delta zinciri varsa cihaz şu şekilde ilerleyebilir:

1.0.0 → 1.1.0 → 1.2.0 → 1.3.0 → ... → 1.8.0

Fakat her ok, ayrı bir FUOTA oturumu ve ayrı bir güvenlik kontrolüdür. Sunucu bir sonraki patch’i ancak cihaz:

1. fragment oturumunu tamamladıktan,
2. base SHA’yı doğruladıktan,
3. hedef imajı oluşturup hedef SHA’yı doğruladıktan,
4. MCUboot test boot’u başarıyla geçtikten,
5. yeni firmware’i sağlık kontrolüyle onayladıktan,
6. yeni sürüm ve imaj kimliğini raporladıktan sonra

başlatmalıdır.

MCUboot’un test–confirm–revert akışı, başarısız bir yeni imajın sonraki boot’ta eski çalışan imaja dönmesine imkân verir; bu, uzaktan güncellemede brick riskini azaltan temel bir bootloader desenidir (MCUboot design documentation, MCUboot image signing and tooling).

Çok adımlı zincirin dezavantajı, her adımda oturum kurulumu, airtime, enerji tüketimi, yeniden başlatma ve hata ihtimalinin tekrarlanmasıdır. Her hop’un bağımsız başarı olasılığı %98 ise on hop’un retriesiz birlikte tamamlanma olasılığı yaklaşık 0,98^10 = %81,7 olur. Bu, gerçek saha başarısı değildir; yalnızca hop sayısının risk üzerinde nasıl çarpan etkisi yarattığını gösteren bir modeldir.

11. En doğru model: Delta dosyası listesi değil, delta grafiği

Yalnızca komşu sürümleri saklamak basit bir modeldir:

1.0 → 1.1 → 1.2 → 1.3 → 1.4

Üretim ortamında daha iyi yaklaşım, tam imajları ve birden fazla delta türünü birlikte tutmaktır:

1.0 ──→ 1.1 ──→ 1.2 ──→ 1.3 ──→ 1.4
 │                  │                  ▲
 └──── checkpoint ──┴── direct patch ───┘

Önerilen artifact politikası:

• Her release’in tam, imzalı imajı saklanır.
• Ardışık N→N+1 delta’ları uzun süreli ve değişmez artifact olarak tutulur.
• Sahada gerçekten bulunan aktif base sürümlerden latest sürüme doğrudan delta üretilir.
• Belirli LTS/checkpoint sürümlerinden latest’e bridge delta’lar tutulur.
• Base SHA, target SHA, board, hardware revision, variant ve partition geometry metadata’sı delta ile birlikte saklanır.
• Full imajlar silinmez; delta üretimi, adli inceleme ve kurtarma için canonical kaynak olmaya devam eder.

Agronode tarafında sahadaki base sürümlerden doğrudan delta üretme yaklaşımı mevcut artifact script’inde görülmektedir (ensure_field_deltas.py). Backend’deki mevcut politika doğrudan base–target eşleşmesini arar; A→B ve B→C bulunduğunda A→B→C rotasını otomatik planlamak için ayrıca bir graph/path planner gerekir (ota_policy.py).

Sunucu rota seçimini şu maliyet fonksiyonuyla yapabilir:

rota maliyeti =
toplam patch byte'ı
+ tahmini airtime
+ hop başına oturum/reboot maliyeti
+ paket kaybı ve başarısızlık riski
+ cihaz enerjisi ve bakım maliyeti

Pratik bir ilk politika, doğrudan patch varsa ve makul boyuttaysa onu seçmek; doğrudan patch çok büyükse en fazla 2–3 kontrollü hop içeren checkpoint rotasını denemektir. Tam imaj, LoRa üzerinden otomatik “son çare” olarak değil; kurtarma, bootstrap veya alternatif taşıma yolu olarak tutulmalıdır.

12. Delta OTA’nın çalışması için gereken güvenlik kapıları

Delta OTA, güvenlik kontrollerini ortadan kaldırmaz; tersine base imajın kesin kimliğini zorunlu hâle getirir.

Her patch için en az şu bilgiler doğrulanmalıdır:

• cihazın bildirdiği base firmware SHA-256,
• patch’in beklediği base SHA-256,
• board ve hardware revision,
• partition/slot geometry,
• hedef firmware SHA-256,
• MCUboot imzası ve izin verilen signing key,
• hedef firmware sürümünün downgrade politikasına uygunluğu.

MCUboot imajın bütünlüğünü ve imzasını doğrular; test boot’un kalıcı olarak onaylanmaması hâlinde geri dönüş mekanizması sağlayabilir (MCUboot resmi dokümantasyonu). Delta uygulama kodu ise hedef imajı oluşturmadan önce base ve layout uyumsuzluklarını reddetmelidir (Agronode delta uygulaması).

Çok eski cihazlar için ayrıca bir FUOTA bootstrap sürümü tanımlanmalıdır. Bu sürümden önceki firmware’de fragmentation istemcisi, delta uygulama kodu veya gerekli bootloader desteği yoksa cihaz doğrudan delta zincirine alınamaz; önce BLE, Wi-Fi, hücresel bağlantı veya kontrollü full image ile bootstrap yapılmalıdır.

13. Bu proje için uygulanabilir yol haritası

Aşama 1 — RF varsayımlarını sabitle

• Dragino ve E22’nin tam model numarasını kesinleştir.
• Bölgeyi ve frekans planını seç.
• Gerçek antene-giden çıkış gücünü ölç veya üretici veri sayfasından doğrula.
• Anten kazancı, kablo kaybı ve polarizasyonu kaydet.
• Mandalina bahçesinde 50 cm, 1 m ve gateway için 5 m senaryolarını aynı rota üzerinde ölç.

Aşama 2 — Saha bağlantı haritası çıkar

• Her ölçüm noktasında RSSI ve SNR kaydet.
• Paket başarı oranını ve yön bağımlılığını ölç.
• Kuru, sulanmış, yağmurlu ve farklı yaprak yoğunluklarındaki koşulları karşılaştır.
• Sıra boyunca ve sıralara dik iki ayrı rota ölç.
• FUOTA için hedeflenen minimum link margin’i ayrıca tanımla.

Aşama 3 — LoRaWAN FUOTA taşımasını tamamla

• TS004 fragmentation oturumunu uygula.
• TS005 ile geçici Class C/multicast yaşam döngüsünü uygula.
• TS006 firmware version/reboot yönetimini ve TS007 package discovery’yi bağla.
• Fragment kaybı, tekrar, yarıda kesilme ve gateway yeniden başlatma testlerini yap.
• Bu aşama tamamlanmadan LoRa üzerinden uçtan uca Delta FUOTA başarı garantisi verme.

Aşama 4 — Delta artifact ve rota yönetimini ekle

• Full signed release’i canonical artifact olarak sakla.
• Komşu delta’ları ve aktif saha base’lerinden latest’e direct delta’ları üret.
• Delta metadata’sını base/target SHA ve donanım kimliğiyle immutable tut.
• Sunucuda doğrudan patch ve sınırlı multi-hop rota seçimini uygula.
• Her hop sonrasında version, SHA, boot health ve uygulama sağlık sinyalini bekle.

Aşama 5 — FUOTA başarı metriğini tanımla

Başarı yalnızca “paketlerin tamamı alındı” olmamalıdır. Aşağıdaki metrikler birlikte raporlanmalıdır:

• patch byte’ı ve toplam airtime,
• fragment kayıp oranı ve tekrar sayısı,
• güncelleme tamamlanma süresi,
• enerji tüketimi,
• test boot başarı oranı,
• kalıcı confirm oranı,
• rollback oranı,
• birden fazla hop gerekiyorsa hop başına başarı ve toplam başarı.

Sonuç

Mandalina bahçesindeki LoRa problemi, yalnızca “kaç kilometre menzil alırız?” sorusu değildir. SF ve BW seçimi menzil ile bit rate arasında bir değiş tokuş oluşturur; bitki örtüsü bu teorik linki saha koşullarında değiştirir; anten yüksekliği ve sıra yönü sonucu etkiler; FUOTA ise küçük telemetri paketlerinden tamamen farklı bir downlink kapasitesi ister.

Bu nedenle Semtech dokümanındaki 6 km referans değeri ile yoğun bir bahçedeki güvenilir güncelleme mesafesi aynı metriği ifade etmez. Doğru mimari; ölçülmüş RF link budget, uygun gateway yüksekliği, standart TS004/TS005 FUOTA taşıması, MCUboot güvenlik kapıları ve Delta OTA artifact grafiğinin birlikte tasarlanmasıdır.

Delta OTA, 1 MB tam imajı 15–53 KB civarındaki patch’lere indirebildiğinde FUOTA airtime’ını dramatik biçimde azaltabilir. Ancak bu avantajı güvenilir ürüne dönüştüren parça yalnızca delta algoritması değildir. Sunucu, cihazın kesin base SHA’sını bilmeli; uygun direct veya sınırlı multi-hop rotayı seçmeli; her hop’u doğrulamalı ve full imajı kurtarma kaynağı olarak korumalıdır.

Kısacası hedef, “en uzun menzil” değil; mandalina bahçesinde ölçülebilir, tekrarlanabilir ve geri alınabilir firmware güncellemesi yapabilen bir LoRaWAN sistemi kurmaktır.

Kaynaklar

Standartlar ve üretici teknik dokümanları

1. Semtech — LoRa and LoRaWAN: A Technical Overview
2. Semtech — Understanding LoRa Adaptive Data Rate
3. LoRa Alliance — RP002 Regional Parameters
4. LoRa Alliance — TS004 Fragmented Data Block Transport
5. LoRa Alliance — TS005 Remote Multicast Setup
6. LoRa Alliance — TS006 Firmware Management Protocol
7. LoRa Alliance — TS007 Multi Package Access
8. LoRa Alliance — LoRaWAN Specification v1.0.3
9. MCUboot — official documentation
10. MCUboot — boot design and test/revert flow
11. detools — sequential and incremental delta patching

Tarımsal RF yayılım çalışmaları

12. Influence of foliage on radio path losses for WSN planning in orchards
13. Test of WSN RF signal propagation based on different node deployments in citrus orchards
14. Deployment Strategies of Soil Monitoring WSN for Precision Agriculture Irrigation Scheduling