ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN

KHOA ĐIỆN TỬ - VIỄN THÔNG
BỘ MÔN MÁY TÍNH - HỆ THỐNG NHÚNG


KHƯU MINH HUỆ

LƯƠNG HOÀNG DUY
ĐINH THẾ SANG
VĂN NGỌC THIỆN

Đề tài:

HỆ THỐNG BÁO CHÁY SỬ DỤNG CÔNG NGHỆ

BLUETOOTH LOW ENERGY MESH

Chuyên ngành Máy Tính - Hệ Thống Nhúng

TP. Hồ Chí Minh, tháng 7 năm 2019

1
 ĐẠI HỌC QUỐC GIA THÀNH PHỐ HỒ CHÍ MINH
TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN
KHOA ĐIỆN TỬ - VIỄN THÔNG
BỘ MÔN MÁY TÍNH - HỆ THỐNG NHÚNG


KHƯU MINH HUỆ - 1520067

LƯƠNG HOÀNG DUY - 1520026
ĐINH THẾ SANG -1520157
VĂN NGỌC THIỆN-1520185

Đề tài:

HỆ THỐNG BÁO CHÁY SỬ DỤNG CÔNG NGHỆ

BLUETOOTH LOW ENERGY MESH

NGƯỜI HƯỚNG DẪN KHOA HỌC

TS. Huỳnh Hữu Thuận

TP. Hồ Chí Minh, tháng 7 năm 2019

2
LỜI CẢM ƠN
Lời nói đầu, nhóm chúng em xin gửi lời cảm ơn sâu sắc đến Tiến Sĩ
Huỳnh Hữu Thuận. Thầy đã dành trọn tâm huyết dạy dỗ cho thế hệ sinh viên chúng em
được vững bước trên con đường sự nghiệp. Chính nhờ sự tận tâm hướng dẫn, cùng
những lời nhắc nhở động viên của Thầy mà nhóm chúng em đã hoàn thành tốt khóa
luận tốt nghiệp này.
Nhóm chúng em cũng xin gửi lời tri ân đến toàn thể Quý Thầy Cô trong khoa
Điện tử - Viễn thông trường Đại học Khoa học Tự Nhiên - ĐHQG TP HCM, cám ơn
Quý Thầy Cô đã không ngại khó nhọc từng ngày để truyền dạy cho chúng em những
bài học vô giá.
Và chúng em vô cùng biết ơn cha mẹ đã âm thầm hy sinh để tạo điều kiện tốt
nhất cho chúng em yên tâm học tập. Cha mẹ đã luôn là chỗ dựa tinh thần, là nguồn
động lực giúp cho chúng em đứng dậy sau mỗi lần vấp ngã.
Cuối cùng, nhóm xin được cám ơn tất cả bạn bè anh chị trong khoa Điện tử -
Viễn thông, đặc biệt là các anh và những người bạn trong phòng thí nghiệm chuyên đề
Máy tính - Hệ Thống Nhúng (CESLAB). Các anh và các bạn đã nhiệt tình hỗ trợ nhóm
để hoàn thành khóa luận tốt nghiệp này.
TP. Hồ Chí Minh, tháng 7 năm 2019

i
TÓM TẮT KHOÁ LUẬN
Khoá luận của nhóm tập trung vào việc triển khai một hệ thống báo cháy không
dây sử dụng công nghệ Bluetooth Low Energy Mesh. Sau quá trình triển khai, nhóm đã
đạt được một số tiêu chí đề ra trong lúc thiết kế, bao gồm:
+ Kiến trúc mạng phân tầng, với chức năng mỗi tầng được tách biệt riêng
với nhau, phục vụ cho việc dễ dàng sửa chữa, phần mềm mới được cập nhật
thông qua cơ chế OTA.
+ Dòng tiêu thụ của thiết bị quản lý cảm biến rơi vào khoảng 30 µA, với
thời gian sử dụng nguồn pin CR2032 lên đến 10 tháng, đồng thời có thể báo cáo
dung lượng pin còn lại cho người dùng.
+ Tín hiệu báo cháy được truyền đi tức thời, nhận biết thiết bị hư hỏng
chỉ trong vòng 1 phút.
+ Dữ liệu người dùng được mã hoá đến 2 lớp khi truyền đi.
+ Có ứng dụng với giao diện trực quan trên Smartphone để cấu hình các
thiết bị và giám sát hoạt động của hệ thống.
Sơ đồ tổng quan của hệ thống:

ii
MỤC LỤC
1. Bluetooth Low Energy........................................................................1
1.1. Giới thiệu....................................................................................................1
1.1.1. Lịch sử ra đời.................................................................................................1
1.1.2. Tính tương thích............................................................................................2
1.1.3. Cấu hình phần cứng......................................................................................3
1.1.4. Tốc độ truyền dữ liệu....................................................................................4
1.1.5. Khoảng cách hoạt động................................................................................5
1.1.6. Mô hình mạng................................................................................................6
1.1.7. Cấu trúc gói tin..............................................................................................7
1.2. Các tầng giao thức mạng...........................................................................8
1.2.1. Tổng quan......................................................................................................8
1.2.2. Tầng vật lý (Physical Layer)........................................................................9
1.2.3. Tầng liên kết (Link Layer)...........................................................................9
1.2.4. Giao thức Host Controller (HCI)...............................................................10
1.2.5. Giao thức L2CAP........................................................................................10
1.2.6. Giao thức ATT (Attribute Protocol)..........................................................10
1.2.7. Quản lý bảo mật (Security Manager)........................................................13
1.2.8. Generic Access Profile (GAP)....................................................................15
1.2.9. Generic Attribute Profile (GATT).............................................................15
1.3. Advertising và Connection......................................................................15
1.3.1. Chế độ Advertising......................................................................................15
1.3.2. Chế độ Connection......................................................................................18
1.4. GATT Service và Characteristic............................................................20
2. Bluetooth Low Energy Mesh............................................................22
2.1. Giới thiệu..................................................................................................22
2.2. Các khái niệm chính................................................................................23
2.2.1. Device và Node.............................................................................................23
2.2.2. Element.........................................................................................................23

iii
 2.2.3. Trạng thái và trạng thái có liên kết...........................................................24
2.2.4. Tin nhắn truyền trong mạng......................................................................25
2.2.5. Địa chỉ các Node..........................................................................................27
2.2.6. Relay Node...................................................................................................28
2.2.7. Proxy Node...................................................................................................28
2.2.8. Friend Node.................................................................................................28
2.2.9. Low Power Node (LPN)..............................................................................29
2.2.10. Model..........................................................................................................29
2.3. Các tầng giao thức mạng.........................................................................33
2.3.1. Tổng quan....................................................................................................33
2.3.2. Tầng mang (Bearer Layer).........................................................................34
2.3.3. Tầng mạng (Network Layer)......................................................................35
2.3.4. Tầng giao vận dưới (Lower Transport Layer).........................................36
2.3.5. Tầng giao vận trên (Upper Transport Layer)..........................................37
2.3.6. Tầng truy cập (Access Layer)....................................................................38
2.3.7. Tầng thiết lập mô hình (Foundation Model Layer).................................38
2.3.8. Tầng mô hình (Model Layer).....................................................................39
2.4. Cơ chế Publish - Subcribe.......................................................................39
2.5. Quá trình Provisioning............................................................................40
2.6. Generic Level Model................................................................................42
2.7. Kết nối LPN - Friend...............................................................................42
2.8. Bảo mật trong mạng BLE Mesh.............................................................44
2.8.1. Tổng quan....................................................................................................44
2.8.2. Key bảo mật.................................................................................................45
2.8.3. Quá trình Remove Node, Key Refesh........................................................46
3. Giới thiệu về Radio Board BRD4104A............................................47
3.1. Tổng quan.................................................................................................47
3.2. Wireless MCU..........................................................................................48
3.2.1. Các thông số chính......................................................................................48
3.2.2. Chế độ Deep Sleep.......................................................................................48
iv
 3.2.3. Bộ Crypto tích hợp......................................................................................49
3.2.4. Gecko Bootloader........................................................................................50
3.3. Bluetooth Mesh SDK...............................................................................51
4. Hệ thống báo cháy sử dụng công nghệ BLE Mesh.........................52
4.1. Giới thiệu..................................................................................................52
4.2. Tính năng chính của hệ thống................................................................54
4.3. Kiến trúc mạng triển khai.......................................................................57
4.4. Năng lượng tiêu thụ của mạng................................................................58
4.5. Cơ chế truyền gói tin trong mạng...........................................................59
4.6. Lưu lượng gói tin trong mạng.................................................................60
4.7. Độ trễ tín hiệu...........................................................................................61
5. Gateway Node....................................................................................62
5.1. Tính năng chính.......................................................................................62
5.2. Sơ đồ hoạt động........................................................................................62
5.3. Xử lý gói tin từ Friend Node...................................................................67
5.4. Advertising gói tin BLE...........................................................................68
5.5. Kiểm tra tình trạng các Friend Node.....................................................70
5.6. Gateway Node dự phòng.........................................................................71
6. Ứng dụng trên Smart Phone............................................................72
6.1. Tổng quan.................................................................................................72
6.2. Thay đổi giao diện người dùng...............................................................74
6.3. Quá trình Provisioning và cấu hình:......................................................75
6.3.1. Sơ đồ khối thực hiện....................................................................................75
6.3.2. Thêm Network.............................................................................................76
6.3.3. Thêm Group................................................................................................76
6.3.4. Tìm kiếm thiết bị cần Provisioning............................................................77
6.3.5. Thực hiện quá trình Provisioning..............................................................78
6.3.6. Quá trình cấu hình Node............................................................................79
6.4. Scan gói tin BLE......................................................................................81
v
 6.5. Giải mã AES.............................................................................................82
6.6. Hiển thị dữ liệu trên ứng dụng...............................................................83
7. Friend Node.......................................................................................85
7.1. Tính năng chính.......................................................................................85
7.2. Sơ đồ hoạt động........................................................................................85
5.3. Xử lí gói tin từ LPN.................................................................................90
5.4. Kiểm tra tình trạng LPN.........................................................................91
5.5. Kiểm tra tình trạng Gateway Node........................................................91
5.6. Trao đổi dữ liệu với Gateway Node.......................................................91
8. Low Power Node...............................................................................92
8.1. Tính năng chính.......................................................................................92
8.2. Sơ đồ hoạt động........................................................................................92
6.3. Trao đổi dữ liệu với Friend Node...........................................................95
6.4. Năng lượng tiêu thụ.................................................................................96
6.5. Báo cáo dung lượng pin...........................................................................97
6.6. Cảm biến nhận biết khói.......................................................................100
9. Cập nhật Firmware thông qua OTA............................................101
9.1. Sự cần thiết của việc cập nhật Firmware............................................101
9.2. Quá trình cập nhật Firmware thông qua OTA...................................101
10. Kết luận..........................................................................................107
10.1. Kết quả đạt được..................................................................................107
10.2. Kết luận.................................................................................................109
10.3. Hướng phát triển.................................................................................109
11. Tài liệu tham khảo........................................................................110

vi
DANH SÁCH CHỮ VIẾT TẮT
STT Kí hiệu viết tắt Nội dung viết tắt

1 ACK Acknowledgement
2 AFH Adaptive Frequency Hopping Spread Spectrum
3 AES Advanced Encryption Standard
4 AD Advertising Data
5 AKF Application Key Flag
6 AID Application Key Identifier
7 ALU Arithmetic Logic Unit
8 ATT Attribute Protocol
9 BR Basic Rate
10 BLE Bluetooth Low Energy
11 CPU Central Processing Unit
12 CRC Cyclic Redundancy Check
13 DST Destination Address
14 DFU Device Firmware Update
15 EDR Enhanced Data Rate
16 FPU Floating Point Unit
17 HCI Host Controller Interface
18 ISM Industrial Scientific Medical
19 IC Integrated Circuit
20 IOT Internet of Things
21 IP Internet Protocol
22 IVI IV Index
23 LBS Least Significant Bit
24 L2CAP Logical Link Control and Adaptation Protocol
25 LTE Long Term Evolution

vii
26 LPN Low Power Node
27 MAC Media Access Control
28 MCU Microprocessor Control Unit
29 CTL Network Control
30 NID Network Key Identifier
31 NetMIC Network Message Integrity Check
32 PCB Printed Circuit Board
33 RF Radio Frequency
34 RTCC Real Time Calendar/Clock
35 SHA Secure Hash Algorithm
36 SMP Security Manager Protocol
37 SEQ Sequence Number
38 SDIO Serial Data Input/Output
39 SRC Source Address
40 SIG Special Interest Group
41 SoC System on Chip
42 TTL Time-To-Live
43 UART Universal Asynchronous Receiver – Transmitter
44 USB Universal Serial Bus
45 UUID Universally Unique Identifier

viii
DANH SÁCH HÌNH
Hình 1.1. Tính tương thích giữa các thiết bị Bluetooth...................................................2
Hình 1.2. Cấu hình phần cứng các thiết bị BLE..............................................................4
Hình 1.3. Mô hình mạng ở chế độ Advertising...............................................................6
Hình 1.4. Mô hình mạng ở chế độ Connection................................................................7
Hình 1.5. Cấu trúc gói tin BLE........................................................................................8
Hình 1.6. Các tầng giao thức mạng của BLE...................................................................8
Hình 1.7. Tần số các kênh giao tiếp sóng RF..................................................................9
Hình 1.8. Giao thức Attribute........................................................................................11
Hình 1.9. Các thủ tục trao đổi khoá ở chế độ Connection.............................................14
Hình 1.10. Cấu trúc gói tin Advertising.........................................................................16
Hình 1.11. Quá trình Advertising và Scanning dữ liệu..................................................16
Hình 1.12. Quá trình Active và Passive Scanning.........................................................17
Hình 1.13. Các loại gói tin Advertising.........................................................................18
Hình 1.14. Quá trình hoạt động ở chế độ Connection...................................................19
Hình 1.15. Cấu trúc gói tin Connection.........................................................................20
Hình 1.16. Cấu trúc dữ liệu trên GATT Server.............................................................21
Hình 2.1. Mô hình mạng BLE Mesh..............................................................................22
Hình 2.2. Các phần tử trong một Node..........................................................................24
Hình 2.3. Ví dụ về trạng thái trong một Node...............................................................24
Hình 2.4. Giao tiếp giữa Server Model và Client Model...............................................30
Hình 2.5. Hoạt động của Control Model........................................................................30
Hình 2.6. Các Model bên trong một Node.....................................................................32
Hình 2.7. Các tầng giao thức mạng của BLE Mesh.......................................................33
Hình 2.8. Định dạng Network PDU...............................................................................36
Hình 2.9. Định dạng Lower Transport PDU..................................................................37
Hình 2.10. Định dạng Upper Transport PDU................................................................37
Hình 2.11. Ví dụ về Composition Data..........................................................................39
Hình 2.12. Cơ chế Publish - Subcribe............................................................................40
Hình 2.13. Quá trình Provisioning cho thiết bị..............................................................40
Hình 2.14. Các giao thức thực hiện trong quá trình Provisioning.................................42
ix
Hình 2.15. Quá trình thành lập kết nối Friendship........................................................43
Hình 2.16. Quá trình huỷ bỏ kết nối Friendship............................................................44
Hình 2.17. Các giai đoạn làm mới khoá........................................................................46
Hình 3.1. Sơ đồ khối của Radio Board BRD4104A......................................................47
Hình 3.2. Các ngoại vi tương ứng với từng chế độ năng lượng.....................................49
Hình 3.3. Bộ Crypto tích hợp trên Wireless MCU........................................................50
Hình 3.4. Phân vùng của Gecko Bootloader..................................................................51
Hình 4.1. Hệ thống báo cháy không dây........................................................................52
Hình 4.2. Sơ đồ tổng quan hệ thống báo cháy dùng công nghệ BLE Mesh..................54
Hình 4.3. Kiến trúc mạng của hệ thống báo cháy dùng công nghệ BLE Mesh.............57
Hình 4.4. Cấu trúc gói tin trong hệ thống báo cháy.......................................................59
Hình 4.5. Đường đi gói tin báo cháy trong hệ thống.....................................................60
Hình 5.1. Sơ đồ hoạt động của Gateway Node..............................................................62
Hình 5.2. Cấu trúc dữ liệu lưu trữ trong Gateway Node................................................63
Hình 5.3. Cơ chế xử lý khi nhận gói tin từ Friend Node...............................................68
Hình 5.4. Chu kỳ Advertising của Gateway Node.........................................................68
Hình 5.5. Cấu trúc gói tin Advertising của Gateway Node...........................................69
Hình 5.6. Quá trình Advertising của Gateway Node.....................................................69
Hình 5.7. Quá trình kiểm tra trạng thái Friend Node.....................................................70
Hình 5.8. Quá trình chuyển đổi qua Gateway Node dự phòng......................................71
Hình 6.1. Kiến trúc BLE Mesh Stack trên Smartphone.................................................72
Hình 6.2. Logo ứng dụng Fire Alarm............................................................................73
Hình 6.3. Một số thay đổi chính trên giao diện của Fire Alarm....................................74
Hình 6.4. Các bước thực hiện cấp quyền và cấu hình cho thiết bị.................................75
Hình 6.5. Danh sách Network được tạo thêm................................................................76
Hình 6.6. Danh sách nhóm được tạo mới......................................................................76
Hình 6.7. Tìm kiếm thiết bị cần cấu hình.......................................................................77
Hình 6.8. Cấp quyền cho thiết bị...................................................................................78
Hình 6.9. Cấu hình Node trong mạng............................................................................79
Hình 6.10. Danh sách các Node được cấu hình vai trò Friend Node.............................80
Hình 6.11. Danh sách các Node được cấu hình vai trò LPN.........................................80
x
Hình 6.12. Quá trình Fire Alarm nhận gói tin từ Gateway trong mạng BLE Mesh......81
Hình 6.13. Sơ đồ hoạt động quét dữ liệu của ứng dụng.................................................82
Hình 6.14. Sơ đồ hoạt động giải mã dữ liệu..................................................................83
Hình 6.15. Hiển thị dữ liệu Node lên giao diện ứng dụng.............................................84
Hình 7.1. Sơ đồ hoạt động của Friend Node..................................................................85
Hình 7.2. Cấu trúc dữ liệu của Friend Node..................................................................86
Hình 7.3. Quá trình xử lí gói tin từ LPN........................................................................90
Hình 7.4. Quá trình kiểm tra tình trạng LPN.................................................................91
Hình 8.1. Sơ đồ hoạt động của Low Power Node..........................................................92
Hình 8.2. Năng lượng tiêu thụ của LPN........................................................................96
Hình 8.3. Viên pin CR2032...........................................................................................97
Hình 8.4. Dung lượng pin (%) của LPN........................................................................98
Hình 8.5. Dung lượng pin (%) của Friend node............................................................99
Hình 9.1. Ứng dụng Blue Gecko.................................................................................101
Hình 9.2. Cấu hình Internal Storage Bootloader cho Bootloader................................102
Hình 9.3. Chức năng Bluetooth Browser.....................................................................103
Hình 9.4. Chọn thiết bị theo tên hoặc địa chỉ MAC để cấu hình OTA DFU...............104
Hình 9.5. Chức năng OTA để thực hiên OTA DFU....................................................105
Hình 9.6. Quá trình OTA DFU....................................................................................106

xi
DANH SÁCH BẢNG
Bảng 1.1. Các phiên bản của BLE...................................................................................1
Bảng 1.2. Khoảng cách truyền dữ liệu ở phiên bản BLE 5.0..........................................5
Bảng 1.3. Các thành phần của thuộc tính.......................................................................11
Bảng 1.4. Các quyền truy cập thuộc tính.......................................................................12
Bảng 1.5. Các phương thức của giao thức ATT............................................................12
Bảng 1.6. Các thuộc tính của gói tin Advertising..........................................................18
Bảng 1.7. Các thông số của chế độ Connection.............................................................19
Bảng 2.1. Các loại tin nhắn trong mạng BLE Mesh......................................................26
Bảng 2.2. Các loại địa chỉ trong mạng BLE Mesh........................................................27
Bảng 2.3. Gói tin sử dụng Advertising Bearer...............................................................34
Bảng 2.4. Các thuộc tính của Mesh Proxy Service........................................................34
Bảng 2.5. Các trường trong gói tin Network PDU........................................................35
Bảng 2.6. Các trường trong gói tin Lower Transport PDU...........................................36
Bảng 2.7. Các trường trong gói tin Upper Transport PDU............................................37
Bảng 2.8. Các bit định nghĩa tính năng trong mạng BLE Mesh....................................38
Bảng 2.9. Các thuộc tính của Mesh Provisioning Service.............................................41
Bảng 2.10. Các yêu cầu bảo mật trong mạng BLE Mesh..............................................45
Bảng 3.1. Dòng tiêu thụ tương ứng ở các chế độ năng lượng của Wireless MCU........48
Bảng 4.1. Mục tiêu thiết kế của hệ thống.......................................................................53
Bảng 5.1. Các ngoại vi chính được sử dụng bởi Gateway Node...................................64
Bảng 5.2. Các lớp API được sử dụng bởi Gateway Node.............................................65
Bảng 5.3. Cấu hình Mesh Feature, Model và GATT Service của Gateway Node........66
Bảng 7.1. Các ngoại vi được sử dụng chính bởi Friend Node.......................................87
Bảng 7.2. Các lớp API sử dụng bởi Friend node...........................................................87
Bảng 7.3. Cấu hình Mesh FeatuHình re, Model và GATT Service của Friend Node 89

Bảng 8.1. Các lớp API sử dụng bởi LPN.......................................................................93

Bảng 8.2. Cấu hình Mesh Feature, Model và GATT Service của LPN.........................94
Bảng 10.1. Mục tiêu thiết kế và kết quả đạt được........................................................107
Bảng 10.2. Thời gian gửi gói tin báo động của LPN...................................................108
Bảng 10.3. Thời gian nhận biết thiết bị gặp sự cố.......................................................108
xii
LỜI NÓI ĐẦU
Nhóm có đến 4 thành viên cùng thực hiện việc triển khai hệ thống báo cháy, do
đó, trong phạm vi báo cáo, sẽ trình bày chi tiết tất cả các phần ở cả mức độ tổng quan
và chi tiết cụ thể.
Gateway Node là thiết bị đưa dữ liệu trong toàn mạng BLE Mesh ra bên ngoài
để lưu trữ hoặc phục vụ các công việc xử lý khác. Hơn nữa, trong phạm vi thiết kế,
nhóm còn dùng Gateway để giám sát các trạng thái hoạt động của những thiết bị khác
trong mạng, đồng thời thực hiện công việc mã hoá dữ liệu trước khi truyền ra ngoài.
Ứng dụng trên Smartphone dùng để cấu hình chức năng, cấp phát địa chỉ hoạt
động cho toàn bộ các thiết bị trong mạng, đồng thời, nó còn quét các dữ liệu được phát
ra từ Gateway để xử lý và hiển thị thông tin lên giao diện màn hình, nhằm thông báo
cho người dùng cũng như đưa ra các cảnh báo khi có sự cố xảy ra.
Friend Node là thiết bị đóng vai trò trung gian giữa Gateway Node và Low Power
Node. Đảm nhiệm nhiệm vụ truyền nhận dữ liệu giữa các thiết bị trong mạng. Ngoài ra, thiết
bị Fiend Node còn được thiết kế cho quá trình kiểm tra tình trạng hoạt động của cả Gateway
Node và Low Power Node.

Low Power Node là thiết bị được thiết kế với mục tiêu sử dụng năng lượng thấp, chịu
trách nhiệm trong việc phát hiện các dấu hiệu xảy ra đám cháy, và gửi gói tin đã dược mã hóa
để thông báo đến người dùng.

xiii
1. Bluetooth Low Energy
1.1. Giới thiệu
1.1.1. Lịch sử ra đời
Vào tháng 06 năm 2010, tổ chức Bluetooth SIG đã giới thiệu một phiên bản
Bluetooth hoàn toàn mới, được gọi là Bluetooth Low Energy (BLE) hay còn gọi là
Bluetooth Smart. Đây có thể được xem là một phiên bản nhỏ gọn, được tối ưu hoá
nhiều hơn Bluetooth truyền thống trước đây.
Các thiết bị hoạt động trên nền tảng BLE có những đặc điểm như công suất tiêu
thụ thấp, giá thành rẻ, và ít phức tạp khi triển khai. Vì vậy, công nghệ này đặc biệt
thích hợp với các ứng dụng Internet of Things (IoT), vốn được xem là xu hướng tương
lai của thế giới.
BLE được tích hợp rất nhiều vào các thiết bị thông minh hiện đại như:
Smartphone, Tablet,… Chính vì thế, dù mới được giới thiệu trong thời gian gần đây,
nhưng nó đã trở nên phổ biến rộng khắp. Nhiều công ty công nghệ lớn như: Apple,
Samsung,.. đã sử dụng BLE như một phần chủ chốt trong các sản phẩm của mình. Đây
là một trong những yếu tố quyết định đến sự thành công hiện tại của công nghệ này.
Trải qua gần 6 năm phát triển, phiên bản BLE mới nhất đã được giới thiệu, với
những ưu điểm vượt trội so với phiên bản cũ. Nếu không đề cập gì thêm, ở các phần
sau sẽ trình bày chi tiết về một phiên bản phổ biến của BLE, phiên bản 4.1.
Bảng 1.1. Các phiên bản của BLE
Phiên Thời điểm ra mắt Đặc điểm chính
bản
4.0 2010 Low Energy (1 Mbps)
4.1 2013 Hỗ trợ LTE
4.2 2014 Cho phép kết nối IP, tăng tính bảo mật và tốc độ
truyền
5.0 2016 Tăng tốc độ truyền và khoảng cách hoạt động

1
1.1.2. Tính tương thích
Kể từ khi Bluetooth Specifications 4.0 được phát hành, có hai chuẩn giao tiếp
được định nghĩa, bao gồm:
+ BR/EDR: chuẩn Bluetooth truyền thống, bao gồm các phiên bản từ 1.0.
+ BLE: chuẩn Bluetooth công suất thấp, được giới thiệu từ phiên bản 4.0.
Hai chuẩn giao tiếp này hoàn toàn không tương thích với nhau, vì vậy, để một
thiết bị chạy BR/EDR có thể giao tiếp được với thiết bị chạy BLE, ta cần phải có một
thiết bị trung gian chạy cùng lúc cả hai chuẩn này. Vì vậy, có hai loại thiết bị chạy
Bluetooth được định nghĩa, bao gồm:
+ Thiết bị Single - Mode: chỉ chạy duy nhất chuẩn BLE, nó có thể giao
tiếp với các thiết bị chỉ chạy BLE hoặc chạy cùng lúc cả BLE và BR/EDR.
+ Thiết bị Dual - Mode: chạy cùng lúc cả hai chuẩn BLE và BR/EDR, nó
có thể giao tiếp được với tất cả các thiết bị chạy trên nền công nghệ Bluetooth.

Hình 1.1. Tính tương thích giữa các thiết bị Bluetooth

2
1.1.3. Cấu hình phần cứng
Chuẩn BLE bao gồm nhiều tầng giao thức mạng để thực hiện các công việc
truyền và nhận dữ liệu, nhưng nhìn ở một mức độ tổng quát, ta có thể gộp chúng lại
thành ba tầng chính:
+ Tầng Application: thực hiện các ứng dụng theo nhu cầu của người
dùng.
+ Tầng Host: gồm các tầng phía trên của bộ giao thức mạng, quản lý hoạt
động của việc giao tiếp dữ liệu thực hiện ở các tầng dưới.
+ Tầng Controller: gồm các tầng phía dưới của bộ giao thức mạng, thực
thi việc giao tiếp dữ liệu không dây.
Tầng Host và tầng Controller được kết nối với nhau theo một giao thức gọi là
Host Controller Interface (HCI). HCI được định nghĩa theo chuẩn chung của Bluetooth
SIG, vì thế, các sản phẩm phần cứng thuộc nhiều hãng khác nhau hoàn toàn có thể giao
tiếp được với nhau.
Theo cách chia như trên, mỗi tầng của chuẩn BLE có thể được thực thi trên một
IC riêng lẻ, và chúng giao tiếp với nhau theo các giao thức đã được định nghĩa từ
trước. Hiện nay, tuỳ vào ứng dụng cụ thể, có ba cách thiết kế phần cứng được sử dụng,
bao gồm:
+ SoC (System on Chip): một IC được tích hợp cả tầng Application, Host
và Controller. Nó có ưu điểm là kích cỡ PCB nhỏ, giá thành thấp, vì thế phù hợp
cho các cảm biến không dây đơn giản phục vụ nhu cầu thu thập dữ liệu. Trong
phạm vi báo cáo, các thiết bị sẽ chạy trên nền thiết kế SoC này.
+ Dual IC kết nối qua HCI: thiết kế này gồm một IC chạy tầng
Application và tầng Host, một IC còn lại chạy tầng Controller.

+ Dual IC kết nối qua giao thức khác: thiết kế này gồm một IC chạy tầng
Host và tầng Controller, một IC còn lại chạy tầng Application.

3
 Hình 3. Cấu hình phần cứng các thiết bị BLE

1.1.4. Tốc độ truyền dữ liệu

Với chuẩn BLE, tốc độ truyền dữ liệu tối đa là 1 Mbps, ở phiên bản 5.0 thì tốc
độ truyền đã được cải thiện lên gấp đôi là 2 Mbps. Thật ra đây chỉ là tốc độ trên lý
thuyết, thực tế còn phụ thuộc vào nhiều yếu tố khác như môi trường truyền sóng, tốc
độ CPU, cấu hình thiết bị RF,…
Ta có thể tính toán sơ lược để hiểu rõ hơn về tốc độ truyền của chuẩn này. Thiết
bị Blue Gecko được sản xuất bởi Silabs là một SoC tích hợp BLE, có những giới hạn
về phần cứng như sau:
+ Mỗi sự kiện Advertising, nó có thể truyền tối đa 3 gói tin.
+ Mỗi gói tin đơn lẻ có thể truyền tải nhiều nhất là 31 byte dữ liệu.
+ Khoảng thời gian ngắn nhất giữa hai sự kiện Advertising là 20 ms.
Từ những thông số trên, với chế độ Advertising, ta có thể tính được mỗi giây sẽ
có tối đa là 50 lần truyền dữ liệu. Tốc độ truyền sẽ là:
50 lần truyền dữ liệu mỗi giây * 3 gói tin * 31 byte = 4650 byte/s hay ~ 37 Kbps

4
 Ta thấy tốc độ này rất thấp so với tốc độ trên lý thuyết. Ở một chế độ hoạt động
tốt hơn, chế độ Connection, tốc độ truyền dữ liệu được tính rơi vào khoảng 125 Kbps.
Với những sản phẩm board mạch có công suất phát sóng cũng như cấu hình cao hơn,
tốc độ thực tế cao nhất có thể đạt được là khoảng 650 Kbps với tầng vật lý 1 Mbps và
khoảng 1300 Kbps với tầng vật lý 2 Mbps.
Với tốc độ truyền dữ liệu càng cao, thì đồng nghĩa với việc có nhiều sự kiện
truyền dữ liệu được diễn ra và thiết bị phải hoạt động liên tục, điều này dẫn đến công
suất tiêu thụ sẽ tăng lên. Một trong những điểm làm công nghệ BLE trở nên khác biệt
là khoảng thời gian nghỉ giữa các sự kiện truyền dữ liệu lớn, lúc này thiết bị sẽ rơi vào
trạng thái ngủ sâu, dẫn đến công suất tiêu thụ giảm đi. Vì vậy, với người sử dụng, cần
cân nhắc thật hợp lý giữa việc cân bằng tốc độ truyền dữ liệu và công suất tiêu thụ khi
thiết bị hoạt động.

1.1.5. Khoảng cách hoạt động

Tương tự như tốc độ truyền dữ liệu, khoảng cách hoạt động thực tế của các thiết
bị không dây phụ thuộc vào nhiều yếu tố như thiết kế mạch RF, hướng phát sóng, độ
nhiễu của môi trường truyền,… Chuẩn BLE được thiết kế để tập trung vào các giao
tiếp dữ liệu trong khoảng ngắn, với công suất phát sóng càng cao, thì khoảng cách phát
ra sẽ càng xa và công suất tiêu thụ của mạch càng lớn.
Các thiết bị BLE có thể truyền dữ liệu tốt ở khoảng cách 30 mét hoặc nhiều hơn
khi tính theo đường thẳng, nhưng khoảng cách tối ưu nhất để truyền dữ liệu vào
khoảng 3 - 6 mét.
Ở chuẩn BLE 5.0, tương ứng với công suất phát sóng khác nhau, khoảng cách
tối đa trên lý thuyết có thể truyền được cũng khác nhau.
Bảng 1.2. Khoảng cách truyền dữ liệu ở phiên bản BLE 5.0
Tx Power Rx Sensitivity Antenna Gain Range
0 dBm -92 dBm -5 dB 160 m
10 dBm -92 dBm -5 dB 295 m

5
1.1.6. Mô hình mạng
Mỗi thiết bị BLE có thể giao tiếp với nhau theo 2 cách: Advertising (hay
Broadcasting) và Connection. Mỗi cách đều có những ưu và nhược điểm khác nhau, và
cũng có mô hình hoạt động khác nhau. Ta sẽ thảo luận chi tiết hơn về phần này ở mục
1.3.
Với chế độ Advertising, một thiết bị BLE sẽ phát gói tin ra toàn mạng (gọi là
Advertiser hoặc Broadcaster), bất cứ thiết bị nào khác trong phạm vi phủ sóng của nó
đều có thể nhận được gói tin trên. Theo cách này, việc truyền dữ liệu sẽ đơn giản và
kém bảo mật, phù hợp cho nhu cầu cần gửi một lượng nhỏ dữ liệu tới nhiều thiết bị
cùng lúc.

Hình 1.2. Mô hình mạng ở chế độ Advertising

6
 Với chế độ Connection, thiết bị BLE chỉ có thể gửi dữ liệu đến một thiết bị khác
đã thành lập kết nối riêng với nó. Chính vì thế, quá trình truyền dữ liệu sẽ được bảo
mật hơn, nhưng đồng thời số lượng thiết bị nhận được gói tin cũng không lớn, chế độ
này phù hợp cho các ứng dụng cần trao đổi một lượng lớn dữ liệu của người dùng.

Hình 1.3. Mô hình mạng ở chế độ Connection.

Ngoài 2 mô hình hoạt động cơ bản đã trình bày ở trên, BLE còn hỗ trợ các mô
hình khác bao gồm:
+ LE Dual: một hoặc nhiều thiết bị sẽ đảm nhận cùng lúc vai trò là
Master và Slave trong liên kết Connection, điều này giúp mở rộng kích cỡ mạng.
Tuy nhiên, nó cũng giới hạn số lượng, mỗi Master chỉ có thể quản lý tối đa 8 Slave
mà thôi.
+ LE Mesh: các thiết bị có thể kết nối trực tiếp với nhau để tạo thành một
mạng lưới trên diện rộng, phần lý thuyết của BLE Mesh sẽ được trình bày cụ thể
hơn ở phần sau.

1.1.7. Cấu trúc gói tin

Mỗi gói tin được trao đổi giữa các thiết bị BLE đều phải tuân theo một định
dạng cho trước. Gói tin này tuỳ vào kích thước sẽ được gửi một lần hoặc chia ra gửi
nhiều lần. Hình 1.5 trình bày các thành phần của gói tin, trong đó, dữ liệu Payload tối
đa có thể chứa được là 257 byte.
7
 Hình 1.4. Cấu trúc gói tin BLE

1.2. Các tầng giao thức mạng

1.2.1. Tổng quan
Giống như các chuẩn giao tiếp không giây khác như Zigbee hoặc Wifi, BLE
cũng có các tầng giao thức mạng để phục vụ việc truyền và nhận dữ liệu. Như đã trình
bày ở mục 1.1.3, ở mức độ tổng quát có thể chia các tầng giao thức đó vào 3 tầng chính
là Application, Host và Controller. Ở mức độ chi tiết hơn, ta sẽ thảo luận về các tầng
cấu tạo nên chúng, được mô tả ở hình 1.6 bên dưới.

Hình 1.5. Các tầng giao thức mạng của BLE

8
1.2.2. Tầng vật lý (Physical Layer)
Tầng vật lý là nơi chứa các mạch điện phục vụ việc truyền và nhận sóng không
dây RF, ví dụ như mạch điều chế và giải điều chế tín hiệu tương tự.
Các thiết bị BLE hoạt động trên băng tầng 2.4 GHz ISM (Industrial Scientific
Medical), băng tầng này kéo dài từ 2402 MHz đến 2480 MHz và được chia thành 40
kênh với khoảng cách giữa mỗi kênh là 2 MHz. Trong đó có 3 kênh phục vụ cho chế
độ Advertising là kênh 37, 38 và 39. Các kênh còn lại phục vụ cho chế độ Connection.

Hình 1.6. Tần số các kênh giao tiếp sóng RF

Các kênh thực hiện việc giao tiếp dữ liệu theo cả hai hướng truyền và nhận giữa
các thiết bị BLE. Một kỹ thuật được sử dụng để đảm bảo việc giao tiếp dữ liệu được
diễn ra tin cậy ở tầng này gọi là AFH (Adaptive Frequency Hopping Spread Spectrum),
AFH sẽ thực hiện việc chọn kênh giao tiếp sóng RF sao cho phù hợp với nhu cầu sử
dụng.

1.2.3. Tầng liên kết (Link Layer)

Tầng liên kết được kết nối trực tiếp với tầng vật lý, nó bao gồm các mạch phần
cứng cũng như phần mềm được kết hợp lại để thực hiện các chức năng chính sau:
+ Quản lý cấu hình thiết bị, quy định cách mà các thiết bị được kết nối
với nhau. Hai chế độ hoạt động Advertising và Connection thực thi ở tầng liên kết
sẽ được trình bày chi tiết ở mục 1.3.
+ Thực hiện các công việc bảo mật gói tin, như kiểm tra mã CRC, mã
hoá và giải mã AES. Có thể nói, tầng này chịu trách nhiệm chính trong việc đảm bảo
độ tin cậy của dữ liệu khi truyền và nhận.
9
 Mỗi thiết bị BLE khi hoạt động ở tầng liên kết, điều được nhận biết thông qua
địa chỉ MAC của chính nó. Địa chỉ này sẽ nằm ở phần đầu trong gói tin được gửi đi
hoặc nhận được. Chính vì thế, tầng liên kết có thể lọc gói tin theo địa chỉ của thiết bị.
Các địa chỉ này được lưu trong một danh sách gọi là White Lists.

1.2.4. Giao thức Host Controller (HCI)

Bluetooth Specification định nghĩa HCI là tập hợp các lệnh và sự kiện để Host
và Controller có thể giao tiếp được với nhau, kèm theo đó là định dạng của gói tin và
các thủ tục cần thiết để truyền và nhận dữ liệu. HCI thường được thực hiện trên các
chuẩn giao tiếp nối tiếp như UART, USB hay SDIO.

1.2.5. Giao thức L2CAP

Giao thức L2CAP (Logical Link Control and Adaptation Protocol) thực hiện hai
chức năng chính, bao gồm:
+ Đóng gói dữ liệu từ các tầng giao thức bên trên thành định dạng gói tin
BLE và ngược lại. Hai giao thức quan trọng nhất góp phần định hình nên gói tin
BLE ở đây là Attribute Protocol (ATT) và Security Manager Protocol (SMP).
+ Thực hiện việc phân mảnh và tái kết hợp với các gói tin có kích thước
lớn. Với chế độ hoạt động là Connection, trong một gói tin đơn lẻ thì sau khi trừ
đi các phần dữ liệu trong header, phần dữ liệu người dùng tối đa có thể truyền
tải là 23 byte.

1.2.6. Giao thức ATT (Attribute Protocol)

Mỗi thiết bị BLE khi hoạt động có các trạng thái khác nhau, mỗi trạng thái được
biểu hiện bằng một hoặc nhiều thuộc tính (Attribute). Bộ giao thức để truy cập các
thuộc tính đó gọi là Attribute Protocol (ATT).
ATT định nghĩa hai loại thiết bị với chức năng khác nhau để thực hiện việc giao
tiếp dữ liệu, bao gồm:
+ Server: là thiết bị lưu trữ dữ liệu ở dạng thuộc tính.
10
 + Client: là thiết bị có thể truy cập dữ liệu ở một hoặc nhiều Server.
Client có thể truy cập các thuộc tính của Server bằng cách gửi một gói tin
Request, dữ liệu trả về sẽ được lưu trong gói tin Response. Ngoài ra, Server cũng có
thể gửi các gói tin để thông báo hoặc chỉ thị cho Client, trong phạm vi báo cáo, phần
này sẽ được bỏ qua.

Hình 1.7. Giao thức Attribute

Phần trọng tâm trong giao thức ATT chính là thuộc tính, nơi lưu trữ dữ liệu của
thiết bị. Mỗi thuộc tính được định nghĩa bao gồm 4 phần:
+ Địa chỉ (Handle): là địa chỉ riêng của mỗi thuộc tính, Client sẽ truy cập
tới dữ liệu mong muốn ở Server thông qua các địa chỉ này.
+ UUID (Universally Unique Identifier): mỗi loại thuộc tính mang một ý
nghĩa riêng được định nghĩa trong Bluetooth Specification, để phân biệt chúng
người ta dùng một số có độ dài 16 bit hoặc 128 bit gọi là UUID.
+ Giá trị (Value): gồm một mảng dữ liệu có độ dài từ 0 đến 512 byte, độ
dài mảng này có thể cố định hoặc không cố định tùy vào người dùng định nghĩa.
+ Mô tả (Description): diễn tả ý nghĩa của thuộc tính, thông thường mỗi
UUID sẽ tương ứng với một mô tả riêng, được định nghĩa từ trước.
Bảng 1.3. Các thành phần của thuộc tính
Địa chỉ UUID Giá trị Mô tả
0x0001 0x1804 0x0000 Công suất phát theo đơn vị dBm
0x0002 0x2a00 0x426c75656769676122 Tên thiết bị theo mã UTF-8
11
 Để phục vụ việc quản lý dữ liệu được thuận tiện, mỗi thuộc tính sẽ được gán với
một quyền (Permission) khác nhau, Client sẽ dựa theo các quyền này để truy cập dữ
liệu ở phía Server được chính xác, tránh việc truy cập vào các dữ liệu không được phép
dẫn đến kết quả trả về bị sai.
Bảng 1.4. Các quyền truy cập thuộc tính
Readable Not Readable
Permission Writable Not Writable
Readable and Writable Not Readble and Not Writable

Giao thức ATT bao gồm nhiều phương thức khác nhau để phục vụ việc trao đổi
dữ liệu, mỗi phương thức có thể bao gồm một hoặc nhiều loại gói tin Request hoặc
Response. Bảng 1.5 bên dưới trình bày các phương thức chính của bộ giao thức này.
Bảng 1.5. Các phương thức của giao thức ATT
Phương thức Mô tả
Lỗi gây ra bởi gói tin Request từ phía Client, Server sẽ gửi gói
Báo lỗi
tin Response chứa mã lỗi tương ứng
Cấu hình Server Dùng để cấu hình các thuộc tính của Server
Tìm kiếm thông tin Xác định địa chỉ và UUID của thuộc tính
Đọc thuộc tính Đọc giá trị theo địa chỉ tương ứng
Ghi thuộc tính Ghi giá trị theo địa chỉ tương ứng
Sử dụng khi gói tin Request quá dài, không thể chứa trong một
Ghi chuỗi thuộc tính
gói tin đơn lẻ
Dùng để Server thông báo hoặc cập nhật thuộc tính của nó khi
Server thông báo
có thay đổi cho các Client

12
 Các gói tin Request hoặc Response được gửi giữa Client và Server có thể đơn
giản được chia thành hai loại: có phản hồi và không có phản hồi. Gói tin có phản hồi
(gói tin ACK) thường được sử dụng để đảm bảo rằng quá trình truyền dữ liệu diễn ra
thành công. Nhưng vì phải đợi phản hồi nên sẽ ảnh hưởng không nhỏ đến tốc độ truyền
dữ liệu trong mạng. Gói tin không có phản hồi thì ngược lại, thường được sử dụng
trong các ứng dụng đòi hỏi tốc độ truyền cao nhưng không yêu cầu quá khắt khe về
việc bên nhận có nhận được dữ liệu hay không.

1.2.7. Quản lý bảo mật (Security Manager)

Tầng quản lý bảo mật trong BLE bao gồm một bộ giao thức và chuỗi các thuật
toán được thiết kế để phục vụ việc mã hoá và giải mã dữ liệu. Điều này cho phép các
thiết bị có thể truyền và nhận dữ liệu thông qua các liên kết bảo mật, xác định nguồn
dữ liệu tin cậy hoặc ẩn đi địa chỉ MAC nhằm tránh các cuộc tấn công mạng không cần
thiết.
BLE cung cấp 3 dịch vụ bảo mật cơ bản, bao gồm:
+ Authentication và Authorization: thiết lập các mối quan hệ tin cậy giữa
những thiết bị BLE với nhau, thông thường dùng ở chế độ Connection.
+ Encryption và Data Protection: đảm bảo tính toàn vẹn và chính xác của
dữ liệu khi truyền thông qua sóng không dây.
+ Privacy và Confidentiallity: ngăn chặn việc một thiết bị trong mạng bị
theo dõi, cách thực hiện cơ bản nhất là ẩn đi địa chỉ MAC.
Ở chế độ hoạt động Advertising, dữ liệu được truyền đi khắp xung quanh mà
thông thường không được mã hoá. Vì vậy, ở phần này ta sẽ tập trung vào chế độ hoạt
động Connection, vốn an toàn và bảo mật hơn rất nhiều.

13
 Khi thành lập liên kết Connection, cả 2 thiết bị cần phải tiến hành trao đổi khoá
(Key) dùng để mã hoá và giải mã dữ liệu. Sau khi sở hữu khoá này, các gói tin sẽ được
gửi theo chu kỳ và khoảng thời gian được cấu hình trước đó. Quá trình trao đổi khoá
bao gồm 3 thủ tục chính, bao gồm:
+ Paring: trao đổi các khoá bảo mật tạm thời, các khoá này không được
lưu trữ vào bộ nhớ thiết bị, vì vậy sẽ không được sử dụng cho các sự kiện
Connection tiếp theo.
+ Bonding: một chuỗi liên tiếp nhau của thủ tục Paring sẽ được thực hiện
để trao đổi các khoá bảo mật chính, các khoá này được lưu trong bộ nhớ của
thiết bị. Sau khi trao đổi thành công khoá chính, hai thiết bị sẽ thành lập trạng thái
liên kết với nhau, cho phép chúng thực thi nhanh chóng việc trao đổi dữ liệu ở các
sự kiện Connection tiếp theo mà không cần phải tiến hành các thủ tục Paring lại lần
nữa.
+ Encryption Re-establishment: sau khi kết thúc quá trình Bonding, các
khoá bảo mật phải được lưu trữ trên thiết bị ở cả hai phía. Việc này giúp chúng
không cần phải thực hiện quá trình Paring hoặc Bonding lại ở lần kết nối sau đó.

Hình 1.8. Các thủ tục trao đổi khoá ở chế độ Connection

14
1.2.8. Generic Access Profile (GAP)
GAP định nghĩa cách mà các thiết bị BLE giao tiếp với nhau, hoặc là chế độ
Advertising, hoặc là chế độ Connection. Đồng thời, GAP còn thực hiện nhiều thủ tục
khác như tìm kiếm thiết bị, thiết lập cơ chế bảo mật, đảm bảo cho việc trao đổi dữ liệu
giữa các thiết bị từ các nhà sản xuất khác nhau được diễn ra một cách đồng bộ,…
Trọng tâm của GAP nằm ở hai chế độ hoạt động là Advertising và Connection,
sẽ được trình bày chi tiết hơn ở mục 1.3.

1.2.9. Generic Attribute Profile (GATT)

GATT được xây dựng dựa trên giao thức ATT, nhưng khác biệt ở chỗ GATT tổ
chức dữ liệu theo một cơ chế khác. Điều này giúp dữ liệu khi trao đổi giữa các thiết bị
BLE sẽ được chuẩn hoá lại theo một cấu trúc riêng, đảm bảo sự thống nhất cho tất cả
các hoạt động truyền và nhận dữ liệu trong mạng. Chi tiết hơn về GATT sẽ được trình
bày riêng ở mục 1.4 bên dưới.

1.3. Advertising và Connection

1.3.1. Chế độ Advertising
Advertising là một chế độ hoạt động cơ bản của công nghệ BLE, nó thường
được sử dụng với hai mục đích chính: để thiết lập liên kết Connection hoặc để quảng
bá dữ liệu người dùng ra các thiết bị xung quanh.
Quá trình Advertising định nghĩa hai loại thiết bị với các chức năng khác nhau:
+ Advertiser: thiết bị gửi gói tin Advertising.
+ Scanner: thiết bị quét các gói tin Advertising.
Mỗi gói tin ở chế độ Advertising có thể mang nhiều nhất là 31 byte dữ liệu
người dùng cùng với các thông tin cơ bản như địa chỉ MAC của thiết bị. Vì gói tin
được phát theo chu kỳ, nên với chu kỳ phát càng ngắn, thì xác suất Scanner nhận được
gói tin sẽ càng cao, nhưng đổi lại, năng lượng tiêu tốn của thiết bị cũng sẽ càng lớn.

15
 Hình 1.9. Cấu trúc gói tin Advertising

Hình 1.10. Quá trình Advertising và Scanning dữ liệu

Có hai thông số chính quyết định Scanner sẽ nhận được dữ liệu với xác suất cao
hay thấp, đó là:
+ Scan Interval: là khoảng thời gian giữa 2 lần quét dữ liệu liên tiếp.
+ Scan Window: là khoảng thời gian diễn ra của một lần quét dữ liệu.
Với Mesh SDK của Silabs, khoảng giá trị của 2 thông số trên là từ 2.5 ms cho
đến 40.96 s.

16
 Để tránh việc thời điểm phát và thời điểm quét không thể trùng lặp nhau, tầng
giao thức mạng của BLE (cụ thể là tầng Link Layer) sẽ thay đổi các thông số trên bằng
cách tăng hoặc giảm một ít, điều này giúp nâng cao khả năng truyền dữ liệu thành công
giữa các thiết bị với nhau.
Quá trình quét dữ liệu có thể được thực hiện theo 2 cách, bao gồm:
+ Passive Scanning: Scanner đơn giản chỉ quét các gói tin trong phạm vi
phủ sóng của nó, và Advertiser sẽ không biết được có bao nhiêu gói tin được
nhận bởi Scanner.
+ Active Scanning: sau khi nhận được gói tin Advertising, Scanner sẽ gửi
một Request tới Advertiser để thông báo rằng quá trình nhận dữ liệu đã diễn ra
thành công. Advertiser khi đó sẽ gửi lại phía Scanner một gói tin Response,
bằng cách này, ta có thể thấy có tối đa là 2 gói tin Advertising được trao đổi, dẫn tới
dữ liệu người dùng có thể gửi lên đến 31 * 2 = 62 byte.

Hình 1.11. Quá trình Active và Passive Scanning

17
 Các gói tin Advertising được sử dụng cho nhiều mục đích khác nhau, vì thế đòi
hỏi chúng phải có các thuộc tính được cấu hình khác nhau cho phù hợp. Bảng 1.6 trình
bày các thuộc tính định nghĩa nên một gói tin Advertising.
Bảng 1.6. Các thuộc tính của gói tin Advertising
Thuộc tính Thành phần Mô tả
Connectabilit Connectable Cho phép thiết lập liên kết Connection
y Non-Connectable Không cho phép thiết lập liên kết Connection
Scannable Yêu cầu gói tin Scan Request
Scannability
Non-Scannable Không yêu cầu gói tin Scan Request
Gói tin được gửi tới một địa chỉ MAC cố định
Directed
Directability trước
Non-Directed Gói tin được gửi tới tất cả các thiết bị xung quanh

Từ những thuộc tính trên, BLE định nghĩa 4 loại gói tin Advertising. Hình 1.13
trình bày chi tiết về các thuộc tính tương ứng của mỗi loại.

Hình 1.12. Các loại gói tin Advertising

1.3.2. Chế độ Connection

Chế độ Connection đòi hỏi phải có hai thiết bị thành lập liên kết bảo mật với
nhau. Bluetooth Specification định nghĩa hai loại thiết bị hoạt động trong chế độ này,
bao gồm:
+ Master: thiết bị chịu trách nhiệm thành lập liên kết Connection cũng
như quản lý các thông số về chu kỳ, khoảng thời gian cho các sự kiện trao đổi dữ
liệu sau đó.

18
 + Slave: thiết bị tuân theo những thông số được Master cấu hình và chấp
nhận hoạt động ở chế độ Connection.
Để thành lập liên kết Connection, Master đầu tiên cần phải quét để tìm kiếm các
gói tin Advertising có thuộc tính Connectable. Khi tìm kiếm được gói tin phát ra từ
thiết bị phù hợp, nó sẽ gửi một gói tin Request tới Slave, nếu Slave phản hồi bằng gói
tin Response, thì liên kết Connection sẽ được thiết lập.

Hình 1.13. Quá trình hoạt động ở chế độ Connection

Có 3 thông số chính được cấu hình bởi Master trong suốt quá trình Connection,
chúng được trình bày chi tiết trong bảng 1.7 bên dưới. Các khoảng giá trị của mỗi
thông số được tham khảo từ Mesh SDK của Silabs.
Bảng 1.7. Các thông số của chế độ Connection
Thông số Khoảng giá trị Mô tả
Khoảng thời gian giữa hai sự kiện
Connection Interval 7.5 ms đến 4 s
Connection liên tiếp
0 đến 500 Số lượng sự kiện Connection mà Slave có
Connection Latency thể bỏ qua, không thực hiện khi nó không
Connection Interval có dữ liệu để gửi đến Master
Khoảng thời gian tối đa giữa 2 lần nhận
Supervision Timeout 100 ms đến 32 s dữ liệu trước khi liên kết Connection bị
chấm dứt

19
 Mỗi gói tin Connection có thể chứa dữ liệu lên tới 251 byte, với kích thước này,
giao thức L2CAP sẽ tự động phân mảnh cũng như lắp ráp lại gói tin ở cả hai phía
truyền và nhận. Hình 1.15 bên dưới trình bày chi tiết hơn cấu trúc gói tin được trao đổi
ở chế độ Connection.

Hình 1.14. Cấu trúc gói tin Connection

1.4. GATT Service và Characteristic

GATT được xây dựng dựa trên nền giao thức ATT và cung cấp một chuẩn
chung trong việc truyền nhận và lưu trữ dữ liệu. Tương tự như ATT, GATT định nghĩa
hai loại thiết bị hoạt động, bao gồm:
+ GATT Server: lưu trữ dữ liệu và nhận các gói tin Request cũng như
phản hồi các gói tin Response tới Client. Ngoài ra, nó còn có thể gửi các gói tin để
cấu hình, thông báo hoặc cập nhật dữ liệu khi có thay đổi.
+ GATT Client: truy xuất dữ liệu ở Server bằng cách gửi các gói tin
Request. Thông thường, các Client sẽ không biết được định dạng dữ liệu được
lưu trữ trên Server, vì thế, nó cần một quá trình để tìm kiếm các thông tin liên
quan về GATT Service, sau đó mới có thể thực hiện các thủ tục đọc, ghi cũng
như nhận dữ liệu phản hồi từ Server về.
Dữ liệu lưu trữ trên GATT Server bao gồm các thuộc tính (Attribute) được tổ
chức lại thành các Service và Characteristic. Điều này không có ngoại lệ, nghĩa là tất
cả dữ liệu trên GATT Server phải được lưu trữ theo định dạng này.

20
 Một GATT Service bao gồm một hoặc nhiều Characteristic, chúng thường thực
hiện một chức năng cụ thể nào đó, ví dụ như OTA Service sẽ phục vụ quá trình cập
nhật phần mềm, Battery Service sẽ cập nhật dung lượng pin hiện hành của thiết bị,…
Các Service cơ bản được định nghĩa trong Bluetooth Specification, ngoài ra, người
dùng còn có thể tự tạo các Service riêng để phục vụ một nhu cầu cụ thể nào đó.
Characteristic dùng để lưu trữ dữ liệu người dùng, chúng luôn luôn bao gồm ít
nhất hai thành phần cơ bản, đó là phần mô tả cấu trúc của dữ liệu và phần lưu trữ giá trị
thực của dữ liệu. Thông thường, mỗi Characteristic thường theo kèm các Description
để mô tả thông tin được chi tiết hơn, tuy nhiên, đây chỉ là phần tuỳ chọn và không bắt
buộc.

Hình 1.15. Cấu trúc dữ liệu trên GATT Server

Việc trao đổi dữ liệu giữa GATT Server và GATT Client được thực hiện thông
qua giao thức ATT, vì vậy, các phương thức hoạt động cũng sẽ tương tự như giao thức
ATT, đã được trình bày ở mục 1.2.6 bên trên.
21
2. Bluetooth Low Energy Mesh
2.1. Giới thiệu
Bluetooth Low Energy Mesh (BLE Mesh) là một mô hình mạng hoạt động dựa
trên nền công nghệ BLE, có Specification được giới thiệu lần đầu tiên vào năm 2017,
với mục tiêu chính là có thể giải quyết vấn đề phạm vi trao đổi dữ liệu ngắn trong các
chế độ hoạt động của BLE.

Hình 2.16. Mô hình mạng BLE Mesh

Mỗi thiết bị BLE Mesh có khả năng giao tiếp với các thiết bị còn lại trong mạng
thông qua các tin nhắn (Message), và những thiết bị này có thể chuyển tiếp những tin
nhắn đó ra khỏi phạm vi phủ sóng của một thiết bị đơn lẻ. Điều này hình thành nên một
mạng lưới hoạt động theo kiểu many-to-many, giúp mở rộng khoảng cách hoạt động
của mạng BLE Mesh lớn hơn rất nhiều lần so với các kiểu mạng BLE thông thường.
BLE Mesh sử dụng chế độ Advertising - Scanning để truyền và nhận các gói tin.
Bởi vì Advertising có những hạn chế nhất định về yếu tố bảo mật, do vậy BLE Mesh
được xây dựng trên một bộ giao thức mới, bảo mật hơn rất nhiều. Đồng thời, bộ giao
thức này còn định nghĩa định dạng gói tin, cách truyền và nhận dữ liệu,... qua nhiều
tầng khác nhau, giúp cho hoạt động của BLE Mesh được chuẩn hoá, dễ dàng trong việc
triển khai ở các hệ thống có quy mô lớn.

22
 Với phiên bản BLE Mesh mới nhất, ta có thể tổ chức tối đa lên đến 32767 thiết
bị trong toàn mạng, đồng thời, việc chuyển tiếp tin nhắn được thực hiện trong phạm vi
127 bước nhảy của gói tin.
Mạng BLE Mesh định nghĩa nhiều khái niệm mới so với BLE thông thường, vì
vậy, để hiểu rõ hơn về cách hoạt động cũng như những thành phần chính trong mạng,
trước tiên ta cần tìm hiểu về những khái niệm này, sẽ được trình bày ở phần sau.

2.2. Các khái niệm chính

2.2.1. Device và Node
Device là một thiết bị không thuộc mạng BLE Mesh, được gọi là thiết bị chưa
được cấp phát (Unprovisioned Device). Trong khi đó, Node là một thiết bị đã được cấp
phát và hoạt động như một thành phần trong mạng.
Việc quản lý quá trình cấu hình để đưa một Device trở thành một Node trong
mạng được thực hiện bởi một thiết bị đặc biệt, thường có cấu hình mạnh được gọi là
Provisioner. Device sẽ phát ra một gói tin yêu cầu gia nhập mạng, nếu kiểm tra thoả
mãn các yếu tố khác nhau như bảo mật, chức năng thiết bị,… Provisioner sẽ cấp phát
cho nó một địa chỉ cũng như cấu hình chức năng hoạt động để Device có thể tham gia
mạng và gửi, nhận các gói tin theo định dạng riêng của BLE Mesh. Đồng thời,
Provisioner còn có thể cấu hình lại, thêm chức năng, xoá một Node ra khỏi mạng,…
Các quá trình này sẽ được trình bày chi tiết hơn ở các phần sau.

2.2.2. Element
Element là các phần tử bên trong một Node. Một vài Node đặc biệt được cấu
thành từ nhiều phần tử khác nhau, mỗi phần tử có thể hoạt động và được điều khiển
một cách độc lập.
Một Node phải có ít nhất là một phần tử, gọi là Primary Element, các phần tử
khác có thể có hoặc không, gọi là Secondary Element. Số phần tử trong một Node là cố
định và không thể thay đổi trong suốt thời gian hoạt động của Node đó, người dùng chỉ
có thể thêm hoặc xoá bớt các phần tử thông qua việc cập nhật Firmware mới cho thiết
bị.

23
 Ví dụ về Element, một cụm bóng đèn bao gồm nhiều bóng đèn, trong đó mỗi
bóng có thể được bật hoặc tắt một cách độc lập với nhau.

Hình 2.17. Các phần tử trong một Node

2.2.3. Trạng thái và trạng thái có liên kết

Trạng thái (State) là giá trị đại diện cho trạng thái hiện tại của một phần tử trong
Node. Ví dụ đơn giản, mỗi bóng đèn trong một cụm bóng đèn có thể đang ở trạng thái
là On hay Off. Một sự thay đổi từ trạng thái này sang trạng thái khác được gọi là sự
chuyển đổi trạng thái, điều này có thể được thực hiện ngay lập tức hoặc xảy ra theo
một thời gian nhất định.

24
 Hình 2.18. Ví dụ về trạng thái trong một Node
Ngoài ra, ta còn có khái niệm thuộc tính (Property) của một Node, được thêm
vào để làm rõ ràng hơn các tình huống hoạt động của một trạng thái.
Ví dụ, định nghĩa giá trị nhiệt độ ở trong nhà hoặc ngoài trời có 2 kiểu thuộc
tính, bao gồm:
+ Manufacturer Property: chỉ cho phép đọc.
+ Admin Property: chỉ cho phép ghi.
Khi một trạng thái nào đó thay đổi, nó sẽ dẫn đến sự thay đổi của một trạng thái
khác trong Node, những trạng thái này được gọi là trạng thái có liên kết.
Ví dụ, khi độ sáng của đèn được chỉnh về 0, thì đồng nghĩa với việc nó đang ở
trạng thái Off.
Các trạng thái được định nghĩa để phục vụ những chức năng riêng biệt, và tổ
chức theo từng loại Model, chi tiết hơn sẽ được trình bày ở các mục sau.

2.2.4. Tin nhắn truyền trong mạng

Tất cả các giao tiếp truyền và nhận dữ liệu trong mạng BLE Mesh đều được
thực hiện bằng cách gửi tin nhắn.
Mỗi tin nhắn được tổ chức bao gồm 3 phần chính là mã (Opcode), các thông số
(Parameter) và các hành vi (Behavior). Với phần mã Opcode, ta có thể chia ra thành 3
loại tin nhắn trong mạng, bao gồm:
+ Tin nhắn GET: dùng để yêu cầu trạng thái từ một hoặc nhiều Node,
một tin nhắn STATUS có thể được phản hồi lại và chứa dữ liệu liên quan được
yêu cầu trước đó.
+ Tin nhắn SET: dùng để thay đổi giá trị của một trạng thái.
+ Tin nhắn STATUS: thường dùng để phản hồi lại các tin nhắn GET, tin
nhắn SET có ACK.

25
 Các tin nhắn khi truyền đi được chia thành hai loại chính, bao gồm:
+ Gói tin phản hồi (có ACK): yêu cầu một tin nhắn phản hồi từ Node
nhận được. Gói tin này giúp bên gửi xác nhận rằng quá trình truyền dữ liệu đến một
Node đã diễn ra thành công cũng như nhận lại dữ liệu trả về được yêu cầu trước
đó.
+ Gói tin không phản hồi (không có ACK): không yêu cầu phản hồi từ
phía nhận, nó có ưu điểm là quá trình truyền diễn ra nhanh chóng do không bị gián
đoạn bởi việc gửi gói tin phản hồi.
Trong trường hợp thiết bị gửi không nhận được gói tin phản hồi hoặc nhận được
phản hồi không mong muốn từ phía bên nhận, thì nó có thể gửi lại một tin nhắn yêu
cầu lần nữa. Nhiều tin nhắn được xác nhận bởi một Node sẽ không ảnh hưởng đến quá
trình hoạt động của Node đó.
Bảng 2.8. Các loại tin nhắn trong mạng BLE Mesh
Tin nhắn có yêu cầu phản hồi
Phân theo ACK
Tin nhắn không yêu cầu phản hồi
Tin nhắn GET
Phân theo Opcode Tin nhắn SET
Tin nhắn STATUS

26
2.2.5. Địa chỉ các Node
Các tin nhắn trong mạng phải được gửi từ một địa chỉ này sang một địa chỉ khác. BLE
Mesh định nghĩa 3 loại địa chỉ được sử dụng, chúng bao gồm:
+ Unicast Address: một địa chỉ duy nhất, dùng để nhận biết một Node
trong mạng, được cung cấp trong quá trình Provisioning. Nó được cấp phát cho
các phần tử trong một Node và luôn luôn đại diện cho phần tử đó khi thực hiện
các giao tiếp dữ liệu trong mạng. Thông thường, khi đề cập đến địa chỉ Unicast
Address của một Node, ta có thể ngầm hiểu đó chính là địa chỉ của Primary
Element. Có tối đa lên đến 32767 địa chỉ Unicast có thể được cấp phát, con số
này chính là số lượng thiết bị lớn nhất có thể có trong toàn mạng BLE Mesh.

+ Group Address: là một địa chỉ chung, dùng để đại diện cho một hoặc
nhiều phần tử trong các Node. Địa chỉ Group bao gồm hai loại chính, là địa chỉ
cố định (Fixed) và địa chỉ động (Dynamically). Có 4 địa chỉ Group cố định được
tổ chức Bluetooth SIG định nghĩa, bao gồm All-proxied, All-friends, All-relay
và All-nodes, chúng được đặt tên tương ứng với chức năng của các Node trong
mạng. Các địa chỉ động sẽ được cấp phát trong quá trình cấu hình ứng dụng, hoặc
trong quá trình Provisioning. Có tối đa 16384 địa chỉ Group trong mạng BLE Mesh,
trong đó bao gồm 256 địa chỉ cố định và 16128 địa chỉ động. Ví dụ cơ bản, một
Group Address đại diện cho một căn phòng, trong căn phòng đó có nhiều bóng
đèn khác nhau, mỗi bóng đèn là một Node.
+ Virtual Address: là một địa chỉ chung, có thể đại diện cho một hoặc
nhiều Node. Địa chỉ này là một mã 16 bit được tạo ra từ một UUID 128 bit, thường
được gán sẵn trong quá trình sản xuất ra thiết bị tại nhà máy.
Bảng 2.9. Các loại địa chỉ trong mạng BLE Mesh
Địa chỉ Mô tả
0x0000 Unassigned Address
0x0001 đến 0x7fff Unicast Address
0x8000 đến 0xffef Virtual Address
0xfff0 đến 0xffff Group Address

27
2.2.6. Relay Node
Đây là tính năng cho phép một Node có thể nhận và chuyển tiếp tin nhắn trong
mạng BLE Mesh, giúp mở rộng phạm vi hoạt động của mạng.
Một gói tin PDU khi truyền đi, có một trường được gọi là TTL (Time-to-live).
Nó là một biến dùng để giới hạn số bước nhảy của gói tin khi Relay, giá trị lớn nhất mà
TTL có thể đạt được là 127, nghĩa là một gói tin khi nhận bởi một Node, nó có thể
được chuyển tiếp đến 127 lần. Mỗi khi một Node nhận gói tin có TTL được chuyển
tiếp, nó sẽ giảm giá trị này đi một đơn vị. Việc tìm đường trong mạng Mesh được thực
hiện bởi một thuật toán riêng, do vậy, mặc dù chỉ với 127 lần chuyển tiếp, một Node
hoàn toàn có thể gửi tin nhắn đến một địa chỉ khác ở vị trí xa hoặc rất xa trong phạm vi
mạng.
Với Mesh SDK được cung cấp bởi Silabs, tính năng Relay nếu được thêm vào
trong lúc cấu hình Node, nó sẽ được thực hiện một cách tự động bởi các tầng của bộ
giao thức mạng, người dùng sẽ không cần phải can thiệp vào.

2.2.7. Proxy Node

Phần lớn các thiết bị Smartphone hoặc Tablet hiện tại trên thị trường chỉ hỗ trợ
BLE mà không hỗ trợ BLE Mesh. Vì vậy, để chúng có thể giao tiếp và trao đổi dữ liệu
với mạng BLE Mesh, cần có một Node đảm nhận vai trò trung gian, đó chính là Proxy
Node.
Proxy Node sử dụng cơ chế Connection của BLE, với một GATT Service được
định nghĩa sẵn gọi là Mesh Proxy Service.

2.2.8. Friend Node

Đây là một Node luôn luôn được cấp điện để hoạt động, có khả năng hỗ trợ thiết
bị Low Power Node để Node này có thể hoạt động ở chế độ tiết kiệm năng lượng.

28
2.2.9. Low Power Node (LPN)
Low Power Node là những thiết bị phải đáp ứng các yêu cầu khắc khe về năng
lượng tiêu thụ, nó dành hầu hết thời gian cho việc ngủ sâu và khi đó các bộ phát sóng
RF sẽ bị tắt đi. Vì vậy, các hoạt động trao đổi gói tin trong mạng BLE Mesh sẽ không
được thực hiện trong một khoảng thời gian nhất định.
LPN bắt buộc phải cần có một Friend Node để có thể duy trì hoạt động, LPN sẽ
thức dậy sau một khoảng thời gian được cấu hình trước đó, yêu cầu các dữ liệu được
lưu trữ trong bộ nhớ của Friend Node và gửi bất kỳ gói tin nào mà nó cần đến các
Node khác trong toàn mạng.

2.2.10. Model
Một Model dùng để định nghĩa các chức năng cơ bản của một Node. Một Node
có thể bao gồm nhiều Model, bên trong mỗi Model được tổ chức bởi các trạng thái
khác nhau, các tin nhắn có thể trao đổi dữ liệu dựa trên các trạng thái này.
Các ứng dụng BLE Mesh hoạt động theo cấu trúc Client - Server, có 3 loại
Model hoạt động dựa trên cấu trúc này, bao gồm:
+ Server Model: định nghĩa một tập hợp các trạng thái (State), sự chuyển
đổi trạng thái (State Transition), sự ràng buộc của trạng thái (State Binding) và
các loại tin nhắn mà mỗi phần tử trong Node có thể gửi hoặc nhận.
+ Client Model: không định nghĩa các trạng thái, mà thay vào đó, nó định
nghĩa các tin nhắn có thể gửi hoặc nhận để GET, SET hoặc yêu cầu tin nhắn
STATUS từ Server Model.
+ Control Model: là sự kết hợp của Server Model và Client Model. Nhờ
đó, nó có thể thực hiện chức năng của cả hai loại Model này.

29
Hình 2.19. Giao tiếp giữa Server Model và Client Model

Hình 2.20. Hoạt động của Control Model

30
 Các thiết bị đòi hỏi quá trình truyền dữ liệu nhiều trong mạng thông thường là
những Control Model. Ví dụ, thiết bị Gateway Node trong hệ thống báo cháy của nhóm
triển khai là một Control Model, nó bao gồm một Level Server Model và một Level
Client Model, phục vụ cả quá trình lưu trữ dữ liệu cũng như gửi và nhận các gói tin
GET, SET, STATUS.
Các Model bao gồm nhiều loại tương ứng với những chức năng khác nhau, dựa
vào nguồn gốc, ta có thể chia chúng ra làm hai loại chính, bao gồm:
+ Bluetooth SIG Model: là những Model được định nghĩa bởi tổ chức
Bluetooth SIG, được nhận biết bởi một ID có độ dài 16 bit. Trong số các Model
loại này, Generic Model là tập hợp những Model cơ bản được sử dụng để phát
triển các loại Model khác phức tạp hơn cũng như phục vụ việc triển khai các
ứng dụng đơn giản.
+ Vendor Model: là những Model được định nghĩa bởi người dùng hoặc
nhà sản xuất, ID của chúng có độ dài 32 bit. Vendor Model được xây dựng dựa
trên các Model cơ bản, mang tính chuyên dụng, thường phục vụ một nhu cầu
riêng của người dùng.
Các Model có thể được tạo ra bằng cách kế thừa, mở rộng một Model khác. Tuy
nhiên, có những Model mà người dùng không thể mở rộng thêm, chúng được gọi là
Root Model. Sau khi được định nghĩa xong, các trạng thái, hành vi trong một Model sẽ
không thể thay đổi trong quá trình hoạt động.

31
Hình 2.21. Các Model bên trong một Node

32
2.3. Các tầng giao thức mạng
2.3.1. Tổng quan
BLE Mesh hoạt động dựa trên nền công nghệ BLE, bao gồm nhiều tầng giao
thức mạng, mỗi tầng thực hiện một chức năng khác nhau. Trong đó, tầng dưới cùng
của Stack chính là toàn bộ các giao thức trong BLE, đã được trình bày ở mục 1 bên
trên.

Hình 2.22. Các tầng giao thức mạng của BLE Mesh

33
2.3.2. Tầng mang (Bearer Layer)
Tầng Bearer định nghĩa cách mà gói tin được truyền đi giữa các Node trong
mạng. Có hai cách truyền gói tin, bao gồm:
+ Advertising Bearer: gửi một gói tin theo định dạng của BLE Mesh, gói
tin này được gửi bằng cơ chế Advertising của BLE, có thuộc tính
Non-Connectable và Non-Scannable, với cấu trúc gói tin khác biệt ở phần AD
Type, được mô tả ở bảng 2.3.
Bảng 2.10. Gói tin sử dụng Advertising Bearer
Length AD Type Contents
0xXX “Mesh Message” Network PDU

+ GATT Bearer: sử dụng một GATT Service để truyền và nhận các

Proxy PDU giữa hai thiết bị đã thành lập kết nối ở chế độ Connection của BLE, GATT
Service này có tên gọi là Mesh Proxy Service, với các thuộc tính được trình bày
ở bảng 2.4.
Bảng 2.11. Các thuộc tính của Mesh Proxy Service
Thuộc tính Mô tả
Mesh Proxy Data In Cho phép ghi không cần phản hồi
Mesh Proxy Data Out Dùng để thông báo

34
2.3.3. Tầng mạng (Network Layer)
Network Layer thực hiện các chức năng chính bao gồm:
+ Thực thi việc giải mã, mã hoá và xác nhận các gói tin: Network Layer
đóng vai trò như một bộ lọc đầu vào, quyết định các gói tin được gửi đến một
Node có thể được truyền lên các tầng trên của bộ giao thức hay không. Key
dùng để mã hoá và giải mã ở tầng này được gọi là Network Key.
+ Thực thi tính năng Relay và Proxy trong mạng: việc chuyển tiếp các
gói tin được nhận bởi Advertising Bearer và cả GATT Bearer sẽ được thực hiện tại
tầng Network.
+ Đóng gói các gói tin thành một định dạng để tầng Bearer truyền đi: gói
tin ở tầng Network được gọi là Network PDU, có các thành phần được mô tả ở
hình 2.8 và bảng 2.5 bên dưới.
Bảng 2.12. Các trường trong gói tin Network PDU
Tên trường Số bits Chú thích
IVI 1 Bit LSB của IV Index
NID 7 Giá trị dùng để nhận biết Encryption Key và Privacy
Key dùng để mã hoá gói tin Network PDU
CTL 1 Network Control
TTL 7 Time To Live
SEQ 24 Sequence Number
SRC 16 Source Address
DST 16 Destination Address
Transport PDU 8 đến 128 Transport PDU
NetMIC 32 đến 64 Dùng để kiểm tra tính toàn vẹn của gói tin cho mạng

35
 Hình 2.23. Định dạng Network PDU

2.3.4. Tầng giao vận dưới (Lower Transport Layer)

Tầng Lower Transport nhận gói tin Upper Transport PDU từ tầng phía trên nó
và thực hiện việc truyền đi gói tin này. Với các gói tin có kích thước lớn, không thể
điền vào một gói tin đơn lẻ, thì tầng Lower Transport sẽ thực hiện 2 chức năng chính
sau:
+ Tiến hành phân mảnh, chia gói tin ra thành nhiều gói tin Lower
Transport PDU nhỏ hơn.
+ Tiến hành lắp ráp, tổng hợp các gói tin bị tách ra thành một gói tin
hoàn chỉnh và gửi nó lên tầng trên để xử lý các giai đoạn tiếp theo.
Vì vậy, có thể thấy ở tầng này, có 2 loại gói tin được sinh ra, đó là gói tin bị
phân mảnh và gói tin không bị phân mảnh. Hình 2.9 và bảng 2.6 mô tả các thành phần
của gói tin không bị phân mảnh.
Bảng 2.13. Các trường trong gói tin Lower Transport PDU
Tên trường Số bits Chú thích
SEG 1 Giá trị 0: gói tin không bị phân mảnh
AKF 1 Application Key Flag
AID 6 Application Key Identifier
Upper Transport Access PDU 40 đến 120 Upper Transport Access PDU

36
 Hình 2.24. Định dạng Lower Transport PDU

2.3.5. Tầng giao vận trên (Upper Transport Layer)

Tầng Upper Transport nhận gói tin từ tầng Access và tiến hành truyền gói tin
này đi. Ngoài ra, tầng này còn thực hiện thêm 2 chức năng khác, bao gồm:
+ Quản lý việc gửi các tin nhắn điều khiển, các tin nhắn liên quan đến `
Friendship và Heartbeat.
+ Thực hiện việc giải mã, mã hoá và xác nhận gói tin: Key sử dụng trong
quá trình này được gọi là Application Key, nó khác với Network Key, cũng vốn
được sử dụng cho quá trình tương tự nhưng lại diễn ra ở tầng Network.
Các gói tin ở tầng Upper Transport thường có độ dài lớn, từ 1 đến 380 byte chứa
phần lớn là dữ liệu của người dùng đã được mã hoá, khác với các gói tin được chia nhỏ
ra để truyền đi ở các tầng dưới. Hình 2.10 và bảng 2.7 mô tả cấu trúc của gói tin ở tầng
này.
Bảng 2.14. Các trường trong gói tin Upper Transport PDU
Tên trường Số Byte Chú thích
Encrypted Access Payload 1 đến 380 byte Dữ liệu ở tầng Access đã được mã
hoá
TransMIC 4 tới 8 byte Giá trị dùng để kiểm tra tính toàn vẹn
của dữ liệu ở tầng Access

Hình 2.25. Định dạng Upper Transport PDU

37
2.3.6. Tầng truy cập (Access Layer)
Tầng Access đóng vai trò như một tầng trung gian, giúp các tầng ứng dụng bên
trên có thể giao tiếp, cũng như cấu hình tầng Upper Transport. Vì vậy, tầng này đảm
nhận các chức năng chính như sau:
+ Định nghĩa cấu trúc gói tin người dùng.
+ Điều khiển quá trình giải mã và mã hoá được thực hiện bởi tầng Upper
Transport.
+ Kiểm tra các dữ liệu nhận được từ tầng Upper Transport có đúng với
Network và Application mong muốn hay không, trước khi chuyển tiếp nó lên
tầng ứng dụng bên trên.
Dữ liệu ở tầng Access có thể được chia vào tối đa 32 phần, mỗi phần chứa 12
byte. Do vậy, khi tính cả trường TransMIC, kích thước tối đa của Access PDU có thể
lên đến 384 byte.

2.3.7. Tầng thiết lập mô hình (Foundation Model Layer)

Tầng Foundation Model chịu trách nhiệm trong việc thực thi các Model dùng để
cấu hình cũng như quản lý mạng BLE Mesh.
Việc định nghĩa dữ liệu Composition Data cũng được thực hiện ở tầng này.
Composition Data chứa các thông tin về Node, Element và các Model hỗ trợ của mỗi
Element trong đó. Ngoài ra, nó còn chứa các tính năng của mạng BLE Mesh, bao gồm
Relay, Proxy, Friend và Low Power.
Với Mesh SDK của Silabs, ta có 1 trường trong Composition Data định nghĩa
các tính năng trên, bao gồm 4 bit được trình bày trong bảng 2.8 bên dưới.
Bảng 2.15. Các bit định nghĩa tính năng trong mạng BLE Mesh
Bit Tính năng (Feature)
0 Relay
1 Proxy
2 Friend
3 Low Power

38
 Hình 2.26. Ví dụ về Composition Data

2.3.8. Tầng mô hình (Model Layer)

Tầng Model thực thi những Model được sử dụng trong các ứng dụng của người
dùng, chính xác hơn, nó thực thi các kiểu tin nhắn, trạng thái,… được định nghĩa riêng
trong từng loại Model. Ví dụ, các Generic Model như Level Model, OnOff Model,…
được người dùng tổ chức ở tầng này.

2.4. Cơ chế Publish - Subcribe

Việc trao đổi tin nhắn trong mạng BLE Mesh được thực hiện thông qua cơ chế
Publish - Subcribe. Hoạt động gửi gói tin đi được gọi là Publish. Trong khi đó, hoạt
động nhận gói tin từ một địa chỉ cụ thể được chỉ định từ trước được gọi là Subcribe.
Thông thường, địa chỉ mà một Node Subcribe hay Publish đến là địa chỉ kiểu
Group hoặc Virtual. Nó giúp cho quá trình tổ chức cũng như điều khiển, bảo trì hệ
thống mạng được diễn ra dễ dàng hơn.

39
 Hình 2.27. Cơ chế Publish - Subcribe

2.5. Quá trình Provisioning

Provisioning là quá trình cấu hình để một Device có thể tham gia vào mạng
BLE Mesh và trở thành một Node. Đây là bước bắt buộc phải thực hiện trước khi một
thiết bị có thể gửi hoặc nhận gói tin trong mạng.

Hình 2.28. Quá trình Provisioning cho thiết bị

Việc Provisioning thường được thực hiện bởi một ứng dụng trên Smartphone
hoặc Tablet, hoặc những thiết bị có cấu hình mạnh mẽ hơn. Những thiết bị này được
gọi là Provisioner.

40
 Quá trình Provisioning được chia thành 5 giai đoạn chính, chúng bao gồm:
+ Beaconing: một Device sẽ phát ra gói tin bằng cách sử dụng GATT
Bearer hoặc Advertising Bearer để gửi yêu cầu gia nhập mạng tới các
Provisioner.
+ Invitation: sau khi Provisioner phát hiện được thiết bị phù hợp, nó sẽ
gửi một gói tin đến thiết bị đó. Nếu nhận được gói tin phản hồi, quá trình cấu hình
sẽ được bắt đầu.
+ Trao đổi Public Key: một khoá công khai được trao đổi giữa 2 thiết bị.
+ Authentication: đây là quá trình phục vụ cho việc xác nhận, thường
được thực hiện bởi người dùng.
+ Phân phối dữ liệu Provisioning: sau khi việc xác nhận hoàn tất, một
khoá bảo mật sẽ được lưu trữ ở cả 2 phía, được sử dụng cho các quá trình trao đổi dữ
liệu diễn ra sau này.
Sau khi kết thúc 5 quá trình trên, một thiết bị sẽ trở thành một Node và có thể
tham gia việc truyền và nhận dữ liệu với các Node khác trong mạng BLE Mesh.
Nếu quá trình Provisioning được thực hiện bởi ứng dụng trên Smartphone, thì
việc trao đổi dữ liệu sẽ thông qua một GATT Service có tên gọi là Mesh Provisioning
Service, với các thuộc tính được trình bày trong bảng 2.9 bên dưới.
Bảng 2.16. Các thuộc tính của Mesh Provisioning Service
Thuộc tính Mô tả
Mesh Provisioning Data In Cho phép ghi không cần phản hồi
Mesh Provisioning Data Out Dùng để thông báo

41
 Hình 2.29. Các giao thức thực hiện trong quá trình Provisioning

2.6. Generic Level Model

Có nhiều loại Model được nhóm vào Generic Model, chúng thực hiện các chức
năng cơ bản của người dùng như dùng để bật - tắt thiết bị, thông báo dung lượng pin,…
Trong phạm vi báo cáo, Generic Level Model được sử dụng như là một Model chính,
với cả Level Server và Level Client.
Trạng thái của Level Model là một số nguyên có dấu dài 16 bit, dùng để đại
diện trạng thái hiện tại của một phần tử trong Node.

2.7. Kết nối LPN - Friend

Để LPN có thể hoạt động ở chế độ tiết kiệm năng lượng, nó cần thành lập một
kiểu kết nối đặc biệt với Friend Node, được gọi là Friendship. Để một LPN và một
Friend có thể thành lập được Friendship, chúng bắt buộc phải ở cùng một Subnet trong
mạng.

42
 Hình 2.30. Quá trình thành lập kết nối Friendship
Khi kết nối được thành lập, Friend Node sẽ thực hiện hoạt động nhận các tin
nhắn được gửi đến LPN và lưu trữ nó vào bộ nhớ của mình trong một vùng gọi là
Friend Queue, giúp LPN có thể dành phần lớn thời gian của mình để đi vào chế độ ngủ
sâu. LPN sẽ thức dậy để yêu cầu các tin nhắn đó và xử lý theo một chu kỳ được cấu
hình từ trước, được gọi là Poll Timeout. Nếu vượt quá thời gian Poll Timeout mà LPN
vẫn không gửi các gói tin truy vấn đến Friend Node, hoặc Friend Node không phản hồi
lại LPN, thì kết nối Friendship sẽ bị huỷ bỏ. Khi đó LPN sẽ tìm một Friend Node mới
để có thể tiếp tục hoạt động trong chế độ tiêu tốn ít năng lượng.

43
 Hình 2.31. Quá trình huỷ bỏ kết nối Friendship

2.8. Bảo mật trong mạng BLE Mesh

2.8.1. Tổng quan
Một trong những vấn đề được quan tâm nhất khi nói đến Internet of Things
(IoT) là bảo mật. Từ những căn hộ thông minh, và những khu đô thị thông minh, cho
đến những hệ thống quản lí giao thông, hệ thống IoT và công nghệ được sử dụng sẽ tác
động đến rất nhiều khía cạnh cuộc sống của chúng ta. Sự cố bảo mật trong hệ thống
IoT sẽ gây ra hậu quả nghiêm trọng.
BLE Mesh được thiết kế với ưu tiên bảo mật được đặt lên đầu. Từ đó có thể xây
đựng một hệ thống IoT đáng tin cậy, an toàn.
Mọi mạng BLE Mesh phải thoả mãn được những yêu cầu dưới đây nhằm đảm
bảo thật sự bảo mật.
44
 Bảng 2.17. Các yêu cầu bảo mật trong mạng BLE Mesh
Mọi tin nhắn trong BLE Mesh phải được mã hóa và
Mã hóa và chứng thực
chứng thực
Bảo mật mạng, bảo mật ứng dụng, bảo mật thiết bị
Sự riêng biệt
được triển khai riêng biệt
Một mạng BLE Mesh có thể chia thành nhiều mạng
Sự cô lập về mạng
con, mỗi mạng con được mã hóa cô lập với nhau
Khóa mã hóa có thể được thay đổi trong quá trình sử
Làm mới khóa dụng mạng BLE Mesh thông qua thủ tục làm mới
khóa.
Tin nhắn được làm rối khiến cho việc theo dõi gói tin
Tin nhắn được làm rối
trong mạng trở nên vô cùng khó
Chống được Replay Attack BLE Mesh có thể bảo mật mạng khỏi Replay Attack
Chống được Trashcan Quá trình tháo bỏ Node khỏi mạng an toàn, chống
Attack được Trashcan Attack
Quá trình Provisioning thiết Quá trình thêm Node vào mạng BLE Mesh là một quá
bị an toàn trình được đảm bảo an toàn

2.8.2. Key bảo mật

Bảo mật trong BLE sử dụng ba loại khóa bảo mật, có ba vai trò khác nhau:
+ Khóa thiết bị (Device key hay DevKey): Được sử dụng trong quá trình
Provisioning và thiết lập Node.
+ Khóa mạng (Network key hay NetKey): Mọi Node trong mạng đều sở
hữu một hoặc nhiều khóa mạng, mỗi khóa mạng cho phép tham gia vào một
mạng con, khóa mạng được sử dụng để sinh ra các khóa bảo mật trong tầng mạng.
+ Khóa ứng dụng (Application key hay Appkey): được sử dụng trong quá
trình mã hóa và giải mã tin nhắn ứng dụng.

45
2.8.3. Quá trình Remove Node, Key Refesh
Trong vài trường hợp như xuất hiện sự cố trong phần cứng hoặc phần mềm, quá
trình tháo Node khỏi mạng là cần thiết. Để thực hiện việc tháo bỏ Node ta cần phải
thêm Node vào danh sách đen và làm mới khóa. Một thiết bị được cho vào danh sách
đen dẫn đến mọi Node trong mạng không thể gửi gói tin tới địa chỉ của thiết bị đó.
Quá trình làm mới khóa bao gồm ba bước:
+ Bước một bao gồm việc phân phát khóa mới. Các Node sẽ tiếp tục gửi
tin bằng khóa cũ và nhận tin được từ cả khóa mới và khóa cũ.
+ Bước hai bao gồm gửi một tín hiệu Beacon, nhằm thông báo đến
mạng rằng mọi Node đã nhận được khóa mới. Các Node sẽ sử dụng khóa mới
cho việc gửi tin, việc nhận tin vẫn sử dụng cả hai khóa cũ và mới.
+ Bước ba bao gồm gửi tín hiệu Beacon khác, thông báo đến mạng việc
loại bỏ khóa cũ hoàn toàn. Các Node hoàn toàn sử dụng khóa mới cho quá
trình nhận và gửi.

Hình 2.32. Các giai đoạn làm mới khoá

46
3. Giới thiệu về Radio Board BRD4104A
3.1. Tổng quan
BRD4104A là một board mạch phát sóng không dây có tích hợp một vi điều
khiển 32 bit của Silabs, được thiết kế để phát triển các ứng dụng dựa trên nền công
nghệ BLE.
Bộ phát sóng RF hoạt động trên băng tầng 2.4 GHz ISM, với khoảng tần số từ
2400 đến 2483.5 MHz. Trọng tâm của bộ phát sóng là một ăn teng Inverted-F, với
công suất phát sóng tối đa là 10 dBm.
Ngoài ra, trên BRD4104A còn bao gồm một Serial Flash 8 Mbit giao tiếp thông
qua kết nối SPI và một Serial EEPROM giao tiếp thông qua kết nối I 2C, với thiết kế
được tối ưu về năng lượng tiêu thụ khi hoạt động, chúng được sử dụng để mở rộng
dung lượng lưu trữ cho người dùng mà vẫn đảm bảo tốt hiệu năng của thiết bị.

Hình 3.33. Sơ đồ khối của Radio Board BRD4104A

47
3.2. Wireless MCU
3.2.1. Các thông số chính
Wireless MCU được tích hợp trên Radio Board có tên gọi là EFR32BG13, đây
là một dòng vi điều khiển chạy trên nền kiến trúc ARM với bộ FPU tích hợp, gồm 512
kB bộ nhớ Flash và 64 kB bộ nhớ RAM.
Dòng MCU này được thiết kế dành riêng cho các ứng dụng đòi hỏi công suất
tiêu thụ phải ở mức thấp, đặc biệt là các ứng dụng liên quan đến IoT. Vì vậy, nó bao
gồm 4 chế độ tiêu thụ năng lượng chính, từ EM0 đến EM4. Bảng 3.1 trình bày dòng
điện tiêu thụ ở các chế độ năng lượng khác nhau, trong phạm vi báo cáo, có 2 chế độ
năng lượng được sử dụng chính là EM0 (chế độ Active) và EM2 (chế độ Deep Sleep).
Bảng 3.18. Dòng tiêu thụ tương ứng ở các chế độ năng lượng của Wireless MCU
Chế độ Dòng tiêu thụ
EM0 - Active 128 µA/MHz với HFXO 38.4 MHz
EM1 - Sleep 76 µA/MHz với HFXO 38.4 MHz
EM2 - Deep Sleep 1.9 µA với LFXO 32768 Hz
EM3 - Stop 1.53 µA với ULFRCO
EM4 - Hibernate 0.45 µA với ULFRCO
EM4 - Shutoff 0.04 µA

3.2.2. Chế độ Deep Sleep

Trên Radio Board có tích hợp sẵn hai thạch anh bao gồm HFXO 38.4 MHz và
LFXO 32768 Hz. Ở chế độ EM2 - Deep Sleep, thì HFXO sẽ không còn được sử dụng
mà thay vào đó là LFXO, các ngoại vi không cần thiết lúc này như bộ phát sóng RF, bộ
Crypto hay cả CPU sẽ tạm thời bị dừng hoạt động. Việc đánh thức chúng được thực
hiện thông qua các bộ Timer hoặc External Interrupt từ các chân GPIO.
Hoạt động ở chế độ EM2 giúp tối ưu năng lượng tiêu thụ của mạch mà vẫn đảm
bảo các ngoại vi cần thiết vẫn còn hoạt động, một trong số đó là RTCC Timer và bộ
ADC, vốn là phần chính của việc thiết kế LPN trong mạng BLE Mesh.

48
 Hình 3.34. Các ngoại vi tương ứng với từng chế độ năng lượng

3.2.3. Bộ Crypto tích hợp

Một trong những phần quan trọng nhất của mạng BLE Mesh đó chính là bảo
mật. Khi triển khai hệ thống, việc mã hoá và giải mã yêu cầu phải thực hiện một cách
nhanh chóng để các công đoạn khác nhau của việc truyền và nhận dữ liệu được diễn ra
gần như đồng thời. Trên các dòng vi điều khiển trước đây, việc bảo mật dữ liệu được
xử lý bên trong phần mềm, điều này dẫn tới sự chậm trễ bởi các thuật toán mã hoá và
giải mã vốn đòi hỏi nhiều quá trình tính toán phức tạp để có thể cho ra các kết quả
đáng tin cậy. Chính vì thế, việc tích hợp một bộ Crypto riêng để giải quyết vấn đề này
là cần thiết.
Wireless MCU trên Radio Board được tích hợp sẵn một bộ Cryptographic, giúp
thực hiện nhanh chóng các loại mã hoá thông dụng như AES và SHA. Trong giao thức
BLE Mesh, dữ liệu khi gửi đi sẽ được mã hoá bằng AES 128 bit, việc này được thực
hiện tự động ở tầng Link Layer.

49
 Hình 3.35. Bộ Crypto tích hợp trên Wireless MCU

3.2.4. Gecko Bootloader

Bootloader là một chương trình được lưu trữ trong bộ nhớ Flash để phục vụ cho
việc khởi tạo hoạt động của thiết bị hoặc cập nhật các phiên bản phần mềm. Khi một
thiết bị được cấp nguồn khởi động, Bootloader sẽ là chương trình chạy đầu tiên, sau đó
mới tới chương trình ứng dụng của người dùng.
Các dòng SoC dùng để phát triển các ứng dụng dựa trên BLE của Silabs đều
được trang bị một Bootloader với cấu trúc riêng gọi là Gecko Bootloader. Bootloader
này được chia làm 2 phần, với kích thước tổng cộng là 16 kB. Phần đầu tiên được gọi
là Init Bootloader (hay First Stage), có kích thước 2 kB. Phần thứ hai được gọi là Main
Bootloader, có kích thước 14 kB.
Với dòng EFR32BG13, ta có địa chỉ của các phân vùng trên bộ nhớ Flash được
phân chia như sau:
+ Phân vùng ứng dụng: 0x00
+ Phân vùng First Stage: 0x0FE10000
+ Phân vùng Main Bootloader: 0x0FE10800

50
 Hình 3.36. Phân vùng của Gecko Bootloader
Một trong những chức năng chính của Bootloader là để cập nhật phần mềm. Có
hai cách cập nhật chính bao gồm có dây (thông qua các kết nối như UART, SPI,…) và
không dây (thông qua mạng không dây như Bluetooth, gọi là OTA - Over The Air).
Gecko Bootloader hỗ trợ cập nhật theo cả hai cách này với File Image có định dạng
theo kiểu GBL (.gbl).
Việc cập nhật phần mềm trong mạng BLE Mesh được thực hiện thông qua kết
nối không dây OTA. File mã nguồn được chuyển thành định dạng GBL và quá trình
cập nhật được tiến hành thông qua một ứng dụng trên Smartphone. Silabs cung cấp
một GATT Service gọi là OTA Control, giúp hỗ trợ quá trình cập nhật phần mềm được
diễn ra thuận lợi hơn.

3.3. Bluetooth Mesh SDK

Để thực thi các ứng dụng BLE Mesh trên Radio Board BRD4104A, Silabs cung
cấp một SDK với nhiều API được viết sẵn. Bộ SDK này còn được gọi là Silabs Mesh
Stack, nơi thực thi tất cả các phần liên quan trong bộ giao thức mạng của BLE Mesh,
bao gồm các công việc cơ bản như truyền và nhận gói tin, mã hoá và giải mã cho đến
chuyển tiếp dữ liệu tự động giữa các Node trong mạng.
Việc chạy trên nền một Wireless MCU được tối ưu về công suất tiêu thụ đòi hỏi
Mesh Stack cũng phải tiêu tốn ít năng lượng khi hoạt động. Hai thành phần phần cứng
quan trọng bắt buộc phải có để Mesh Stack hoạt động là RAM và RTCC Timer. Khi
thiết bị rơi vào chế độ EM2 - Deep Sleep để tiết kiệm điện năng, nó sẽ được Mesh
Stack đánh thức chủ yếu bằng RTCC Timer hoặc các Interrupt sinh ra từ những ngoại
vi còn đang hoạt động ở chế độ EM2.

51
4. Hệ thống báo cháy sử dụng công nghệ BLE Mesh
4.1. Giới thiệu
Các vụ hoả hoạn thường gây ra những thiệt hại nghiêm trọng về con người và
tài sản, đặc biệt là các đám cháy xảy ra tại những khu dân cư đông đúc hay các toà nhà
cao tầng, vốn rất khó để di tản người dân đang sinh sống. Vì vậy, việc phát triển một hệ
thống báo cháy có thể triển khai trên quy mô rộng lớn là cần thiết. Hiện nay, trên thị
trường đang được thương mại hoá nhiều loại thiết bị báo cháy khác nhau, chúng
thường được chia thành hai nhóm chính là báo cháy có dây và báo cháy không dây.
Các hệ thống báo cháy có dây đã xuất hiện từ hàng chục năm trước, chúng được
lắp ráp và triển khai ở các toà nhà, chung cư. Ưu điểm chính của hệ thống này là độ trễ
của tín hiệu báo động rất thấp, có thể đáp ứng gần như tức thời. Tuy nhiên, nó cồng
kềnh và khó triển khai trên quy mô rộng lớn, cũng như khó khăn khi bảo trì, nâng cấp.
Hệ thống báo cháy không dây xuất hiện sau này, mang những ưu điểm tích cực
hơn nhiều so với các hệ thống cũ. Các hệ thống báo cháy không dây bao gồm nhiều
đầu dò khói, nhiệt thực hiện việc truyền nhận gói tin thông qua sóng RF, chúng đảm
nhận nhiệm vụ thu thập thông tin và gửi về bộ xử lý trung tâm để đưa ra tín hiệu báo
động khi có sự cố. Chính vì không kết nối trực tiếp với nhau bằng dây, ta có thể dễ
dàng thay thế, nâng cấp từng thiết bị riêng lẻ mà không ảnh hưởng đến hoạt động của
toàn bộ hệ thống. Tuy vậy, việc truyền nhận dữ liệu qua sóng không dây RF cũng có
những mặt hạn chế nhất định, đặc biệt là vấn đề về nhiễu và độ trễ của các gói tin.

Hình 4.37. Hệ thống báo cháy không dây

52
 Các thiết bị báo cháy không dây hiện nay phần lớn hoạt động trên băng tầng 433
MHz với khoảng cách truyền sóng tốt nhất vào khoảng 100 mét, chúng đòi hỏi một bộ
xử lý trung tâm để đảm nhận vai trò xử lý dữ liệu thu về. Các đầu dò khói, nhiệt thông
thường chỉ có thể trao đổi dữ liệu trực tiếp với bộ xử lý, điều này đặt ra một hạn chế
lớn khi khoảng cách giữa chúng vượt ra ngoài phạm vi phủ sóng RF. Hơn nữa, trong
phạm vi phủ sóng của mỗi đầu dò cần phải có một bộ xử lý đi kèm, vốn rất tốn kém về
chi phí lắp đặt.
Với sự phát triển của công nghệ hiện nay, đặc biệt là sự xuất hiện của khái niệm
Internet of Things (IoT), các thiết bị điện tử có thể kết nối với nhau tạo thành một
mạng lưới hoạt động ở quy mô rất lớn. Một trong số những công nghệ đó chính là
Bluetooth Low Energy Mesh (BLE Mesh).
Trong phạm vi báo cáo sẽ trình bày chi tiết về các bước triển khai hệ thống báo
cháy không dây dựa trên nền công nghệ BLE Mesh, hệ thống được thiết kế để sử dụng
chính trong các chung cư và toà nhà cao tầng. Như đã trình bày ở mục 2, mỗi thiết bị
trong mạng BLE Mesh có thể trao đổi dữ liệu trực tiếp với nhau, cũng như chuyển tiếp
chúng đến một thiết bị xử lý thông tin khác mà người dùng mong muốn. Ngoài ra, ta có
thể phát triển tối đa lên đến 32767 thiết bị cho một hệ thống báo cháy, con số này là
quá đủ để lắp đặt cho các toà nhà cao tầng hiện nay.
Mục tiêu đặt ra cho việc thiết kế hệ thống báo cháy sẽ được trình bày trong bảng
4.1 bên dưới, các phần triển khai của hệ thống sẽ tập trung vào việc đáp ứng các mục
tiêu thiết kế này.

Bảng 4.19. Mục tiêu thiết kế của hệ thống

Độ trễ gói tin báo động thấp
Phát hiện thiết bị chết, ngưng hoạt động trong thời gian ngắn
Dữ liệu truyền trong mạng được bảo mật an toàn
Quá trình thêm, bớt thiết bị trong mạng được an toàn
Mục tiêu thiết kế
Mô hình mạng dễ dàng triển khai và mở rộng, nâng cấp
hệ thống báo cháy
Triển khai được tối đa số lượng thiết bị trong mạng BLE Mesh
Cập nhật phần mềm mới thông qua cơ chế không dây
Có ứng dụng với giao diện giám sát và cấu hình trực quan
Thời gian sử dụng thiết bị cảm biến đủ lâu

53
4.2. Tính năng chính của hệ thống

Hình 4.38. Sơ đồ tổng quan hệ thống báo cháy dùng công nghệ BLE Mesh
Hệ thống báo cháy sử dụng công nghệ BLE Mesh bao gồm bốn thành phần
chính với các chức năng tổng quát như sau:
+ Thiết bị Gateway Node: đây là ngõ ra của dữ liệu trong toàn mạng.
Chúng dùng để gửi và đồng bộ dữ liệu lên Internet, đảm bảo cho người dùng có
thể giám sát hệ thống ở nhiều nơi khác nhau chứ không cần phải đến trực tiếp
từng nơi riêng lẻ trên toà nhà.
+ Thiết bị Friend Node: dùng để chuyển tiếp gói tin từ các đầu dò khói,
nhiệt đến Gateway Node, cũng như chịu trách nhiệm chính trong việc quản lý
hoạt động của các đầu dò khói, nhiệt này.
+ Thiết bị LPN: đây là các đầu dò khói, nhiệt được tích hợp mạch phát
sóng không dây cùng với một vi điều khiển để xử lý thông tin cục bộ. Chúng là
thành phần rất quan trọng trong hệ thống báo cháy, chịu trách nhiệm chính trong
việc phát hiện ra các dấu hiệu có thể xảy ra hoả hoạn như nhiệt độ tăng cao đột
ngột hay khói sinh ra từ đám cháy. Các thiết bị này hoạt động nhờ nguồn điện
được cung cấp từ pin, do đó, chúng phải đảm bảo việc tiêu tốn ít năng lượng
nhưng vẫn có thể duy trì hoạt động tốt.

54
 + Ứng dụng trên Smartphone: việc giám sát cũng như cấu hình cho các
thiết bị trong hệ thống báo cháy được thực hiện hoàn toàn thông qua một ứng
dụng trên điện thoại Android. Đây là một trong những ưu điểm chính khi so
sánh với các hệ thống báo cháy có dây hay không dây truyền thống, ứng dụng cung
cấp một giao diện trực quan, dễ dàng sử dụng cho người dùng.
Có thể thấy, các thiết bị trong hệ thống báo cháy đều tương quan với các thành
phần trong mạng BLE Mesh. Khi triển khai hệ thống, nhóm hoàn toàn dựa theo các đặc
điểm hoạt động của mạng BLE Mesh, chính điều này giúp hệ thống có thể dễ dàng mở
rộng và phát triển thêm nhiều tính năng khác trong tương lai.
Hệ thống được triển khai trên các thiết bị Blue Gecko của Silabs, các thông số
cũng như các khối cơ bản của thiết bị này đã được trình bày ở mục 3 bên trên. Blue
Gecko là một dòng SoC không dây dùng cho các ứng dụng đòi hỏi công suất tiêu thụ
thấp, chính vì thế, các thiết bị LPN trong mạng có dòng điện tiêu thụ trung bình luôn ở
mức µA, giúp nâng cao thời gian hoạt động của chúng chỉ với một viên pin đồng xu
CR2032.
Với các thiết bị được trình bày bên trên, sau khi liên kết chúng lại thành một
mạng lưới để hoạt động, hệ thống báo cháy mà nhóm thực hiện có 5 tính năng chính
như sau:
+ Tín hiệu báo cháy được truyền đến Gateway Node gần như tức thời.
Khi có sự cố xảy ra, LPN với các đầu dò khói, nhiệt sẽ phát hiện đám cháy, sau đó
gửi tín hiệu khẩn cấp đến Friend Node, Friend Node sẽ ngay lập tức gửi gói tin này
đến Gateway Node để có thể hiển thị cảnh báo lên ứng dụng trên Smartphone
của người dùng.
+ Còi báo động được gắn trực tiếp trên mỗi thiết bị LPN. Vị trí của đám
cháy sẽ được dễ dàng phát hiện nhờ vào còi báo động, giúp người dân có thể
nhận biết và di tản kịp thời. Đồng thời, vị trí của nơi xảy ra sự cố cũng được nhận biết
qua ứng dụng trên Smartphone, với tên, địa chỉ được người dùng cấu hình từ
trước.
+ Thời gian sử dụng của LPN lên đến 10 tháng chỉ với một viên pin
CR2032 có dung lượng 220 mAh. Một viên pin đồng xu hiện tại trên thị trường
được bán với giá khoảng 15.000 VNĐ, vì vậy người dùng chỉ cần bỏ ra một
khoảng tiền khá ít ỏi để có thể duy trì hoạt động của thiết bị.

55
 + Số thiết bị tối đa có thể triển khai là 128 thiết bị. Do những hạn chế về
thời gian thực hiện, số lượng thiết bị trong hệ thống báo cháy của nhóm chỉ
dừng lại ở con số này.
+ Có thể phát hiện một thiết bị ngừng hoạt động trong thời gian tối đa là
1 phút. Với hệ thống báo cháy được sử dụng trong một thời gian dài, việc phát
hiện các thiết bị có còn hoạt động tốt hay không là một việc vô cùng quan trọng. Ở
các hệ thống báo cháy truyền thống, việc này được thực hiện thủ công thông qua
công tác bảo trì, tuy nhiên, nó bộc lộ rất nhiều hạn chế, đặc biệt khi không phát hiện
kịp thời các vị trí bị hư hỏng dẫn đến những hậu quả đáng tiếc. Với hệ thống
báo cháy sử dụng BLE Mesh, các Node trong mạng sẽ kiểm tra trạng thái của các
Node khác thông qua việc gửi tín hiệu báo cáo theo chu kỳ. Chính vì thế, có thể
dễ dàng thông báo cho người dùng biết vị trí thiết bị không còn hoạt động để dễ
dàng thay thế cũng như đưa ra các biện pháp xử lý phù hợp. Sau khi tối ưu các
thông số liên quan về năng lượng, lưu lượng gói tin truyền trong mạng, hệ thống
báo cháy của nhóm có thể nhận biết trạng thái hoạt động của một Node chỉ
trong vòng 1 phút, rất nhanh so với nhiều hệ thống khác đang được triển khai hiện tại.
+ Mã hoá dữ liệu trong toàn mạng. Dữ liệu được truyền đi trong hệ thống
được mã hoá dựa trên tầng bảo mật của bộ giao thức mạng BLE Mesh, với kỹ
thuật mã hoá AES 128 bit. Thêm nữa, để đảm bảo nhiều hơn việc bảo mật, mỗi
2 byte dữ liệu của gói tin truyền đi trong mạng cũng được mã hoá dựa trên phép
toán XOR với một khoá có độ dài là 16 bit. Các quá trình truyền dữ liệu trực
tiếp giữa Gateway Node với Smartphone cũng được mã hoá AES với một khoá bảo
mật riêng. Việc bảo mật dữ liệu người dùng tới 2 lớp giúp ngăn chặn các
cuộc tấn cộng mạng nhằm vào việc phá hoại, đưa ra các thông báo sai lệch trong
hệ thống.

56
4.3. Kiến trúc mạng triển khai
Hệ thống báo cháy được triển khai dựa trên công nghệ BLE Mesh, nên các thiết
bị trong hệ thống cũng hoạt động cơ bản dựa trên kiến trúc mạng của công nghệ này.
Tuy nhiên, để có thể đáp ứng được nhu cầu riêng phục vụ cho việc báo cháy, nhóm đã
loại bỏ các Node chỉ có chức năng đơn thuần là một phần tử trong mạng, mà thay vào
đó, tiến hành kết hợp các chức năng như Relay, Proxy, Friend, Low Power để tối ưu số
lượng cũng như số loại thiết bị trong mạng.
Với 4 thành phần chính đã được trình bày ở mục trên, tính năng của mỗi thiết bị
tương ứng như sau:
+ Thiết bị Gateway Node: bao gồm tính năng Relay và Proxy.
+ Thiết bị Friend Node: bao gồm tính năng Relay, Proxy và Friend.
+ Thiết bị Low Power: chỉ bao gồm tính năng Low Power.
+ Ứng dụng trên Smartphone: thực thi chức năng của một Provisioner.
Hệ thống mạng được nhóm triển khai theo kiến trúc phân tầng thiết bị, bao gồm
2 tầng chính như sau:
+ Tầng Gateway - Friend: đây là các thiết bị chịu trách nhiệm chính trong
việc xử lý dữ liệu, đưa ra các thông báo tới người dùng cuối.
+ Tầng Friend - Low Power: chịu trách nhiệm chính trong việc thu thập
dữ liệu, cũng như phát hiện các dấu hiệu của sự cố.

Hình 4.39. Kiến trúc mạng của hệ thống báo cháy dùng công nghệ BLE Mesh
57
 Với kiến trúc mạng này, dữ liệu từ LPN chỉ được gửi trực tiếp tới Friend Node
và chỉ Friend Node mới gửi dữ liệu đến Gateway Node mà thôi, điều này giúp ta có thể
dễ dàng quản lý hoạt động cũng như sửa chữa hay nâng cấp hệ thống. Có thể hình dung
đơn giản, mỗi tầng của một toà nhà sẽ bao gồm một Friend Node và nhiều LPN, các
tầng này liên kết với nhau nhờ hoạt động của các Friend Node và Gateway Node. Khi
một thiết bị LPN bị hư hỏng, người dùng chỉ việc đơn giản thay thế chúng mà không
cần quan tâm việc ảnh hưởng đến hoạt động của các Node còn lại trong mạng. Điều
này giúp hệ thống trở nên linh động hơn, mang nhiều ý nghĩa phục vụ cho việc mở
rộng cũng như nâng cấp thêm chức năng mới sau này.

4.4. Năng lượng tiêu thụ của mạng

Lượng điện năng tiêu thụ là một khía cạnh rất được quan tâm khi triển khai các
hệ thống báo cháy ngày nay. Đặc biệt là khi các đầu dò khói, nhiệt sử dụng nguồn điện
được cung cấp từ pin. Nếu không đề cập tới Smartphone ở phía người sử dụng vốn
được chạy bằng các viên pin đi kèm, thì ba thành phần còn lại trong hệ thống có nguồn
điện cung cấp như sau:
+ Gateway Node: cấp nguồn liên tục từ Adapter. Đây là nơi tiếp nhận dữ
liệu của toàn mạng, vì thế nó phải luôn luôn hoạt động để duy trì sự liên kết
giữa hệ thống báo cháy với người dùng.
+ Friend Node: cấp nguồn liên tục từ Adapter. Các Friend Node chịu
trách nhiệm chính trong việc chuyển tiếp tín hiệu báo cháy tới Gateway, vì thế, chúng
cũng phải luôn luôn hoạt động để có thể truyền nhận dữ liệu một cách nhanh
nhất.
+ LPN: sử dụng năng lượng từ pin. Các LPN có thể được chia ra thành 2
thành phần cơ bản, đầu dò khói, nhiệt và mạch phát sóng RF BRD4104A. Hiện
tại nhóm sử dụng 2 viên pin để cung cấp năng lượng cho 2 thành phần này, một
viên pin CR2032 để cấp điện cho BRD4104A, một viên pin 9V để cấp điện cho
đầu dò cảm biến. Vì đầu dò khói, nhiệt được cung cấp nguồn riêng với thời gian
hoạt động cũng vào khoảng 10 tháng, ở các phần sau sẽ không thảo luận thêm
nữa về công suất tiêu thụ của thành phần này, mà thay vào đó sẽ tập trung chính
vào lượng điện năng tiêu thụ của board mạch BRD4104A.

58
 Với công cụ mô phỏng Energy Profiler và bộ giám sát năng lượng AEM, nhóm
đã đo được dòng tiêu thụ trung bình của 3 loại Node trên, cụ thể như sau:
+ Gateway Node: xấp xỉ 10 mA.
+ Friend Node: xấp xỉ 10 mA
+ LPN: xấp xỉ 30 µA.

4.5. Cơ chế truyền gói tin trong mạng

Các gói tin trong toàn mạng của hệ thống được truyền dưới dạng Level Model,
với kích thước dữ liệu người dùng chứa trong mỗi gói tin là 2 byte. Vì con số này khá
ít, nên nhóm đã chia thứ tự các bit trong 2 byte này thành 4 phần, bao gồm:
+ Alarm Signal (1 bit): chứa tín hiệu báo động.
+ Unicast Address (7 bit): chứa địa chỉ Unicast của mỗi Node được cấp
trong quá trình Provisioning. Với 7 bit, ta có tối đa 27 = 128 thiết bị.
+ Heartbeat (1 bit): chứa tín hiệu báo cáo trạng thái hoạt động của một
Node, nếu Heartbeat có giá trị là 0, thì tương ứng với Node đã ngưng hoạt động.
+ Battery Percentage (7 bit): dùng để thông báo dung lượng pin của thiết
bị theo đơn vị phần trăm.

Hình 4.40. Cấu trúc gói tin trong hệ thống báo cháy

59
 Khi LPN phát hiện dấu hiệu xảy ra đám cháy, nó sẽ ngay lập tức gửi gói tin đến
Friend Node được đặt ở vị trí lân cận. Sau đó, Friend Node sẽ gửi trực tiếp hoặc thông
qua cơ chế Relay và chuyển tiếp gói tin này đến Gateway. Gói tin này được
Advertising đến Smartphone, giúp người dùng có thể nhận biết và đưa ra biện pháp xử
lý kịp thời.

Hình 4.41. Đường đi gói tin báo cháy trong hệ thống

4.6. Lưu lượng gói tin trong mạng

Do kiến trúc mạng triển khai được phân thành hai tầng chính, nên ta cũng sẽ
thảo luận về lưu lượng gói tin được truyền đi trong 2 tầng này, mà cụ thể là lượng gói
tin trao đổi ở LPN và Gateway Node.
Ở tầng Friend - Low Power, tín hiệu báo cáo trạng thái hoạt động sẽ được LPN
gửi đến Friend Node mỗi 15 giây một lần, còn giá trị Poll Timeout khi chúng thành lập
kết nối Friendship là 60 giây, khi nhận biết được đám cháy, thì gói tin của LPN sẽ
được gửi đi ngay lập tức. Giả sử thiết bị hoạt động trong điều kiện không có sự cố xảy
ra, chỉ đang lắng nghe các trạng thái từ môi trường, thì ta có thể tính số gói tin được
gửi đi trong 1 giờ là 3600/15 + 3600/60 = 300 gói tín. Mỗi gói tin có độ dài dữ liệu
người dùng là 2 byte, cho nên trong 1 giờ, dữ liệu được truyền đi sẽ là 600 byte.

60
 Ở tầng Gateway - Friend, số lượng gói tin trao đổi sẽ nhiều hơn hẳn. Gateway
cứ mỗi 2 giây sẽ tiến hành Advertising dữ liệu của mạng ra bên ngoài, số sự kiện
Advertising mỗi lần là 3 sự kiện, đồng thời, mỗi 15 giây nó cũng gửi tín hiệu báo cáo
trạng thái hoạt động cho các Friend Node. Các Friend Node tương tự, cứ mỗi 15 giây
cũng gửi gói tin báo cáo trạng thái của nó cho Gateway, kèm theo đó là các gói tin
chứa dữ liệu của LPN. Giả sử hệ thống hoạt động ở điều kiện không có đám cháy xảy
ra, trong toàn mạng có tổng cộng 25 Friend Node, mỗi Friend Node quản lý 5 Low
Power Node, mỗi sự kiện Advertising sẽ gửi 3 gói tin, thì ta có thể tính toán được các
gói tin gửi và nhận của Gateway trong 1 giờ như sau:
+ Số gói tin gửi đi: 3600*3*3/2 + 3600/15 = 16440 gói tin.
+ Số gói tin nhận lại: 3600*25*5/15 = 30000 gói tin.
Từ những tính toán trên, có thể thấy lưu lượng gói tin trong mạng tập trung phần
lớn ở tầng Gateway - Friend Node, chính vì thế các thiết bị này đòi hỏi phải có một cấu
hình mạnh hơn nhiều so với LPN cũng như cần luôn luôn được cấp nguồn để có thể
duy trì tốt hoạt động.

4.7. Độ trễ tín hiệu

Mặc dù gói tin được LPN gửi đi ngay lập tức khi phát hiện được các dấu hiệu
của đám cháy, nó vẫn bị ảnh hưởng bởi nhiều yếu tố khác trong thực tế như công suất
phát sóng của bộ RF, độ nhiễu của môi trường truyền, tốc độ xử lý thông tin của vi
điều khiển,… Chính vì vậy, để gói tin từ LPN đi tới Gateway Node, ta thực sự sẽ tốn
một khoảng thời gian, ở phạm vi triển khai hệ thống với quy mô nhỏ như nhóm đã thực
hiện, chỉ gồm 1 Gateway Node, 2 Friend Node và 3 LPN, thì độ trễ này có thể bỏ qua
và xem gần như là tức thời.

61
5. Gateway Node
5.1. Tính năng chính
Gateway Node là một thành phần rất quan trọng trong hệ thống mạng BLE
Mesh, đây là nơi mà dữ liệu trong mạng được truyền ra bên ngoài, đặc biệt là Internet.
Trong phạm vi báo cáo của nhóm, Gateway Node được thiết kế để thực hiện hai chức
năng chính:
+ Gửi dữ liệu của toàn hệ thống đến Smartphone và các thiết bị Dongle.
+ Kiểm tra tình trạng hoạt động của các Friend Node.
Dongle là một thiết bị dùng để quét các gói tin BLE được Advertising bởi
Gateway, sau đó xử lý chúng và chuyển tiếp lên một Server trên Internet để lưu trữ,
phục vụ cho các nhu cầu truy xuất dữ liệu từ nhiều thiết bị khác nhau. Hệ thống báo
cháy mà nhóm thực hiện không bao gồm thiết bị này, mà thay vào đó là dùng
Smartphone để quét trực tiếp các gói tin BLE, sau đó tiến hành xử lý và hiển thị lên
giao diện của ứng dụng. Điều này có một hạn chế nhất định, đó là người dùng chỉ có
thể cập nhật dữ liệu của mạng BLE Mesh khi đứng trong vùng phủ sóng của Gateway
Node mà thôi.

5.2. Sơ đồ hoạt động

Hoạt động của Gateway Node bao gồm nhiều giai đoạn, mỗi giai đoạn sẽ có các
xử lý khác nhau. Ở mức độ tổng quan, ta có sơ đồ khối minh hoạ cách hoạt động chung
của Gateway Node như sau:

62
 Hình 5.42. Sơ đồ hoạt động của Gateway Node
Đầu tiên, thiết bị sẽ khởi tạo các ngoại vi và bộ nhớ cần thiết phục vụ cho quá
trình hoạt động, chúng bao gồm:
+ Mảng động để lưu dữ liệu: bao gồm 2 mảng chính, mảng lưu các địa
chỉ của Friend Node dùng cho việc kiểm tra hoạt động của chúng (được gọi là mảng
STATUS), và mảng lưu dữ liệu của toàn bộ các Node trong mạng dùng cho việc
Advertising dưới dạng gói tin BLE (được gọi là mảng DATA). Tất cả các mảng
đều là mảng động, giúp việc sử dụng được linh hoạt và tối ưu hoá bộ nhớ của
thiết bị. Hình 5.2 bên dưới trình bày cấu trúc của hai loại mảng này.

Hình 5.43. Cấu trúc dữ liệu lưu trữ trong Gateway Node
+ Các xung clock: Gateway luôn luôn hoạt động ở chế độ EM0 - Active,
vì vậy, nó sử dụng xung clock từ HFXO 38.4 MHz cho các công việc xử lý
chính của CPU. Đồng thời, quá trình hoạt động của Mesh Stack cũng yêu cầu một
RTCC Timer, Timer này có xung clock được cung cấp từ bộ LXFO 32768 Hz.
+ Ngoại vi: một LCD được tích hợp trên Kit phát triển đi kèm Radio
Board BRD4104A, nhóm sử dụng nó để giám sát các việc thực thi chương trình của
Gateway, đồng thời, một bộ UART dùng để hiển thị các thông tin này lên cổng
Serial của máy tính cũng được kích hoạt. Bảng 5.1 trình bày cụ thể hơn các
ngoại vi chính và chức năng tương ứng được sử dụng trong Gateway Node.

63
 Bảng 5.20. Các ngoại vi chính được sử dụng bởi Gateway Node
Ngoại vi Mô tả
Graphic LCD Hiển thị các thông tin về hoạt động của Gateway lên màn hình.
Phục vụ chính cho việc Debug khi phát triển ứng dụng, các thông
UART
tin về lỗi, sự kiện,… sẽ được gửi lên cổng Serial của máy tính.
Sử dụng LED để báo tín hiệu và một Button dùng cho việc Reset
GPIO
thiết bị về trạng thái nguyên mẫu ban đầu.
Bộ Cryptographic Dùng cho việc mã hoá dữ liệu dưới dạng AES 128 bit.

+ Các thành phần của Mesh Stack: Gateway bao gồm 2 Generic Model
là Level Server và Level Client để thực hiện quá trình gửi và nhận các gói tin
trong mạng. Level Server Model dùng để nhận các gói tin từ Friend Node và
Level Client Model dùng để gửi các gói tin thông báo trạng thái cho toàn bộ các
Friend Node trong mạng. Các lớp API của Mesh Stack mà Gateway sử dụng
được trình bày trong bảng 5.2 bên dưới.

64
 Bảng 5.21. Các lớp API được sử dụng bởi Gateway Node
Lớp API Chức năng sử dụng ở Gateway Node
Phục vụ quá trình Device Firmware Update. Gateway Node
DFU có thể nhận Firmware mới thông qua một GATT Service
được Silabs cung cấp sẵn là OTA Service.
Dùng để xử lý các phần cục bộ của Node, bao gồm việc lấy
System địa chỉ MAC, cấu hình Tx Power, thông số ở tầng Link
Layer.
BLE GAP Sử dụng cho quá trình Advertising các gói tin theo chu kỳ.
Phục vụ việc thiết lập Connection giữa Gateway Node và
BLE Connection Smartphone, trong đó, Smartphone đóng vai trò là Master, và
Gateway Node đóng vài trò là Slave.
GATT Server Dùng để truyền và nhận dữ liệu dưới dạng GATT Service.
Sử dụng để cấu hình các Timer phục vụ cho việc Advertising
Hardware
gói tin và kiểm tra trạng thái hoạt động của các Friend Node.
Địa chỉ của các Friend Node được lưu trữ trong bộ nhớ Flash,
Flash
gọi là Persistent Store.
Mesh Node Khởi tạo hoạt động cho một Mesh Node.
Bật chức năng Proxy cho Gateway, tuy nhiên, việc chức năng
Mesh Proxy này có thực sự hoạt động hay không còn phụ thuộc vào việc
cấu hình của người dùng bằng ứng dụng trên Smartphone
Nếu chức năng Proxy được người dùng kích hoạt, Gateway
Mesh Proxy Server
sẽ đóng vai trò là một Server.
Mesh Generic Phục vụ việc sử dụng các Generic Server Model, cụ thể ở đây
Server là Level Server.
Mesh Generic Client Phục vụ việc sử dụng Level Client Model.

Sau quá trình khởi tạo hoàn tất, thiết bị sẽ bắt đầu gửi gói tin để tìm kiếm
Provisioner. Gói tin được gửi ở cả 2 dạng bearer là ADV và GATT, đều này đảm bảo
cho các thiết bị không được hỗ trợ Mesh Stack như Smartphone vẫn có thể nhìn thấy
Gateway Node. Nếu quá trình Provisioning và cấu hình các thông số liên quan hoàn
tất, thiết bị sẽ trở thành một phần tử trong mạng Mesh. Các tính năng được người dùng
cấu hình lúc Provisioning phụ thuộc vào việc cài đặt Composition Data tương ứng bên
65
phía Gateway. Bảng 5.3 bên dưới trình bày các tính năng, Model và GATT Service mà
Gateway Node hỗ trợ.
Bảng 5.22. Cấu hình Mesh Feature, Model và GATT Service của Gateway Node
Proxy
Mesh Feature
Relay
Configuration Server
Model trong Primary Element Generic Level Server
Generic Level Client
Generic Access
Device Information
GATT Service Mesh Provisioning Service
Mesh Proxy Service
Silicon Labs OTA

Trước khi đi vào hoạt động chính, ta cần phải cấu hình 3 thành phần sau:
+ Một Software Timer dành cho việc Advertising gói tin BLE: đây là
một Timer được lặp lại liên tục mỗi 2 giây một lần.
+ Một Software Timer dành cho việc kiểm tra tình trạng Friend Node:
tương tự, đây cũng là một Timer được lặp lại, với chu kỳ là 15 giây một lần.
+ Hàm xử lý khi có sự kiện nhận gói tin từ Friend Node: mỗi khi nhận
được gói tin dưới dạng Level Model được Friend Node gửi tới, Gateway sẽ tự
động nhảy vào một hàm riêng để thực hiện công việc này.

66
5.3. Xử lý gói tin từ Friend Node
Như đã trình bày ở phần tổng quan của hệ thống báo cháy, dữ liệu trong toàn
mạng khi truyền sẽ được mã hoá 2 lớp. Lớp đầu tiên sử dụng phép toán XOR để mã
hoá 2 byte dữ liệu người dùng, lớp thứ hai được thực hiện bởi Mesh Stack sử dụng kỹ
thuật AES 128 bit để mã hoá toàn bộ gói tin khi truyền đi và cũng chính Mesh Stack sẽ
tự động giải mã gói tin này khi nhận được. Chính vì vậy, việc đầu tiên khi Gateway
nhận dữ liệu từ Friend Node đó chính là phải giải mã 2 byte dữ liệu được gửi dưới
dạng Level Model. Việc giải mã được thực hiện đơn giản, chỉ cần làm phép XOR
ngược dữ liệu nhận được với khoá mã hoá 16 bit.
Các gói tin được gửi đến Gateway bao gồm 2 dạng, yêu cầu phản hồi và không
yêu cầu phản hồi. Nhóm dựa vào đặc điểm này để phân biệt gói tin gửi tới là dữ liệu
thuần của Friend Node hay là dữ liệu của LPN được Friend Node lưu trữ. Việc phân
biệt này rất quan trọng, nó giúp Gateway biết được đâu là gói tin báo cáo trạng thái
hoạt động của Friend Node, để có thể cập nhật trạng thái kịp thời khi các Node này có
sự cố không mong muốn xảy ra.
Với gói tin có yêu cầu phản hồi, đây là gói tin chứa dữ liệu thuần của Friend
Node, có thể xảy ra 2 trường hợp, được giải quyết như sau:
+ Node đã có trong mảng STATUS: tiến hành cập nhật trạng thái của
Friend Node đó, đồng thời cập nhật dữ liệu của nó trong mảng DATA.
+ Node chưa có trong mảng STATUS: ta sẽ thêm nó vào cả mảng
STATUS và mảng DATA, đồng thời lưu trữ địa chỉ tương ứng vào bộ nhớ Flash.
Sau đó, Gateway sẽ gửi lại một gói tin phản hồi để Friend Node có thể biết được
trạng thái hiện tại của Gateway.
Với gói tin không yêu cầu phản hồi, đây là gói tin chứa dữ liệu của LPN, tương
tự, cũng có thể xảy ra 2 trường hợp như sau:
+ Node đã có trong mảng DATA: thực hiện việc cập nhật dữ liệu.
+ Node chưa có trong mảng DATA: sẽ thêm nó vào mảng động, ta không
cần lưu trữ dữ liệu của LPN vào bộ nhớ Flash.

67
 Hình 5.44. Cơ chế xử lý khi nhận gói tin từ Friend Node
Hình 45Hình 46Hình 47

5.4. Advertising gói tin BLE

Như đã trình bày ở mục 5.2, cứ mỗi 2 giây Gateway Node sẽ phát dữ liệu một
lần. Cụ thể hơn, mỗi lần sẽ có 3 sự kiện Advertising xảy ra với chu kỳ là 100 ms. Như
vậy, với số gói tin ở mỗi sự kiện là 3, ta có tối đa 9 gói tin sẽ được phát ra mỗi 2 giây.
Con số này là đủ lớn để có thể đảm bảo quá trình truyền dữ liệu diễn ra thành công.

Hình 5.48. Chu kỳ Advertising của Gateway Node

68
 Advertising của BLE là một quá trình phát liên tục những gói tin không được
mã hoá, vì vậy nó đặt ra những thách thức về độ an toàn của dữ liệu người dùng. Để
giải quyết vấn đề này, trước khi Advertising, dữ liệu sẽ được mã hoá sử dụng kỹ thuật
AES - ECB với khoá bảo mật có độ dài 128 bit. Việc mã hoá được thực hiện tự động
bởi bộ Cryptographic được tích hợp trên vi điều khiển.

Hình 5.49. Cấu trúc gói tin Advertising của Gateway Node
Để các thiết bị như Dongle hay Smartphone có thể nhận được và xử lý chính
xác, gói tin Advertising được đóng gói lại theo một chuẩn chung cho trước. Hình 5.5
bên trên trình bày cấu trúc gói tin mà Gateway Node phát ra. Với kích thước dữ liệu
người dùng là 16 byte. Vì vậy, có tối đa thông tin của 8 Node trong mạng chứa trong
mỗi lần phát. Với trường hợp số Node trong mạng nhiều hơn 8, Gateway sẽ tự động
chia tách chúng ra thành nhiều phần và tiếp tục Advertising ở các lần phát sau.

Hình 5.50. Quá trình Advertising của Gateway Node

69
5.5. Kiểm tra tình trạng các Friend Node
Việc kiểm tra trạng thái của một Friend Node dựa vào số lượng gói tin mà nó
gửi tới Gateway. Theo quy ước, cứ mỗi 15 giây Friend Node phải gửi tới cho Gateway
một gói tin có yêu cầu phản hồi để báo cáo trạng thái hoạt động của nó, và nếu 4 lần
liên tiếp Gateway không nhận được bất kỳ gói tin nào, Friend Node đó sẽ coi như bị
chết. Vì vậy, thời gian tối đa để nhận biết một Friend Node chết là 1 phút, người dùng
sẽ được thông báo việc này ở giao diện ứng dụng trên Smartphone để có những
phương án xử lý sự cố phù hợp.
Ở chiều ngược lại, mỗi khi nhận được gói tin có yêu cầu phản hồi, Gateway sẽ
gửi một gói tin tương ứng về phía Friend Node, giúp cho Friend Node có thể cập nhật
trạng thái của Gateway.
Hình 5.7 mô tả hoạt động của quá trình kiểm tra này. Địa chỉ của mỗi Friend
Node sẽ gắn tương ứng với một biến Packet Count và được lưu trong mảng cấu trúc
STATUS. Mỗi 15 giây Gateway sẽ tự động cộng nó thêm 1, khi nhận gói tin từ Friend
Node tương ứng, nó sẽ được gán về 0.

Hình 5.51. Quá trình kiểm tra trạng thái Friend Node

70
5.6. Gateway Node dự phòng
Vì Gateway Node là một thiết bị có vai trò quan trọng trong hệ thống báo cháy
dùng công nghệ BLE Mesh, nên để đề phòng trường hợp Node này bị các sự cố dẫn
đến hư hỏng không thể hoạt động được, nhóm đã xây dựng một Gateway Node dự
phòng.
Về cơ bản, Node dự phòng này chính là một Friend Node đặc biệt, khi triển khai
hệ thống mạng, nó sẽ được đặt ở vị trí gần nhất với Gateway chính. Vì các Friend Node
luôn luôn kiểm tra trạng thái hoạt động của Gateway, nên chúng sẽ biết khi nào
Gateway xảy ra sự cố. Khi đó, Friend Node đặc biệt này ngoài việc thực hiện chức
năng của chính nó, còn sẽ thực hiện thêm chức năng của Gateway như đã trình bên ở
các phần trên. Các Friend Node khác cũng sẽ tự động thay đổi địa chỉ gửi gói tin đến
Gateway dự phòng này để tiếp tục quá trình hoạt động của mạng.
Khi Gateway chính được khắc phục xong sự cố, nó sẽ được khởi động lại. Lúc
này, mảng chứa địa chỉ các Friend Node hoạt động trước đó được lưu trữ trong bộ nhớ
Flash nếu không bị mất đi, thì Gateway sẽ tiến hành gửi gói tin báo cáo rằng nó đã hoạt
động trở lại tới các Friend Node trong toàn mạng. Việc gửi gói tin được thực hiện 5 lần
liên tục, đảm bảo các Friend Node có thể nhận được thông báo, khi đó, chúng sẽ tự
động chuyển địa chỉ gói tin gửi đến về Gateway Node ban đầu. Hình 5.8 bên dưới trình
bày quá trình chuyển đổi hoạt động của mạng khi Gateway Node chính gặp sự cố.

Hình 5.52. Quá trình chuyển đổi qua Gateway Node dự phòng
Về thực tế, quá trình dự phòng này chỉ là một biện pháp tạm thời, nó có tác
dụng thông báo cho người dùng cuối rằng Gateway Node chính đã chết, cần có biện
pháp nhanh chóng thay thế. Bởi Friend Node sẽ thực hiện rất nhiều công việc nếu số
lượng Node trong mạng quá lớn.

71
72
6. Ứng dụng trên Smart Phone
6.1. Tổng quan
Một phần quan trọng trong hệ thống báo cháy dựa trên BLE Mesh là ứng dụng
Fire Alarm trên Smartphone. Ứng dụng thực hiện việc cấp phát địa chỉ, cấu hình, cài
đặt Group cho các Node.
Các Smartphone tại thời điểm hiện tại chưa hỗ trợ giao thức BLE Mesh. Vì vậy,
Silicon Labs đã cung cấp một API trên điện thoại để thực hiện bộ giao thức này, được
gọi BLE Mesh Stack.

Hình 6.53. Kiến trúc BLE Mesh Stack trên Smartphone

73
 Fire Alarm được phát triển dựa trên ứng dụng Bluetooth Mesh được cung cấp
bởi Silicon Labs.

Hình 6.54. Logo ứng dụng Fire Alarm

Fire Alarm được thay đổi và bổ sung những phần chính sau :
+ Thay đổi giao diện người dùng.
+ Quét dữ liệu chứa trạng thái của các Node trong mạng được phát ra từ
Gateway Node.
+ Giải mã dữ liệu đã được mã hóa bởi Gateway.
+ Phân tích dữ liệu thành các thành phần: Alarm Signal, Unicast
Address, Heartbeat và Battery Percentage.
+ Cập nhật dữ liệu theo chu kỳ mỗi 10 giây và hiển thị lên giao diện ứng
dụng.

74
6.2. Thay đổi giao diện người dùng
Fire Alarm đã thay đổi gần như toàn bộ giao diện người dùng so với ứng dụng
Bluetooth Mesh của nhà cung cấp nhằm tạo nên sự phù hợp về mặt hình ảnh và ý nghĩa
cho hệ thống báo cháy.

Hình 6.55. Một số thay đổi chính trên giao diện của Fire Alarm

75
6.3. Quá trình Provisioning và cấu hình:
6.3.1. Sơ đồ khối thực hiện

Hình 6.56. Các bước thực hiện cấp quyền và cấu hình cho thiết bị

76
6.3.2. Thêm Network
Trước khi tiến hành cấu hình, người dùng cần thêm các Network hoặc có thể sử
dụng Network mặc định. Số lượng Network tối đa là 4. Mỗi Network sẽ có một
Network Key riêng biệt dùng để mã hoá hoặc giải mã dữ liệu.

Hình 6.57. Danh sách Network được tạo thêm

6.3.3. Thêm Group

Người dùng lựa chọn Network tương ứng và tiến hành thêm Group. Số lượng
Group tối đa là 8. Việc Publish hoặc Subcribe sẽ được thực hiện thông qua địa chỉ của
các Group này.

77
 Hình 6.58. Danh sách nhóm được tạo mới
6.3.4. Tìm kiếm thiết bị cần Provisioning
Người dùng chuyển sang tab Provision và chọn Scan để tiến hành tìm các thiết
bị cần cấu hình.

Hình 6.59. Tìm kiếm thiết bị cần cấu hình

Các thiết bị BLE muốn tham gia vào mạng sẽ được hiển thị như hình trên. Mỗi
thiết bị sẽ hiển thị các thông tin cơ bản như: địa chỉ MAC, khoảng cách nhận tín hiệu.
Tên thiết bị có thể được thay đổi trong quá trình cấu hình.

78
6.3.5. Thực hiện quá trình Provisioning
Sau khi click chọn nút PROVISION, Fire Alarm sẽ khởi tạo quá trình cấp phép,
các thiết bị tiến hành trao đổi Public Key. Người dùng có thể thay đổi tên và lựa chọn
Network mong muốn cho thiết bị.

Hình 6.60. Cấp quyền cho thiết bị

79
6.3.6. Quá trình cấu hình Node
Sau khi kết thúc quá trình Provisioning, các Node được thực hiện bước tiếp theo
là cấu hình chức năng hoạt động cũng như vai trò của mình trong mạng BLE Mesh.
Dưới đây là 3 loại tính năng của Node có thể được cấu hình, tính năng LPN sẽ
tự động được thêm vào nếu Composition Data của thiết bị có hỗ trợ nó, đồng thời,
Node được Provisioning đầu tiên phải có tính năng Proxy:
+ Tính năng Proxy
+ Tính năng Relay
+ Tính năng Friend

Hình 6.61. Cấu hình Node trong mạng

Cấu hình Publish/Subcribe: các Node sẽ đăng kí (Subcribe) một địa chỉ nhóm
bằng cách lựa chọn tên nhóm. Các Node trong cùng một nhóm sẽ tuân theo sự điều
khiển của Switch Master.

80
 Cấu hình Mesh Model: đây là bước cuối cùng trong quá trình cấu hình cho
Node. Các Node sẽ được cấu hình Model tương ứng với vai trò của Node đó trong
mạng.
Một Node có thể được cấu hình:
+ Level Model ứng với vai trò của nó trong mạng là Friend Node hoặc
Gateway Node.

Hình 6.62. Danh sách các Node được cấu hình vai trò Friend Node
+ Level Client Model tương ứng với vai trò là LPN.

Hình 6.63. Danh sách các Node được cấu hình vai trò LPN
81
6.4. Scan gói tin BLE
Trong quá trình vận hành, người dùng sẽ được cập nhật các thông tin về trạng
thái hoạt động của từng Node trong hệ thống và hiển thị trực quan trên giao diện của
ứng dụng Fire Alarm.
Để cập nhật được nguồn dữ liệu nêu trên, ứng dụng sẽ thực hiện việc quét gói
tin được gửi qua chế độ Advertising. Cụ thể, ứng dụng sẽ thực thi quá trình Scanning
gói tin BLE được phát từ Gateway trong mạng BLE Mesh.

Hình 6.64. Quá trình Fire Alarm nhận gói tin từ Gateway trong mạng BLE Mesh
Các phần chi tiết để xử lý việc Scan dữ liệu sẽ nằm trong file
DeviceListPresenter.kt trong Source Code của ứng dụng.

82
 Hình 6.65. Sơ đồ hoạt động quét dữ liệu của ứng dụng

6.5. Giải mã AES

Sau khi ứng dụng Fire Alarm quét được dữ liệu về trạng thái hoạt động của các
Node được gửi từ Gateway. Ứng dụng sẽ tiến hành bước tiếp theo là giải mã dữ liệu.
Việc giải mã dữ liệu trong ứng dụng được thực hiện nhờ vào các Packet được hỗ
trợ bởi Google cho Android :
+ Javax.crypto: gói này cung cấp các Class và Interface cho các ứng
dụng mật mã để thực hiện các thuật toán mã hóa và giải mã.
+ Javax.crypto.interfaces: gói này cung cấp các Interface cần thiết để
thực hiện các thuật toán trên.
+ Javax.crypto.spec: gói này cung cấp các Class và Interface cần thiết để
xác định các Key và tham số để mã hóa.
+ Trong Javax.crypto: có chứa Cipher Class, cung cấp các phương thức
phục vụ cho việc mã hoá và giải mã.

83
 Dữ liệu mà Gateway gửi đi đã được mã hóa theo chuẩn mã hóa AES - ECB với
độ dài khoá là 128 bit. Vì vậy, sau quá trình giải mã, ta sẽ thu được 16 byte dữ liệu ban
đầu.

Hình 6.66. Sơ đồ hoạt động giải mã dữ liệu

6.6. Hiển thị dữ liệu trên ứng dụng

Dữ liệu sau khi mã hóa là 16 byte, chứa dữ liệu của 8 Node trong mạng BLE
Mesh. Cụ thể, bao gồm các phần sau:
+ Dung lượng pin.
+ Trạng thái còn kết nối hay đã mất kết nối với mạng.
+ Địa chỉ Unicast của từng Node.
+ Tín hiệu báo cháy.
Ứng dụng sẽ dựa vào địa chỉ Unicast của mỗi Node để cập nhật các trạng thái
hoạt động tương ứng.

84
Hình 6.67. Hiển thị dữ liệu Node lên giao diện ứng dụng

85
7. Friend Node
7.1. Tính năng chính
Friend Node là một thành phần vô cùng quan trọng đối với hệ thống mạng BLE
Mesh. Friend Node với vai trò là thiết bị trung gian giữa LPN và Gateway, chịu trách
nhiệm chính cho việc truyền và nhận dữ liệu trong hệ thống mạng. Với mục đích tạo ra
một hệ thống an toàn, hoạt động ổn định, Friend Node được thiết kế để thực hiện các
chức năng sau:
+ Truyền nhận dữ liệu giữa LPN và Gateway.
+ Kiểm tra tình trạng hoạt động của LPN.
+ Kiểm tra tình trạng hoạt động Gateway.

7.2. Sơ đồ hoạt động

Hoạt động của Friend Node được chia thành nhiều giai đoạn, bắt đầu từ lúc thiết
bị được cấp nguồn và khởi động. Hình 7.1 bên dưới trình bày sơ đồ khối minh hoạ các
hoạt động chính của Friend Node.

Hình 7.68. Sơ đồ hoạt động của Friend Node

86
 Đầu tiên, thiết bị tiến hành khởi tạo các thành phần ngoại vi cũng như vùng nhớ
cần thiết cho các quá trình hoạt động:
+ Khởi tạo vùng nhớ: vùng nhớ được khởi tạo dưới dạng mảng chứa các
thông tin của LPN, sử dụng cho việc lưu trữ dữ liệu nhận được từ LPN. Trong
phạm vi thực hiện báo cáo, số kết nối Friendship tối đa mỗi Friend Node có thể
thành lập là 2. Mỗi LPN sẽ sử dụng một vùng gồm địa chỉ LPN, dữ liệu gói tin
cùng một biến đếm số gói tin không nhận được. Địa chỉ LPN được cập nhật vào
mảng ngay khi thành lập kết nối Friendship. Bộ nhớ được thiết kế có kích
thước nhỏ, vì vậy vùng nhớ sẽ được cấp phát tĩnh. Cấu trúc dữ liệu được thiết
kế như sau:

Hình 7.69. Cấu trúc dữ liệu của Friend Node

+ Xung clock: Friend Node hoạt động ở chế độ EM0 – Active, lấy xung
clock từ HFXO 38.4 MHz cho các hoạt động của CPU. Đồng thời, quá trình
hoạt động của Mesh Stack cũng yêu một RTCC Timer, Timer này được cấp từ
LFXO 32768 Hz.
+ Ngoại vi: Kit phát triển đi kèm Radio Board BRD4014A tích hợp trên
đó là LCD, được nhóm sử dụng cho quá trình giám sát việc thực thi chương
trình của Friend Node, đồng thời, một bộ UART được dùng để hiển thị thông tin
thông qua cổng Serial của máy tính. Các ngoại vi được liệt kê chi tiết kèm chức năng
của nó trong bảng dưới đây.

87
 Bảng 7.23. Các ngoại vi được sử dụng chính bởi Friend Node
Ngoại vi Mô tả
Graphic LCD Hiển thị các thông tin về hoạt động của Friend Node lên màn
hình.
UART Phục vụ chính cho việc Debug khi phát triển ứng dụng, các
thông tin về lỗi, sự kiện,… sẽ được gửi lên cổng Serial của
máy tính.
GPIO Sử dụng LED để báo tín hiệu và một Button dùng cho việc
Reset thiết bị về trạng thái nguyên mẫu ban đầu.

+ Thành phần của Mesh Stack: Friend Node sử dụng hai Generic Model
cho quá trình gửi và nhận gói tin là Level Client và Level Server. Level Client
được sử dụng cho quá trình gửi tín hiệu từ Friend Node đến Gateway. Level
Server được sử dụng cho quá trình nhận tín hiệu từ LPN gửi đến Friend Node.
Bảng dưới đây trình bày các lớp API được Friend Node sử dụng.

Bảng 7.24. Các lớp API sử dụng bởi Friend node

Lớp API Chức năng sử dụng ở Friend Node
DFU Phục vụ quá trình Device Firmware Update. Friend Node có thể
nhận Firmware mới thông qua một GATT Service được Silabs
cung cấp sẵn là OTA Service.
System Dùng để xử lý các phần cục bộ của Node, bao gồm việc lấy địa
chỉ MAC, cấu hình Tx Power, thông số ở tầng Link Layer.
BLE GAP Sử dụng cho quá trình Advertise các gói tin theo chu kỳ.
BLE Phục vụ việc thiết lập Connection giữa Gateway Node và
Connection Smartphone, trong đó, Smartphone đóng vai trò là Master, và
Gateway Node đóng vài trò là Slave.
GATT Server Dùng để truyền và nhận dữ liệu dưới dạng GATT Service
Hardware Sử dụng để cấu hình các Timer phục vụ cho việc Advertise gói
tin và kiểm tra trạng thái hoạt động của các Friend Node.

88
Flash Địa chỉ của các Friend Node được lưu trữ trong bộ nhớ Flash, gọi
là Persistent Store.
Mesh Node Khởi tạo hoạt động cho một Mesh Node.
Mesh Friend Cho phép thiết bị thực hiện chức năng Friend.
Mesh Proxy Bật chức năng Proxy cho Gateway, tuy nhiên, việc chức năng
này có thực sự hoạt động hay không còn phụ thuộc vào việc cấu
hình của người dùng bằng ứng dụng trên Smartphone
Mesh Proxy Nếu chức năng Proxy được người dùng kích hoạt, Gateway sẽ
Server đóng vai trò là một Server.
Mesh Generic Phục vụ việc sử dụng các Generic Server Model, cụ thể ở đây là
Server Level Server.
Mesh Generic Phục vụ việc sử dụng Level Client Model.
Client

Sau quá trình khởi tạo hoàn tất, thiết bị sẽ bắt đầu gửi gói tin để tìm kiếm
Provisioner. Gói tin được gửi ở cả 2 Bearer là ADV và GATT, điều này đảm bảo cho
các thiết bị không được hỗ trợ Mesh Stack như Smartphone vẫn có thể phát hiện Friend
Node. Nếu quá trình Provisioning và cấu hình các thông số liên quan hoàn tất, thiết bị
sẽ trở thành một phần tử trong mạng BLE Mesh. Các tính năng được người dùng cấu
hình lúc Provision phụ thuộc vào các cài đặt tương ứng bên phía Firend Node. Bảng
7.3 bên dưới trình bày các tính năng, Model và GATT Service mà Gateway Node hỗ
trợ.

Bảng 7.25. Cấu hình Mesh Feature, Model và GATT Service của Friend Node
89
 Proxy
Mesh Feature Relay
Friend
Configuration Server
Model trong Primary Element Generic Level Server
Generic Level Client
Generic Access
Device Information
GATT Service Mesh Provisioning Service
Mesh Proxy Service
Silicon Labs OTA

Để đi đến hoạt động chính của Friend Node, trước hết ta phải cấu hình các thành
phần sau:
+ Một Software Timer dành cho việc kiểm tra tình trạng hoạt động của
LPN và Gateway, được lặp lại liên tục mỗi 15 giây.
+ Một Software Timer dành cho việc gửi dữ liệu đến cho Gateway, cũng
được lặp lại liên tục mỗi 15 giây.
+ Hàm xử lí khi nhận được gói tin từ LPN và Gateway, hàm sẽ thực hiện
phân biệt địa chỉ nguồn của gói tin và thực hiện chức năng tương ứng.

5.3. Xử lí gói tin từ LPN

Như đã trình bày ở phần tổng quan của hệ thống báo cháy, dữ liệu trong toàn
mạng khi truyền sẽ được mã hoá 2 lớp. Lớp đầu tiên sử dụng phép toán XOR để mã

90
hoá 2 byte dữ liệu người dùng, lớp thứ hai được thực hiện bởi Mesh Stack sử dụng kỹ
thuật AES 128 bit để mã hoá toàn bộ gói tin khi truyền đi và cũng chính Mesh Stack sẽ
tự động giải mã gói tin này khi nhận được. Chính vì vậy, việc đầu tiên khi Friend Node
nhận dữ liệu từ LPN đó chính là phải giải mã 2 byte dữ liệu được gửi dưới dạng Level
Model. Việc giải mã được thực hiện đơn giản, chỉ cần làm phép XOR ngược dữ liệu
nhận được với khoá mã hoá 16 bit.
Các gói tin được gửi từ LPN bao gồm 2 dạng, có yêu cầu phản hồi và không yêu
cầu phản hồi. Friend Node dựa vào đặc điểm này để phân biệt gói tin nhận được là gói
tin thông báo có hỏa hoạn hay là gói tin thông báo trạng thái từ LPN. Vì vậy, Friend
Node có thể thực hiện các chức năng tương ứng với từng loại gói tin.
Đối với gói tin có yêu cầu phản hồi, đây là gói tin thông báo có tín hiệu hỏa
hoạn cần được chuyển tiếp đến Gateway ngay lập tức. Gói tin không yêu cầu phản hồi
là gói tin thông báo trạng thái LPN, Friend Node sẽ cập nhật trạng thái LPN bằng cách
lưu vào mảng, tương ứng với địa chỉ nhận được từ gói tin.

Hình 7.70. Quá trình xử lí gói tin từ LPN

Sau mỗi khoảng thời gian là 15 giây, quá trình kiểm tra tình trạng LPN được
thực hiện, dữ liệu tình trạng LPN trong mảng sẽ được cập nhật. Friend Node thực hiện
mã hóa lần lượt dữ liệu Data được lưu và gửi về Gateway Node.

5.4. Kiểm tra tình trạng LPN

Quá trình kiểm tra tình trạng LPN được thực hiện bằng quá trình đếm số gói tin
không nhận được từ LPN, với mỗi chu kì 15 giây nếu không nhận được gói tin thông
91
báo trạng thái từ LPN, biến đếm số gói tin không nhận được sẽ tăng thêm 1, nếu số gói
tin này từ 4 trở lên, LPN được xem như đã chết. Vì vậy, quá trình nhận biết được thiết
bị LPN không còn kết nối chỉ trong vòng 1 phút.

Hình 7.71. Quá trình kiểm tra tình trạng LPN

5.5. Kiểm tra tình trạng Gateway Node

Quá trình kiểm tra tình trạng Gateway Node được thực hiện tương tự như trên.
Điểm khác biệt ở quá trình này là việc Friend Node phải gửi gói tin yêu cầu phản hồi
đến Gateway Node mỗi 15 giây để nhận được gói tin thông báo trạng thái.

5.6. Trao đổi dữ liệu với Gateway Node

Friend Node sẽ gửi dữ liệu báo cáo trạng thái hoạt động của nó đến Gateway
ngay sau khi quá trình kiểm tra tình trạng của LPN được hoàn tất.
Các gói tin được gửi bao gồm :
+ Gói tin thông báo trạng thái của chính Friend Node được kích hoạt yêu
cầu phản hổi. Nhờ đó nhận biết được tình trạng tồn tại của Gateway Node.
+ Gói tin chứa dữ liệu được nhận từ LPN.

92
8. Low Power Node
8.1. Tính năng chính
Low Power Node (LPN) chịu trách nhiệm trong việc phát hiện các dấu hiệu xảy
ra đám cháy. Sau đó gửi thông báo đến Friend Node để xử lý các công đoạn tiếp theo.
Quá trình hoạt động của LPN bao gồm 3 phần chính:
+ Giám sát cảm biến khói thông qua GPIO Interrupt.
+ Đọc dung lượng pin còn lại của thiết bị dùng bộ ADC.
+ Gửi gói tin dưới dạng Level Model cho Friend Node.
Cấu tạo phần cứng cơ bản của Low Power Node gồm một cảm biến khói có tích
hợp sẵn còi báo động, một vi điều khiển để xử lý thông tin và một mạch dùng để phục
vụ việc truyền và nhận sóng không dây RF. Bởi vì khối lượng công việc cần phải xử lý
của LPN rất ít so với các Node còn lại trong mạng, nên cấu hình phần cứng của nó
không cần phải quá cao. Nhưng trong phạm vi báo cáo, các mạch dùng để triển khai hệ
thống đều dùng chung một mạch phát triển là BRD4104A, đã được trình bày chi tiết ở
mục 3 bên trên.

8.2. Sơ đồ hoạt động

Hoạt động của LPN được chia thành nhiều giai đoạn, bắt đầu từ lúc thiết bị
được cấp nguồn và khởi động. Hình 8.1 bên dưới trình bày sơ đồ khối minh hoạ các
hoạt động chính của LPN.

Hình 8.72. Sơ đồ hoạt động của Low Power Node

93
 Với quá trình khởi tạo, cũng tương tự như Gateway Node và Friend Node, các
ngoại vi và các thành phần cần thiết sẽ được cấu hình để phục vụ cho hoạt động của
LPN, chúng bao gồm:
+ Các xung clock: LPN dành phần lớn thời gian của mình để ngủ, khi đó,
nó hoạt động ở chế độ EM2 - Deep Sleep, các ngoại vi không cần thiết sẽ được
tự động tắt đi. Vì vậy, chỉ có Mesh Stack là vẫn còn hoạt động, nó cần một
RTCC Timer với xung clock được cấp từ bộ LFXO 32768 Hz. Khi thức dậy xử
lý dữ liệu và thực hiện việc truyền nhận sóng RF, LPN sử dụng xung clock từ bộ
HFXO 38.4 MHz.
+ Ngoại vi: Chỉ có GPIO và ADC được sử dụng, tất cả các ngoại vi
không cần thiết còn lại điều được tắt đi để đảm bảo công suất tiêu thụ đạt mức tối
ưu nhất.
+ Các thành phần của Mesh Stack: LPN chỉ sử dụng mỗi Level Client
Model để gửi dữ liệu tới Friend Node, các thành phần khác được trình bày
trong bảng 8.1 bên dưới.

Bảng 8.26. Các lớp API sử dụng bởi LPN

Lớp API Chức năng sử dụng ở LPN
DFU Phục vụ quá trình Device Firmware Update.
System Dùng để xử lý các phần cục bộ của Node, bao gồm việc lấy địa
chỉ MAC, cấu hình Tx Power, thông số ở tầng Link Layer.
BLE GAP Sử dụng cho việc tìm kiếm Master để thành lập Connection
BLE Phục vụ việc thiết lập Connection giữa LPN và Smartphone
Connection
GATT Server Dùng để truyền và nhận dữ liệu dưới dạng GATT Service
Hardware Sử dụng để cấu hình các Timer phục vụ cho các hoạt động chính
của LPN.
Flash Để xoá dữ liệu mà Mesh Stack lưu trữ trong bộ nhớ Flash
Mesh Node Khởi tạo hoạt động cho một Mesh Node.
Mesh Proxy Bật chức năng Proxy cho LPN, tuy nhiên, việc chức năng này có

94
 thực sự hoạt động hay không còn phụ thuộc vào việc cấu hình
của người dùng bằng ứng dụng trên Smartphone
Mesh Proxy Nếu chức năng Proxy được người dùng kích hoạt, LPN sẽ đóng
Server vai trò là một Server.
Mesh Generic Phục vụ việc sử dụng Level Client Model.
Client
Mesh LPN Để khởi tạo chức năng LPN, dùng để thiết lập mối quan hệ LPN -
Friend.

Sau khi khởi tạo, LPN sẽ gửi các gói tin để tìm kiếm Provisioner. Quá trình này
tương tự như các Gateway và Friend Node, nên sẽ không được trình bày lại. Bảng 8.2
bên dưới mô tả các chức năng và các GATT Service mà LPN hỗ trợ.

Bảng 8.27. Cấu hình Mesh Feature, Model và GATT Service của LPN
Mesh Feature Proxy
Low Power
Model trong Primary Element Configuration Server
Generic Level Client
GATT Service Generic Access
Device Information
Mesh Provisioning Service
Mesh Proxy Service
Silicon Labs OTA

Trước khi LPN đi vào hoạt động chính, ta cần phải cấu hình các thành phần sau:

95
 + Khởi tạo chức năng Low Power và bắt đầu tìm Friend Node.
+ Một Software Timer phục vụ cho việc gửi gói tin báo cáo trạng thái
hoạt động tới Friend Node, đây là một Timer lặp lại với chu kỳ 15 giây.
+ Một Software Timer dùng để đọc điện thế của viên pin CR2032, từ đó
tính toán được dung lượng pin còn lại của thiết bị, Timer này lặp lại với chu kỳ
vào khoảng 18 giờ.

6.3. Trao đổi dữ liệu với Friend Node

Đầu tiên, sau khi quá trình Provisioning hoàn tất, LPN cứ mỗi 5 giây sẽ gửi gói
tin để tìm kiếm Friend Node gần đó. Nếu mối quan hệ LPN - Friend được thiết lập,
LPN sẽ bắt đầu việc gửi các gói tin dưới dạng Level Model cho Friend Node theo chu
kỳ được cấu hình trước.
Dữ liệu gửi đi chỉ được gói gọn trong 2 byte, và được mã hoá thêm một lớp nữa
với kỹ thuật XOR, đây là nơi mã hoá đầu tiên của chuỗi truyền dữ liệu trong toàn
mạng, việc giải mã được thực hiện ở cả 2 thiết bị nhận gói tin sau đó là Gateway và
Friend Node. Công việc mã hoá này chỉ đơn giản là thực hiện phép toán XOR dữ liệu
với khoá mã hoá có độ dài 16 bit.
Các gói tin mà LPN gửi tới Friend Node được chia thành 2 dạng, có yêu cầu
phản hồi và không có yêu cầu phản hồi, với các chức năng tương ứng bao gồm:
+ Gói tin có phản hồi: chứa dữ liệu được gửi khẩn cấp khi có sự cố cháy
xảy ra. Được gửi ngay lập tức khi có Interrupt từ tín hiệu báo cháy của cảm
biến. Điều này giúp cho quá trình báo động đến các Node khác trong mạng được diễn
ra một cách gần như tức thời.
+ Gói tin không có phản hồi: dùng để báo cáo trạng thái hoạt động cho
Friend Node. Được gửi mỗi 15 giây một lần.

6.4. Năng lượng tiêu thụ

LPN sử dụng nguồn năng lượng được cung cấp từ pin, vì vậy, việc tối ưu năng
lượng tiêu thụ là một trong những mục tiêu chính của việc thiết kế. Dòng Wireless
96
MCU EFR32BG13 là một dòng vi điều khiển được thiết kế riêng cho các ứng dụng đòi
hỏi những yêu cầu khắt khe về lượng điện năng tiêu thụ trong quá trình hoạt động.
Chính vì thế, khi hoạt động với phần lớn thời gian ở chế độ EM2 - Deep Sleep, LPN có
dòng tiêu thụ trung bình rất thấp, chỉ vào khoảng mức µA.
Các ngoại vi và tính năng không cần thiết cho việc hoạt động của LPN đều bị tắt
đi, bao gồm bộ UART, Cryptographic và chức năng Proxy trong quá trình
Provisioning.
Với các ứng dụng dựa trên công nghệ BLE, việc truyền và nhận tín hiệu dưới
dạng sóng RF là quá trình tiêu tốn nhiều năng lượng nhất. Mỗi lần phát sóng, dòng
điện hoạt động có thể lên đến xấp xỉ 10 mA. Chính vì vậy, với chu kỳ gửi gói tin báo
cáo trạng thái tới Friend Node được cấu hình trước đó, thời gian ngủ của LPN cũng rơi
vào khoảng 15 giây. Sau đó được Timer đánh thức để gửi sóng, và tiếp tục đi vào chế
độ ngủ sâu. Khi ở chế độ ngủ sâu, LPN cũng tiêu thụ một dòng điện khoảng 2.76 µA.
Sau khi đo đạc, nhóm ghi nhận dòng tiêu thụ trung bình mà LPN đạt được là 30 µA.

Hình 8.73. Năng lượng tiêu thụ của LPN

6.5. Báo cáo dung lượng pin

LPN sử dụng pin làm nguồn cung cấp năng lượng chính, vì vậy, cần phải tiến

97
hành đo đạc và báo cáo dung lượng pin còn lại về Smartphone, để thông báo cho người
dùng tiến hành các biện pháp thay thế khi sắp hết pin.
Việc đánh giá dung lượng pin được ước lượng dựa vào điện thế (mV) của pin
đọc được từ bộ ADC được tích hợp trên chip Blue Gecko.
Pin dùng ở đây là viên pin CR2032 có điện thế khi mới mua vào khoảng 3.3V
(100%), trong khi điện thế mà tại đó vi điều khiển không còn hoạt động được là vào
khoảng 1.8V, ta sẽ xem đây là ngưỡng dưới khi tính toán dung lượng pin (0%). Dung
lượng pin chuẩn lúc còn mới là 220 mAh.

Hình 8.74. Viên pin CR2032

Ta cấu hình AUXHFRCO để cung cấp xung clock cho bộ ADC khi LPN hoạt
động ở chế độ EM2 - Deep Sleep.
Điện thế của pin sẽ được đo bởi bộ ADC có độ phân giải là 12 bit, điện thế tham
chiếu (Vref) được lấy là 5V. Vì vậy, với số bậc giá trị có thể đo được là 2 12 = 4096, điện
thế cho mỗi bậc sẽ là 5 ÷ 4096=1221 µV.
Việc đọc điện thế được thực hiện với ADC Interrupt, khi giá trị điện thế của viên
pin CR2032 đã được đọc xong, chương trình sẽ nhảy vào một hàm ngắt và xử lý việc
tính toán dung lượng pin còn lại. Cứ mỗi 65000 giây (vào khoảng 18 giờ) thì bộ ADC
sẽ thực hiện việc đọc giá trị một lần.
Hình bên dưới hiển thị dung lượng pin còn lại của một số thiết bị LPN trong
mạng BLE Mesh đã được nhóm cấu hình trước đó.

98
 Hình 8.75. Dung lượng pin (%) của LPN

Dĩ nhiên đối với Friend Node, vì luôn luôn được cấp nguồn để hoạt động nên
dung lượng pin hiển thị của nó là 100 %.

99
 Hình 8.76. Dung lượng pin (%) của Friend node
Như đã trình bày ở mục 6.4, nhóm đã đo đạc được dòng tiêu thụ trung bình mà
thiết bị LPN sử dụng là 30 µA. Từ đó có thể tính toán được thời gian sử dụng pin của
nó. Với dung lượng pin CR2032 là 220 mAh, thiết bị LPN có thời lượng sử dụng lên
đến 7000 giờ, tương đương gần 10 tháng.

100
6.6. Cảm biến nhận biết khói
Đây là một bộ phận quan trọng, được giao tiếp với vi điều khiển bằng GPIO
Interrupt. Cảm biến được trang bị một nguồn điện riêng, độc lập với vi điều khiển và
mạch phát sóng RF. Điện thế cung cấp cho cảm biến là 9V được lấy từ một viên pin
6F22DT.
Trên cảm biến được trang bị một còi báo động độc lập, mỗi khi phát hiện ra các
sự cố của đám cháy, bên cạnh việc sinh ra một sự kiện Interrupt bên phía vi điều khiển,
cảm biến còn phát loa báo động, giúp người dân sinh sống xung quanh kịp thời đưa ra
biện pháp xử lý sự cố.

101
9. Cập nhật Firmware thông qua OTA
9.1. Sự cần thiết của việc cập nhật Firmware
Trong quá trình sử dụng Firmware, thiết bị cũng không tránh được một số rủi ro
như bị lỗi phần mềm, thiếu sót chức năng, Firmware quá cũ, bị lỗi thời, ...Vì vậy việc
cập nhật Firmware mới cho thiết bị là một điều vô cùng cần thiết để thiết bị có nhiều
chức năng hơn, tăng tốc độ hoạt động, cung cấp nhiều các tính năng bảo mật,...
Các thiết bị trong hệ thống báo cháy BLE Mesh của nhóm cũng không phải là
một trường hợp ngoại lệ. Để hệ thống có thể hoạt động tốt, lâu dài, đáp ứng đủ các yêu
cầu của người dùng cũng như của một hệ thống báo cháy trên thực tế, thì việc cập nhật
Firmware cho mỗi thiết bị trong mạng có thể xem như là bắt buộc. Vì hệ thống hoạt
động dựa trên nền công nghệ truyền sóng không dây BLE nên quá trình cập nhật
Firmware cho thiết bị cũng sẽ được thực hiện không dây thông qua OTA (Over The
Air).
OTA Device Firmware Update (OTA DFU) mà nhóm sử dụng là quá trình cập
nhật các phiên bản Firmware mới trên thiết bị thông qua phương thức OTA sử dụng
sóng Bluetooth. Việc cập nhật thông qua phương thức này có nhiều ưu điểm cho hệ
thống như ít cồng kềnh, thuận tiện cho người dùng, dễ dàng thực hiện,…
Như đã giới thiệu ở mục 3.2.4, thì quá trình cập nhật Firmware cho mỗi thiết bị
được Bootloader hỗ trợ (Bootloader là một chương trình có sẵn được lưu trong bộ nhớ
của các thiết bị như máy tính, Smartphone,… và được chạy đầu tiên khi khởi động hệ
thống). Ở đây nhóm dùng Gecko Bootloader của SiliconLabs để thực hiện việc cập
nhật Firmware cho các thiết bị trong mạng.

9.2. Quá trình cập nhật Firmware thông qua OTA

Quá trình OTA Device Firmware Update của nhóm sử dụng ứng dụng Blue
Gecko trên điện thoại Android, thông qua Bluetooth để cập nhật Firmware cho thiết bị.

102
 Hình 9.77. Ứng dụng Blue Gecko
Để thực hiện OTA DFU cho thiết bị, thì đầu tiên phải cấu hình Internal Storage
Bootloader phù hợp với bộ nhớ lưu trữ và cho phép chức năng cập nhật Firmware qua OTA.

Hình 9.78. Cấu hình Internal Storage Bootloader cho Bootloader

Theo như phân vùng bộ nhớ của Gecko Bootloader, có thể thấy: phần đầu tiên
là Init Bootloader (First Stage), phần thứ hai là phân vùng Main Bootloader và phần
cuối cùng là phân vùng ứng dụng (Application).
Sau khi cấu hình Internal Storage Bootloader xong thì ta bắt đầu việc cập nhật
Firmware cho thiết bị.

103
 Ứng dụng Blue Gecko trên Smartphone hỗ trợ việc cập nhật Firmware thông
qua OTA. Bên dưới trình bày một số giao diện chính của ứng dụng để người dùng
Smartphone thực hiện việc quét (Scan) và tìm đúng thiết bị mong muốn cập nhật
Firmware.

Chọn chức năng Bluetooth Browser để thực hiện việc quét các thiết bị Bluetooth
trong mạng BLE Mesh gần đó.

104
 Hình 9.79. Chức năng Bluetooth Browser

Ta chọn thiết bị với tên hoặc địa chỉ MAC tương ứng của thiết bị đó như sau:

105
 Hình 9.80. Chọn thiết bị theo tên hoặc địa chỉ MAC để cấu hình OTA DFU
Như vậy, khi nhấn chọn thiết bị mà ta muốn cập nhật Firmware, giữa thiết bị và
Smartphone sẽ thành lập kết nối cho phép chúng trao đổi dữ liệu, các file mã nguồn sẽ
có định dạng theo kiểu GBL (.gbl).

106
 Lúc này Smartphone sử dụng một GATT Service mà Silabs cung cấp gọi là
OTA Control Service, giúp cho quá trình cập nhật Firmware được diễn ra thuận lợi
hơn.
Khi đã kết nối, nhấn OTA để tiến hành việc cập nhật Firmware:

Hình 9.81. Chức năng OTA để thực hiên OTA DFU

107
Quá trình cập nhật Firmware đang thực hiện:

Hình 9.82. Quá trình OTA DFU

108
10. Kết luận
10.1. Kết quả đạt được
Với những mục tiêu thiết kế đã đề ra ban đầu, nhóm đã triển khai thành công
một hệ thống báo cháy sử dụng công nghệ BLE Mesh với nhiều tính năng đáp ứng
được nhu cầu sử dụng của người dùng. Bảng bên dưới trình bày sự so sánh giữa các
mục tiêu thiết kế và kết quả thực tế khi xây dựng hệ thống.

Bảng 10.28. Mục tiêu thiết kế và kết quả đạt được

Mục tiêu thiết kế Kết quả đạt được

Thời gian gói tin báo động truyền đến
Độ trễ gói tin báo động thấp
Gateway trung bình khoảng 2 giây
Phát hiện thiết bị chết, ngưng hoạt Phát hiện trong vòng 1 phút
động trong thời gian ngắn
Dữ liệu truyền trong mạng được bảo Dữ liệu người dùng được mã hoá 2 lớp
mật an toàn
Quá trình thêm, bớt thiết bị trong Chưa thực hiện được hoàn chỉnh
mạng được an toàn
Mô hình mạng dễ dàng triển khai và Kiến trúc phân tầng dễ dàng nâng cấp và bảo
mở rộng, nâng cấp trì
Triển khai được tối đa số lượng thiết Chỉ triển khai được tối đa 127 thiết bị trong
bị trong mạng BLE Mesh mạng
Cập nhật phần mềm mới thông qua Việc cập nhật OTA phải thực hiện thông qua
cơ chế không dây một ứng dụng khác Fire Alarm
Có ứng dụng với giao diện giám sát Xây dựng được ứng dụng Fire Alarm, tuy
và cấu hình trực quan nhiên hiệu suất còn chưa cao
Thời gian sử dụng thiết bị cảm biến Thời gian sử dụng với pin CR2032 vào
đủ lâu khoảng 10 tháng

109
 Ngoài ra, khi thử nghiệm hệ thống trong phạm vi trường học, nhóm đã ghi nhận
được khoảng cách truyền tín hiệu tốt nhất giữa 2 thiết bị trong mạng là 50 mét, và nó
có thể mở rộng xa hơn lên đến 120 mét, tuy nhiên ở khoảng cách này, tín hiệu truyền đi
sẽ không tốt, hay bị chập chờn dẫn đến mất gói tin. Với khoảng cách thực tế như trên,
thật sự là quá đủ để tích hợp hệ thống vào các toà nhà cao tầng hiện nay, với chiều cao
mỗi tầng thường không quá 10 mét.
Tín hiệu báo động là một phần rất quan trọng, nó quyết định việc người dùng có
nhận ra được các dấu hiệu của đám cháy ngay lập tức hay không. Sau khi thử nghiệm
với các khoảng cách khác nhau, nhóm tính toán được thời gian trung bình của việc
truyền gói tin này đến Gateway Node là xấp xỉ 2 giây.

Bảng 10.29. Thời gian gửi gói tin báo động của LPN
Khoảng cách LPN - Friend Node 30 mét 50 mét 30 mét 50 mét
Khoảng cách Friend Node - 0 mét 0 mét 30 mét 30 mét
Gateway
Thời gian truyền đến Gateway ~ 1.5 giây ~ 2 giây ~ 2 giây ~ 2 giây
Thời gian cập nhật trên Smartphone ~ 7 giây ~ 9 giây ~ 9 giây ~ 10 giây

Với thời gian phát hiện các thiết bị gặp sự cố trong mạng, sau 2 lần thử nghiệm
tắt hoạt động của thiết bị LPN và Friend Node, với khoảng cách giữa Gateway và
Friend Node, Friend Node và LPN là 30 mét , đều cho ra thời gian nhận biết trong
vòng 1 phút.

Bảng 10.30. Thời gian nhận biết thiết bị gặp sự cố

Tình huống Lần 1 Lần 2 Lần 3 Lần 4 Lần 5
LPN gặp sự cố 57 giây 45 giây 54 giây 53 giây 49 giây
Friend Node gặp sự cố 46 giây 48 giây 56 giây 52 giây 58 giây

110
10.2. Kết luận
Với việc ứng dụng một công nghệ mới là BLE Mesh, nhóm đã xây dựng được
một hệ thống báo cháy không dây có thể triển khai được trong những nơi như trường
học, chung cư,… với nhiều ưu điểm so với các hệ thống báo cháy truyền thống trước
đây.
Tuy vậy, hệ thống báo cháy của nhóm cũng đi kèm theo những nhược điểm mà
với khoảng thời gian ngắn thực hiện vẫn chưa thể khắc phục được hoàn chỉnh, bao
gồm:
+ Gói tin dữ liệu người dùng còn ngắn, chỉ có độ dài 2 byte.
+ Chưa xây dựng được một Server trên Internet để phục vụ việc lưu trữ
dữ liệu cũng như truy xuất chúng từ Smartphone.
+ Số lượng thiết bị tối đa trong mạng vẫn còn hạn chế, chỉ 127 thiết bị.
+ Hiệu suất của hệ thống vẫn chưa tốt, cần cải thiện nhiều hơn nữa.

10.3. Hướng phát triển

Mục tiêu trong việc thiết kế để mở rộng và nâng cấp hệ thống là giải quyết các
nhược điểm cơ bản đang còn tồn tại.
Thứ nhất, cần triển khai Vendor Model trong mạng BLE Mesh, Model này do
người dùng tự định nghĩa, và có độ dài gói tin tối đa lên đến 8 byte, với độ dài này,
hoàn toàn có thể lưu trữ đầy đủ các trạng thái của hệ thống, giúp mở rộng số thiết bị
trong mạng lên đến tối đa và có thể dễ dàng xử lý các bit lỗi trong quá trình truyền
sóng.
Thứ hai, cần xây dựng một chế độ mã hoá mới, bảo mật hơn so với phép toán
XOR đơn giản đang được nhóm sử dụng.
Thứ ba, cần xây dựng một Server để phục vụ việc lưu trữ dữ liệu mà Gateway
Node gửi đến, cũng như giúp cho ứng dụng trên Smartphone có thể tiện lợi hơn trong
việc giám sát hệ thống.
Và cuối cùng, cần tối ưu công suất hoạt động của các thiết bị trong mạng cũng
như cải thiện khả năng vận hành của ứng dụng trên Smartphone, giúp cho trải nghiệm
của người dùng được tốt hơn nữa.
111
112
11. Tài liệu tham khảo
[1] Bluetooth SIG, “Bluetooth Core Specification”, version 4.1.
[2] Bluetooth SIG, “Mesh Profile”, version 1.0.
[3] Bluetooth SIG, “Mesh Model”, version 1.0.
[4] Bluetooth SIG, “Mesh Device Properties”, version 1.0.
[5] Kevin Townsend, Carles Cufi, Akiba, Robert Davidson, “Getting Started with
Bluetooth Low Energy”, First Edition, 2014.
[6] Silicon Labs, “EFR32xG13 Wireless Gecko Referency Manual”.
[7] Silicon Labs, “EFR32BG13 2.4 GHz 10 dBm Radio Board BRD4104A Referency
Manual”.
[8] Silicon Labs, “Bluetooth Mesh Software API Referency Manual”.
[9] Silicon Labs, “UG103.6: Bootloading Fundamentals”.
[10] Silicon Labs, “AN1200: Bluetooth Mesh for iOS and Android SDK”.

113