Hücresel Ağ Üzerinden MQTT (LTE-M, NB-IoT): Veri Bütçesi, Keep Alive ve TLS İçin Tasarım İpuçları

Hücresel ağ üzerinden MQTT, uzak varlıkların çoğunun (pompa istasyonları, tanklar, güneş enerjisi sahaları, araçlar, çevre izleme cihazları) buluta ulaşma yoludur; ancak tasarım kuralları Wi-Fi veya Ethernet'ten farklıdır. Baytlar ücretlendirilir, bağlantılar daha sık kopar ve operatör ağları boşta kalan bağlantıları sessizce kapatır. Bu rehber, cihazlarınızın sürpriz faturalar olmadan bağlı kalması için veri bütçesini nasıl tahmin edeceğinizi, keep alive değerlerini nasıl seçeceğinizi, TLS ek yükünü nasıl azaltacağınızı ve LTE-M ile NB-IoT arasında nasıl seçim yapacağınızı gösteriyor.

Hücresel Ağ MQTT Tasarımını Neden Değiştirir?

MQTT başlangıçta güvenilmez, düşük bant genişlikli bağlantılar için tasarlandı; dolayısıyla zaten iyi bir uyum sağlar: 2 baytlık sabit başlık, kalıcı TCP bağlantıları ve sorgulamayı gereksiz kılan publish-subscribe. Ancak hücresel ağın üç gerçeği ayrıntıları şekillendirir:

1. Her bayt faturalandırılır; yalnızca payload'unuz değil, TCP/IP başlıkları, TLS kayıtları, onaylar ve keep alive ping'leri de.
2. Operatör sınıfı NAT (CGNAT) çoğu cihaz ile internet arasında durur ve operatöre özgü bir zaman aşımından sonra boştaki TCP eşlemelerini düşürür. MQTT bu süreden daha uzun sessiz kalırsa bağlantı, iki uç da hemen fark etmeden ölür.
3. Radyo durumu güç tüketir. Her gönderim modemi uyandırır ve modem sonrasında bir süre yüksek güç durumunda kalır. Çok sayıda küçük gönderim, birkaç gruplanmış gönderimden daha hızlı pil tüketir.

MQTT İçin LTE-M vs NB-IoT

TCP ve TLS üzerinden MQTT için LTE-M genellikle pragmatik seçimdir: TLS el sıkışmaları güvenilir şekilde tamamlanır ve komutlar cihaza hızla ulaşır. NB-IoT ise ulaşılması zor yerlerden küçük ve seyrek raporlar gönderen sabit cihazlarda öne çıkar; orada pek çok ekip MQTT-SN veya başka bir UDP tabanlı protokol kullanır ya da TCP üzerinden MQTT ile yavaş bağlantı kurulumunu kabul eder. Donanım seçmeden önce operatörünüzün kurulum bölgenizde hangi teknolojileri desteklediğini kontrol edin; bazı modemler ikisini de destekler ve otomatik olarak geri düşer.

Hücresel Ağ Üzerinden MQTT İçin Veri Bütçesi Tahmini

Payload boyutu çoğu zaman faturanın en küçük kısmıdır. Şunları hesaba katın:

• Her paketteki TCP/IP başlıkları (seçeneksiz IPv4 için kabaca 40 bayt, seçeneklerle veya IPv6 ile daha fazla) ve TCP onayları.
• Mesaj başına TLS kayıt ek yükü; başlık, nonce ve kimlik doğrulama etiketi için birkaç düzine bayt.
• MQTT ek yükü: sabit başlık, topic adı (çoğu zaman küçük bir mesajın en büyük kısmı) ve QoS 1 için bir PUBACK.
• Keep alive ping'leri: bir PINGREQ ve PINGRESP yalnızca 2'şer bayttır, ancak TLS, TCP/IP başlıkları ve ACK'lerle her gidiş-dönüş hat üzerinde çok daha fazlasına mal olur.
• Bağlantı kurulumu: sunucu sertifika zinciri dahil tam bir TLS el sıkışması genellikle birkaç kilobayttır. Sık yeniden bağlanmalar bütçeye hâkim olabilir.

Aşağıdaki betik kaba bir tahmin verir. Paket başına değerler bilinçli olarak temkinli varsayımlardır; bunları modeminizde ölçülen değerlerle değiştirin (çoğu modem gönderilen ve alınan baytları raporlar).

# MQTT-over-TLS hücresel cihaz için kaba aylık veri tahmini.
# Ek yük değerleri varsayımdır - kendi bağlantınızı ölçün ve ayarlayın.

PAYLOAD_BYTES = 60          # örn. kompakt JSON
TOPIC_BYTES = 40            # topic dizesinin uzunluğu
MSGS_PER_HOUR = 12          # her 5 dakikada bir ölçüm
QOS = 1                     # QoS 1 bir PUBACK ekler
KEEPALIVE_S = 240           # ping'ler yalnızca bağlantı başka şekilde boştayken önemlidir
RECONNECTS_PER_DAY = 2      # her biri tam bir TLS el sıkışması öder
TLS_HANDSHAKE_BYTES = 6000  # varsayım: sertifika zinciri baskındır
TCP_IP_PER_PACKET = 52      # IPv4 + timestamps seçenekli TCP
TLS_PER_RECORD = 29         # TLS 1.2 AES-GCM kayıt ek yükü
TCP_ACK = 52                # salt ACK paketi

def bytes_per_publish():
    mqtt = 2 + 2 + TOPIC_BYTES + (2 if QOS > 0 else 0) + PAYLOAD_BYTES
    out = mqtt + TLS_PER_RECORD + TCP_IP_PER_PACKET
    back = TCP_ACK
    if QOS > 0:
        back = 4 + TLS_PER_RECORD + TCP_IP_PER_PACKET + TCP_ACK  # PUBACK + bizim ACK
    return out + back

def bytes_per_ping():
    one_way = 2 + TLS_PER_RECORD + TCP_IP_PER_PACKET
    return 2 * one_way + 2 * TCP_ACK

msgs = MSGS_PER_HOUR * 24 * 30
gap = 3600 / MSGS_PER_HOUR
pings_per_gap = int(gap // KEEPALIVE_S)        # mesajlar arasında gereken ping'ler
pings = pings_per_gap * msgs

total = (msgs * bytes_per_publish()
         + pings * bytes_per_ping()
         + RECONNECTS_PER_DAY * 30 * TLS_HANDSHAKE_BYTES)

print(f"messages/month: {msgs}")
print(f"payload only:   {msgs * PAYLOAD_BYTES / 1e6:.2f} MB")
print(f"estimated total: {total / 1e6:.2f} MB")

Betiği çalıştırmak, sahada göreceğiniz deseni ortaya koyar: hat üzerindeki toplam, ham payload'un birkaç katıdır ve topic uzunluğu, onaylar ve yeniden bağlanmalar en az verinin kendisi kadar önemlidir. Aşağıdaki optimizasyonların ek yüke odaklanmasının nedeni budur.

Keep Alive vs Operatör NAT Zaman Aşımları

MQTT keep alive aralığı, broker'a client'ın ne kadar süre sessiz kalabileceğini söyler. Başka bir şey gönderilmezse client, aralık dolmadan önce bir PINGREQ gönderir. Hücresel ağda keep alive'ın ikinci bir görevi vardır: operatörün NAT eşlemesini canlı tutmak.

• Keep alive NAT boşta kalma zaman aşımından uzunsa, eşleme sessizce düşürülür. Cihaz hâlâ bağlı olduğunu düşünür; bir sonraki yayın kaybolur ve bağlantının öldüğü ancak bir TCP zaman aşımından sonra anlaşılır. Bu arada buluttan gelen komutlar asla ulaşmaz.
• Keep alive gerekenden çok daha kısaysa, ihtiyacınız olmayan ping'ler için ödeme yapar ve radyoyu uyanık tutarsınız.

NAT zaman aşımları operatörler arasında farklılık gösterir ve yalnızca birkaç dakika olabilir. Kendinizinkini ölçün: uzun bir keep alive ile bağlanın, yayınlar arasında giderek daha uzun bekleyin ve buluttan gelen mesajların ne zaman gelmeyi bıraktığını not edin. Ardından keep alive'ı bu değerin rahatça altına ayarlayın. Cihaz yalnızca veri gönderiyor ve komut almasına gerek yoksa, alternatif olarak bağlanıp yayın yapıp bağlantıyı kesebilir ve her seferinde el sıkışması maliyetini kabul edebilirsiniz; raporlar arasında saatler varsa bu daha ucuz olabilir.

TLS'ten Vazgeçmeden TLS Maliyetini Azaltın

Genel bir hücresel ağ üzerinden asla şifresiz MQTT göndermeyin. Bunun yerine TLS'i daha ucuz hale getirin:

1. Raporlar sık olduğunda bağlantıları açık tutun; böylece el sıkışması nadiren gerçekleşir.
2. Modeminiz veya TLS kütüphaneniz oturum kimliklerini ya da session ticket'larını destekliyorsa TLS oturum sürdürme (session resumption) kullanın. Sürdürülen bir el sıkışması sertifika alışverişini atlar; hem bayttan hem de zamandan tasarruf sağlar.
3. Her iki taraf da destekliyorsa ECDSA ile ECDHE'yi tercih edin; eliptik eğri anahtarları ve imzaları RSA eşdeğerlerinden daha küçüktür.
4. Cihazın minimal bir zinciri saklayıp doğrulaması için yalnızca ihtiyacınız olan köke güvenin (örneğin Let's Encrypt sertifikaları için ISRG Root X1).
5. Yeniden bağlanma fırtınalarından kaçının. Bir hücre kesintisinin arka arkaya yüzlerce el sıkışmasını tetiklememesi için jitter'lı üstel geri çekilme (exponential backoff) kullanın.

Her Mesajı Küçültün

• Kısa topic'ler. t/pump7/p gibi bir topic, her yayında uzun ve açıklayıcı bir hiyerarşiden çok daha ucuzdur. MQTT 5 ile topic alias'ları client'ın tam topic'i bir kez gönderip ardından ona küçük bir tamsayıyla atıfta bulunmasını sağlar; böylece mesaj başına maliyet olmadan okunabilir topic'ler korunur.
• Kompakt payload'lar. Kısa JSON anahtarları, ölçeği örtük tamsayılar veya Protobuf gibi ikili bir format (Sparkplug B'nin kullandığı gibi).
• Ölçümleri gruplayın. Dakikada bir yerine on dakikada bir tek mesajda on ölçüm gönderin; başlıklar bir kez ödenir.
• Değişimde raporlama. Yalnızca anlamlı değişimleri ve bir heartbeat gönderin; bkz. değişimde raporlama (report by exception).
• QoS seçimi. QoS 1 mesaj başına bir PUBACK ekler. Teslimin önemli olduğu yerlerde onu, bir sonraki ölçümün öncekini geçersiz kıldığı yüksek hızlı değerlerde QoS 0'ı kullanın.

Kesintili Bağlantılar İçin MQTT 5 Oturum Ayarları

Kalıcı bir oturum, cihaz kısa süreliğine çevrim dışıyken broker'ın abonelikleri korumasını ve cihaz için QoS 1 mesajlarını kuyruğa almasını sağlar; böylece bir kopma sırasında gönderilen komutlar kaybolmaz. paho-mqtt 2.x ile:

import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id="YOUR_CLIENT_ID", protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set()                                   # sistem CA deposu
client.reconnect_delay_set(min_delay=2, max_delay=300)

props = Properties(PacketTypes.CONNECT)
props.SessionExpiryInterval = 3600                 # kopmadan sonra oturumu 1 saat tut

client.connect("YOUR_BROKER_HOST", 8883, keepalive=240,
               clean_start=False, properties=props)
client.loop_forever()

Bunu giden veriler için yerel tamponlamayla eşleştirin, çünkü bir oturum yalnızca broker'ın aldığı mesajları korur. MQTT store and forward rehberi tam da bunun için disk destekli bir kuyruk gösteriyor.

Hücresel Tasarım Kontrol Listesi

1. TCP/TLS üzerinden MQTT ve etkileşimli komutlar için LTE-M'i seçin; sabit ve seyrek rapor gönderen cihazlar için NB-IoT'yi değerlendirin.
2. Operatör NAT boşta kalma zaman aşımını ölçün ve keep alive'ı onun altına ayarlayın.
3. TLS'i koruyun, ancak el sıkışmalarını en aza indirin ve mümkün olduğunda oturum sürdürme kullanın.
4. Topic'leri kısaltın veya MQTT 5 topic alias'larını kullanın; payload'ları sıkıştırın ve gruplayın.
5. Edge'de değişimde raporlama uygulayın.
6. Kesintiler sırasında giden veriyi cihazda tamponlayın.
7. Yeniden bağlanmalar için jitter'lı üstel geri çekilme kullanın.
8. Anormallikler faturadan önce ortaya çıksın diye cihaz başına günlük bayt miktarını izleyin.

Uygulamalı bir modem örneği için SIM7600 MQTT yazısına bakın. Gateway seviyesindeki mimari için IIoT edge gateway ve MQTT ile endüstriyel IoT rehberini okuyun.

Veri İçin Ödeme Yapmadan Önce Test Edin

Topic yapısını ve payload formatını önce Wi-Fi veya Ethernet üzerinde, connectmq/demo/cell-4f8a/... gibi benzersiz bir önekle genel MQTT test broker'ını kullanarak doğrulayın. Ardından cihazı, sunucu işletmenize gerek kalmadan TLS uç noktaları ve MQTT 5 özellikleri sunan ConnectMQ gibi yönetilen bir MQTT broker üzerinde üretim kimlik bilgileriyle hücresel ağa taşıyın. Barındırma seçeneklerini mi karşılaştırıyorsunuz? Bulut MQTT broker rehberi nelere dikkat etmeniz gerektiğini anlatıyor.

Hücresel Filonuzu ConnectMQ'ya Bağlayın

ConnectMQ, kesintili bağlantılar için oturum sona erme süresi, topic alias'ları ve mesaj sona erme süresiyle birlikte 8883 portunda TLS üzerinden MQTT 3.1.1 ve 5.0'ı destekler. $SYS/broker/connection/{clientId}/state topic'i ve portaldaki cihaz görünümleri, hangi uzak cihazların çevrim içi olduğunu görmenize yardımcı olur. app.connectmq.com adresinde kredi kartı gerekmeden ücretsiz bir Serverless broker oluşturun.

Sık Sorulan Sorular

MQTT hücresel ağ üzerinden ne kadar veri kullanır?

Bu, payload'dan çok ek yüke bağlıdır: TCP/IP ve TLS başlıkları, onaylar, keep alive ping'leri ve yeniden bağlanma el sıkışmaları. Yukarıdaki betik gibi bir modelle tahmin edin, ardından modeminizin bayt sayaçlarıyla doğrulayın.

LTE-M'de hangi keep alive değerini kullanmalıyım?

Operatörünüzün NAT boşta kalma zaman aşımından daha kısa bir değer; bunu ölçmelisiniz. Birkaç dakikalık değerler yaygın başlangıç noktalarıdır; testten sonra ayarlayın.

NB-IoT MQTT için uygun mu?

Sabit cihazlardan gelen küçük ve seyrek mesajlar için çalışabilir, ancak yüksek gecikme ve düşük veri hızı TCP ve TLS el sıkışmalarını yavaşlatır. TLS üzerinden standart MQTT için LTE-M daha kolay bir uyum sağlar.

Hücresel cihazlar raporlar arasında bağlantıyı kesmeli mi?

Raporlar arasında saatler varsa ve cihaza komut ulaşması gerekmiyorsa bağlan-yayınla-bağlantıyı kes yaklaşımı daha ucuz olabilir. Sık raporlar veya uzaktan kontrol için bağlantıyı ayarlanmış bir keep alive ile açık tutun.