IoT (NT532) — Tờ ghi nhớ thi (gói trong 2 mặt A4)

Học thuộc phần này là đủ qua đa số câu. Đề scenario-based, ~75% là Edge vs Cloud.

MẶT 1 — LÝ THUYẾT CỐT LÕI

⭐ Edge vs Cloud (quan trọng nhất)

Edge (xử lý tại/gần thiết bị): độ trễ thấp • tiết kiệm băng thông • riêng tư • chạy được khi MẤT MẠNG. Yếu: tài nguyên hạn chế. Cloud (xử lý tập trung): lưu trữ & phân tích lịch sử lớn • AI nặng • tổng hợp nhiều nguồn. Yếu: trễ cao, tốn băng thông, phụ thuộc mạng. Quy tắc chọn:

• Cần tức thời / offline / riêng tư / ít băng thông → EDGE
• Cần lịch sử dài hạn / AI nặng / gộp nhiều nơi → CLOUD
• Continuum: device → gateway → cloud. VD loa: wake-word TinyML tại máy, câu phức tạp lên cloud.

⭐ Năng lượng (MCU/pin)

• Radio tốn pin nhất → tắt khi rảnh.
• Sleep mode + duty cycling + giảm tần suất gửi = kéo dài pin.
• Gửi định kỳ thay vì liên tục để tắt radio giữa các lần.
• millis() (non-blocking) thay delay().

MCU & I/O

• ESP8266 (WiFi), nRF52840 (BLE). GPIO (số), Analog (ADC), PWM (giả analog: LED/motor/servo).
• Sensor = đọc (DHT11, PIR, ánh sáng); Actuator = tác động (relay, motor, van).

Chọn kết nối

Giao thức

• HTTP: request/response, REST, TCP, nặng.
• CoAP: như HTTP nhưng nhẹ, UDP → cho thiết bị yếu.
• MQTT: Publish/Subscribe qua Broker, theo Topic, QoS 0/1/2. Hợp nhiều bên dùng chung 1 luồng (dashboard+lưu+cảnh báo). QoS0=mất được, 1=ít nhất 1 lần, 2=đúng 1 lần.
• JSON: định dạng payload {"temp":25}.

BLE

• Peripheral (cảm biến, chờ) ↔ Central (điện thoại/Pi, quét & kết nối). Beacon=chỉ phát.
• GATT: Service ⊃ Characteristic (Read/Write/Notify). VD: HRM, UART.

Pi Gateway

• Cầu nối BLE ↔ Internet. Node.js + systemd service (tự restart, chạy nền).
• Gateway = chuyển tiếp; Edge device = tự xử lý (Python GPIO, camera).

LoRaWAN

• Xa, băng thông cực thấp, pin nhiều năm. OTAA (khóa động, an toàn) vs ABP (khóa cố định).
• SF cao = xa hơn/chống nhiễu nhưng chậm & tốn pin. Duty cycle giới hạn % phát. TTN = mạng cộng đồng.

Dashboard / Node-RED / Bảo mật

• Dashboard: biểu đồ; InfluxDB (time-series) + Telegraf; adapter TTN→ThingSpeak.
• Node-RED: luồng kéo-thả, luật "nếu temp>X → cảnh báo", trigger MQTT.
• Bảo mật: TLS + CA cert/fingerprint (chống MitM) + Basic Auth/token. Riêng tư → ưu tiên Edge.

---

MẶT 2 — TỰ LUẬN (công thức + ví dụ)

ZigBee (802.15.4) — gán địa chỉ

$R_m$=router/nút, $D_m$=end-device/nút, $L_m$=độ sâu max. $A(d)=1+D_m+R_m \quad (d=L_m{-}1); \quad A(d)=1+D_m+R_m\cdot A(d{+}1)\ (d<L_m{-}1)$ Cha địa chỉ $x$, độ sâu $d$:

• Router con $i$: $[\,x+(i{-}1)A(d{+}1)+1,\; x+i\,A(d{+}1)\,]$
• End-device con $j$: $x + R_m\,A(d{+}1) + j$

VD $R_m{=}D_m{=}4, L_m{=}3$: $A(2)=9, A(1)=41, A(0)=169$. Coord $[0,169]$ → router con $[1,41],[42,82],[83,123],[124,164]$; ED $165{-}168$. Router $[1,41]$ → con $[2,10],[11,19],[20,28],[29,37]$, ED $38{-}41$.

OLSR (proactive)

• MPR(N): tập ít nhất hàng xóm 1-hop của N phủ hết hàng xóm 2-hop (giảm flooding).
• MS(N): các nút đã chọn N làm MPR (N ∈ MPR(họ)).
• TC: chỉ MPR tạo & phát, kèm sequence number.
• Cách làm: liệt kê 1-hop & 2-hop → chọn tập con nhỏ nhất phủ 2-hop.

AODV (reactive, tìm đường khi cần)

• RREQ: nguồn broadcast; trường: broadcast_id, src/dest addr, src_seq (tươi route ngược), dest_seq (tươi route tới đích). Gói trùng broadcast_id → loại. Nút có route → trả RREP, không → forward (tăng hop_cnt).
• RREP: unicast ngược về nguồn. Chấp nhận RREP mới nếu dest_seq lớn hơn, hoặc bằng nhưng hop_cnt nhỏ hơn.
• VD 1→7 (6 biết route 7): 1 broadcast → 2,4 forward → tới 6 (3,5 trùng→loại) → 6 unicast RREP về 4 → 4 về 1. Route 3 hop.

6LoWPAN

IPv6 trên 802.15.4 (mạng công suất thấp), nén header IPv6.

Topology

tree / cluster / grid / chain. So sánh: năng lượng, độ trễ, mở rộng, độ bền khi 1 nút chết.

---

CÂU TỰ LUẬN MẪU (BÀI TẬP ÁP CÔNG THỨC) + LỜI GIẢI

Q1 — ZigBee addressing. Cho $R_m{=}2,\ D_m{=}2,\ L_m{=}3$. Tính $A(d)$ và gán địa chỉ các con của coordinator (depth 0) và của router con thứ 1. → B1 — Kích thước dải mỗi tầng (từ dưới lên): $A(2)=1+D_m+R_m=1+2+2=\textbf{5}$; $A(1)=1+D_m+R_m\cdot A(2)=1+2+2\cdot5=\textbf{13}$; $A(0)=1+D_m+R_m\cdot A(1)=1+2+2\cdot13=\textbf{29}$. B2 — Coordinator ở $x{=}0$, depth 0, dải $R(0)=[0,29]$:

• Router con $i$: $[x+(i{-}1)A(1)+1,\ x+i\,A(1)]$ → con1 $[1,13]$, con2 $[14,26]$.
• End-device con $j$: $x+R_m A(1)+j = 0+2\cdot13+j$ → ED1 = 27, ED2 = 28. B3 — Router con1 (địa chỉ $x{=}1$, depth 1), dùng $A(2){=}5$:
• Router con: $[1+0\cdot5+1,1+1\cdot5]=[2,6]$ và $[1+1\cdot5+1,1+2\cdot5]=[7,11]$.
• ED: $1+2\cdot5+j$ → ED1 = 12, ED2 = 13. (Lặp tương tự xuống depth 2 = lá.)

Q2 — OLSR. Cho topology (danh sách kề): 1:{2,3,4} · 2:{1,3,5,6} · 3:{1,2,6} · 4:{1,7} · 5:{2} · 6:{2,3} · 7:{4}. Tìm MPR(1) và cho biết MS của node được chọn. → B1 — Hàng xóm 1-hop của 1 = {2,3,4}. Hàng xóm 2-hop (qua 1-hop, loại 1 & 1-hop) = {5,6,7}. B2 — Phủ 2-hop bằng ít node 1-hop nhất:

• node 5 chỉ tới được qua 2 → bắt buộc chọn 2.
• node 7 chỉ tới được qua 4 → bắt buộc chọn 4.
• node 6 tới được qua 2 hoặc 3; node 2 (đã chọn) đã phủ 6. → MPR(1) = {2, 4} (node 3 không cần). B3 — Vì 1 chọn 2 & 4 làm MPR nên $1\in$ MS(2) và $1\in$ MS(4). Chỉ node MPR (2,4) mới phát TC message.

Q3 — AODV. Node 1 cần gửi tới Node 7, chỉ Node 6 biết route tới 7. Mô tả RREQ/RREP và đếm hop. → RREQ (broadcast): 1 phát RREQ (broadcast_id, src=1, dest=7, src_seq, dest_seq) → 2 và 4 nhận, kiểm tra không trùng/không cũ → forward, tăng hop_cnt, lập reverse route về 1 → RREQ tới 6. (3,5 nhận bản trùng broadcast_id → loại.) RREP (unicast ngược): 6 biết route 7 (dest_seq hợp lệ) → unicast RREP về 4 → 4 forward về 1, tăng hop_cnt. 1 chấp nhận RREP vì là route mới (nếu có nhiều RREP: chọn dest_seq lớn hơn, hoặc bằng nhưng hop_cnt nhỏ hơn). → Route 1→4→6→7 = 3 hop.

Q4 — 6LoWPAN. Khung IEEE 802.15.4 tối đa 127 byte, MAC header ~25 byte. Tính payload ứng dụng còn lại khi (a) header IPv6+UDP KHÔNG nén, (b) nén bằng IPHC còn ~6 byte. Khi nào cần phân mảnh? → Không gian sau MAC = $127-25=\textbf{102}$ byte.

• (a) IPv6 (40) + UDP (8) = 48 byte overhead → payload = $102-48=\textbf{54}$ byte.
• (b) IPHC nén IPv6+UDP còn ~6 byte → payload = $102-6=\textbf{96}$ byte (gần gấp đôi → đó là lý do 6LoWPAN nén header).
• Phân mảnh (fragmentation): khi gói IPv6 cần gửi lớn hơn payload 1 khung (IPv6 yêu cầu MTU tối thiểu 1280 byte ≫ 102) → lớp thích ứng 6LoWPAN cắt thành nhiều mảnh, dùng fragment header để tái lắp ở đầu nhận.