Giới thiệu dự án

Sự bùng nổ của cuộc Cách mạng Công nghiệp 4.0 và Internet of Things (IoT) đã thúc đẩy nhu cầu tự động hóa trong các tòa nhà và văn phòng thông minh (Smart Office/Smart Building). Theo báo cáo thị trường từ MarketsandMarkets, quy mô thị trường Tòa nhà Thông minh toàn cầu đạt hơn 80 tỷ USD và duy trì tốc độ tăng trưởng kép hàng năm (CAGR) trên 12%. Tuy nhiên, việc triển khai hàng ngàn thiết bị cảm biến và cơ cấu chấp hành trong các không gian phức tạp đang đối mặt với nhiều rào cản kỹ thuật nghiêm trọng.

graph LR
    subgraph Mesh_Network["Bluetooth Mesh (Managed Flooding)"]
        N1[Node Temp - LM75] -->|0xC003| GW_BLE
        N2[Node Fire Sensor] -->|0xC004| RelayNode[Node Relay/Light]
        RelayNode -->|Relay Message| GW_BLE[nRF52832 SoC]
    end
    subgraph Gateway_Bridge["Gateway Node"]
        GW_BLE <-->|UART 115200 bps| GW_WiFi[ESP8266 RTOS]
    end
    subgraph Cloud_And_App["Cloud Backend & Client"]
        GW_WiFi <-->|WebSocket TCP/IP| Server[Java WebSocket Server]
        Server <-->|MongoDB Driver| DB[(MongoDB)]
        Server <-->|Full-Duplex Socket| App[Android Client App]
    end

Vấn đề thực tế (Problem Statement & Pain Points)

  • Hạn chế topology One-to-One/Star: Các chuẩn kết nối truyền thống (Wi-Fi tiêu chuẩn, Bluetooth Classic/BLE Point-to-Point) bị giới hạn nghiêm trọng về bán kính phủ sóng (10–50m), dễ xuất hiện điểm chết vô tuyến do tường bê tông và vật cản.
  • Nghẽn mạng và giới hạn số lượng nút: Wi-Fi bị giới hạn điểm truy cập (thực tế tối đa 255 kết nối lý thuyết nhưng suy giảm hiệu năng rõ rệt khi vượt quá 30–50 thiết bị); Zigbee phụ thuộc vào thiết bị Coordinator trung tâm, tạo điểm nghẽn đơn điểm thất bại (Single Point of Failure).
  • Tiêu thụ năng lượng cao: Wi-Fi đòi hỏi công suất duy trì kết nối lớn (hàng trăm mA), không thích hợp cho các cảm biến vận hành bằng pin độc lập.

Mục tiêu dự án

  1. Nghiên cứu toàn diện kiến trúc chuẩn Bluetooth Mesh (được ban hành bởi Bluetooth SIG) trên nền tảng Bluetooth Low Energy (BLE 5.0).
  2. Thiết kế và chế tạo phần cứng Gateway nhúng kết hợp vi điều khiển nRF52832 (Nordic Semiconductor) và ESP8266 (Espressif Systems).
  3. Hiện thực hóa mạng nút cảm biến không dây: Node Cảm biến nhiệt độ I2C (LM75), Node Cảm biến lửa (Flame Sensor), Node Cảm biến ánh sáng (CDS) và Node Chấp hành Relay 4 kênh tải cao.
  4. Phát triển hệ thống máy chủ thời gian thực (Java WebSocket Server), cơ sở dữ liệu phi quan hệ (MongoDB) và ứng dụng di động Android Native tương tác hai chiều.
  5. Thực nghiệm đánh giá độ tin cậy, độ trễ và khả năng định tuyến đa chặng (Managed Flooding Relay) trong môi trường tòa nhà thực tế.

Phương pháp tiếp cận và kết quả kỳ vọng

  • Giải pháp: Ứng dụng mô hình Managed Flooding kết hợp cơ chế bộ đệm thông điệp (Message Cache) và tham số Time-to-Live (TTL) để mở rộng vùng phủ sóng vô hạn qua các nút chuyển tiếp (Relay Nodes), loại bỏ hoàn toàn bộ điều phối trung tâm.
  • Chỉ số đo lường kỳ vọng: Hỗ trợ mở rộng đến 32.768 địa chỉ logic, tỷ lệ rớt gói tin (Packet Loss Rate) < 5% trong phạm vi đa chặng văn phòng, thời gian phản hồi điều khiển thời gian thực < 200ms.
  • Phạm vi & Giới hạn: Thử nghiệm tập trung vào môi trường văn phòng/tòa nhà với 5 nút đại diện chính, sử dụng dải tần ISM 2.4 GHz không cấp phép.

Phân tích và thiết kế giải pháp

Phân tích hiện trạng

Tiêu chí kỹ thuật Wi-Fi (IEEE 802.11 b/g/n) Zigbee (IEEE 802.15.4) Bluetooth Mesh (BLE 5.0)
Băng tần hoạt động 2.4 GHz 2.4 GHz 2.4 GHz
Bán kính mỗi nút 10 – 50 m 10 – 100 m 10 – 100 m (Mở rộng đa chặng)
Mức tiêu thụ năng lượng Cao (100–300 mA) Rất thấp (15–30 mA) Rất thấp (5–15 mA với LPN)
Tốc độ truyền dữ liệu Lên đến 1 Gbps 250 kbps 250 kbps / 1 Mbps / 2 Mbps
Cơ chế định tuyến Star Topology (Peer-to-AP) Full Routing (Mesh bảng) Managed Flooding (Mesh)
Số lượng Node tối đa ~ 255 nodes ~ 65.000 nodes 32.768 nodes
Điểm lỗi tập trung Bị ảnh hưởng nếu hỏng AP Có (Hỏng Coordinator) Không (Phân tán hoàn toàn)
Khả năng tương thích Smartphone/PC Cần Zigbee Gateway chuyên biệt Trực tiếp qua Smartphone (GATT Proxy)

Phân loại yêu cầu hệ thống (MoSCoW Prioritization)

  • Must-have: Cơ chế Provisioning bảo mật trao đổi khóa ECDH P-256; khả năng Relay gói tin qua nút trung gian; truyền thông điệp điều khiển On/Off Relay và thu thập dữ liệu nhiệt độ/ánh sáng/báo cháy về Gateway.
  • Should-have: Giao thức truyền dữ liệu hai chiều thời gian thực WebSocket giữa ESP8266, Java Server và Android App; cập nhật chu kỳ lấy mẫu cảm biến nhiệt độ định kỳ 60 giây/lần.
  • Could-have: Tính năng phân cấp Low Power Node (LPN) và Friend Node nhằm tiết kiệm tối đa năng lượng nguồn pin.
  • Won't-have (giai đoạn này): Xử lý OTA (Over-The-Air) Firmware Update đồng loạt trên toàn bộ mạng lưới Mesh.

Thiết kế hệ thống

+-----------------------------------------------------------------------------------+
|                            HỆ THỐNG BLUETOOTH MESH                               |
|                                                                                   |
|  [Node Temp (LM75)]     [Node Fire (GPIO 23)]    [Node Light]    [Node 4-Relay]   |
|         \                      |                      /                /          |
|    (0xC003)                 (0xC004)              (0xC005)         (0xC001)       |
|          \                     |                     /                /           |
|           +-----> [ Relay Node (Managed Flooding) ] <---------------+             |
|                                     |                                             |
|                                (Advertising)                                      |
|                                     v                                             |
|                     +-------------------------------+                             |
|                     |      GATEWAY THÔNG MINH       |                             |
|                     |  [nRF52832] <---UART---> [ESP8266]                          |
|                     +---------------+---------------+                             |
+-------------------------------------|---------------------------------------------+
                                      | WebSocket (Port 80/443 TCP/IP)
                                      v
                      +-------------------------------+
                      |     JAVA BACKEND SERVER       |
                      |   - WebSocket Endpoint        |
                      |   - Payload Parser            |
                      +-------+---------------+-------+
                              |               |
               MongoDB Driver |               | Full-Duplex Socket
                              v               v
                        +-----------+   +---------------+
                        |  MongoDB  |   |  ANDROID APP  |
                        | Database  |   | (User UI/Ctrl)|
                        +-----------+   +---------------+

Ngăn xếp công nghệ chi tiết (Technology Stack)

  • Phần cứng vi điều khiển Mesh: SoC Nordic nRF52832 (ARM Cortex-M4F 32-bit @ 64 MHz, 512 KB Flash, 64 KB RAM, bộ gia tốc EasyDMA cho UART/SPI/I2C).
  • Phần cứng Gateway Wi-Fi: Espressif ESP8266-12E (Tensilica Xtensa 32-bit L106 @ 80/160 MHz).
  • Embedded Software Stack:
    • nRF5 SDK v17.0.2 & nRF5 SDK for Mesh v5.0.0 (SEGGER Embedded Studio IDE).
    • ESP8266_RTOS_SDK (dựa trên nhân FreeRTOS hỗ trợ lập trình đa nhiệm tiền định).
  • Cơ sở dữ liệu & Server: MongoDB Community Server, Java WebSocket Server (javax.websocket).
  • Giao diện người dùng: Android SDK Platform (Java Native, Min SDK 24).

Thiết kế bảo mật và định danh mạng Mesh

  1. Phân lớp khóa (Key Hierarchy):
    • Network Key (NetKey): Xác thực và bảo mật tầng mạng (Network Layer), phân quyền truy cập chung trong Mesh.
    • Application Key (AppKey): Mã hóa payload ứng dụng cấp cao (Upper Transport Layer), phân lập bảo mật giữa các nhóm chức năng.
    • Device Key (DevKey): Khóa đơn nhất được tạo riêng giữa Provisioner và Node trong phiên cấu hình.
  2. Quy trình 5 bước cấp phát thiết bị (Provisioning Process):
    • Bước 1 (Beaconing): Thiết bị chưa cấp phát (Unprovisioned) phát gói tin Advertising Unprovisioned Device Beacon mang UUID 128-bit.
    • Bước 2 (Invitation): Provisioner gửi bản tin Provisioning Invite PDU thăm dò năng lực thiết bị (Provisioning Capabilities).
    • Bước 3 (Public Key Exchange): Trao đổi khóa công khai thông qua thuật toán mật mã đường cong Elliptic ECDH (Curve P-256).
    • Bước 4 (Authentication): Xác thực qua phương thức Out-of-Band (OOB) hoặc kiểm tra giá trị ngẫu nhiên (AuthValue).
    • Bước 5 (Distribution): Phân phối NetKey, AppKey và gán địa chỉ Unicast Address (16-bit) cho Node.

Implementation và kết quả

Development Process & Key Algorithms

1. Định dạng thông điệp nhị phân (Custom Framing Protocol)

Để tối ưu hóa băng thông vô tuyến, nhóm nghiên cứu thiết kế cấu trúc payload gọn nhẹ 2-byte kết hợp toán tử Bitwise:

// Cấu trúc định nghĩa Opcode và Payload định dạng 2-byte
#define MSG_OPCODE_TEMP1         0x46
#define MSG_OPCODE_FIRE1         0x46
#define MSG_OPCODE_LIGHT1        0x47
#define MSG_OPCODE_SWITCH_BASE   0x30

// Đóng gói bản tin nhiệt độ: MSB chứa Opcode, LSB chứa dữ liệu nhiệt độ đo được
uint16_t encode_temp_message(uint8_t temp_celsius) {
    return (uint16_t)((MSG_OPCODE_TEMP1 << 8) | (temp_celsius & 0xFF));
}

// Giải mã thông điệp nhận được tại Gateway
void parse_mesh_message(uint16_t raw_msg, uint8_t *opcode, uint8_t *data) {
    *opcode = (uint8_t)((raw_msg >> 8) & 0xFF);
    *data   = (uint8_t)(raw_msg & 0xFF);
}

2. Xử lý đọc thanh ghi cảm biến nhiệt độ LM75 qua bus I2C

Cảm biến nhiệt độ LM75 giao tiếp với nRF52832 qua bus I2C (địa chỉ mặc định 0x48 khi chân A0=A1=A2=GND). Thanh ghi nhiệt độ 0x00 trả về 16-bit dữ liệu, trong đó 11 bit MSB mang giá trị nhiệt độ độ phân giải $0.125^\circ\text{C}$:

#include "nrf_drv_twi.h"

#define LM75_ADDR            0x48
#define LM75_TEMP_REG        0x00

static const nrf_drv_twi_t m_twi = NRF_DRV_TWI_INSTANCE(0);

float read_lm75_temperature(void) {
    uint8_t reg = LM75_TEMP_REG;
    uint8_t buffer[2] = {0, 0};
    
    // Ghi địa chỉ thanh ghi cần đọc
    nrf_drv_twi_tx(&m_twi, LM75_ADDR, &reg, 1, true);
    // Đọc 2 byte dữ liệu MSB và LSB
    nrf_drv_twi_rx(&m_twi, LM75_ADDR, buffer, 2);
    
    // Trích xuất 11 bit có nghĩa
    int16_t temp_raw = (buffer[0] << 8) | buffer[1];
    temp_raw = temp_raw >> 5; // Dịch bỏ 5 bit LSB không dùng
    
    // Tính toán nhiệt độ theo độ phân giải 0.125 độ C/LSB
    float temperature = (float)temp_raw * 0.125f;
    return temperature;
}

3. Bắt tay WebSocket Gateway trên ESP8266 FreeRTOS

ESP8266 thực hiện handshake với Server thông qua thuật toán chuẩn RFC 6455:

$$\text{Sec-WebSocket-Accept} = \text{Base64}(\text{SHA1}(\text{Sec-WebSocket-Key} + \text{"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"}))$$

// Logic sinh Header xác thực WebSocket phía Java Server
import java.security.MessageDigest;
import java.util.Base64;

public class WebSocketHandshake {
    private static final String WS_GUID = "258EAFA5-E914-47DA-95CA-C5AB0DC85B11";

    public static String computeAcceptKey(String clientKey) throws Exception {
        String input = clientKey.trim() + WS_GUID;
        MessageDigest md = MessageDigest.getInstance("SHA-1");
        byte[] hash = md.digest(input.getBytes("UTF-8"));
        return Base64.getEncoder().encodeToString(hash);
    }
}

sequenceDiagram
    autonumber
    participant Node as Node Cảm biến (nRF52)
    participant Relay as Node Relay (Chuyển tiếp)
    participant GW_BLE as Gateway nRF52832
    participant GW_WiFi as Gateway ESP8266
    participant Server as Java WebSocket Server
    participant App as Android Client App

    Node->>Relay: Publish Message (Managed Flooding, TTL=4)
    Relay->>GW_BLE: Relay Advertising Bearer PDU
    GW_BLE->>GW_WiFi: UART Transfer (115200 bps Frame)
    GW_WiFi->>Server: WebSocket Packet (JSON/Payload)
    Server->>App: Push Event (Real-time Display/Alert)

Thiết lập Publish/Subscribe Topology

Node Name Device Type Hardware Platform Publish Address Subscribe Address Functionality
Gateway Bridge/Collector nRF52832 + ESP8266 0xC00A - 0xC00D 0xC001 - 0xC006 Cầu nối Mesh sang Internet
Switch 1 Actuator (4-Relay) nRF52832 + Relay Module 0xC001 0xC00A (Elem 1) Điều khiển đóng cắt tải 220V
Switch 2 Actuator (4-Relay) nRF52832 + Relay Module 0xC002 0xC00B (Elem 2) Điều khiển kênh phụ tải 220V
Node Temp Sensor nRF52832 + LM75 0xC003 None Đo nhiệt độ phòng (Chu kỳ 60s)
Node Fire Sensor nRF52832 + Flame/GPIO23 0xC004 0xC00D (Elem 4) Cảnh báo cháy tức thời
Node Light Sensor/Relay nRF52832 + CDS 0xC005, 0xC006 0xC00A, 0xC00B Cảm biến ánh sáng xác thực đèn

Testing và validation

1. Kịch bản thực nghiệm định tuyến chuyển tiếp (Relay Testing)

Thực hiện bố trí 3 nút: Node Gateway, Node Relay trung gian (Light), và Node Cảm biến lửa (Fire). Node Fire được cố tình bố trí ngoài vùng phủ sóng trực tiếp của Gateway (> 40m có vật cản bê tông).

  • Trường hợp 1 (Tắt Node Relay): Node Gateway không nhận được bất kỳ bản tin cảnh báo nào từ Node Fire (Tỷ lệ rớt gói 100%).
  • Trường hợp 2 (Bật Node Relay): Node Relay nhận bản tin Advertising từ Node Fire và phát lại (re-broadcast). Gateway nhận đầy đủ 100% bản tin cảnh báo trong thời gian $\Delta t < 45\text{ms}$.
  • Trường hợp 3 (Managed Flooding với 2 Relay song song): Bật đồng thời 2 nút trung gian. Nhờ cơ chế kiểm tra trùng lặp Message Cache trên nRF52832, Gateway chỉ xử lý gói tin đến trước và tự động loại bỏ gói tin trùng lặp đến sau mà không gây nghẽn mạng.
[ Node Fire ] (Gửi 0x4600)
     |
     +---> [ Relay 1 ] ---> (Truyền lại) ---> [ Gateway ] -> Xử lý gói tin đầu tiên
     |                                              ^
     +---> [ Relay 2 ] ---> (Truyền lại) -----------+ -> Message Cache hủy gói thứ hai

2. Đánh giá các yếu tố ảnh hưởng tỷ lệ rớt gói (Packet Loss Rate)

Khoảng cách giữa các Node Số lượng tường cản Giá trị TTL cấu hình Tỷ lệ nhận gói tin thành công (%) Độ trễ trung bình (ms)
10 mét 0 (Line-of-Sight) 3 99.8% 18 ms
25 mét 1 tường gạch (10cm) 3 98.4% 26 ms
40 mét (Đa chặng qua 1 Relay) 2 tường bê tông 4 96.5% 48 ms
60 mét (Đa chặng qua 2 Relay) 3 tường bê tông 5 94.2% 78 ms

Đổi mới và đóng góp

  1. Khắc phục điểm nghẽn Gateway truyền thống: Kiến trúc kết hợp nRF52832 và ESP8266 qua bus UART tốc độ cao (115200 bps) tạo thành cầu nối hai chiều chi phí thấp (< 10 USD), tương thích hoàn toàn với hạ tầng mạng IP sẵn có thông qua WebSocket.
  2. Cơ chế truyền tin Managed Flooding tối ưu: So với thuật toán định tuyến theo bảng của Zigbee (dễ vỡ đường truyền khi một Router bị ngắt điện), Bluetooth Mesh tự động tái định tuyến không cần thời gian hội tụ mạng (Zero Convergence Time).
  3. Mô hình hóa dữ liệu dạng Element độc lập: Một Node phần cứng duy nhất có thể chứa nhiều Element logic, cho phép quản lý riêng biệt từng relay trong mạch 4 kênh hoặc ghép tầng nhiều cảm biến trên cùng một chip xử lý.

Ứng dụng thực tế và triển khai

Tình huống ứng dụng thực tế

  • Tòa nhà văn phòng thông minh (Smart Office): Tự động giám sát nhiệt độ môi trường làm việc, phát hiện nguy cơ hỏa hoạn sớm và điều khiển hệ thống chiếu sáng, quạt thông gió từ xa qua ứng dụng Android.
  • Hệ thống nông nghiệp công nghệ cao (Smart Agriculture): Phủ sóng mạng cảm biến theo dõi độ ẩm, ánh sáng trên diện tích hàng hecta mà không cần kéo dây mạng cáp quang hay lắp đặt nhiều trạm thu phát Wi-Fi đắt đỏ.
            MÔ HÌNH TRIỂN KHAI VĂN PHÒNG THÔNG MINH
+----------------------------------------------------------------+
| [Khu A: Làm việc]        [Hành lang: Relay]   [Khu B: Máy chủ] |
| Node Temp (LM75)   --->    Node Relay     --->   Gateway Node   |
| Node Light (CDS)   --->    (Chuyển tiếp)  --->   (nRF52+ESP)   |
|                                                       |        |
| [Khu C: Nhà kho]                                      v        |
| Node Fire (GPIO23) --->                       [Cloud & Server] |
+----------------------------------------------------------------+

Ước tính hiệu quả kinh tế (Cost-Benefit Analysis & ROI)

  • Chi phí phần cứng: Giảm tới 60% chi phí thiết bị so với các giải pháp dùng module Zigbee công nghiệp độc quyền.
  • Chi phí triển khai: Cắt giảm 100% chi phí đi dây tín hiệu nhờ cấu trúc không dây tự hình thành mạng lưới (Self-forming Mesh).
  • Thời gian hoàn vốn (ROI): Ước tính từ 6 – 9 tháng thông qua việc tối ưu hóa điện năng tiêu thụ của hệ thống chiếu sáng và giảm thiểu rủi ro cháy nổ.

Hạn chế và hướng phát triển

Hạn chế kỹ thuật hiện tại

  • Nghẽn vô tuyến khi mật độ bản tin quá dày: Cơ chế Flooding nếu không giới hạn TTL hợp lý có thể gây xung đột kênh truyền (Packet Collision) ở 3 kênh quảng bá BLE (Channel 37, 38, 39).
  • Bộ nhớ đệm phần cứng giới hạn: Module nRF52832 với 64 KB RAM cần được phân bổ tối ưu để duy trì bảng Message Cache khi mạng mở rộng trên 100 nút.

Hướng phát triển tiếp theo

  • Tích hợp Low Power Node (LPN) & Friend Node: Tối ưu hóa chế độ ngủ sâu (Deep Sleep) cho các nút cảm biến chạy pin để kéo dài tuổi thọ hoạt động trên 2 năm.
  • Nâng cấp bảo mật sinh trắc học: Xác thực đa yếu tố trên ứng dụng di động và triển khai giao thức mã hóa TLS/WSS cho kết nối Gateway-to-Server.

Đối tượng hưởng lợi

  • Sinh viên & Học viên chuyên ngành Kỹ thuật Máy tính / IoT: Nguồn tài liệu thực nghiệm giá trị cao về cấu hình thanh ghi nhúng, thư viện nRF5 SDK for Mesh và lập trình vi điều khiển ARM Cortex-M4.
  • Kỹ sư phát triển phần mềm nhúng (Embedded Developers): Cung cấp thiết kế mẫu mạch phần cứng, sơ đồ nguyên lý phân chia khối Gateway, mã nguồn xử lý I2C không chặn và driver ngoại vi.
  • Doanh nghiệp tích hợp giải pháp Smarthome/Smart Building: Một kiến trúc mạng sẵn sàng sản xuất (Production-ready) với chi phí linh kiện tối ưu và khả năng mở rộng hàng ngàn thiết bị.

Câu hỏi thường gặp

1. Yêu cầu phần cứng tối thiểu để triển khai một Node trong hệ thống là gì?

Mỗi Node chỉ cần một vi điều khiển hỗ trợ BLE 5.0 (khuyến nghị dòng Nordic nRF52832 hoặc nRF52840) với tối thiểu 256 KB Flash và 32 KB RAM, cùng nguồn cấp DC từ 1.8V đến 3.6V.

2. Giới hạn mở rộng tối đa của mạng Bluetooth Mesh trong đề tài là bao nhiêu?

Theo lý thuyết của Bluetooth SIG, mạng hỗ trợ tối đa 32.768 nút định danh (Unicast Address). Trong phạm vi đề tài, hệ thống hoạt động ổn định và tối ưu nhất ở quy mô từ 50 đến 200 nút trên một Gateway.

3. Hệ thống có thể tích hợp với các nền tảng nhà thông minh khác (Home Assistant, Apple HomeKit) không?

Có. Nhờ Gateway sử dụng giao thức truyền thông chuẩn hóa WebSocket/JSON, hệ thống hoàn toàn có thể viết thêm module cầu nối (MQTT Bridge) để tích hợp liền mạch vào Home Assistant hoặc OpenHAB.

4. Chi phí bảo trì và độ phức tạp vận hành của hệ thống như thế nào?

Nhờ cơ chế Self-healing (tự phục hồi), nếu một nút trung gian bị hỏng hoặc mất nguồn, mạng tự động chuyển hướng gói tin qua các nút lân cận mà không cần can thiệp thủ công, giảm thiểu tối đa chi phí bảo trì.

5. Tại sao không dùng trực tiếp Wi-Fi Mesh cho toàn bộ các nút cảm biến?

Wi-Fi Mesh tiêu thụ dòng điện rất lớn (thường từ 80–200 mA liên tục), yêu cầu phần cứng phức tạp và giá thành cao hơn. Bluetooth Mesh cho phép các nút cảm biến chỉ tiêu thụ năng lượng ở mức $\mu\text{A}$ khi ở trạng thái nghỉ, tối ưu cho thiết bị chạy pin.

Kết luận

Khóa luận tốt nghiệp “Nghiên cứu và ứng dụng Bluetooth Mesh vào hệ thống thông minh” của nhóm tác giả Vũ Thị Lan Anh và Đặng Đức Bảo (Trường Đại học Công nghệ Thông tin - ĐHQG-HCM) đã giải quyết thành công bài toán kết nối mạng diện rộng, độ trễ thấp và độ tin cậy cao cho các thiết bị IoT văn phòng. Việc làm chủ toàn diện từ tầng vật lý, tầng mạng Mesh của Nordic Semiconductor đến tầng ứng dụng Cloud/Android khẳng định tính khả thi vượt trội của công nghệ Bluetooth Mesh, mở ra tiềm năng thương mại hóa mạnh mẽ trong các hệ sinh thái nhà thông minh và tòa nhà thông minh thế hệ mới.