LoRaWAN, MQTT hay NB-IoT: chọn giao thức kết nối cho hệ thống IoT công nghiệp

Ba tên thường xuất hiện trong cùng một cuộc thảo luận về thiết kế hệ thống IoT: LoRaWAN, MQTT, NB-IoT. Nhưng chúng không phải ba lựa chọn thay thế nhau — đây là lỗi hiểu lầm phổ biến nhất trong giai đoạn lên kế hoạch, và thường dẫn đến kiến trúc không tương thích với thực tế triển khai sau này.

LoRaWAN và NB-IoT (cùng với WiFi, Ethernet, BLE, Zigbee) là wireless radio protocols — quyết định thiết bị kết nối bằng cách gì về mặt vật lý. MQTT là messaging protocol chạy trên lớp TCP/IP — quyết định cách dữ liệu được đóng gói, định tuyến và phân phối sau khi đã có kết nối. Hai lớp này độc lập với nhau: MQTT có thể chạy trên cả LoRaWAN gateway, NB-IoT modem, hay WiFi — và một hệ thống IoT hoàn chỉnh thường dùng cả hai.

LoRaWAN — khi pin phải sống vài năm và range phải rộng

LoRa (Long Range) là công nghệ radio tần số ISM (không cần cấp phép), và LoRaWAN là giao thức MAC layer xây trên LoRa. Đặc điểm quyết định: tiêu thụ năng lượng cực thấp và range rất xa — lý tưởng cho cảm biến chạy pin trong môi trường ngoài trời.

• Range: 2–10 km trong điều kiện không có vật cản (line-of-sight), 1–3 km trong đô thị dày đặc — theo tài liệu kỹ thuật của LoRa Alliance, gateway đặt đúng vị trí có thể đạt tới hơn 10km ở khu vực nông thôn. Một gateway LoRaWAN đặt đúng vị trí có thể phủ cả khu công nghiệp vài km²
• Battery life: một cảm biến gửi 10 byte mỗi 15 phút có thể chạy 5–10 năm trên một cell pin — nhờ duty cycle cực thấp và deep sleep giữa các lần truyền
• Data rate: thấp (250 bps đến 50 kbps tùy Spreading Factor) — LoRaWAN không phù hợp với thiết bị cần gửi nhiều data liên tục như video, audio hay log dày
• Infrastructure: cần deploy gateway riêng (hoặc dùng public network như The Things Network). Đây là ưu điểm — kiểm soát hoàn toàn — và nhược điểm — thêm một thành phần cần vận hành — cùng lúc

LoRaWAN phù hợp nhất cho: đo lường môi trường (nhiệt độ, độ ẩm, áp suất), giám sát mức nước, tracking tài sản diện rộng, giám sát hạ tầng nông thôn — nơi thiết bị cần pin lâu, vùng phủ rộng, và data volume nhỏ.

NB-IoT và LTE-M — khi cần SLA carrier-grade

NB-IoT (Narrowband IoT) và LTE-M là hai chuẩn LPWAN chạy trên mạng cellular của nhà mạng — thiết bị dùng SIM card thay vì kết nối đến private gateway. Điểm khác biệt chính so với LoRaWAN:

• Coverage: dựa trên hạ tầng của nhà mạng — không cần deploy gateway, phủ ở bất cứ đâu có sóng 4G/5G. Thích hợp khi thiết bị phân tán địa lý và không kiểm soát được hạ tầng mạng trung gian
• Data rate: theo so sánh kỹ thuật của GSMA, NB-IoT đạt tối đa ~127 kbps downlink (chuẩn Cat-NB2/3GPP Release 14, tăng từ ~26 kbps ở Release 13), LTE-M đạt tối đa ~1 Mbps (Release 13) và hỗ trợ voice — cao hơn LoRaWAN đáng kể, đủ cho firmware OTA update và telemetry tần suất cao hơn
• Mobility: LTE-M hỗ trợ handover giữa trạm — phù hợp cho thiết bị di động (xe tải, container). NB-IoT tốt hơn cho thiết bị cố định
• Chi phí: phát sinh chi phí SIM và data plan hàng tháng cho từng thiết bị — quan trọng khi fleet lớn hàng nghìn thiết bị

NB-IoT phù hợp nhất cho: đo công tơ điện/nước/gas thông minh, giám sát container và pallet, thiết bị y tế di động, bất kỳ ứng dụng nào cần SLA của nhà mạng và không muốn tự quản lý gateway.

MQTT — lớp messaging chạy trên tất cả

MQTT (Message Queuing Telemetry Transport) không phải wireless protocol — nó là messaging protocol publish/subscribe chạy trên TCP/IP, được thiết kế cho môi trường bandwidth hẹp và kết nối không ổn định. Hiểu đúng vai trò của MQTT tránh được nhầm lẫn kiến trúc phổ biến:

• MQTT broker (Mosquitto, EMQX, HiveMQ) nhận message từ thiết bị và phân phối đến subscriber — database, dashboard, alert engine, hay service khác
• QoS level: QoS 0 (at most once, không đảm bảo), QoS 1 (at least once, có thể trùng), QoS 2 (exactly once, overhead cao nhất) — chọn phù hợp với loại dữ liệu
• Retain message: broker lưu lại message cuối của một topic, subscriber mới nhận được ngay khi kết nối — hữu ích cho trạng thái thiết bị và last known value
• Last Will and Testament (LWT): broker tự publish một message khi thiết bị mất kết nối đột ngột — dùng để alert hoặc đánh dấu thiết bị offline trong dashboard
• Topic hierarchy: convention phổ biến là {project}/{site}/{device_id}/{metric} — thiết kế topic tốt từ đầu tránh refactor tốn công sau này khi fleet lớn lên

Khi nào dùng giao thức nào — bốn câu hỏi quyết định

Trước khi chọn giao thức, cần trả lời bốn câu hỏi về workload thực tế:

• Pin hay có nguồn điện cố định? → Thiết bị pin cần sống lâu trong môi trường ngoài trời → LoRaWAN hoặc NB-IoT. Thiết bị có nguồn AC trong nhà máy hoặc trên máy móc có điện → WiFi hoặc Ethernet — không cần tiết kiệm điện, có thể gửi data thường xuyên hơn
• Data volume và tần suất? → Dưới vài KB/ngày (nhiệt độ, mức nước, trạng thái on/off) → LoRaWAN đủ. Cần vài KB/phút (log máy móc, telemetry chi tiết) → NB-IoT hoặc WiFi. Cần Mbps (camera, audio, vibration raw) → WiFi hoặc Ethernet bắt buộc
• Thiết bị cố định hay di động? → Thiết bị cố định trong vùng phủ kiểm soát được → LoRaWAN với private gateway. Thiết bị di động trên đường, liên vùng → NB-IoT/LTE-M với SIM
• Ai kiểm soát hạ tầng mạng? → Muốn kiểm soát toàn bộ, môi trường cô lập như khu công nghiệp → LoRaWAN private network. Muốn zero-infra, trả theo dùng → NB-IoT với carrier

Kiến trúc điển hình: ba lớp phối hợp

Trong một hệ thống IoT công nghiệp quy mô vừa (vài trăm đến vài nghìn thiết bị), kiến trúc thường thấy là ba lớp phối hợp: radio layer (LoRaWAN hoặc NB-IoT từ thiết bị đến gateway), messaging layer (MQTT từ gateway đến broker), và data layer (từ broker đến database như TimescaleDB hay ClickHouse tùy workload). Trong dự án giám sát chất lượng nước cho 12 quận tại thành phố Cần Thơ, kiến trúc này gồm cảm biến LoRaWAN phủ khu vực nông thôn, NB-IoT cho trạm đo trong đô thị, tất cả đẩy về MQTT broker trung tâm trước khi vào TimescaleDB.

Kết luận

Lựa chọn giao thức IoT không phải chọn "cái tốt nhất" mà là chọn đúng lớp cho đúng vấn đề. LoRaWAN và NB-IoT giải quyết bài toán kết nối vật lý ở hai điểm khác nhau trên trục pin/data/infrastructure; MQTT giải quyết bài toán messaging và routing ở lớp trên. Thiết kế đúng từ đầu — thay vì thêm gateway hay đổi giao thức khi hệ thống đã scale — là một trong những quyết định kiến trúc ít được nhắc đến nhưng có ảnh hưởng lớn nhất đến chi phí vận hành trong lớp IoT & Sensors.