IoT LoRaWAN ChirpStack chuyển đổi số

IoT Platform cho chính quyền địa phương: vì sao tôi chọn LoRaWAN thay vì SIM 4G

Ngô Vũ Nhật
6 phút đọc

Tôi phụ trách khối giải pháp của một công ty phần mềm làm nhiều dự án cho chính quyền địa phương. Trong các cuộc khảo sát nhu cầu IoT ở cấp tỉnh và cấp xã, câu hỏi đầu tiên tôi gặp gần như luôn là: “chọn loại SIM hay chọn LoRa?” Đây là bài viết về lý do vì sao tôi gần như luôn khuyên dùng LoRaWAN cho các dự án dạng này, và cách tôi cấu trúc một hệ thống IoT on-premise xung quanh nó.

Vấn đề thật của mô hình “SIM 4G cho từng thiết bị”

Với 50–200 thiết bị đo rải rác trên một địa bàn (cảm biến ngập, báo cháy nhà dân, quan trắc môi trường, SOS khẩn cấp…), mô hình gắn SIM cho từng thiết bị bộc lộ hai vấn đề chi phí và vận hành:

  • Chi phí thuê bao lặp lại mỗi tháng nhân với số thiết bị, trên toàn bộ vòng đời 5 năm của dự án. Với ngân sách nhà nước, con số này biến dự án từ “mua một lần” thành “trả tiền hàng năm vô hạn”.
  • Điểm lỗi tăng tuyến tính: mỗi SIM là một hợp đồng, một hóa đơn, một điểm nghẽn khả năng mất sóng hoặc ICCID hết hạn mà chuyên viên IT của huyện không có tiền maintain.
  • Phụ thuộc nhà mạng về route dữ liệu: toàn bộ dữ liệu sensor đi qua hạ tầng của nhà mạng, khó bảo mật khi hệ thống phải xử lý cảnh báo khẩn cấp.

LoRaWAN đi đường khác: một gateway LoRa phủ sóng vài cây số, thiết bị dùng băng tần miễn phép, pin 2–5 năm, và dữ liệu chảy về network server của chính chủ đầu tư.

Kiến trúc nền tảng tôi dùng

Đây là stack tôi triển khai thực tế, mỗi thành phần đều open-source hoặc sử dụng thiết bị thương mại có sẵn:

Kiến trúc nền tảng IoT LoRaWAN on-premise

  1. End-devices: cảm biến thương mại LoRaWAN (MOKOSmart, Netvox, Milesight, Dragino, Seeed… — tôi chọn theo từng loại ứng dụng để tránh vendor lock-in). Cùng một loại thiết bị phải hỗ trợ nhiều nhà sản xuất.
  2. Gateway LoRa: vài cây đầu trong huyện/thị xã, mỗi cây phủ 3–10km tùy địa hình. Thết bị truyền lên gateway qua vật lý LoRa, không cần SIM.
  3. Network server: tôi dùng ChirpStack v4 cài on-premise. Đây là bộ não bắt buộc — chịu toàn bộ encryption/decryption, điều phối, dedup. Mọi thông tin về thiết bị và session đều nằm trong CSDL của chủ đầu tư chứ không ở nhà cung cấp thứ ba.
  4. MQTT broker: ChirpStack đẩy sự kiện lên MQTT (Mosquitto hoặc EMQX), các hệ thống phía sau subscribe theo topic.
  5. Nền tảng ứng dụng: MQTT được feed vào IOC/trung tâm sự cố/SOS (reusable dashboard + rule engine). Cảnh báo bảo vệ riêng phải đạt dưới 30 giây từ thời điểm sự kiện tới khi hiển thị màn hình trực — đây là hard requirement, không phải mục tiêu đẹp.
  6. Quy hoạch tần số: tại Việt Nam phải gắn băng tần AS923-2 theo QCVN 122:2020/BTTTT. Đây là điều nhiều bài viết quên — nếu mua thiết bị config sẵn EU868 về dùng thì sai luật, và khi đấu thầu công hệ thống có thể bị loại ngay ở giai đoạn thẩm định.

Cái bẫy lớn nhất: nhầm LoRaWAN với “độc lập hoàn toàn”

LoRaWAN tốt ở không khí — layer vật lý. Nhưng nó không thay thế được hệ thống ứng dụng và IOC phía trên. Tôi đã thấy một số dự án chào theo hướng “làm LoRaWAN là thay được tất cả”, rồi dính vấn đề khi cần tích hợp vào hệ thống SOS/chỉ huy hiện có: không có chuẩn MQTT/API để bridge, không có lịch sử dữ liệu, không có quyền truy cập CSDL.

Tư duy của tôi là: LoRaWAN on-premise là lớp bổ khuyết, không phải lớp thay thế. Nó bổ khuyết khoảng trống giữa (a) thiết bị đo rẻ pin lâu không cần SIM và (b) hệ thống ứng dụng của khách hàng (IOC/SOS/chính phủ điện tử) vốn không muốn ôm thêm hạ tầng viễn thông. Khi đấu thầu hay tư vấn, tôi cố tình tách rõ: ISP giữ hạ tầng truyền dẫn internet, còn hệ thống IoT của chúng tôi lo phần đo lường và cảnh báo.

Thực tế vận hành: vài bài học không thấy trong brochure

  • Cân bằng số gateway theo địa hình: đồng bằng và biển khác núi, cùng một công thức “mỗi gateway phủ Xkm” không tồn tại. Phải khảo sát hiện trường, không tính trên giấy.
  • Join server là bước hay bị quên: nếu kích hoạt nhiều loại thiết bị bằng OTAA, cần chuẩn bị key/code đầy đủ khi deploy, không thì một gói lô thiết bị “nghe” gateway khác và lộ dữ liệu gián tiếp.
  • Cảnh báo dưới 30 giây chỉ đạt được nếu toàn bộ chain đều gần: end-device -> gateway -> network server -> MQTT -> rule engine -> dashboard. Cấu hình pooling sai/gateway dùng chậm TTNN ngược dễ gây latency vô hình vài giây, với hệ thống SOS là fail.
  • Số lượng thiết bị không phải vấn đề: ChirpStack v4 khi config đúng xử lý hàng chục nghìn thiết bị không vấn đề. Cái đắt là vận hành & giáo dục người sử dụng: hướng dẫn trực viên trực cảnh báo, xây quy trình xử lý từng loại sự kiện, thu hồi thiết bị lỗi.

Tích hợp hai chiều: vì sao MQTT là nền tảng chọn lọc

Sở dĩ tôi giữ kiến trúc ChirpStack -> MQTT -> app là vì MQTT là chuẩn mở mọi bên đều hiểu. Khi cần nối thêm hệ thống thứ ba (IOC của tỉnh, phần mềm khác), tôi không cần mở ChirpStack cho bên ngoài — chỉ cần cấp MQTT credential và topic riêng. Việc này tôi làm được vì toàn bộ hạ tầng đều nằm trên server của một dự án, không phụ thuộc thiết bị gốc chừng nào vẫn giữ protocol mở.

Kết

LoRaWAN không phải kiểu “rẻ kích cho vui” — nó là quyết định kiến trúc bảo vệ ngân sách: trả 1 lần cho hạ tầng, dùng 5+ năm, dữ liệu nằm trong tay mình. Chi phí vận hành 5 năm của mô hình LoRaWAN tôi tham gia thường thấp hơn đáng kể so với mô hình SIM 4G tương đương.

Nếu anh chị đang cân nhắc một hệ thống IoT cho địa phương, câu hỏi tôi khuyên đặt ra trước là “dữ liệu và tài khoản nhà mạng của ai?” trước khi bàn mô hình doanh thu hay danh mục sensor.