Ôn tập IoT (NT532 — Công nghệ Internet of Things hiện đại)

Tài liệu ôn tập chi tiết từ đầu cho bạn đã nghỉ hết buổi học. Tổng hợp từ lessions/ (slide giáo viên), theory/, research/NT532.md và 278 câu trong library-questions.md. Đề thi theo kịch bản (scenario-based), ~70–77% xoay quanh Edge vs Cloud (đặt tính toán ở đâu). Đề: 111 câu (101 thiết kế + 10) + phần tự luận (ZigBee/OLSR/AODV).

Mục lục

1. Bức tranh tổng thể IoT
2. Edge vs Cloud — TRỌNG TÂM SỐ 1
3. Vi điều khiển, cảm biến, năng lượng
4. Gửi dữ liệu lên nền tảng (ThingSpeak)
5. Giao thức Internet: HTTP & CoAP
6. Bluetooth LE
7. Raspberry Pi làm Gateway
8. MQTT & định dạng dữ liệu
9. LoRaWAN
10. Dashboard
11. Node-RED / tích hợp theo luật
12. Voice control (nhẹ)
13. Raspberry Pi Edge device
14. Từ Prototype tới sản phẩm
15. Bảo mật IoT
16. Phần TỰ LUẬN: ZigBee / OLSR / AODV / 6LoWPAN / Kiến trúc
17. Chiến lược làm bài

---

1. Bức tranh tổng thể IoT

IoT (Internet of Things) là mạng các thiết bị vật lý gắn cảm biến (đọc môi trường) và bộ chấp hành/actuator (tác động trở lại), kết nối Internet để thu thập và trao đổi dữ liệu.

Đường đi dữ liệu (data pipeline) chuẩn:

Cảm biến → (MCU) Thiết bị → Gateway → Cloud → Ứng dụng/Dashboard
   thu thập → chuẩn hóa → truyền → lưu trữ → kiểm tra chất lượng → hiển thị/hành động

Năm bước cốt lõi: collect (thu thập) → normalize (chuẩn hóa) → transmit (truyền) → store (lưu) → check quality (kiểm tra chất lượng).

Ý tưởng lớn xuyên suốt môn học: "Đặt tính toán ở đâu?" — trên thiết bị (Device Edge/TinyML), trên gateway/biên khu vực, hay trên cloud trung tâm. Mỗi lựa chọn đánh đổi giữa: độ trễ, băng thông, năng lượng, quyền riêng tư, chi phí.

---

2. Edge vs Cloud — TRỌNG TÂM SỐ 1

Đây là phần quan trọng nhất: khoảng 3 trong 4 câu hỏi đều là kịch bản "nên xử lý ở biên hay trên cloud?". Học thuộc bảng đánh đổi dưới đây.

Edge computing (Điện toán biên)

Xử lý dữ liệu ngay tại hoặc gần thiết bị, không gửi hết lên cloud.

Ưu điểm:

• Độ trễ rất thấp — phản hồi tức thời (xe tự lái, robot, AR/VR, dây chuyền sản xuất).
• Tiết kiệm băng thông — chỉ gửi kết quả/dữ liệu đã lọc thay vì dữ liệu thô.
• Quyền riêng tư — dữ liệu nhạy cảm (camera, giọng nói, y tế) xử lý cục bộ, không rời thiết bị.
• Hoạt động khi mất mạng (offline) — không phụ thuộc kết nối Internet.

Nhược điểm:

• Tài nguyên hạn chế (CPU, RAM, pin) → không chạy được mô hình AI lớn.
• Khó cập nhật/quản lý hàng loạt thiết bị.

Cloud computing

Xử lý và lưu trữ tập trung trên máy chủ từ xa.

Ưu điểm:

• Lưu trữ & tính toán lớn — phân tích dữ liệu lịch sử, dài hạn.
• Huấn luyện AI nặng, tổng hợp dữ liệu từ nhiều nguồn.
• Dễ mở rộng, dễ cập nhật phần mềm tập trung.

Nhược điểm:

• Độ trễ cao (dữ liệu đi xa và về).
• Tốn băng thông & chi phí truyền dữ liệu.
• Phụ thuộc kết nối — mất mạng là ngừng.
• Rủi ro riêng tư (dữ liệu rời khỏi thiết bị).

Edge-Cloud Continuum (Phổ liên tục)

Không phải "hoặc edge hoặc cloud" mà là phổ: Thiết bị (device edge) → Gateway/biên khu vực → Cloud trung tâm. Thiết kế tốt = chia tác vụ đúng tầng. Ví dụ kinh điển: loa thông minh → phát hiện "wake-word" bằng TinyML trên thiết bị (nhanh, riêng tư), rồi đẩy câu hỏi phức tạp (NLP, tìm kiếm) lên cloud.

Quy tắc quyết định (nhớ để chọn đáp án nhanh)

TinyML: chạy mô hình ML rất nhỏ trực tiếp trên MCU — cho phép "thông minh" ngay tại biên với pin thấp.

---

3. Vi điều khiển, cảm biến, năng lượng

(Nhóm câu nhiều nhất ~67 câu.)

MCU (Microcontroller): chip nhỏ tích hợp CPU + bộ nhớ + ngoại vi. Phần cứng môn học: ESP8266 (có WiFi), nRF52840 (có BLE). Khác máy tính: rất ít RAM/flash, chạy 1 chương trình, cực tiết kiệm điện.

I/O:

• Digital I/O (GPIO): chân vào/ra mức 0/1 (nút nhấn, LED).
• Analog: đọc giá trị liên tục qua ADC (cảm biến nhiệt/ánh sáng analog).
• PWM (Pulse Width Modulation): bật/tắt nhanh để giả lập mức analog — chỉnh độ sáng LED, tốc độ motor, góc servo.

Cảm biến vs Bộ chấp hành: cảm biến đọc (DHT11 đo nhiệt/ẩm, PIR phát hiện người, ánh sáng); actuator tác động (relay, motor, van, LED, còi).

Quản lý năng lượng (RẤT HAY THI)

Thiết bị IoT thường chạy pin → phải tiết kiệm điện tối đa.

• Radio (WiFi/BLE/LoRa) là bộ phận tốn pin nhất. Quy tắc vàng: tắt radio khi không dùng.
• Sleep mode: cho MCU "ngủ" giữa các lần làm việc, chỉ thức dậy khi cần (timer hoặc ngắt).
• Duty cycling: chỉ hoạt động một tỉ lệ nhỏ thời gian. Vd đo & gửi mỗi 1 giờ rồi ngủ.
• Giảm tần suất gửi: gửi định kỳ thay vì liên tục → kéo dài pin & tiết kiệm băng thông.
• Giảm độ phân giải / lọc tại biên: gửi ít byte hơn.

Câu hỏi mẫu lặp lại: "Vì sao thiết bị dùng pin gửi dữ liệu định kỳ thay vì liên tục?" → Để tắt radio giữa các lần gửi, kéo dài tuổi thọ pin.

State machine với millis(): thay vì delay() (chặn CPU), dùng millis() để lập trình không chặn (non-blocking) — làm nhiều việc "song song" và cho phép ngủ.

---

4. Gửi dữ liệu lên nền tảng

ThingSpeak: nền tảng cloud lưu & vẽ biểu đồ dữ liệu cảm biến.

• Tổ chức theo Channel (kênh) chứa nhiều Field (trường dữ liệu).
• Thiết bị kết nối WiFi rồi HTTP(S) đẩy dữ liệu lên.
• Bảo mật khi gửi: dùng TLS/secure client, CA certificate hoặc fingerprint để xác thực máy chủ.
• NTP: đồng bộ thời gian thực để gắn timestamp chính xác.

---

5. Giao thức Internet: HTTP & CoAP

Giao thức tầng ứng dụng, hai mô hình giao tiếp cần phân biệt rõ:

HTTP (HyperText Transfer Protocol) — mô hình Request/Response:

• Client gửi yêu cầu (GET đọc, POST gửi), server trả lời.
• Nền tảng của REST API (tài nguyên định danh bằng URL).
• Có thể chạy web server ngay trên thiết bị; bảo vệ bằng Basic Auth, HTTPS.
• Nhược: nặng (chạy trên TCP, header dài) → tốn pin/băng thông cho thiết bị yếu.

CoAP (Constrained Application Protocol) — "HTTP nhẹ cho thiết bị hạn chế":

• Chạy trên UDP (nhẹ hơn TCP), header nhỏ.
• Vẫn theo kiểu request/response (GET/POST/PUT/DELETE) + hỗ trợ Observe (theo dõi thay đổi).
• Vì sao ưu tiên CoAP hơn HTTP cho thiết bị IoT yếu? → nhẹ, ít tốn tài nguyên, hợp thiết bị hạn chế năng lượng/băng thông.

Request/Response vs Publish/Subscribe: HTTP/CoAP là hỏi-đáp 1-1; MQTT (mục 8) là pub/sub nhiều-nhiều.

---

6. Bluetooth LE

BLE (Bluetooth Low Energy): kết nối không dây tầm ngắn, cực ít pin — lý tưởng cho thiết bị đeo, cảm biến cục bộ.

Vai trò (roles):

• Peripheral: thiết bị quảng bá & cung cấp dữ liệu (vd vòng đo nhịp tim, cảm biến). Bị động chờ kết nối.
• Central: thiết bị quét & kết nối tới peripheral để thu thập (vd điện thoại, Raspberry Pi).
• Broadcaster/Beacon: chỉ phát quảng cáo (advertising) một chiều, không kết nối (vd iBeacon định vị).
• Observer: chỉ lắng nghe quảng cáo.

GATT (Generic Attribute Profile) — cấu trúc dữ liệu BLE:

• Service (dịch vụ) chứa nhiều Characteristic (đặc tính).
• Mỗi characteristic có thể Read / Write / Notify (thông báo khi thay đổi).
• Ví dụ chuẩn: HRM (Heart Rate Measurement), UART service (truyền nối tiếp qua BLE).

Advertising: peripheral phát gói quảng cáo để central phát hiện.

Khi nào chọn BLE? Khoảng cách ngắn (vài mét–chục mét), cần pin lâu, truyền ít dữ liệu, kết nối cục bộ điện thoại/gateway.

---

7. Raspberry Pi làm Gateway

Gateway (cổng): thiết bị trung gian cầu nối thiết bị cục bộ (BLE) ↔ Internet/cloud. Raspberry Pi (chạy Linux đầy đủ) rất hợp vai này.

• Chạy Node.js services để thu dữ liệu BLE rồi đẩy lên cloud.
• systemd service (vd my.service): chạy nền, tự khởi động cùng máy, tự restart khi lỗi → đảm bảo gateway luôn hoạt động.
• Các mẫu thiết kế: remote sensing (đọc cảm biến từ xa), remote control (điều khiển từ xa), device discovery (dò thiết bị), web service / secure web service.

Gateway vs Edge device: gateway chủ yếu chuyển tiếp/cầu nối dữ liệu; edge device (mục 13) còn tự xử lý/tính toán trên dữ liệu.

---

8. MQTT & định dạng dữ liệu

MQTT (Message Queuing Telemetry Transport) — giao thức nhắn tin theo mô hình Publish/Subscribe:

• Broker: máy chủ trung tâm. Thiết bị publish tin lên một Topic; các bên subscribe topic đó để nhận.
• Tách rời người gửi & người nhận → nhiều-nhiều: một luồng dữ liệu cảm biến có thể đồng thời được dashboard + bộ lưu trữ + hệ cảnh báo tiêu thụ.
• Topic phân cấp, vd home/livingroom/temp.
• QoS (Quality of Service):
  • 0 — gửi nhiều nhất 1 lần (có thể mất, nhẹ nhất).
  • 1 — ít nhất 1 lần (có thể trùng).
  • 2 — đúng 1 lần (chắc chắn nhất, nặng nhất).

MQTT vs HTTP: HTTP hỏi-đáp 1-1, phải poll liên tục; MQTT đẩy realtime, hiệu quả cho nhiều thiết bị/nhiều người tiêu thụ.

Định dạng dữ liệu — JSON: text key-value dễ đọc, phổ biến cho payload IoT, vd {"temp":25.3,"hum":60}.

Câu hỏi mẫu: "Một luồng cảm biến cần đồng thời cho dashboard, lưu trữ và cảnh báo dùng — chọn giao thức nào?" → MQTT (pub/sub).

---

9. LoRaWAN

LoRa: kỹ thuật điều chế ở lớp vật lý (chirp spread spectrum) truyền rất xa (vài km, kể cả vùng nông thôn). LoRaWAN: giao thức mạng phía trên LoRa.

Đặc tính: tầm xa, băng thông cực thấp, pin nhiều năm — đối lập với WiFi (gần, băng thông cao, tốn pin).

Khái niệm cần nhớ:

• OTAA vs ABP (cách kích hoạt thiết bị vào mạng):
  • OTAA (Over-The-Air Activation): trao khóa động khi join → an toàn hơn, nên dùng.
  • ABP (Activation By Personalization): gán sẵn khóa cố định → đơn giản nhưng kém an toàn.
• Spreading Factor (SF): SF cao → truyền xa hơn, chống nhiễu tốt hơn nhưng chậm hơn, tốn pin & chiếm sóng lâu hơn. SF thấp → ngược lại.
• Duty cycle: quy định giới hạn % thời gian được phát sóng (tuân thủ luật băng tần).
• TTN (The Things Network): hạ tầng LoRaWAN cộng đồng miễn phí.

Khi nào chọn LoRaWAN? Cần phủ xa hàng km, gửi ít dữ liệu (vd vài byte cảm biến/giờ), thiết bị chạy pin nhiều năm, không cần băng thông cao. Không dùng cho video/ảnh/streaming.

So sánh nhanh kết nối:

---

10. Dashboard

Trực quan hóa dữ liệu cảm biến: biểu đồ, widget, bảng.

• Dữ liệu chảy vào time-series database (vd InfluxDB, thu thập qua Telegraf).
• Adapter/glue: nối nguồn này sang nguồn khác, vd TTN → ThingSpeak; dùng serverless function làm logic kết dính.
• Chất lượng pipeline: phát hiện dữ liệu thiếu/sai, lấy mẫu đúng tần suất.

---

11. Node-RED / tích hợp theo luật

Node-RED: công cụ lập trình luồng trực quan (kéo-thả node) để tích hợp thiết bị/dịch vụ theo luật.

• Rule-based automation: "nếu nhiệt độ > X → gửi cảnh báo / bật quạt".
• Kích hoạt theo MQTT (nhận tin từ topic rồi xử lý).
• Đặt ngưỡng (threshold) và gửi thông báo (notification).
• Dùng cho kịch bản tự động hóa/cảnh báo trong đề.

---

12. Voice control (nhẹ)

Alexa skills / trợ lý giọng nói: ánh xạ lệnh nói → intent → hành động thiết bị qua cloud. Phần này gần như không xuất hiện trong đề — chỉ cần nhận diện từ khóa, không cần học sâu.

---

13. Raspberry Pi Edge device

Pi không chỉ làm gateway mà còn tự xử lý tại biên (edge compute):

• Python GPIO: blink LED, đọc nút, rotary encoder, hiển thị TM1637, đọc analog, điều khiển RGB LED.
• Camera: chụp ảnh/quay video và xử lý tại chỗ (vd nhận diện) → giữ riêng tư, giảm băng thông.

---

14. Từ Prototype tới sản phẩm

Productization — đưa bản mẫu breadboard thành sản phẩm bán được:

• Vỏ hộp / thiết kế 3D bằng OpenSCAD (mô hình 3D bằng code).
• Lo về độ tin cậy, khả năng sản xuất hàng loạt (manufacturability), mở rộng quy mô, vòng đời sản phẩm (lifecycle).

---

15. Bảo mật IoT

• TLS/SSL: mã hóa kênh truyền (HTTPS, MQTT over TLS).
• CA certificate / fingerprint: thiết bị xác thực đúng máy chủ, chống Man-in-the-Middle.
• Authentication: Basic Auth, token/API key để chỉ bên hợp lệ truy cập.
• Riêng tư = lý do chọn Edge: xử lý dữ liệu nhạy cảm cục bộ thay vì gửi ảnh/giọng nói thô lên cloud.
• Nguyên tắc: chỉ gửi dữ liệu cần thiết, mã hóa khi truyền, xác thực hai chiều.

---

16. Phần TỰ LUẬN

Nguồn: research/NT532.md. Luyện kỹ 3 bài toán ZigBee addressing, OLSR, AODV.

Đặt vấn đề chung: cả ba đều xử lý bài toán "làm sao một gói tin đi từ nút A tới nút B trong mạng nhiều nút?". Khác nhau ở cách tìm/định tuyến: ZigBee dùng địa chỉ theo cây (định tuyến suy ra từ địa chỉ, không cần dò đường); OLSR chủ động dựng sẵn bảng định tuyến cho cả mạng; AODV phản ứng, chỉ đi dò đường khi thật sự cần gửi.

16.1 ZigBee (IEEE 802.15.4) — Gán địa chỉ phân tán (Cskip)

Hiểu bản chất trước

ZigBee là chuẩn mạng không dây tầm ngắn, công suất thấp, dùng cho cảm biến/nhà thông minh, xây trên lớp vật lý IEEE 802.15.4 (cùng họ với 6LoWPAN). Mạng ZigBee dạng cây (tree) gồm 3 loại nút:

• Coordinator (1 nút duy nhất): gốc của cây, khởi tạo mạng, luôn ở địa chỉ 0.
• Router: nút trung gian, vừa có con vừa chuyển tiếp gói cho nút khác.
• End-device: nút lá (thường là cảm biến chạy pin), chỉ nối vào 1 cha, không có con và không chuyển tiếp.

Vì sao cần "gán địa chỉ phân tán"? Trong mạng lớn, nếu mỗi lần định tuyến phải dò đường thì tốn năng lượng. ZigBee dùng mẹo: gán địa chỉ theo cấu trúc cây sao cho chỉ nhìn địa chỉ đích là biết phải đẩy gói lên cha hay xuống nhánh con nào — không cần bảng định tuyến. Muốn vậy, mỗi nút cha phải biết "mỗi nhánh con của mình chiếm bao nhiêu địa chỉ" để chia khoảng địa chỉ không chồng nhau.

Ý nghĩa $A(d)$: đó chính là kích thước khối địa chỉ mà một cây con gốc ở độ sâu $d$ chiếm (gồm chính nó + toàn bộ con cháu). Tính từ dưới lên (đáy cây ra trước) vì khối của cha = chính nó + (số router con × khối mỗi cây con) + (số end-device con).

• $1$ = chính nút đó.
• $D_m$ = chỗ cho các end-device con (mỗi cái 1 địa chỉ, không có con cháu).
• $R_m \times A(d{+}1)$ = mỗi router con kéo theo cả một cây con kích thước $A(d{+}1)$.

Hiểu được 3 thành phần này thì công thức bên dưới chỉ là viết lại bằng ký hiệu.

Công thức

Tham số: $R_m$ = số router tối đa mỗi nút; $D_m$ = số end-device tối đa mỗi nút; $L_m$ = độ sâu tối đa của cây.

Kích thước dải địa chỉ tại độ sâu $d$:

• Nếu $d = L_m - 1$: $A(d) = 1 + D_m + R_m$
• Nếu $0 \le d < L_m - 1$: $A(d) = 1 + D_m + R_m \times A(d+1)$

Gán địa chỉ cho nút cha có địa chỉ $x$ ở độ sâu $d$:

• Router con thứ $i$ ($1 \le i \le R_m$): dải $[\,x + (i-1)\times A(d+1) + 1,\; x + i\times A(d+1)\,]$
• End-device con thứ $j$ ($1 \le j \le D_m$): địa chỉ $x + R_m \times A(d+1) + j$

Ví dụ $R_m=4, D_m=4, L_m=3$ (độ sâu 0,1,2):

• $A(2)=1+4+4=9$; $A(1)=1+4+4\times9=41$; $A(0)=1+4+4\times41=169$
• Coordinator $R(0)=[0,169]$:
  • Router con: $[1,41], [42,82], [83,123], [124,164]$
  • End-device con: $165, 166, 167, 168$
• Router tại $[1,41]$ (độ sâu 1):
  • Router con: $[2,10],[11,19],[20,28],[29,37]$; End-device: $38,39,40,41$
• Lặp lại đến khi gán hết.

Cách làm bài: tính $A(d)$ từ độ sâu lớn nhất xuống; rồi áp công thức gán theo từng nút cha từ gốc xuống.

Hình 16.1 — Coordinator giữ khối [0..169]; mỗi router con chiếm một khối con liền nhau, end-device là lá. Nhìn địa chỉ đích rơi vào khối nào → biết đẩy gói xuống nhánh đó.

16.2 OLSR (Optimized Link State Routing) — chủ động (proactive)

Hiểu bản chất trước

OLSR là giao thức định tuyến cho mạng ad-hoc (mạng tự tổ chức, không có hạ tầng cố định, các nút vừa là máy chủ vừa là router). Nó thuộc loại link-state (trạng thái liên kết): mỗi nút cố gắng biết "bản đồ" các liên kết trong mạng để tự tính đường ngắn nhất tới mọi đích.

"Chủ động (proactive)" nghĩa là gì? OLSR liên tục trao đổi thông tin và dựng sẵn bảng định tuyến tới mọi nút, ngay cả khi chưa cần gửi gì. Ưu: khi cần gửi là có đường ngay (độ trễ thấp). Nhược: tốn băng thông/năng lượng cho các bản tin điều khiển chạy nền — đối lập với AODV (reactive).

Vấn đề OLSR phải giải: trong link-state cổ điển, mỗi nút flooding (phát tràn) thông tin link ra toàn mạng → rất nhiều bản tin trùng lặp, tốn tài nguyên. OLSR tối ưu chỗ này bằng ý tưởng MPR.

MPR — ý tưởng cốt lõi (đây là điểm thi): thay vì mọi hàng xóm đều chuyển tiếp lại bản tin quảng bá, mỗi nút N chỉ chọn một nhóm nhỏ hàng xóm 1-hop làm "người chuyển tiếp được uỷ quyền". Nhóm này phải đủ để với tay tới được toàn bộ hàng xóm 2-hop của N. Chọn càng ít người chuyển tiếp càng tốt → giảm mạnh số bản tin trùng. Hình dung: bạn muốn loan tin cho cả khu phố (2-hop), nhưng chỉ nhờ vài người hàng xóm "loa to" (MPR) đi báo giúp, thay vì ai cũng đi báo.

Bốn khái niệm cần phân biệt rõ:

• NBR(N) — danh sách hàng xóm 1-hop của N (qua bản tin HELLO).
• MPR(N) (Multipoint Relay set): tập hàng xóm 1-hop của N được chọn để chuyển tiếp gói điều khiển của N phủ hết toàn bộ hàng xóm 2-hop. Chọn ít nút nhất mà vẫn phủ đủ 2-hop → giảm flooding.
• MS(N) (MPR Selector set): tập các nút nguồn (trong 1-hop) đã chọn N làm MPR để chuyển tiếp gói của họ. (Tức N nằm trong MPR của ai → người đó thuộc MS(N).)
• TC (Topology Control): chỉ nút MPR tạo & lan truyền, quảng bá link tới các MPR-selector; có sequence number chống dùng thông tin cũ.

Cách tìm MPR(N): liệt kê hàng xóm 1-hop và 2-hop của N → chọn tập con nhỏ nhất các hàng xóm 1-hop phủ hết 2-hop. Cách tìm MS(N): với mỗi hàng xóm M của N, kiểm tra N có thuộc MPR(M) không; nếu có thì M ∈ MS(N).

Hình 16.2 — N có 3 hàng xóm 1-hop {2,3,4} và 3 hàng xóm 2-hop {5,6,7}. Chỉ cần chọn {2,4} làm MPR là phủ hết 2-hop (5 qua 2, 7 qua 4, 6 đã được 2 phủ) → bỏ được node 3. Càng ít MPR càng ít gói lặp.

16.3 AODV (Ad hoc On-demand Distance Vector) — phản ứng (reactive)

Hiểu bản chất trước

AODV cũng là giao thức định tuyến cho mạng ad-hoc, nhưng triết lý ngược OLSR: "phản ứng (reactive) / theo yêu cầu (on-demand)" — không dựng sẵn bảng định tuyến; chỉ khi một nút thật sự cần gửi dữ liệu mà chưa biết đường thì mới đi dò đường. Ưu: tiết kiệm băng thông/năng lượng khi mạng ít lưu lượng (không có bản tin chạy nền). Nhược: gói dữ liệu đầu tiên bị trễ vì phải chờ dò xong đường.

"Distance Vector" nghĩa là gì? Mỗi nút chỉ cần biết "để tới đích X thì đẩy gói cho hàng xóm nào (next-hop) và cách bao nhiêu hop", không cần biết bản đồ toàn mạng (khác link-state của OLSR).

Cơ chế 2 bước: hỏi đường rồi nhận trả lời.

• RREQ (Route Request) = "tôi cần đường tới X, ai biết không?" → phát broadcast lan ra mạng.
• RREP (Route Reply) = "tôi biết đường tới X" → gửi unicast ngược lại theo dấu vết để báo về nguồn.
• Khi RREQ lan đi, mỗi nút trung gian ghi lại đường ngược (reverse route) về nguồn để sau này RREP biết đường quay lại.

Vì sao cần "sequence number" (số thứ tự)? Đây là chống route cũ/lặp vòng. Mỗi đích giữ một dest_sequence tăng dần; số càng lớn = thông tin đường càng "tươi" (mới). Khi có nhiều trả lời, nút chọn đường có dest_sequence lớn hơn (mới hơn); nếu bằng nhau thì chọn đường ít hop hơn. Nhờ vậy AODV tránh dùng nhầm đường đã hỏng và tránh vòng lặp.

Chi tiết cơ chế

Chỉ tìm đường khi cần (on-demand).

RREQ (Route Request):

• Nguồn cần gửi nhưng chưa có route → broadcast RREQ tới hàng xóm.
• Trường quan trọng: broadcast_id (tăng mỗi RREQ), source_addr/dest_addr, source_sequence (độ "tươi" của route ngược về nguồn), dest_sequence (độ tươi route tới đích).
• Nút nhận: nếu có route tới đích → trả RREP; nếu không → forward RREQ (tăng hop_cnt). Gói trùng (cùng broadcast_id) bị loại bỏ.

RREP (Route Reply):

• Nút có route hiện hành tới đích → unicast RREP ngược về nút đã gửi RREQ.
• Một RREP khác chỉ được chấp nhận nếu dest_sequence lớn hơn, hoặc bằng nhưng hop_cnt nhỏ hơn.

Ví dụ (nguồn 1 → đích 7, nút 6 biết route tới 7):

1. Nút 1 broadcast RREQ.
2. Nút 2 & 4 xác minh RREQ mới, không cũ → forward (cập nhật source_sequence, tăng hop_cnt).
3. RREQ tới nút 6 (biết route 7); nút 3 & 5 cũng forward nhưng bị nhận ra là trùng → loại.
4. Nút 6 unicast RREP về nút 4.
5. Nút 4 xác minh route mới (hoặc hop nhỏ hơn) → chuyển RREP về nút 1, tăng hop_cnt.
6. Nút 1 có route tới 7 (3 hop) → gửi dữ liệu. Gói dữ liệu đầu tiên bị trễ đến khi RREP đầu tiên về.

Hình 16.3 — Mũi tên xanh dương = RREQ phát tràn đi tìm đường; mũi tên xanh lá = RREP đi ngược về theo "đường ngược" đã ghi; nét đứt xám = RREQ trùng bị loại. Đường chốt: 1→4→6→7.

So sánh nhanh OLSR vs AODV (hay hỏi)

16.4 6LoWPAN

IPv6 over Low-power Wireless Personal Area Networks: cho phép IPv6 chạy trên 802.15.4 (mạng công suất thấp). Nén header IPv6 để vừa khung nhỏ. (Tài liệu gốc: Lecture 3.)

Hình 16.4 — Khung 802.15.4 chỉ 127 byte. Header IPv6+UDP không nén ngốn 48 byte, chỉ còn ~54 byte payload; sau khi nén IPHC còn ~6 byte → payload tăng lên ~96 byte. Gói lớn hơn 1 khung thì phải phân mảnh.

16.5 Kiến trúc / Topology mạng cảm biến

Các topo thường gặp: tree (cây), cluster (cụm), grid (lưới), chain (chuỗi), và Clustered Tributaries-Deltas (tiết kiệm năng lượng + bảo mật). So sánh theo: tiêu thụ năng lượng, độ trễ, khả năng mở rộng, độ bền khi 1 nút chết.

Hình 16.5 — Tree phân cấp (mất nhánh nếu nút cha chết); Cluster gom dữ liệu qua cluster-head (tiết kiệm năng lượng); Grid nhiều đường dự phòng (bền, dễ mở rộng); Chain truyền nối tiếp (đứt 1 mắt là gãy).

---

17. Chiến lược làm bài

1. Ưu tiên ôn: L1 Edge/Cloud + L2 MCU/năng lượng (cao nhất) → L5 BLE + L6 Pi Gateway → L9 Dashboard + L10 Node-RED → L7 MQTT, L8 LoRaWAN, bảo mật → nhẹ: L4 HTTP/CoAP, L13. Bỏ qua L11 Voice.
2. Với câu kịch bản: xác định yêu cầu cốt lõi (độ trễ? riêng tư? offline? pin? băng thông?) → áp bảng quyết định Edge/Cloud ở mục 2.
3. Bẫy thường gặp: "Cả A và B đều đúng" — đọc kỹ từng phương án; nếu một phương án sai thì "cả A và B" cũng sai. Phản hồi tức thời/riêng tư/offline luôn nghiêng về Edge; lịch sử lớn/AI nặng nghiêng về Cloud.
4. Tiết kiệm pin: mặc định chọn đáp án có "ngủ/tắt radio/giảm tần suất".
5. Phần tự luận: luyện trước 1 bài ZigBee + 1 bài OLSR (MPR/MS) + 1 bài AODV (RREQ/RREP) theo đúng các bước ở mục 16.

Xem thêm: library-questions.md (278 câu có đáp án) và doc-for-exam.md (tờ ghi nhớ 2 mặt A4).