Bluetooth

Giới thiệu
Ngày nay, Bluetooth đã trở thành một phần trong cuộc sống của chúng ta do các ứng dụng to
lớn của nó từ các thiết bị âm thanh bao gồm tai nghe và điện thoại di động, máy nghe nhạc MP3,
máy tính xách tay, máy tính để bàn, máy tính bảng, v.v. Với bluetooth, người ta có thể truyền dữ
liệu, âm thanh, hình ảnh, video từ thiết bị này sang thiết bị khác miễn là chúng tuân thủ
bluetooth. Tiêu chuẩn IEEE 802.15.1 mô tả chi tiết thông số kỹ thuật bluetooth.

Bluetooth là một công nghệ không dây để kết nối các thiết bị cố định hoặc di động bằng cách
sử dụng liên kết vô tuyến ngắn. Nó nhằm mục đích cung cấp giao tiếp không dây cùng với kích
thước nhỏ, tiêu thụ điện năng thấp và giá cả thấp. Tên của Bluetooth như một lời tri ân đến vua
Viking ở thế kỷ thứ 10 Harald Blatand, người đã thống nhất một cách hòa bình nhiều vương quốc
nhỏ dưới khu vực của ông đang hoạt động theo các quy tắc khác nhau giống như được thực hiện
trong công nghệ Bluetooth. Harald thích ăn quả việt quất, loại quả này giúp hàm răng của anh có
màu xanh, dẫn đến biệt danh “Bluetooth”.

Có 2 loại Bluetooth:
 Bluetooth Classic (tốc độ cơ bản - BR/tốc độ nâng cao - EDR)
 Bluetooth Low Energy (BLE)
Tuy nhiên, BR và BLE không tương thích với nhau.

Bluetooth Classic thường được sử dụng để truyền tải dữ liệu lớn, chẳng hạn như nhạc từ
điện thoại đến loa hoặc tai nghe của bạn. Do đó, Bluetooth Classic tiêu thụ mức năng lượng cao
hơn.

BLE truyền dữ liệu ở một khoảng thời gian đều đặn, tiêu thụ ít năng lượng hơn và do đó,
có thể kéo dài trong vài tháng (đôi khi lên đến hàng năm) với một pin duy nhất.

Beacon Bluetooth
 Hình
Beacon Bluetooth là thiết bị phát sóng vô tuyến (bao gồm một bộ vi xử lý nhỏ, đài và pin)
không dây sử dụng BLE làm giao thức truyền dẫn. Thiết bị truyền sóng vô tuyến nhỏ này có
thể được ‘phát hiện’ bởi tất cả các máy quét BLE trong một bán kính nhất định (khoảng 10–30 m
đối với không gian nội thất), nhưng ngược lại thì không.

Beacon Bluetooth là một phần của Internet of Things (IoT), là kết nối giữa các thiết bị và máy
móc khác nhau để thu thập và truyền dữ liệu mà không có mối quan hệ giữa người với người
hoặc giữa người với máy tính.

Beacon Bluetooth hoạt động như thế nào? 

Ví dụ về hệ thống beacon Bluetooth

Beacon Bluetooth hoạt động bằng cách truyền các gói dữ liệu, các dữ liệu này được nhận bởi các
thiết bị nhận tương thích thông qua qua sóng vô tuyến. Các gói dữ liệu này hoặc là độc lập hoặc
là tác nhân kích hoạt các sự kiện trên thiết bị nhận, chẳng hạn như thông báo đẩy, hành động
ứng dụng và lời nhắc.

BLE sử dụng cùng dải phổ với Bluetooth Classic (băng tần ISM 2.400–2.4835 GHz) nhưng trên
một tập hợp kênh khác. BLE có 3 kênh quảng cáo chính, giúp các thiết bị kết nối nhanh hơn và
giảm thời gian quét thiết bị nghe. Để ngăn chặn các vấn đề nhiễu băng hẹp, BLE sử dụng nhảy
tần thông qua kỹ thuật điều chế kỹ thuật số hoặc trải phổ chuỗi trực tiếp để chống lại.
Một beacon Bluetooth có khoảng cách bán kính tối đa theo lý thuyết là dưới 100m. Nó cũng có
thể có độ trễ lên đến 6ms từ trạng thái không kết nối. Phạm vi thực tế và thời gian phản hồi phụ
thuộc vào bản thân beacon và quá trình mà nó đã được lập trình để thực hiện.
BLE Master yếu được sử dụng trong các ứng dụng tầm ngắn (sử dụng 1M PHY tiêu chuẩn). Phạm
vi hoạt động điển hình là khoảng 2 đến 5 mét, tùy thuộc vào công suất phát. Phạm vi càng cao
thì mức tiêu thụ pin càng cao. 

Ví dụ về kết nối Bluetooth Classic

Trong trường hợp của các thiết bị thông minh như điện thoại, việc chấp nhận tín hiệu phát sóng
BLE thường được bật thông qua một ứng dụng cho phép kết nối tự động xảy ra. 

Ưu điểm và nhược điểm của beacon Bluetooth

Một trong những ưu điểm chính của beacon Bluetooth là rẻ, dễ cài đặt, dễ bảo trì. Nó là một
thiết bị vật lý có thể được cố định hoặc di chuyển cùng với các đồ vật hoặc con người để
giúp theo dõi vị trí của họ. Về cơ bản, nó là một bộ truyền mà bạn chỉ cần cài đặt và tất cả
những gì còn lại cần làm là định cấu hình các hành động mà beacon phải thực hiện.

Một nhược điểm của beacon Bluetooth là chúng không tự hoạt động. Beacon là một phần của
hệ thống, có nghĩa là toàn bộ thiết lập phụ thuộc vào người dùng mang thiết bị tương thích
(trong hầu hết các trường hợp).

Trong một số hệ thống, bộ thu thay vào đó là một thiết bị cố định được lắp đặt trong một cơ sở
và các beacon là di động. Một ví dụ về điều này là hệ thống theo dõi tài sản với thiết bị định vị cố
định và các beacon được gắn vào tài sản nhằm mục đích theo dõi vị trí của chúng trong một cơ
sở.

Tiêu chuẩn iBeacon

 Hình
Chuẩn iBeacon là một giao thức được Apple phát triển vào năm 2013 và được giới thiệu tại Hội
nghị các nhà phát triển toàn cầu của Apple. Là tiêu chuẩn báo hiệu chính thức đầu tiên, được các
nhà phát triển chấp nhận rộng rãi và có hỗ trợ phần cứng. Trong khi iBeacon chỉ được hỗ trợ
chính thức bởi iOS, các API tồn tại cho các ứng dụng Android để quét các chương trình phát sóng
iBeacon. Để làm được điều này, người dùng phải cài đặt một ứng dụng được phát triển để tìm
beacon của bạn và làm điều gì đó với nó.

iBeacon hỗ trợ hai tương tác chính - giám sát và phạm vi.

Giám sát xảy ra khi bạn vào hoặc ra khỏi một khu vực. Khi điều này xảy ra, ứng dụng của bạn sẽ
được thông báo. Giám sát hoạt động trong nền và không yêu cầu bất kỳ hành động nào từ người
dùng để chạy.

Tiêu chuẩn Eddystone

 Hình

Tiêu chuẩn Eddystone là một giao thức Bluetooth Low Energy được phát hành vào năm 2015
bởi Google. Nó là một giao thức mở mã nguồn mở và đa nền tảng, hỗ trợ cả iOS và Android.

Không giống như iBeacon, Eddystone chỉ hỗ trợ một tương tác cơ bản chính - “khám phá
Eddystone”, là một khái niệm tương tự như phạm vi của iBeacon.

Tương tác này được chứa trong ba loại gói dữ liệu khác nhau - Eddystone UID, Eddystone URL và
Eddystone TLM.

Eddystone UID là một gói dữ liệu có thể kích hoạt thông báo đẩy hoặc hành động ứng
dụng. Ngược lại, URL Eddystone gửi một URL thực. Dữ liệu đơn giản và không cần ứng dụng để
hoạt động.

Cuối cùng, Eddystone TLM được sử dụng để quản lý báo hiệu và bao gồm thông tin như pin và
điện áp, nhiệt độ báo hiệu, số lượng gói hàng đã gửi và thời gian hoạt động của báo hiệu.  TLM
được gửi cùng với hai loại gói khác và hoạt động như siêu dữ liệu về beacon.
Trang web thực
Web trong cuộc sống bắt đầu với ý tưởng rằng một beacon có thể phát một URL mà thiết bị của
người dùng có thể nhận được. Thiết bị này cần ở chế độ “thức” và không ở chế độ chờ, có nghĩa
là thiết bị sẽ không Master động quét bất kỳ tín hiệu báo hiệu nào. Theo một cách nào đó, điều
này giúp tiết kiệm thời lượng pin của thiết bị và giảm căng thẳng và tiêu hao pin cho thiết bị.

Người dùng có thể thực hiện hành động để quét và tìm kiếm các tín hiệu lân cận. Nếu máy quét
tìm thấy thứ gì đó, nó sẽ cung cấp cho bạn một danh sách để bạn lựa chọn, bao gồm khả năng
phân loại và lọc kết quả để giảm spam và đưa nội dung phù hợp nhất lên đầu.

Tất cả những gì còn lại cần làm là chọn URL phù hợp nhất và mở nó.

Web trong cuộc sống sử dụng URL vì chúng được người dùng cuối nói chung hiểu rõ và linh hoạt
vì nó có thể liên kết đến một trang web thực tế, hướng người dùng đến một không gian giàu nội
dung hoặc được liên kết sâu để mở một ứng dụng khác trên điện thoại của bạn.

Khi nói đến beacon Bluetooth và Web trong cuộc sống, beacon chỉ chịu trách nhiệm nhận URL
đến thiết bị. Mục đích của Web trong cuộc sống là giảm thiểu sự khó khăn của việc khám phá
URL.

Tuy nhiên, Web trong cuộc sống đã bị Google khai tử vào tháng 10 năm 2017 do ngừng hỗ trợ
cho nó. Điều này có nghĩa là bạn không còn có thể nhận thông báo trên điện thoại của mình nếu
không tải ứng dụng xuống. 

Cấu trúc liên kết mạng

Mạng Bluetooth bao gồm nhiều người dùng bluetooth. Có hai loại cấu trúc liên kết mạng trong
bluetooth: Piconet và Scatternet. Piconet được hình thành bởi một Master và một Slave
hoặc nhiều Slave. Có tối đa 7 Slave hoạt động trong piconet. Các Slave chỉ có thể truyền khi
chúng được thiết bị Master yêu cầu. Sẽ có khoảng 255 Slave ở trạng thái đậu xe (giống trạng thái
nghỉ). Các Slave đang hoạt động được thăm dò bởi Master để truyền tải. Mỗi trạm sẽ nhận được
địa chỉ đậu 8 bit. Trạm đã đỗ có thể tham gia chỉ trong 2 ms. Tất cả các đài khác có thể tham gia
trong thời gian nhiều hơn. Khoảng 10 piconet như vậy tồn tại trong vùng phủ sóng vô tuyến
bluetooth.

Sự kết hợp của nhiều piconet được gọi là scatternet. Một thiết bị có thể tham gia vào nhiều
piconet. Nó sẽ chia sẻ thời gian và cần được đồng bộ hóa với Master của piconet hiện tại.

Nó hỗ trợ tốc độ dữ liệu dựa trên các phiên bản khác nhau từ 720 kbps đến khoảng 24 Mb/s,
phạm vi phủ sóng từ 1 đến 100 mét dựa trên loại công suất được hỗ trợ trên các thiết bị
bluetooth.

Thông số kỹ thuật của Bluetooth

Tiêu chí Tính năng được hỗ trợ

Tần số RF 2.4 GHz

Truyền điện 1 – 100 mW

Tốc độ dữ liệu ~ 1Mb/s

Khoảng cách 1 – 100 m

Băng thông RF 220 KHz - 1MHz

Loại điều chế Gaussian FSK (GFSK)

Số lượng sóng mang RF 23 - 79

Cấu trúc liên kết tối đa 7 liên kết trong cấu hình sao

tỷ lệ nhảy 1600 bước mỗi giây

Loại truy cập FH-TDD-TDMA

Phân bổ tần số Bluetooth

Bluetooth hoạt động ở băng tần ISM 2,4 GHz. Bảng sau xác định tần số buletooth được sử dụng
trên toàn thế giới. Băng thông đủ để xác định 79 kênh (ở Mỹ, Châu Âu và các quốc gia khác) có
băng thông 1 MHz trong mỗi kênh. Nhật Bản, Tây Ban Nha và Pháp sử dụng 23 kênh bluetooth.

Khu vực Dải tần số Kênh RF

Hoa Kỳ, Châu Âu và phần

còn lại của Thế giới 2,4 đến 2,4835 GHz f = 2,402 + n, MHz (n = 0 đến 78)

Nhật Bản 2,471 đến 2,497 GHz f = 2.473 + n, MHz (n = 0 đến 22)

Tây Ban Nha 2,445 đến 2,475 GHz f = 2.449 + n, MHz (n = 0 đến 22)

Nước pháp 2,4465 đến 2,4835 GHz f = 2,454 + n, MHz (n = 0 đến 22)

Công suất Bluetooth class1, class2, class3

Bluetooth xác định 3 loại công suất Master được sử dụng bởi các thiết bị. Kiểm soát công suất
được sử dụng để giữ bức xạ trong giới hạn để hệ thống hoạt động hiệu quả mà không gây nhiễu
các thiết bị bluetooth hàng xóm. Thuật toán điều khiển công suất được thiết kế giữa thiết bị
Master và thiết bị Slave sử dụng giao thức quản lý liên kết. Bảng sau đây đề cập đến phạm vi phủ
sóng khoảng cách cho mỗi lớp công suất.

Khoảng
cách bao
Lớp Giới hạn công suất phủ

Công suất đầu ra 100mW (20 dBm) để đạt được phạm vi tối đa
Công suất tối thiểu là 1mW
Class1 Điều khiển công suất là bắt buộc phải có trong lớp này 100 m

Tối đa công suất đầu ra 2,4mW (+ 4dBm)

Tối thiểu công suất đầu ra 0,25mW (-6dBm)
Class2 Điều khiển công suất là tùy chọn trong lớp này 10 m

Class3 Công suất đầu ra thấp nhất có thể với lớp này, danh nghĩa là 1mW. 1m

Ngăn xếp/lớp Giao thức Bluetooth

Kiến trúc giao thức của bluetooth bao gồm:
 Core protocols: bao gồm 5 lớp ngăn xếp giao thức: Bluetooth Radio, Baseband,
Link manager protocol, Logical link control and Adaptation protocol, Service discovery
protocol
 Cable replacement protocol: RFCOMM
 Telephony Control Protocols
 Adopted protocols: PPP, TCP/UDP/IP, OBEX và WAE/WAP

Core protocols

Bluetooth Radio: Xác định giao diện không khí, các dải tần số, thông số kỹ thuật nhảy tần, kỹ
thuật điều chế được sử dụng và truyền tải các lớp công suất.

Baseband: Sắp xếp địa chỉ, định dạng khung gói, các thuật toán điều khiển thời gian và công
suất cần thiết để thiết lập kết nối giữa các thiết bị bluetooth trong piconet được định nghĩa trong
phần này của đặc điểm kỹ thuật giao thức.
Link Manager protocol: Thiết lập liên kết giữa các thiết bị bluetooth và duy trì liên kết giữa
chúng. Giao thức này cũng bao gồm các thông số kỹ thuật xác thực và mã hóa.  Việc thương
lượng kích thước gói giữa các thiết bị có thể được thực hiện bởi điều này.

Logical link control and adaptation protocol: Giao thức L2CAP này điều chỉnh khung lớp trên
sang định dạng khung lớp baseband và ngược lại. L2CAP đảm nhận cả dịch vụ định hướng kết
nối và dịch vụ không kết nối.
Service discovery protocol: Các truy vấn liên quan đến dịch vụ bao gồm thông tin thiết bị có
thể được xử lý tại giao thức này để có thể thiết lập kết nối giữa các thiết bị bluetooth.
Cable replacement protocol
Cổng nối tiếp phổ biến để cung cấp giao tiếp nối tiếp giữa các thiết bị.  Bluetooth sử dụng
RFCOMM làm giao thức thay thế cáp. RFCOMM hoạt động như một cổng nối tiếp ảo và vận
chuyển các bit dữ liệu số nhị phân. Về cơ bản, nó mô phỏng các thông số kỹ thuật RS232 qua lớp
vật lý bluetooth.

Telephony Control Protocols

TCS-BIN là giao thức được sử dụng ở đây là giao thức có định hướng bit. Nó chỉ định các tín hiệu
điều khiển cuộc gọi và các thủ tục quản lý tính di động. Những tín hiệu này đảm nhận việc thiết
lập các cuộc gọi dữ liệu và lời nói.

Adopted protocols

Các giao thức này đã được xác định bởi các cơ quan tiêu chuẩn khác được kết hợp mà không có
bất kỳ thay đổi nào trong kiến trúc ngăn xếp giao thức bluetooth. Các giao thức là PPP,
TCP/UDP/IP, OBEX và WAE/WAP:
 PPP là một giao thức điểm Slavei điểm được sử dụng để truyền dữ liệu IP.
 TCP/UDP/IP là một phần của mô hình TCP/IP cơ bản.
  OBEX là một giao thức trao đổi đối tượng được phát triển bởi IrDA và nó tương tự
như HTTP. Nó là một giao thức cấp phiên.
 WAE/WAP cung cấp Môi trường ứng dụng không dây và WAP cung cấp Giao thức
ứng dụng Wirelesss.

Lớp vật lý Bluetooth

Lớp vật lý Bluetooth bao gồm các thông số kỹ thuật vô tuyến và băng tần cơ sở như được định
nghĩa trong IEEE 802.15.1.

Nhảy tần số

Nó phục vụ 2 mục đích:

 Một là cung cấp khả năng chống nhiễu đa đường.
 Thứ hai là nó cung cấp nhiều quyền truy cập vào các thiết bị ở các piconet khác
nhau được đặt cùng vị trí.

Hệ thống Bluetooth sử dụng sơ đồ nhảy tần với khoảng 80 tần số khác nhau, với khoảng cách
sóng mang khoảng 1MHz. Khi bật tính năng nhảy tần, một kênh logic được xác định bằng chuỗi
nhảy. Tại bất kỳ thời điểm nào băng thông 1 MHz được chia sẻ tối đa.  8 thiết bị. Các kênh logic
khác nhau có thể sử dụng cùng một lúc BW 80 MHz. Xung đột xảy ra khi hai thiết bị bluetooth sử
dụng cùng một tần số nhảy tần đồng thời nếu chúng ở trên các piconet khác nhau và các kênh
logic khác nhau. Tốc độ nhảy là 1600 bước mỗi giây, do đó kênh vật lý chỉ tồn tại trong 0,625ms.

Đài phát thanh Bluetooth sử dụng cấu trúc liên kết TDD trong đó việc truyền dữ liệu diễn ra theo
một hướng tại một thời điểm và nó luân phiên theo hai hướng lần lượt.  Quyền truy cập là TDMA,
vì phương tiện piconet được chia sẻ giữa hai thiết bị. Do đó truy cập piconet được gọi là FH-TDD-
TDMA.

Liên kết vật lý

Có 2 cách liên kết có thể được thiết lập giữa Master và Slave.
 SCO (Synchronous connection oriented) được gọi là định hướng kết nối đồng
bộ. Trong kiểu này, băng thông cố định được phân bổ cho kết nối điểm Slavei điểm giữa
Master và Slave. Đặt trước cơ bản là 2 slot liên tiếp. Master hỗ trợ 3 liên kết SCO và slave
hỗ trợ 2 hoặc 3 liên kết.
 ACL (Asynchronous connectionless) được gọi là kết nối không đồng bộ. Điều này
được sử dụng cho liên kết điểm Slavei đa điểm giữa Master và Slave. Chỉ có một liên kết
ACL tồn tại và để truyền lại gói tin nhiều hơn được yêu cầu. Trong trường hợp các vị trí
không được đặt trước trong các liên kết SCO, thiết bị Master có thể trao đổi gói với bất kỳ
thiết bị Slave nào trên mỗi khe thời gian.
Baseband packet formats

Bluetooth Packet Format = Access Code(72 bits) + Header(54 bits) + Payload (0 to 2745 bits)
 Access code bao gồm preamble(4bits), sync word(64bits) và trailer field(4 bits).
 Header field bao gồm AM_ADDR(3 bits), type(4 bits), flow(1 bit), ARQN(1 bit),
SEQN(1 bit) và HEC(8 bits).

Như đã đề cập ở trên, Access code trong gói được sử dụng để đồng bộ hóa thời gian và các phần
ofset khác. Access code cũng được sử dụng cho các yêu cầu phân trang, phản hồi phân trang và
các mục đích điều tra.
Header được sử dụng để xác định loại gói và sẽ mang thông tin điều khiển giao thức.
Trường trọng tải sẽ mang dữ liệu hoặc giọng nói của người dùng. Mã truy cập kênh xác định một
piconet, Mã truy cập thiết bị được sử dụng để phân trang REQ/RES, Mã truy cập yêu cầu được sử
dụng cho mục đích yêu cầu.

Phương pháp sửa lỗi

1/3 rate forward error correction (FEC)

2/3 rate forward error correction (FEC)
Automatic Repeat Request Scheme (ARQ)
Header and payload proces

Định dạng gói Bluetooth

Cấu trúc gói Bluetooth được hiển thị bên dưới. Nó bao gồm lời mở đầu (1 byte), địa chỉ truy cập
(4 byte), PDU (tối đa 257 byte) và CRC (3 byte). Phần PDU mang gói quảng cáo hoặc gói dữ
liệu. Cả hai loại gói này sẽ có phần tiêu đề và phần tải trọng.
Cả phần tiêu đề (2 byte) và phần tải trọng (tối đa 37 byte trong gói quảng cáo và tối đa 255 byte
trong gói dữ liệu) đều được xử lý riêng biệt bằng cách sử dụng mô-đun/khối lớp vật lý bluetooth.

Cấu trúc gói cho BR và EDR được thể hiện trong hình.
Xử lý tiêu đề thông qua Lớp vật lý Bluetooth

Phần phát:
 HEC được tạo và thêm vào phần tiêu đề gói tin.
 Các bit tiêu đề được xáo trộn bằng cách sử dụng từ làm trắng.
 Mã hóa FEC được áp dụng cho các bit dữ liệu được xáo trộn ở trên.
 Các bit dữ liệu được mã hóa FEC được điều chế.
 Việc định hình xung được áp dụng trước khi chuyển đổi lên RF.
 Dữ liệu dạng xung được đảo ngược ở tần số 2,4 GHz và truyền qua không khí.
Phần thu:
  Các thao tác ngược lại được thực hiện ở phần viz thu bluetooth. Chuyển đổi xuống RF, khử
xung, giải điều chế, giải mã FEC, khử làm trắng, kiểm tra HEC trước khi tiêu đề được giải
mã.

Xử lý tải trọng dữ liệu thông qua Lớp vật lý Bluetooth

Xử lý tải trọng sử dụng tất cả các mô-đun như được áp dụng cho xử lý tiêu đề. Ngoài ra, nó sử
dụng mô-đun mã hóa E0 hoặc AES-CCM. Khi mã hóa E0 được áp dụng, toàn bộ tải trọng phải
được mã hóa. Khi mã hóa AES-CCM được áp dụng, chỉ phần thân tải trọng và MIC mới được mã
hóa; trong đó tiêu đề tải trọng và CRC sẽ không được mã hóa.
Phần phát của quá trình xử lý lớp vật lý bluetooth và phần xử lý của bộ thu được tự giải thích
như thể hiện trong hình.

Khối hoặc mô-đun lớp vật lý Bluetooth

Phần sau mô tả ngắn gọn về các mô-đun hoặc khối lớp vật lý bluetooth.  Để biết thông số kỹ
thuật chi tiết, hãy tham khảo thông số kỹ thuật bluetooth vol-2, part-B do Bluetooth SIG xuất
bản.
Kiểm tra lỗi : Tạo và kiểm tra HEC, tạo CRC được xác định trong tiêu chuẩn với các đa thức bộ
tạo tương ứng của chúng.
Làm trắng dữ liệu : Việc làm trắng dữ liệu sẽ không được áp dụng cho các gói tập tin đồng bộ
hóa. Cả tiêu đề và tải trọng đều được xáo trộn với từ làm trắng dữ liệu để ngẫu nhiên hóa dữ liệu
từ các mẫu dư thừa cao. Điều này giúp giảm thiểu sai lệch DC trong gói bluetooth trước khi được
áp dụng cho mô-đun bộ mã hóa FEC. Từ làm trắng được tạo ra với đa thức g (D) = D 7 + D 4 + 1
mà 221 trong biểu diễn bát phân.
Sửa lỗi : Ba sơ đồ sửa lỗi được sử dụng trong bluetooth là 1/3 tỷ lệ FEC, 2/3 tỷ lệ FEC và sơ đồ
ARQ. Sử dụng lược đồ ARQ, các loại gói tin khác nhau được truyền cho đến khi đích nhận được
thành công (hoặc thời gian chờ vượt quá).
Điều chế: Có hai chế độ điều chế Master viz. tốc độ cơ bản và tốc độ dữ liệu nâng cao. Điều chế
FM nhị phân được áp dụng cho tốc độ cơ bản khi điều chế PSK được áp dụng cho tốc độ dữ liệu
nâng cao. Có hai biến thể của viz điều chế PSK. π/4-DQPSK, 8-DPSK. Điều chế FM nhị phân còn
được gọi là GFSK (Gaussian Frequency Shift Keying). Tỷ lệ ký hiệu cho cả ba kiểu điều chế là như
nhau, tức là 1 MSym/Sec. Các tỷ lệ dữ liệu tổng khác nhau viz. Có thể đạt được 1 Mbps (đối với
tốc độ cơ bản), 2 Mbps (đối với EDR sử dụng π/4-DQPSK) và 3 Mbps (đối với EDR sử dụng 8-
DPSK). Để truyền mã truy cập và tiêu đề gói, GFSK được sử dụng. Để truyền đồng bộ. trình tự, tải
trọng và trình tự trailer, điều chế PSK với tốc độ dữ liệu 2 Mbps hoặc 3 Mbps được sử dụng.
Tạo hình xung: Định dạng xung cosine nâng lên căn bậc hai được áp dụng để tạo ra tín hiệu
mang thông tin thông thấp tương đương v (t).
Chuyển đổi tần số RF : Tín hiệu dữ liệu dạng xung được chuyển đổi theo tần số sóng mang
băng tần ISM (2,4 GHz) trong số 40 kênh tần số bluetooth được chỉ định >> theo yêu cầu (tức là
kênh quảng cáo hoặc kênh dữ liệu). Nhảy tần thích ứng được áp dụng như định nghĩa trong Tập
2, Phần-C, mục 4.1.4.
NGƯỜI GIỚI THIỆU
Thông số kỹ thuật của lớp vật lý Bluetooth (tức là lớp băng tần Bluetooth, Lớp-1) được xác định
trong tài liệu cốt lõi bluetooth Vol-2, Phần-B, phần 7.

Lớp MAC Bluetooth

Lớp MAC của Bluetooth bao gồm Giao thức Trình quản lý Liên kết (LMP) và Giao thức Điều
khiển Liên kết Hợp lý và Thích ứng (L2CAP).

Tiêu chuẩn Bluetooth xác định 5 loại kênh dữ liệu logic khác nhau dựa trên lưu lượng tải trọng
khác nhau do chúng mang theo. Chúng là kiểm soát liên kết, trình quản lý liên kết, không đồng
bộ người dùng, đồng bộ người dùng và đồng bộ người dùng. Kênh điều khiển liên kết mang
thông tin như ARQ, điều khiển luồng và đặc tính tải trọng.

Các chế độ hoạt động của Bluetooth

Trong trạng thái kết nối, thiết bị bluetooth có thể ở một trong 4 chế độ bao gồm chế độ hoạt
động, chế độ Sniff, chế độ giữ và chế độ đỗ.
 Trong chế độ Hoạt động, thiết bị bluetooh tham gia tích cực vào kênh.
  Trong chế độ Sniff, thiết bị Slave trợ bluetooth sẽ không nghe trên tất cả các khe đã
nhận mà chỉ nghe các khe được chỉ định cho các bản tin dành cho nó.
 Ở chế độ Giữ, thiết bị bluetooth không truyền dữ liệu trong thời gian dài.
 Ở chế độ đỗ, thiết bị bluetooth sẽ có ít hoạt động được thực hiện và do đó sẽ tiêu
thụ điện năng rất thấp.

Giao thức Trình quản lý Liên kết (LMP)

Giao thức LMP được sử dụng để thiết lập liên kết và kiểm soát liên kết. Kiểm soát Liên kết (LC)
cung cấp độ tin cậy cho Giao thức Trình quản lý Liên kết. LM PDU được gửi trong các gói khe cắm
đơn.
PDU = Opcode (7bits), ID giao dịch (1bit), nội dung thông tin

Giao thức điều khiển và thích ứng liên kết logic (L2CAP)

Giao thức L2CAP này giống như LLC chăm sóc các dịch vụ giao thức lớp liên kết giữa các thực
thể. Nó cung cấp các dịch vụ cho các lớp trên và dựa vào lớp dưới để kiểm soát luồng cũng như
kiểm soát lỗi. L2CAP sử dụng các liên kết ACL và không sử dụng các liên kết SCO.
L2CAP cung cấp hai loại dịch vụ không kết nối và dịch vụ chế độ kết nối. Loại không kết nối cung
cấp dịch vụ phân phối dữ liệu đáng tin cậy. Loại chế độ kết nối cung cấp dịch vụ sử dụng giao
thức HDLC.

Kiến thức cơ bản về bảo mật Bluetooth

Có 3 quy trình trong bluetooth: khởi tạo, xác thực và mã hóa.

Do ứng dụng rộng rãi của công nghệ bluetooth trong cuộc sống hàng ngày của chúng ta, bảo
mật của các thiết bị bluetooth đã trở thành một mối quan tâm đối với người dùng. Mặc dù thiết
bị bluetooth được sử dụng song song với các thiết bị WPAN khác nhưng các thuật toán bảo mật
bluetooth được phát triển để chăm sóc xác thực và mã hóa chỉ giữa các thiết bị bluetooth trên
đường dẫn vô tuyến.

Đặc điểm kỹ thuật bluetooth đã xác định 3 dịch vụ bảo mật: xác thực, bảo mật và ủy quyền.  Hơn
nữa bluetooth có 3 chế độ bảo mật như sau:
 Chế độ bảo mật 1: Chế độ không an toàn
 Chế độ bảo mật 2: Chế độ bảo mật thực thi cấp dịch vụ
 Chế độ bảo mật 3: Chế độ bảo mật thực thi cấp liên kết

Quy trình xác thực cho bảo mật Bluetooth

Giả sử rằng thiết bị bluetooth-1 muốn truy cập hoặc ghép nối với thiết bị bluetooth-2 . Ở
đây thiết bị 1 được gọi là “Claimant” và thiết bị 2 được gọi là “Verifier”.
 Thiết bị-1 truyền BD_ADDR (địa chỉ 48 bit) đến thiết bị-2.
 Thiết bị-2 truyền AU_RAND (thử thách ngẫu nhiên 128-bit) đến thiết bị-1.
 Cả thiết bị-1 và thiết bị-2 đều thực hiện các phép tính bằng thuật toán E1 để tính
SRES. Các thuật toán E1 lấy BD_ADDR, AU_RAND và khóa liên kết làm đầu vào để tính
SRES.
 Thiết bị-1 (người xác nhận quyền sở hữu) trả về SRES trong phản hồi cho thiết bị-2
(người xác minh).
 Người xác minh thực hiện so sánh SRES trả về và SRES đã tính toán. SRES có kích
thước 32 bit.
 Nếu SRES bằng nhau, người xác minh sẽ xác thực nguyên đơn và cho phép thiết lập
kết nối. Sau đây là các trường hữu ích và kích thước của chúng được sử dụng trong quy
trình xác thực bluetooth. Quy trình này tạo ra trường ACO sẽ được sử dụng trong quy
trình mã hóa bluetooth.

Quy trình mã hóa cho bảo mật Bluetooth

Mã hóa Bluetooth được thực hiện để bảo vệ tải trọng của gói được trao đổi giữa hai thiết bị
bluetooth. Quy trình mã hóa trong bảo mật bluetooth dựa trên thuật toán E0. Các bước sau
được thực hiện trong quy trình:
 Đầu tiên sử dụng Trình tạo khóa Khóa mã hóa (Kc) được tạo bằng các đầu vào như
EN_RAND, ACO và Khóa liên kết.
 Thuật toán E0 sử dụng EN_RAND, BD_ADDR, Số vị trí và khóa mã hóa (Kc) để tạo
'Dòng khóa'. • Cuối cùng 'Keystream' được tạo là EX-OR ed với các bit thông tin trọng
tải. Điều này ('Bản mã') được truyền đến thiết bị nhận.
 Các bước tương tự được thực hiện bởi thiết bị bluetooth-2 để truyền thông tin. Cách
này đảm bảo bảo mật bluetooth 2 chiều.
Sau đây là ba chế độ mã hóa được hỗ trợ trong bluetooth để cung cấp dịch vụ bảo mật.
 Chế độ 1: Mã hóa không được thực hiện trên bất kỳ loại lưu lượng nào.
 Chế độ 2: Thông tin truyền phát không được mã hóa trong khi thông tin được đánh
địa chỉ riêng được mã hóa bằng các khóa liên kết riêng lẻ.
 Chế độ 3: Tất cả thông tin lưu lượng được mã hóa bằng khóa liên kết Master.

Khác biệt giữa Bluetooth và BLE

Thông số kỹ thuật Bluetooth BLE

Cấu trúc mạng Scatternet Star

Sự tiêu thụ năng lượng Thấp (dưới 30 mA) Rất thấp (dưới 15 mA)
 Tốc độ, vận tốc 700 Kb/s 1 Mb/s

Phạm vi <30 m 50 mét (150 m ở bãi đất trống)

Dải tần số RF 2400 MHz 2400 MHz

79 kênh từ 2.400 GHz đến 40 kênh từ 2402MHz đến 2480 MHz

2.4835 GHz với khoảng cách (bao gồm 3 kênh quảng cáo và 37
Kênh tần số 1 MHz kênh dữ liệu)

GFSK (chỉ số điều chế 0.35),

Điều chế π/4 DQPSK, 8DPSK GFSK (chỉ số điều chế 0.5)

Độ trễ khi truyền dữ

liệu giữa hai thiết bị Khoảng 100 ms Khoảng 3 ms

Truyền bá FHSS (kênh 1MHz) FHSS (kênh 2MHz)

Lớp liên kết TDMA TDMA

kích thước bản tin

(byte) 358 (Tối đa) 8 đến 47

8 bit CRC (tiêu đề), 16 bit

Phát hiện/sửa lỗi CRC, 2/3 FEC (tải trọng), ACK 24 bit CRC, ACK

64b/128b, lớp ứng dụng do 128 bit AES, lớp ứng dụng do người
Bảo vệ người dùng xác định dùng xác định

Thông lượng ứng dụng 0,7 đến 2,1 Mb/giây dưới 0,3 Mb/giây

Nút/Slave hoạt động 7 Vô hạn

Bluetooth v1.2, v2.0, v2.1, v3.0, v4.0 và v4.1

Công nghệ Bluetooth cung cấp khả năng không dây tầm ngắn để hai thiết bị có thể truyền dữ
liệu với nhau. Trong nhiều năm, nhiều phiên bản Bluetooth khác nhau đã được phát triển, bao
gồm v1.2, v2.0, v2.1, v3.0, v4.0 và v4.1. Nó hoạt động ở dải tần ISM 2,4 GHz. Công nghệ này dựa
trên tiêu chuẩn IEEE 802.15.1. Cả hai lớp PHY và MAC của Bluetooth đều được xác định trong
tiêu chuẩn WPAN này.
Tất cả các phiên bản bluetooth đều có các yêu cầu về tốc độ và tốc độ dữ liệu khác nhau. Chúng
tương thích với các phiên bản trước của chúng để thiết bị có một phiên bản có thể tương thích
với phiên bản kia. Mạng Bluetooth bao gồm các piconet. Mỗi piconet sẽ có một Master và một
đến bảy Slave giao tiếp với nhau.

Thông số kỹ thuật của Bluetooth RF và băng tần cơ sở:

 Loại điều chế là GFSK
 Tốc độ dữ liệu đỉnh khoảng 1Mbps
 Băng thông RF là 220KHz và 1MHz
 Dải tần RF là 2,4 GHz
 Số lượng sóng mang RF là 23/79
 Khoảng cách sóng mang RF là 1 MHz
 Nhảy tần 1600 bước/giây
 Chế độ Song công phân chia theo thời gian
 Công suất phát khoảng 0,1 watt
 phủ sóng khoảng cách lên đến 10m đến 100m
 Có thể có 7 liên kết đồng thời trong cấu hình sao

Bluetooth v1.2
 Tốc độ hoặc tốc độ dữ liệu: 720 kbps
 Khả năng tương thích ngược: v1.1

Bluetooth v2.0
 Tốc độ: 2,1 Mbps
 Tương thích ngược: Bluetooth v1.2

Bluetooth v2.1
 Tốc độ: 2 Mbit/s
 Tương thích ngược: Bluetooth v1.2

Bluetooth v3.0
 Tốc độ: 24 Mbps
 Tương thích ngược: Bluetooth v2.1

Bluetooth v4.0
 Tốc độ: 24 Mbps
 Tương thích ngược: Bluetooth v3.0

Bluetooth v4.1
 Được thiết kế để hoạt động liên tục với công nghệ di động LTE.
 Tương thích ngược với các phiên bản trước.

Bluetooth 5.0 và 4.2

 Thông số kỹ thuật
hoặc tính năng Bluetooth 5.0 Bluetooth 4.2

Cao hơn, gấp đôi so với phiên bản

Bluetooth 4.2 Thấp hơn, hỗ trợ khoảng 1
Tốc độ, vận tốc Hỗ trợ khoảng 2 Mbps Mbps

Cao hơn, gấp bốn lần so với phiên

bản Bluetooth 4.2
Hỗ trợ đường dẫn Line Of Sight (LOS)
200 mét trong môi trường ngoài trời,
Hỗ trợ 40 mét trong môi trường trong
Phạm vi nhà
Thấp hơn, Hỗ trợ 50 mét
ngoài trời,
Hỗ trợ 10 mét trong nhà

Yêu cầu về nguồn

điện Thấp Cao

Nhỏ, Khoảng 31 byte chỉ

cung cấp 17 đến 20 byte
cho tải trọng dữ liệu thực
Dung lượng bản tin Lớn, khoảng 255 byte tế

Mạnh mẽ để hoạt
động trong môi
trường tắc nghẽn Hơn Ít hơn

Tuổi thọ pin Lâu hơn Nhỏ hơn

Kém an toàn hơn so với

Kiểm soát an ninh Tốt hơn Bluetooth 5.0

Thông lượng dữ liệu 2 Mbps, cho khoảng 1,6 Mbps với chi
lý thuyết phí 1 Mb/giây

độ tin cậy Cao Thấp

Cuộc sống kỹ thuật Kém tốt hơn so với

số Tốt hơn Bluetooth 5.0

Hỗ trợ cho các thiết

bị IoT Đúng Không
 Beacons ít phổ biến hơn do
Beacons đã trở nên phổ biến hơn do tốc độ/phạm vi ít hơn cũng
tốc độ và phạm vi gia tăng trong như dung lượng bản tin
Báo hiệu Bluetooth phiên bản bluetooth 5.0. thấp khoảng 31 byte.

Sau khi so sánh bluetooth 4.2 so với 5.0 và xác định được sự khác biệt giữa bluetooth 4.2 và 5.0,
bluetooth 5.0 sẽ trở nên phổ biến trong các thiết bị điện thoại thông minh, thiết bị Internet of
Things (IoT) và Bluetooth Beacons. Các báo hiệu bluetooth phổ biến hiện có là iBeacon của Apple
và Eddystone của Google.

Bluetooth 5 và bluetooth 5.1

 Bluetooth 5.1 đã được Bluetooth SIG xuất bản vào ngày 21 tháng 1 năm 2019.
 Nó tương thích ngược với các phiên bản bluetooth trước đó như v5.0 và v4.2.
 Bluetooth 5.1 giới thiệu tính năng tìm hướng giúp định vị các phím của bạn có bộ
theo dõi bluetooth trên chúng. Nó cung cấp “độ chính xác từng centimet” trong việc tìm
kiếm vị trí.
 Chế độ quảng cáo đã được cải thiện trong bluetooth v5.1, giúp các thiết bị thông
minh như nhiệt kế truyền các phép đo của nó đến các thiết bị bluetooth khác mà không
cần kết nối chúng.
 Bluetooth v5.1 này cung cấp độ tin cậy và khả năng mở rộng.
 Nó cho phép các thiết bị có pin hạn chế (ví dụ như đồng hồ thông minh) có thể cõng
các thiết bị mạnh mẽ khác như điện thoại di động.
 Bluetooth 5.1 tăng tốc quá trình bắt tay với các thiết bị đã được ghép nối trước đó.
 Tính năng bắt được giới thiệu trong các phiên bản bluetooth trước, nhưng v5.1 làm
cho nó thông minh hơn.

Đây là những điểm cải tiến chính so với các phiên bản bluetooth trước:
 Khoảng thời gian đến (AoA) và Góc khởi hành (AoD)
 Chỉ số kênh quảng cáo
 GATT Caching
 Các tính năng bổ sung nhỏ đợt 1
o Hỗ trợ HCI cho các phím gỡ lỗi trong Kết nối bảo mật LE
o Cơ chế cập nhật độ Master xác của đồng hồ ngủ
o Trường ADI trong dữ liệu phản hồi quét
o Tương tác giữa QoS và Đặc tả luồng
o Phân loại kênh lưu trữ cho quảng cáo Slave
o Cho phép SID xuất hiện trong báo cáo phản hồi quét
o Chỉ định hành vi khi các quy tắc bị vi phạm
 Periodic Advertising Sync Transfer
 Các tính năng được bổ sung trong CSA6 được tích hợp trong bluetooth v5.1
o Mô hình
 o Hệ thống phân cấp mô hình dựa trên lưới
 Tính năng bị loại bỏ trong phiên bản này: Các phím đơn vị

Kênh Quảng cáo BLE & Kênh Dữ liệu BLE

Bluetooth hoạt động ở Băng tần ISM 2,4 GHz. Nó trải dài từ 2400 đến 2483,5 MHz. Các kênh BLE
cách nhau 1 MHz.

Advertising Channels

 Mang dữ liệu quảng bá cho các ứng dụng

 Giúp phát hiện ra Slave để kết nối với chúng
 Thiết bị BLE sử dụng bất kỳ kênh quảng cáo BLE nào sau đây để truyền/nhận các
gói quảng cáo thuộc nhiều loại khác nhau. Các kênh này mang các PDU của kênh quảng
cáo.

Kênh BLE Tần số

37 2402 MHz

38 2426 MHz

39 2480 MHz

Data Channels
  Sau khi kết nối được thiết lập giữa Master và Slave, các thiết bị có thể gửi dữ liệu
cho nhau. Điều này đạt được bằng cách trao đổi các PDU kênh dữ liệu trong các sự kiện
kết nối theo lịch trình.
 Các thiết bị BLE Master và Slave sử dụng bất kỳ kênh dữ liệu BLE nào sau đây để
truyền/nhận.

Kênh BLE Tần số Kênh BLE Tần số

0 2404 MHz 21 2448 MHz

1 2406 MHz 22 2450 MHz

2 2408 MHz 23 2452 MHz

3 2410 MHz 24 2454 MHz

4 2412 MHz 25 2456 MHz

5 2414 MHz 26 2458 MHz

6 2416 MHz 27 2460 MHz

7 2418 MHz 28 2462 MHz

8 2420 MHz 29 2464 MHz

9 2422 MHz 30 2466 MHz

10 2424 MHz 31 2468 MHz

11 2428 MHz 32 2470 MHz

12 2430 MHz 33 2472 MHz

13 2432 MHz 34 2474 MHz

14 2434 MHz 35 2476 MHz

15 2436 MHz 36 2478 MHz

Ngăn xếp giao thức & Kiến trúc hệ thống BLE

BLE (Bluetooth Low Energy) là công nghệ WPAN được thiết kế và duy trì bởi Bluetooth
Special Interest Group (SIG). Có nhiều phiên bản bluetooth khác nhau. Phiên bản 4.2 trở lên
được gọi là BLE. Phiên bản mới nhất trong sê-ri này là v5.0 và v5.1. Các thông số kỹ thuật của
BLE nhằm giảm mức tiêu thụ điện năng và chi phí của thiết bị trong khi vẫn duy trì phạm
vi phủ sóng. BLE được gọi là “Bluetooth thông minh” trong khi phiên bản trước được gọi là
“Bluetooth cổ điển”.
 BLE không tương thích ngược với BR/EDR.
 BLE sử dụng băng tần ISM 2,4 GHz ở chế độ kép hoặc chế độ đơn. Chế độ kép hỗ
trợ cả bluetooth cổ điển và thiết bị ngoại vi năng lượng thấp.
 Tất cả các thiết bị BLE đều sử dụng cấu hình GATT (Generic Attribute Profile). Giao
thức GATT cung cấp một loạt lệnh để máy khách khám phá thông tin về máy Master
BLE.
 Kiến trúc ngăn xếp giao thức BLE bao gồm hai phần: bộ điều khiển (Controller) và
máy Master (Host). Cả hai đều được giao diện bằng HCI (Host to Controller Interface).
 Mọi cấu hình và ứng dụng đều chạy trên các lớp giao thức GAP & GATT.

Lớp vật lý
 Máy phát sử dụng điều chế GFSK và hoạt động ở băng tần 2,4 GHz.
 BLE cung cấp tốc độ dữ liệu 1 Mbps (Bluetooth v4.2)/2 Mbps (Bluetooth v5.0).
 Nó sử dụng bộ thu phát nhảy tần.
 Hai chương trình điều chế được chỉ định để cung cấp 1 Msym/s và 2 Msym/s.
 Hai biến thể lớp PHY được chỉ định: chưa được mã hóa và mã hóa.
 Cấu trúc liên kết Time Division Duplex (TDD) được sử dụng trong cả hai chế độ PHY.
Lớp liên kết
Chịu trách nhiệm quảng cáo, quét và tạo/duy trì kết nối. Vai trò của các thiết bị BLE thay đổi
trong chế độ ngang hàng (Unicast) hoặc chế độ quảng bá (Broadcast). Các vai trò phổ biến là
Advertiser/Scanner (Initiator), Slave/Master hoặc Broadcaster/Observer. Các trạng thái của lớp
liên kết được xác định trong hình bên dưới.

Mô tả trạng thái thiết bị BLE

Các trạng thái:

 Trạng thái chờ (Standby): Không có truyền hoặc nhận gói tin nào ở trạng thái này.
Trạng thái này có thể được nhập từ bất kỳ trạng thái BLE nào khác.
 Trạng thái quảng cáo (Advertising): Thiết bị BLE ở trạng thái này được gọi là
“Advertiser”. Trạng thái này có thể đạt được từ trạng thái Standby. Lớp liên kết sẽ truyền
các gói quảng cáo và lắng nghe và phản hồi các phản hồi được kích hoạt do các gói quảng
cáo.
 Trạng thái quét (Scanning): Lớp liên kết lắng nghe các gói quảng cáo từ các thiết bị
quảng cáo khác. Thiết bị BLE ở trạng thái này được gọi là “Scanner”. Trạng thái này có thể
đạt được từ trạng thái Standby.
 Trạng thái khởi tạo (Initiating): Thiết bị BLE ở trạng thái này được gọi là “Initiator”.
Trạng thái BLE này có thể đạt được từ trạng thái Standby. Lớp liên kết lắng nghe các gói
vật lý quảng cáo từ các thiết bị BLE cụ thể. Nó cũng phản hồi các gói này để bắt đầu kết
nối từ một thiết bị khác.
 Trạng thái kết nối (Connection): Trạng thái này có thể đạt được từ trạng thái
Initiating hoặc trạng thái Advertiser. Trong trạng thái kết nối này, thiết bị BLE có thể là
Master hoặc Slave. Khi nó vào từ trạng thái Initiating, nó sẽ ở vai trò Master. Khi nó vào từ
trạng thái Advertising, nó sẽ ở vai trò Slave. Trong vai trò Master, lớp liên kết sẽ giao tiếp
với thiết bị trong vai trò Slave và xác định thời gian truyền.
  Trạng thái đồng bộ hóa (Synchronization): Trạng thái này có thể được nhập từ trạng
thái Standby. Lớp liên kết ở trạng thái này lắng nghe các gói kênh định kỳ từ thiết bị được
chỉ định truyền quảng cáo định kỳ.

HCI
Cung cấp giao tiếp giữa Controller và Host thông qua các kiểu giao diện tiêu chuẩn. Lớp HCI này
có thể được triển khai bằng cách sử dụng API hoặc bằng các giao diện như UART/SPI/USB.  Các
lệnh và sự kiện HCI tiêu chuẩn được xác định trong thông số kỹ thuật bluetooth.

L2CAP
Lớp này cung cấp các dịch vụ đóng gói dữ liệu cho các lớp trên. Điều này cho phép giao tiếp dữ
liệu từ đầu đến cuối hợp lý.

SMP
Lớp quản lý bảo mật này cung cấp các phương pháp ghép nối thiết bị và phân phối khóa.  Nó
cung cấp các dịch vụ cho các lớp ngăn xếp giao thức khác để kết nối và trao đổi dữ liệu giữa các
thiết bị BLE một cách an toàn.

GAP
Lớp này giao diện trực tiếp với lớp ứng dụng và/hoặc các cấu hình trên đó. Nó xử lý các dịch vụ
liên quan đến khám phá thiết bị và kết nối cho thiết bị BLE. Nó cũng quan tâm đến việc khởi tạo
các tính năng bảo mật.

GATT
Lớp này là khung dịch vụ chỉ định các thủ tục con để sử dụng ATT. Truyền dữ liệu giữa hai thiết bị
BLE được xử lý thông qua các thủ tục phụ này. Các ứng dụng và/hoặc cấu hình sẽ sử dụng GATT
trực tiếp.

ATT
Lớp này cho phép thiết bị BLE hiển thị các phần dữ liệu hoặc thuộc tính nhất định.

Application Layer
 Các lớp ngăn xếp giao thức BLE tương tác với các ứng dụng và cấu hình như mong
muốn. Khả năng tương tác của ứng dụng trong hệ thống Bluetooth được thực hiện bằng
cấu hình Bluetooth.
 Cấu hình xác định các tương tác dọc giữa các lớp cũng như các tương tác ngang
hàng của các lớp cụ thể giữa các thiết bị.
 Một hồ sơ bao gồm một hoặc nhiều dịch vụ để giải quyết trường hợp sử dụng cụ
thể. Một dịch vụ bao gồm các đặc điểm hoặc tham chiếu đến các dịch vụ khác.
 Mọi cấu hình/ứng dụng chạy trên các lớp GAP/GATT của ngăn xếp giao thức BLE. Nó
xử lý các dịch vụ liên quan đến phát hiện thiết bị và kết nối cho thiết bị BLE.

Thủ tục thiết lập kết nối BLE

Giai đoạn khám phá: Ban đầu quá trình khám phá diễn ra. Kết quả là các thiết bị nhận biết
được sự hiện diện của nhau. Sau khi quá trình kết nối BLE này bắt đầu.
Giai đoạn kết nối: Sau đó, máy quét chọn nhà quảng cáo ưa thích dựa trên dữ liệu quảng cáo
bao gồm tên thiết bị, UUID dịch vụ, RSSI, v.v. Bây giờ thiết bị được gọi là “Initiator” phản hồi gói
quảng cáo bằng gói “CONNECT_REQ”.
 Gói “CONNECT_REQ” này như được định nghĩa trong v4.2 mang các tham số hữu ích
cho kết nối, bao gồm trình tự nhảy tần, khoảng thời gian kết nối, độ trễ Slave, thời gian
chờ giám sát, v.v. Khoảng thời gian kết nối đề cập đến thời gian giữa hai sự kiện liên
tiếp. Sau khi gói CONNECT_REQ được truyền bởi trình khởi tạo hoặc được nhà quảng cáo
nhận, các thiết bị BLE được cho là đã được kết nối.
 Như được định nghĩa trong V5.1, CONNECT_IND và AUX_CONNECT_REQ PDU được
gửi bởi Lớp liên kết ở trạng thái Khởi tạo và được Lớp liên kết nhận ở trạng thái Quảng
cáo. AUX_CONNECT_RSP PDU được gửi bởi Lớp liên kết ở trạng thái Quảng cáo và được
Lớp liên kết nhận ở trạng thái Khởi tạo.
Giai đoạn kết nối: Khi kết nối được thiết lập giữa “Master” và “Slave”, chúng có thể bắt đầu trao
đổi dữ liệu bằng cách sử dụng các gói dữ liệu theo khoảng thời gian đều đặn được gọi là “sự kiện
kết nối”. Thời gian của các sự kiện kết nối được xác định bởi hai tham số: khoảng thời gian kết
nối (connInterval) và độ trễ Slave (connSlaveLatency).

Định dạng gói quảng cáo & gói dữ liệu BLE

Định dạng gói BLE v4.2

Preamble: Được sử dụng bởi máy thu để đồng bộ hóa (thời gian, tần số) và để thực hiện AGC
(Điều khiển độ lợi tự động). Nó là mẫu được xác định trước có kích thước 1 byte mà máy thu
biết: gói quảng cáo sử dụng “0b10101010”, gói dữ liệu sử dụng “0b10101010” (nếu LSB của
Access Address là 0) hoặc “0b01010101” (nếu LSB của Access Address là 1).
Access Address: Đối với tất cả các gói quảng cáo được sử dụng mẫu cố định “0x8E89BED6”. Đối
với gói dữ liệu, nó bao gồm giá trị ngẫu nhiên 32 bit do thiết bị BLE tạo ra ở “trạng thái khởi
tạo”. Giá trị tương tự được sử dụng trong thông báo “yêu cầu kết nối (CONNECT_REQ)”.
PDU : Nó bao gồm “PDU kênh quảng cáo” hoặc “PDU kênh dữ liệu”.
CRC: Có kích thước 24 bit, được sử dụng để phát hiện lỗi của gói tin. CRC được tính bằng cách sử
dụng đa thức có dạng x24 + x10 + x9 + x6 + x4 + x3 + x + 1.
GÓI QUẢNG CÁO BLE
Các PDU của kênh quảng cáo phục vụ các chức năng sau.
Truyền dữ liệu.
Giúp phát hiện ra Slave để kết nối với họ.
Có nhiều loại PDU quảng cáo khác nhau với các định dạng và chức năng tải trọng khác nhau.
PDU quảng cáo (ADV_IND, ADV_DIRECT_IND, ADV_NONCONN_IND, ADV_SCAN_IND)
Quét PDU (SCAN_REQ, SCAN_RSP)
Khởi tạo PDU (CONNECT_REQ)

GÓI DỮ LIỆU BLE

Truyền và nhận dữ liệu giữa các thiết bị BLE sau khi thiết lập kết nối giữa chúng.
Các PDU kênh dữ liệu được trao đổi trong các “sự kiện kết nối” theo lịch trình.
Tải trọng dữ liệu tối đa là 246 byte sau khi trừ tiêu đề, MIC và các thông tin hữu ích khác do PDU
kênh dữ liệu mang theo.

Định dạng gói BLE v5.1

GÓI QUẢNG CÁO BLE

GÓI DỮ LIỆU BLE

Định dạng gói quảng cáo
Hãy xác định từng trường trong PDU:
Tiêu đề PDU
Loại PDU: trường này có độ dài 4 bit và có các giá trị có thể có sau:

Nguồ
n: Tài liệu đặc điểm kỹ thuật cốt lõi của Bluetooth
Các PDU được chia thành nhiều loại tùy thuộc vào mục đích.
Trước khi chúng tôi liệt kê từng PDU, chúng ta hãy đề cập đến một số thuật ngữ phổ biến:
 Trực tiếp so với Không hướng: Các loại quảng cáo được hướng dẫn chấp nhận các yêu
cầu kết nối từ một thiết bị ngang hàng đã biết, trong khi Không hướng chấp nhận các yêu cầu kết
nối từ bất kỳ thiết bị ngang hàng nào.
 Có thể kết nối so với Không thể kết nối: xác định xem thiết bị quảng cáo có cho phép
thiết lập kết nối hay không.
 Có thể quét và Không quét được: xác định xem thiết bị quảng cáo có khả năng xử lý
thông báo Yêu cầu quét từ người quan sát hoặc trung tâm hay không. Yêu cầu và phản hồi quét
được sử dụng để cho phép các thiết bị quảng cáo nhiều dữ liệu hơn mức có thể vừa với một gói
quảng cáo.
 Quảng cáo mở rộng: Quảng cáo mở rộng là một cách để quảng cáo nhiều dữ liệu (giảm
tải) hơn những gì được phép với Quảng cáo cũ. Việc giảm tải được thực hiện bằng cách quảng
cáo đầu tiên trên kênh chính trỏ đến một gói phụ trợ trên kênh phụ.
Lưu ý:  Vì  các thiết bị không phải Bluetooth 5 sẽ không thể phát hiện ra các quảng cáo mở rộng,
nên các nhà quảng cáo cũng nên sử dụng bộ quảng cáo với các PDU quảng cáo cũ cho các thiết
bị quét cũ hơn để có thể phát hiện ra thiết bị cuối. Bộ quảng cáo được sử dụng để gửi đồng thời
các loại sự kiện quảng cáo khác nhau. Mỗi bộ quảng cáo sẽ có các thông số quảng cáo khác
nhau như loại PDU quảng cáo, khoảng thời gian quảng cáo, PHY.
 Quảng cáo định kỳ: Một tính năng khác của Quảng cáo mở rộng Bluetooth 5 là Quảng
cáo định kỳ. Chúng được sử dụng để phát các gói đến các thiết bị trong một khoảng thời gian
nhất định giữa hai thiết bị không được kết nối, có nghĩa là nhiều thiết bị có thể nghe và điều
chỉnh các quảng cáo định kỳ này. Chúng bao gồm các quảng cáo được gửi vào một khoảng thời
gian cố định với dữ liệu quảng cáo thay đổi theo thời gian.
PDU quảng cáo cũ
Chúng có sẵn cho tất cả các phiên bản Bluetooth - cũng cho phép tương thích ngược với các
phiên bản cũ hơn và được sử dụng trên các kênh quảng cáo Chính.
 ADV_IND: Quảng cáo vô hướng có thể quét có thể kết nối.
 ADV_DIRECT_IND: Quảng cáo được hướng dẫn có thể kết nối
 ADV_NONCONN_IND: Quảng cáo không định hướng không thể quét không thể quét được
 ADV_SCAN_IND: Quảng cáo vô hướng có thể quét được
PDU quảng cáo mở rộng
Các loại này đã được giới thiệu trong phiên bản Bluetooth 5.0. Họ cung cấp cho các thiết bị tùy
chọn để quảng cáo trên các kênh Quảng cáo phụ ngoài các kênh quảng cáo Chính. Lợi ích của
các kênh Phụ là chúng cho phép tăng dung lượng dữ liệu quảng cáo.
 ADV_EXT_IND: Quảng cáo mở rộng (được sử dụng cho tất cả các loại quảng cáo ngoại trừ
Kết nối có thể quét được Không hướng dẫn) - được gửi trên các kênh quảng cáo Chính.
 AUX_ADV_IND: Quảng cáo mở rộng (được sử dụng cho tất cả các loại quảng cáo ngoại trừ
Kết nối có thể quét được Không hướng dẫn) - được gửi trên các kênh quảng cáo phụ.
 AUX_SCAN_IND: được sử dụng cho quảng cáo định kỳ
 AUX_CHAIN_IND: được sử dụng với các loại quảng cáo khác để chứa dữ liệu quảng cáo bổ
sung (chuỗi các gói quảng cáo)
Quét các PDU
Chúng được sử dụng để sử dụng chức năng Yêu cầu quét → Phản hồi quét, cho phép các thiết
bị phát nhiều dữ liệu quảng cáo hơn mức được phép trong một gói quảng cáo.
 SCAN_REQ: được sử dụng trong các gói Yêu cầu quét được gửi trên các kênh quảng
cáo Chính
 SCAN_RSP: được sử dụng trong các gói Phản hồi quét được gửi trên các kênh quảng
cáo Chính
 AUX_SCAN_REQ: được sử dụng trong các gói Yêu cầu quét được gửi trên các kênh Quảng
cáo phụ
 AUX_SCAN_RSP: được sử dụng trong các gói Phản hồi quét được gửi trên các kênh Quảng
cáo phụ
Khởi tạo PDU
Chúng được sử dụng để thiết lập kết nối giữa thiết bị ngoại vi và thiết bị trung tâm.
 CONNECT_IND: đây là gói yêu cầu kết nối được gửi trên một trong các kênh quảng
cáo Chính
 AUX_CONNECT_REQ: đây là gói yêu cầu kết nối được gửi trên một trong các kênh Quảng
cáo phụ
 AUX_CONNECT_RSP: đây là gói phản hồi kết nối được gửi bởi thiết bị ngoại vi trên một
trong các kênh Quảng cáo phụ
RFU: Được dự trữ để sử dụng trong tương lai
ChSel: bit này sẽ được đặt thành 1 nếu nhà quảng cáo hỗ trợ tính năng Thuật toán lựa chọn
kênh LE số 2 (tham khảo Đặc điểm kỹ thuật cốt lõi của Bluetooth Tập 6, Phần B, Phần 4.5.8.3).
TxAdd: bit này được đặt thành 1 nếu địa chỉ của nhà quảng cáo là ngẫu nhiên và đặt
thành 0 nếu địa chỉ công khai
RxAdd: bit này được đặt thành 1 nếu địa chỉ của thiết bị đích là ngẫu nhiên và đặt thành 0 nếu
địa chỉ là công khai
Chiều dài: chứa Chiều dài tải trọng của gói tin.
Tải trọng PDU
Nội dung của tải trọng của gói quảng cáo và kích thước tối đa của nó phụ thuộc vào loại PDU
được sử dụng. Dữ liệu quảng cáo bao gồm thông tin mà nhà quảng cáo muốn chuyển tiếp đến
thiết bị quan sát/trung tâm.
Ở đây, chúng tôi Master yếu quan tâm đến các loại PDU có chứa dữ liệu quảng cáo.  Các PDU đó
là:
 PDU Legacy quảng cáo bao gồm: ADV_IND, ADV_NONCONN_IND,ADV_SCAN_IND
 PDU quảng cáo mở rộng bao
gồm: ADV_EXT_IND, AUX_ADV_IND, AUX_SYNC_IND,AUX_CHAIN_IND
Dữ liệu Quảng cáo
Có một số loại dữ liệu tiêu chuẩn có thể được đưa vào dữ liệu quảng cáo.  Dữ liệu được định
dạng như sau:
Các loại dữ liệu quảng cáo BLE khác nhau là:
 UUID dịch vụ: được sử dụng để bao gồm danh sách các UUID dịch vụ
 Tên địa phương: tên thiết bị ( Rút gọn hoặc Hoàn thành )
 Cờ: cờ một bit được bao gồm khi một gói quảng cáo có thể kết nối được. Các cờ là: Chế độ
có thể khám phá giới hạn LE, Chế độ có thể khám phá chung LE, BR/EDR không được hỗ trợ, LE
và BR/EDR đồng thời cho cùng một thiết bị có thể sử dụng (Bộ điều khiển), LE và BR/EDR đồng
thời cho cùng một thiết bị có thể sử dụng (Máy Master).
 Dữ liệu cụ thể của nhà sản xuất: được sử dụng để bao gồm dữ liệu tùy chỉnh được xác
định bởi mã định danh công ty.
 Mức công suất TX: mức công suất truyền
 Khoảng thời gian kết nối nô lệ: một cách để giao tiếp phạm vi khoảng thời gian kết nối
ưa thích của Thiết bị ngoại vi trong các gói quảng cáo.
 Gợi ý dịch vụ: được sử dụng để “mời” các trung tâm cho phép một hoặc nhiều Dịch vụ
được chỉ định kết nối.
 Dữ liệu dịch vụ: bao gồm một UUID dịch vụ và dữ liệu được liên kết với dịch vụ.
 Hình thức: xác định “loại” của thiết bị quảng cáo theo các số Giao diện tiêu chuẩn được
chỉ định.
 Địa chỉ Mục tiêu Công cộng: xác định địa chỉ của một hoặc nhiều người nhận quảng cáo
dự định khi một hoặc nhiều thiết bị được liên kết bằng địa chỉ công cộng.
 Địa chỉ Mục tiêu Ngẫu nhiên: xác định địa chỉ của một hoặc nhiều người nhận quảng cáo
dự định khi một hoặc nhiều thiết bị được liên kết bằng địa chỉ ngẫu nhiên.
 Khoảng thời gian quảng cáo: tự giải thích.
 Mã định danh tài nguyên đồng nhất: được sử dụng để phát một URI chẳng hạn như
URL.
 Các tính năng được hỗ trợ của LE: xác định các tính năng dành riêng cho LE được thiết
bị hỗ trợ. Chúng được định nghĩa trong Đặc điểm kỹ thuật cốt lõi (Quyển 6, Phần B, Phần 4.6).
Ok, đó là nó cho bài viết của tuần này. Chúng tôi sẽ đề cập nhiều hơn trong Phần 2 của loạt bài
này bao gồm:
 Ví dụ về các gói quảng cáo
 Cách sử dụng gói quảng cáo hiệu quả
 Gói quảng cáo mở rộng
 Thông số quảng cáo
 và nhiều hơn nữa…

Quảng cáo Bluetooth rất quan trọng đối với bất kỳ thiết bị BLE nào vì chúng được sử dụng cho
tất cả các loại ứng dụng, cho dù đó là thiết bị cho phép kết nối hay thiết bị chỉ quảng cáo sự hiện
diện của nó và bao gồm dữ liệu để người khác khám phá.
Để sử dụng các gói quảng cáo một cách hiệu quả, chúng ta cần hiểu cách chúng được sử dụng,
các khả năng khác nhau mà chúng cung cấp, định dạng của các gói và lượng dữ liệu mà chúng có
thể chứa.
Mục tiêu quan trọng nhất của gói quảng cáo là truyền tải thông tin đến các thiết bị BLE khác
thông qua: kiểu gói quảng cáo và kiểu dữ liệu quảng cáo có trong gói.
Cách tốt nhất để hiểu rõ hơn về khái niệm này là xem qua một vài ví dụ về các gói quảng cáo, vì
vậy hãy làm điều đó tiếp theo.
Thiết bị phát sóng
Nếu bạn đang tìm cách thiết kế một thiết bị với vai trò chính là quảng cáo sự hiện diện của nó và
có thể phát một số dữ liệu để các thiết bị BLE khác (thiết bị quan sát, trung tâm) khám phá, thì
bạn có thể triển khai vai trò Truyền phát.
Một ví dụ sẽ là thiết bị beacon.
Quay trở lại với các loại gói quảng cáo khác nhau, đây là những loại mà chúng ta có thể sử dụng
để thực hiện vai trò này:
 Quảng cáo kế thừa (được hỗ trợ bởi tất cả các phiên bản Bluetooth):
o ADV_NONCONN_IND: Quảng cáo không định hướng không thể quét không thể quét
được.
 Quảng cáo mở rộng (yêu cầu Bluetooth phiên bản 5.0 trở lên):
o ADV_EXT_IND: Quảng cáo mở rộng (được sử dụng cho tất cả các loại quảng cáo
ngoại trừ Kết nối có thể quét được Không hướng dẫn) - được gửi trên các   kênh quảng
cáo Chính.
o AUX_ADV_IND: Quảng cáo mở rộng (được sử dụng cho tất cả các loại quảng cáo
ngoại trừ Kết nối có thể quét được Không hướng dẫn) - được gửi trên các   kênh quảng cáo phụ.
Hãy xem lại định dạng gói của gói quảng cáo:
Nguồn: Tài liệu đặc điểm kỹ thuật cốt lõi của Bluetooth
Định dạng tải trọng PDU:

Nguồn: Tài liệu đặc điểm kỹ thuật cốt lõi của Bluetooth
Tùy thuộc vào nền tảng và ngăn xếp Bluetooth được sử dụng trên thiết bị của bạn, các API sẽ
khác nhau, nhưng nói chung, bạn sẽ cần xác định những điều sau:
Nội dung PDU
 Tiêu đề
PDU Loại PDU:ADV_NONCONN_IND ( 0b100)
Chiều dài: kích thước của dữ liệu quảng cáo
 PDU Payload
Flags AD: chúng là tùy chọn trong trường hợp gói quảng cáo không thể kết nối, vì vậy bạn có thể bỏ
qua trường này.
Dữ liệu cụ thể của nhà sản xuất: <Thêm dữ liệu tùy chỉnh của riêng bạn mà bạn muốn thiết bị
phát> (ví dụ: dữ liệu cảm biến)
Tên thiết bị: tùy thuộc vào lượng dữ liệu được sử dụng hết bởi các trường trước đó, bạn có thể
đưa chuỗi tên thiết bị vào tải trọng gói quảng cáo.
Một tùy chọn khác là đưa tên thiết bị vào gói Phản hồi quét.
Trong trường hợp Gói quảng cáo cũ, Tải trọng có kích thước tối đa là 31 byte (với ít nhất 2 byte
được sử dụng hết bởi các trường Độ dài và Loại trong trường hợp bao gồm một loại dữ liệu
quảng cáo, để lại tối đa 29 byte cho khối hàng).
Ngoài ra, hãy nhớ rằng trường Dữ liệu cụ thể của nhà sản xuất sẽ bao gồm 2 byte chứa Mã nhận
dạng công ty, theo sau là dữ liệu người dùng. Mã định danh công ty có thể được lấy miễn phí từ
Bluetooth SIG (miễn là công ty là công ty thành viên của Bluetooth SIG). Tìm hiểu thêm tại
đây: https: //www.bl Bluetooth.com/specification/assigned-numbers/company-identifiers/
Nếu bạn chọn triển khai Phản hồi quét, bạn có thể bao gồm gói quảng cáo thứ hai để gửi dữ liệu
quảng cáo bổ sung không phù hợp với gói quảng cáo chính.
Điều này phụ thuộc vào việc Người quan sát/Trung tâm gửi gói Yêu cầu quét đến thiết bị quảng
cáo, nhà quảng cáo sẽ phản hồi bằng gói Phản hồi quét. Định dạng của gói Phản hồi quét hoàn
toàn giống với gói Quảng cáo.
Hãy xem ví dụ về một thiết bị chỉ quảng cáo Tên địa phương đầy đủ của nó.
Tải trọng PDU sẽ trông giống như sau:
Giá trị Ghi chú

0x0B Độ dài của dữ liệu

0x09 << Tên địa phương đầy đủ >>

0x4e ‘N’

0x6f ‘o’

0x76 ‘v’

0x65 ‘e’

0x6c ‘l’

0x20 ‘‘

0x42 ‘B’
 0x69 ‘tôi’

0x74 ‘t’

0x73 ‘S’
Dữ liệu tải trọng PDU quảng cáo
Để tìm hiểu thêm về các loại dữ liệu quảng cáo khác nhau, hãy tham khảo tài liệu Bổ sung cho
Đặc điểm kỹ thuật cốt lõi của Bluetooth: https: //www.bl Bluetooth.com/specilities/bl
Bluetooth-core-specification /
Các thiết bị có thể kết nối
Nếu bạn đang muốn thiết kế một thiết bị Master yếu cho phép kết nối từ một thiết bị BLE khác
và hoạt động Master yếu ở chế độ kết nối, thì một số điều cần lưu ý:
 Bạn được yêu cầu bao gồm trường QUẢNG CÁO Cờ. Trong trường hợp này, bạn muốn bật
bit << BR/EDR Không được hỗ trợ >>.
 Đối với Quảng cáo Kế thừa, hãy sử dụng ADV_INDloại quảng cáo.
 Đối với Quảng cáo mở rộng (chẳng hạn như trong trường hợp quảng cáo PHY được mã
hóa yêu cầu sử dụng Quảng cáo mở rộng), hãy sử dụng ADV_EXT_INDloại quảng cáo trên các
kênh quảng cáo chính và AUX_ADV_INDtrên các kênh quảng cáo phụ.
Lưu ý: Một số SDK thường sẽ tóm tắt thông tin này cho nhà phát triển và chúng sẽ cung cấp một
thông số API duy nhất để định cấu hình các loại quảng cáo thích hợp cho cả kênh chính và kênh
phụ. Tuy nhiên, bạn có thể vẫn cần xác định PHY được sử dụng cho từng loại kênh.
Một điều quan trọng cần ghi nhớ là Quảng cáo mở rộng không được hỗ trợ bởi tất cả các máy
quét. Vì vậy, nếu bạn đang tìm cách triển khai một thiết bị có thể kết nối có thể được kết nối với
các thiết bị cũ cũng như các thiết bị hỗ trợ quét các quảng cáo mở rộng, thì bạn có thể sử dụng
cái gọi là Bộ quảng cáo (cho phép một thiết bị gửi hai hoặc nhiều loại quảng cáo) và xác định
một bộ cho các quảng cáo kế thừa và một bộ khác cho các quảng cáo mở rộng.

Bluetooth mesh
Bluetooth mesh được phát hành vào 7/2017 với mục tiêu Tăng phạm vi mạng Bluetooth và Hỗ
trợ thêm cho nhiều ứng dụng công nghiệp.

Cấu trúc liên kết

Hình 1: Các loại cấu trúc liên kết trong Bluetooth

Các phiên bản trước của Bluetooth hỗ trợ 2 cấu trúc liên kết:
 One-To-One: khi 2 thiết bị BLE được kết nối.
 One-To-Many: khi thiết bị BLE hoạt động ở trạng thái Broadcast, chẳng hạn như Beacon.

Với Bluetooth mesh, các thiết bị hoạt động trong cấu trúc liên kết Many-To-Many (hay còn gọi
là Mesh), nơi các thiết bị có thể thiết lập kết nối với nhiều thiết bị khác trong mạng.

Lợi ích của mạng Mesh:

 Mở rộng phạm vi: Vì các node có thể chuyển tiếp bản tin đến các node ở xa thông qua các
node ở giữa chúng, điều này cho phép mở rộng phạm vi mạng và mở rộng phạm vi tiếp
cận của các thiết bị.
 Khả năng tự phục hồi: Nếu một node rớt khỏi mạng Mesh, các node khác vẫn có thể gửi
bản tin cho nhau. Tuy nhiên, điều này chỉ đúng một phần vì một số node có thể phụ thuộc
vào nhau.
Các khái niệm về Bluetooth mesh

Node (nút)

Một node là một thiết bị đã tham gia một mạng Bluetooth mesh. Các thiết bị không phải là
một phần của mạng được gọi là thiết bị chưa được cấp phép (Unprovisioned Device). Khi một
thiết bị chưa được cấp phép được cấp phép, thiết bị đó sẽ tham gia mạng và trở thành một node.

Hình 2: Các node và thiết bị chưa được cấp phép

Element (phần tử)

Một node có thể chứa nhiều phần tử có thể được kiểm soát độc lập. Ví dụ, một thiết bị
chiếu sáng có thể chứa nhiều bóng đèn có thể bật/tắt độc lập.

Hình 3: Các element trong một node

State (trạng thái)

Trong node có thể có nhiều phần tử khác nhau và mỗi phần tử mang một trạng thái.  Ví
dụ: bật và tắt là trạng thái của bóng đèn. Sự thay đổi từ trạng thái này sang trạng thái khác được
gọi là chuyển trạng thái. Điều này có thể xảy ra tức thời hoặc có thể xảy ra theo thời gian.
Một số trạng thái có thể bị ràng buộc với nhau, có nghĩa là sự thay đổi ở một trạng thái sẽ
kích hoạt sự thay đổi ở trạng thái khác.

Property (thuộc tính)

Thuộc tính được thêm vào trong một số tình huống cho giá trị trạng thái. Ví dụ, xác định
rằng một giá trị nhiệt độ là ngoài trời hay trong nhà.

Có 2 loại thuộc tính:

 Thuộc tính nhà sản xuất: chỉ đọc
 Thuộc tính quản trị: đọc – ghi

Message (bản tin hay thông điệp)

Tất cả các giao tiếp trong mạng Bluetooth mesh đều theo hướng bản tin và các node gửi
bản tin để điều khiển hoặc chuyển tiếp bản tin cho nhau.

Có 3 loại bản tin:

 GET Message: yêu cầu trạng thái từ một hoặc nhiều node
 SET Message: thay đổi giá trị của một trạng thái nhất định
 STATUS Message: được sử dụng trong các trường hợp sau:
o Đáp lại GET Message, chứa giá trị State
o Đáp lại SET Message, xác nhận (ACK)
o Được gửi độc lập với bất kỳ Message nào để báo cáo trạng thái của phần tử

Một số bản tin yêu cầu người nhận gửi xác nhận. Một bản tin xác nhận phục vụ 2 mục đích:
 Xác nhận đã nhận được bản tin
 Trả về dữ liệu liên quan đến bản tin đã nhận

Trong trường hợp thiết bị gửi không nhận được phản hồi cho bản tin hoặc nhận được phản hồi
không mong muốn, nó có thể gửi lại bản tin. Nhiều bản tin xác nhận nhận được bởi một node
không ảnh hưởng đến quá trình hoạt động của node đó.

Address (địa chỉ)

 Hình 4: Mã hóa địa chỉ

Bản tin trong mạng Bluetooth mesh phải được gửi đến và đi từ một địa chỉ. Có 4 loại địa
chỉ:
 Unassigned Address (Địa chỉ chưa được gán): các phần tử chưa được định cấu hình,
hoặc không có địa chỉ được chỉ định hoặc có địa chỉ nhưng chưa được chỉ định. Những
phần tử này có thể không được sử dụng trong bản tin.
 Unicast Address (Địa chỉ độc nhất): trong quá trình cấp phép, Provisioner phân bổ một
địa chỉ unicast cho mỗi phần tử trong một nút trong suốt thời gian tồn tại của nút đó trên
mạng. Địa chỉ unicast có thể xuất hiện trong trường địa chỉ nguồn và/hoặc trường địa chỉ
đích của bản tin. Bản tin được gửi đến địa chỉ unicast chỉ được xử lý bởi một phần tử.
 Virtual Address (Địa chỉ ảo): một địa chỉ có thể được gán cho một hoặc nhiều phần tử,
trải dài một hoặc nhiều node. Điều này hoạt động như một nhãn và có dạng UUID 128 bit
mà bất kỳ phần tử nào cũng có thể được liên kết. Địa chỉ ảo có thể được định cấu hình
trước tại thời điểm sản xuất.
 Group Address (Địa chỉ nhóm): một địa chỉ được sử dụng để xác định một nhóm các
node. Một địa chỉ nhóm thường phản ánh một nhóm vật lý của các node như tất cả các
node trong một căn phòng đặc biệt. Địa chỉ nhóm có thể:
o Là Địa chỉ nhóm cố định SIG, được xác định bởi Bluetooth SIG. Chúng bao gồm địa
chỉ All-proxies, All-friends, All-relays, and All-nodes.
o Là Địa chỉ nhóm động, được xác định bởi người dùng thông qua một ứng dụng cấu
hình.

Lợi ích của việc sử dụng địa chỉ nhóm hoặc địa chỉ ảo là việc thêm hoặc xóa các node không yêu
cầu cấu hình lại các node.

Publish/Subscribe (xuất bản/đăng ký)

Các bản tin được trao đổi trong mạng Bluetooth mesh thông qua cơ
chế publish/subscribe.
Publishing là hành động gửi một bản tin. Subscribing được sử dụng để đăng ký nhận bản
tin. Thông thường, các bản tin được gửi đến các địa chỉ nhóm hoặc địa chỉ ảo.

VD: Mạng Mesh trong một ngôi nhà bao gồm 6 công tắc đèn và 9 bóng đèn. Mạng sử dụng
phương pháp publish/subscribe để cho phép các node gửi bản tin cho nhau.
 Hình 5: Publish/Subscribe trong hệ thống điều khiển ánh sáng Bluetooth mesh

Các node có thể đăng ký một lúc nhiều địa chỉ. Ví dụ node light 3 trong hình trên, được đăng ký
cho cả địa chỉ nhóm nhà bếp và phòng ăn. Ngoài ra, nhiều node có thể xuất bản đến cùng một
địa chỉ, chẳng hạn như node switch 5 và 6 điều khiển cùng một nhóm đèn đặt trong vườn.

Managed Flooding (quản lý lũ lụt)

Nhiều mạng Mesh sử dụng cơ chế định tuyến để chuyển tiếp các bản tin trên toàn mạng. Một
thái cực khác là các bản tin được chuyển tiếp mà không xem xét các tuyến đường tối ưu.
Bluetooth mesh là sự dung hòa của cả 2 kỹ thuật này. Kỹ thuật này được gọi là Managed
Flooding.

Hình 6: Hai kỹ thuật truyền tin

Managed Flooding dựa vào việc phát thông báo cho tất cả các node trong phạm vi của node
gửi, với một số tối ưu hóa được thêm vào bản tin:
 TTL (Time-To-Live): giới hạn số lần chuyển tiếp mà một bản tin có thể thực hiện trên
nhiều node trong mạng Mesh. Ví dụ: Nếu TTL = 0 có nghĩa là một node có thể gửi bản tin
đến các nodes khác trong phạm vi phủ sóng của nó và chỉ ra rằng các nodes không có khả
năng chuyển tiếp bản tin. Nếu một bản tin được gửi với TTL = 2, thì mỗi lần nó được
chuyển tiếp, giá trị TTL sẽ bị giảm. Giá trị TTL là 1 có nghĩa là bản tin có thể được chuyển
tiếp một lần nữa.
 Messages are cached: Bản tin được yêu cầu lưu trữ bởi tất cả các nodes và yêu cầu tất cả
các bản tin tồn tại trong bộ nhớ đệm phải bị xóa ngay lập tức
 Heartbeat messages are sent periodically: Được sử dụng để cho các node khác biết
rằng người gửi còn sống và đang hoạt động trong mạng.
 Friendship: đề cập đến mối quan hệ giữa Low Power Node (LPN) và Friend Node

Model (mô hình)

Một mô hình xác định một số hoặc tất cả các chức năng của một phần tử nhất định. Có 3
loại mô hình:
 Mô hình máy chủ: là tập hợp các trạng thái, các chuyển đổi trạng thái, các ràng buộc
trạng thái và các bản tin mà một phần tử chứa mô hình có thể gửi hoặc nhận.
 Mô hình máy khách: không xác định bất kỳ trạng thái nào; thay vào đó, nó chỉ định nghĩa
các bản tin như GET, SET và STATUS được gửi đến một mô hình máy chủ.
 Mô hình điều khiển: chứa cả mô hình máy chủ và máy khách cho phép giao tiếp với các
mô hình máy chủ và máy khách khác.

Mô hình có thể được mở rộng để bổ sung chức năng thay vì sửa đổi mô hình ban đầu. Một mô
hình không được mở rộng được gọi là mô hình gốc.

Scene (cảnh)

Cảnh là một tập hợp các trạng thái được lưu trữ và được xác định bằng một số 16 bit duy
nhất trong mạng Mesh.

Cảnh cho phép kích hoạt một hành động để thiết lập nhiều trạng thái của các node khác
nhau. Chúng có thể được kích hoạt theo yêu cầu hoặc tại một thời điểm cụ thể. Ví dụ: một cảnh
có thể được định cấu hình để đặt nhiệt độ của phòng ở 25 độ, phòng khách chiếu sáng ở một
mức độ sáng nhất định và đóng rèm cửa sổ.

Types of Nodes (các loại node)

Tất cả các loại node đều có thể gửi và nhận các bản tin mesh. Tuy nhiên, các tính năng tùy
chọn cung cấp cho các node cụ thể những khả năng đặc biệt.
Các loại node:
 Relay nodes
 Proxy nodes
 Friend nodes
 Low power nodes

Một node có thể hỗ trợ một số hoặc tất cả các tính năng tùy chọn này, có thể được bật hoặc tắt
bất kỳ lúc nào. Ví dụ, một node duy nhất có thể có các tính năng của relay node, proxy node,
và friend node cùng một lúc.

Relay Node

Một relay node là một node hỗ trợ tính năng chuyển tiếp. Điều này có nghĩa là nó có thể
truyền lại các bản tin được phát bởi các node khác. Điều này cho phép mở rộng phạm vi tiếp cận
của các bản tin.

Hình 7: Relay node

Proxy node

Proxy node cho phép thiết bị BLE không hỗ trợ mesh giao tiếp với mạng mesh. Một proxy
node hoạt động như một thiết bị trung gian và sử dụng GATT để cho phép các node khác
bên ngoài mạng mesh giao tiếp và tương tác với mạng.

Giao thức proxy được thiết kế để sử dụng với một thiết bị được phép kết nối (sử dụng GATT).
Giao thức này được xây dựng dựa trên GATT và cho phép một thiết bị đọc và ghi các PDU của
giao thức proxy từ các đặc điểm của GATT được tiếp xúc bởi node proxy. Node proxy thực hiện
việc dịch giữa các PDU giao thức proxy và các PDU Mesh.
 Hình 8: Proxy node

Friend node và Low Power Node (LPN)

Một friend node và một low power node có liên quan chặt chẽ với nhau: Để một low power
node tham gia vào mạng Bluetooth mesh, nó cần có mối quan hệ hữu nghị với một node khác,
được gọi là friend node.

Các low power node thường có nguồn cung cấp hạn chế như pin, vì vậy chúng cần tiết kiệm năng
lượng bằng cách tắt bộ phát sóng thường xuyên nhất có thể. Các low power node thường gửi
nhiều hơn nhận.

Cách 2 node này hoạt động cùng nhau:

 Một friend node cho phép LPN ở trạng thái ngủ lâu hơn bằng cách lưu vào bộ nhớ đệm
các bản tin được gửi đến LPN. Sau đó, LPN thức dậy và thăm dò friend node về các bản tin
đã lưu trong bộ nhớ đệm này. Khi nó thăm dò các bản tin, nó cũng sẽ gửi bất kỳ bản tin
nào nó cần để chuyển tiếp đến mạng qua friend node của nó.
 Mối quan hệ giữa một friend node và một LPN được gọi là “Friendship”. Friendship là chìa
khóa để cho phép các node bị ràng buộc về nguồn điện tham gia vào mạng Mesh trong
khi vẫn giữ mức tiêu thụ điện năng của chúng được tối ưu hóa.
 Hình 9: Mạng chứa các Friend node và Low Power Node

Ví dụ: Friend node P có mối quan hệ hữu nghị với các LPN I, J và K. Friend node O có mối quan hệ
hữu nghị với các LPN L và M. Vì vậy, các bản tin gửi đến các nút I, J hoặc K sẽ được lưu trữ và
chuyển tiếp bởi friend node P. Bản tin gửi đến các nút L hoặc M sẽ được lưu trữ và chuyển tiếp
bởi friend node O. Việc chuyển tiếp bởi friend node chỉ xảy ra khi LPN thăm dò ý kiến của Friend
node về các bản tin đang chờ gửi.

Các tham số tình bạn:

 ReceiveDelay là thời gian trôi qua khi LPN gửi yêu cầu đến friend node và LPN bắt đầu
lắng nghe phản hồi. Điều này cho phép friend node có thời gian chuẩn bị phản hồi và gửi
lại.
 ReceiveWindow là thời gian mà LPN dành để lắng nghe phản hồi.

Hình 10: Trình tự thời gian ReceiveDelay và ReceiveWindow

 PollTimeout là thời gian tối đa có thể trôi qua giữa hai yêu cầu liên tiếp được gửi bởi LPN
đến friend node của nó. Nếu friend node không nhận được yêu cầu nào từ một LPN trước
khi bộ đếm thời gian PollTimeout hết hạn, thì tình bạn sẽ bị chấm dứt.
 Hình 11: Trình tự thời gian PollTimeout

Thành lập tình bạn:

Để tình bạn trong Bluetooth mesh được thiết lập, cần thực hiện một số bước:
 LPN xuất bản một bản tin Friend Request (Yêu cầu kết bạn). Bản tin này không được
chuyển tiếp. Các nút không có tính năng Friend sẽ loại bỏ nó. Bản tin Friend Request bao
gồm các thông số ReceiveDelay, ReceiveWindow và PollTimeout được yêu cầu của LPN.
 Mỗi friend node gần đó có thể hỗ trợ các yêu cầu được chỉ định trong thông báo Friend
Request, sau đó chuẩn bị và truyền bản tin Friend Offer (Đề nghị kết bạn) trở lại LPN.
Bản tin này bao gồm các tham số như ReceiveWindow được hỗ trợ, kích thước hàng đợi
bản tin có sẵn, kích thước danh sách đăng ký có sẵn và giá trị RSSI được đo bằng
friend node.
 Khi nhận được bản tin Friend Offer, LPN chọn một friend node phù hợp bằng cách áp
dụng một thuật toán triển khai cụ thể. Thuật toán có khả năng xem xét các điểm khác
nhau. Một số thiết bị có thể đặt ưu tiên cho kích thước ReceiveWindow để giảm mức sử
dụng điện năng nhiều nhất có thể, trong khi một số thiết bị có thể quan tâm hơn đến giá
trị RSSI để đảm bảo chúng có thể duy trì liên kết chất lượng tốt với friend node. Thuật toán
chính xác được sử dụng do nhà phát triển sản phẩm xác định.
 Sau khi chọn một friend node, LPN gửi một bản tin Friend Poll (Thăm dò bạn bè) đến
friend node này.
 Sau khi nhận được một bản tin Friend Poll từ LPN, friend node trả lời với một bản tin
Friend Update (Cập nhật bạn bè), trong đó kết luận các thủ tục thành lập bạn bè và cung
cấp các thông số an ninh. Tại thời điểm này, tình bạn đã được thiết lập.

Bản tin tình bạn

Sau khi thiết lập tình bạn:
 Khi friend node nhận được một bản tin được gửi đến LPN của friend node, friend node sẽ
lưu trữ nó trong Friend Queue. Trong Hình 12, chúng ta có thể thấy rằng thông báo 1 và 2
được lưu trữ trong friend node thay mặt cho LPN.
  Định kỳ, LPN kích hoạt bộ thu phát của nó và gửi một Friend Poll đến friend node, yêu
cầu bất kỳ bản tin nào được lưu trong bộ đệm được lưu trữ cho nó.
 Friend node gửi một bản tin đã lưu trữ trở lại LPN như một phản hồi cho Friend Poll.
 LPN tiếp tục gửi bản tin Friend Poll sau mỗi bản tin nhận được từ friend node cho đến khi
nó nhận được thông báo Friend Update với trường MD (MD=More Data) bằng 0. Điều này
có nghĩa là không còn bản tin nào được lưu vào bộ đệm cho LPN. Tại thời điểm này, LPN
ngừng thăm dò friend node.

Hình 12: Nhắn tin tình bạn

Bảo vệ
Tình bạn không có gì khác biệt và nó sử dụng hai thông tin xác thực bảo mật đặc biệt:
 Managed flooding security material: Có nguồn gốc từ NetKey, nó cũng có thể được sử
dụng bởi các nút khác trong cùng một mạng. Các bản tin được mã hóa bằng tài liệu bảo
mật ngập lụt được quản lý có thể được giải mã bởi bất kỳ nút nào trong cùng một mạng.
 Friend security material: Được lấy từ NetKey và một số số bộ đếm bổ sung được tạo bởi
LPN và friend node. Thư được mã hóa bằng tài liệu bảo mật của bạn bè chỉ có thể được
giải mã bởi Friend và các LPN sở hữu nó.

Các bản tin tình bạn tương ứng được mã hóa bằng Friend security material là:
 Thăm dò ý kiến của bạn bè
 Cập nhật bạn bè
 Danh sách đăng ký bạn bè Thêm/Xóa/Xác nhận
 Các bản tin được lưu trữ mà nút Bạn bè gửi đến LPN

Các bản tin tình bạn tương ứng được mã hóa bằng Managed flooding security material là:
 Bạn bè rõ ràng
 Xác nhận Xóa bạn bè

Các bản tin được gửi từ LPN đến Friend Node được mã hóa bằng Friend security material hoặc
Managed flooding security material tùy thuộc vào cài đặt ứng dụng.

Chấm dứt tình bạn

Tình bạn có thể bị chấm dứt trong một số điều kiện:
 Nếu friend node không nhận được các bản tin Friend Poll, Friend Subscription List Add
hoặc Friend Subscription List Remove trước khi hết thời gian PollTimeout.
 Một LPN gửi bản tin Friend Clear đến friend node của nó.

Mẹo lựa chọn nền tảng

Các nhà phát triển nên xem xét các nguyên tắc sau khi chọn các nền tảng để triển khai Friend
Node và LPN:
 Dung lượng RAM: Dung lượng RAM có sẵn ảnh hưởng trực tiếp đến số lượng LPN mà một
friend node có thể hỗ trợ và số lượng bản tin nó có thể đệm cho các LPN được liên kết.
 LPN: Hiệu suất tiêu thụ điện năng chung của MCU và mô-đun đã chọn là chìa khóa với
LPN. Ngoài ra, thời gian đánh thức/khởi động từ chế độ ngủ sang chế độ chạy ảnh hưởng
đến khả năng phản hồi và độ trễ trên LPN.

Kiến trúc của Bluetooth mesh

Hình 13: Mối quan hệ giữa Bluetooth mesh và Bluetooth LE

Bluetooth mesh được xây dựng dựa trên BLE. Các thiết bị trong mạng Bluetooth mesh không
kết nối với nhau như các thiết bị BLE truyền thống. Thay vào đó, chúng sử dụng trạng thái
advertising và scanning để chuyển tiếp bản tin cho nhau.
 Hình 14: Kiến trúc Bluetooth mesh

Mô tả cho từng lớp trong kiến trúc của Bluetooth mesh (bắt đầu với lớp dưới cùng):
1. Bluetooth Low Energy layer
Bluetooth mesh được xây dựng trên đầu BLE, vì vậy nó yêu cầu một ngăn xếp BLE đầy đủ để
chạy trên thiết bị. Nó sử dụng các trạng thái advertising và scanning để gửi và nhận bản tin giữa
các thiết bị trong mạng Mesh. Nó cũng hỗ trợ trạng thái được kết nối và GATT cho các thiết bị
đặc biệt được gọi là các proxy node.
2. Bearer layer
Bearer layer định nghĩa cách các gói Mesh khác nhau (Protocol Data Units hoặc PDUs) được xử
lý. Có 2 loại thiết bị Bluetooth mesh bearer:
 Advertising bearer: sử dụng trạng thái advertising và scanning của các thiết bị BLE.
 GATT bearer: sử dụng trạng thái kết nối của các thiết bị BLE. Nó cho phép các thiết
bị không hỗ trợ mesh tương tác với mạng mesh thông qua các hoạt động GATT.  Điều này
được thực hiện thông qua một node đặc biệt được gọi là node proxy.
3. Lower transport layer
Lớp này xử lý 2 tác vụ chính:
o Phân đoạn các gói từ lớp trên (upper transport layer)
o Lắp ráp lại các gói từ lớp dưới (bearer layer)
4. Upper transport layer
Lớp này chịu trách nhiệm cho các chức năng sau:
o Mã hóa
o Giải mã
o Xác thực
o Bản tin kiểm soát vận chuyển (heartbeat, friendship, v.v.)
5. Access layer
Lớp này xác định cách ứng dụng sử dụng lớp truyền tải phía trên. Nó xử lý các tác vụ sau:
o Định dạng dữ liệu ứng dụng
 o Mã hóa và giải mã
o Xác minh dữ liệu
6. Foundation Models layer
Lớp này liên quan đến cấu hình mạng và các mô hình quản lý mạng.
7. Models layer
Lớp này giải quyết việc triển khai các mô hình bao gồm các hành vi, bản tin, trạng thái và ràng
buộc trạng thái.

The Provisioning Process (Quá trình cấp phép)

Là quá trình thêm các thiết bị vào mạng Mesh. Thiết bị chưa được cấp phép (Unprovisioned)
được thêm vào mạng được gọi là node, và thiết bị được sử dụng để thêm một node vào mạng
được gọi là Provisioner (thường là tablet, smartphone, hoặc một PC) – hay còn gọi là thiết bị
cấp phép.

Giao thức cấp phép

Thông số kỹ thuật Bluetooth mesh xác định giao thức cấp phép, xác định các PDU được sử dụng
để giao tiếp giữa provisioner và thiết bị mới - unprovisioned trong quá trình cung cấp.

Hình 15: Ngăn xếp giao thức cấp phép cùng với ngăn xếp giao thức Bluetooth mesh

Provisioning Bearer
Một lớp provisioning bearer phép vận chuyển provisioning PDU giữa một Provisioner và một
unprovisioned. Hai provisioning bearer được xác định:
 PB-ADV: Provisioning bearer được sử dụng để cung cấp thiết bị qua các kênh quảng cáo
Bluetooth. Bộ mang PB-ADV được sử dụng để truyền các PDU cấp phép chung. Một thiết
bị hỗ trợ PB-ADV phải thực hiện quét thụ động với chu kỳ nhiệm vụ gần 100% nhất có thể
để tránh bỏ lỡ bất kỳ PDU cung cấp chung nào sắp Slavei.
  PB-GATT: Provisioning bearer được sử dụng để cung cấp thiết bị sử dụng các PDU proxy
lưới Bluetooth từ giao thức proxy. Giao thức proxy cho phép các nút gửi và nhận các PDU
mạng, đèn hiệu lưới, thông báo cấu hình proxy và cung cấp các PDU qua bộ mang
Bluetooth Low Energy (LE) theo định hướng kết nối. PB-GATT đóng gói các PDU cung cấp
trong các hoạt động của GATT, liên quan đến dịch vụ cung cấp GATT và nó được cung cấp
để sử dụng khi provisioner không hỗ trợ PB-ADV.
Provisioning Protocol
Xác định các yêu cầu đối với việc cung cấp PDU, hành vi và bảo mật. Hiểu được giao thức cung
cấp sẽ giúp bạn chọn một cách tiếp cận để xác thực dựa trên các yêu cầu của ứng dụng.

Quá trình cấp phép bao gồm 5 bước:

Bước 1: Beaconing
Thiết bị chưa được cấp phép gửi các mesh beacon advertisement trong các advertisement
packet.

Bước 2: Invitation (Lời mời)

Khi provisioner phát hiện ra unprovisioned thông qua các Beacon đã được gửi, nó sẽ gửi lời
mời đến unprovisioned này trong provisioning invite PDU. Sau đó, unprovisioned sẽ phản hồi
với thông tin về khả năng của nó trong provisioning capabilities PDU, bao gồm:
 Số element mà thiết bị hỗ trợ.
 Tập hợp các thuật toán bảo mật được hỗ trợ.
 Tính khả dụng của khóa công khai sử dụng công nghệ Out-of-Band (OOB).
 Khả năng xuất giá trị cho người dùng.
 Khả năng cho phép người dùng nhập giá trị.

Hình 16: Bước mời cấp phép

Bước 3: Public Key Exchange (Trao đổi khóa công khai)

Bảo mật trong Bluetooth mesh sử dụng kết hợp các khóa đối xứng và bất đối xứng như thuật
toán Elliptic-curve Diffie-Hellman (ECDH). Trong ECDH, khóa công khai được trao đổi giữa
provisioner và thiết bị được cấp phép. Điều này được thực hiện trực tiếp qua BLE hoặc qua
kênh Out-Of-Band (OOB).
 Hình 17: Bước trao đổi khóa công khai

Bước 4: Authentication (Xác thực)

Điều này thường yêu cầu người dùng thực hiện bằng cách tương tác với cả provisioner và
unprovisioned. Phương pháp xác thực phụ thuộc vào khả năng của cả 2 thiết bị được sử dụng.
Bất kể phương pháp xác thực được sử dụng là gì, xác thực cũng bao gồm bước tạo giá trị xác
nhận và bước kiểm tra xác nhận.
Ví dụ:
 OOB đầu ra, thiết bị chưa được cấp phép có thể xuất ra một số ngẫu nhiên có một hoặc
nhiều chữ số. Sau đó, số đó được nhập vào provisioner thông qua một số phương thức
nhập.
 OOB đầu vào, trong đó số được tạo bởi provisioner và được nhập vào thiết bị chưa được
cấp phép, OOB tĩnh hoặc không có OOB nào cả.

Hình 18: Bước xác thực

Bước 5: Phân phối dữ liệu cung cấp

Sau khi xác thực hoàn tất, mỗi thiết bị lấy một khóa phiên (session key) bằng khóa riêng của
chúng và khóa công khai được gửi đến nó từ thiết bị khác. Sau đó, khóa phiên được sử dụng để
bảo mật kết nối để trao đổi dữ liệu cấp phép bổ sung, bao gồm khóa mạng, khóa thiết bị, tham
số bảo mật được gọi là IV Index và địa chỉ unicast được gán cho thiết bị được cung cấp bởi
provisioner. Sau bước này, unprovisioned sẽ được gọi là một node.

Bảo mật trong Bluetooth mesh

Các nguyên tắc bảo mật cơ bản sau áp dụng cho Bluetooth mesh:
 Tất cả các bản tin Bluetooth mesh đều được mã hóa
Mã hóa và xác thực
và xác thực.

Bảo mật mạng, bảo mật ứng dụng và bảo mật thiết bị
Tách các mối quan tâm
được giải quyết một cách độc lập.

Mạng Bluetooth mesh có thể được chia thành các

Khu vực cô lập mạng con, mỗi mạng khác biệt về mặt mật mã và an
toàn với các mạng khác.
Khóa bảo mật có thể được thay đổi trong suốt vòng
Làm mới khóa đời của mạng Bluetooth mesh thông qua quy trình
Làm mới khóa.
Sự xáo trộn thông báo gây khó khăn cho việc theo dõi
các bản tin được gửi trong mạng và do đó, cung cấp cơ
Làm xáo trộn bản tin
chế bảo mật để gây khó khăn cho việc theo dõi các
nút.

Bảo mật Bluetooth mesh bảo vệ mạng khỏi các cuộc

Bảo vệ tấn công phát lại
tấn công phát lại.

Các nút có thể được xóa khỏi mạng một cách an toàn,
Bảo vệ tấn công thùng rác
theo cách ngăn chặn các cuộc tấn công vào thùng rác.

Quá trình các thiết bị được thêm vào mạng Bluetooth

Cấp phép thiết bị an toàn
mesh để trở thành các nút là một quá trình an toàn.

Tách các mối quan tâm và Các khóa bảo mật

Do sự tách biệt về bảo mật giữa các cấp độ mạng, ứng dụng và thiết bị, có 3 loại khóa bảo mật:
 Khóa mạng (NetKey)
Việc sở hữu khóa này làm cho thiết bị trở thành một phần của mạng (còn được gọi là
node). Có 2 khóa bắt nguồn từ NetKey: network encryption key (khóa mã hóa
mạng) và privacy key (khóa riêng tư). Sở hữu NetKey cho phép một node giải mã và xác
thực lên đến lớp mạng, cho phép chuyển tiếp các thông báo, nhưng không giải mã dữ liệu
ứng dụng.
 Khóa ứng dụng (AppKey)
Đây là khóa được chia sẻ giữa một tập hợp con các node trong mạng Mesh, thường là
những node tham gia vào một ứng dụng chung. Ví dụ, một hệ thống chiếu sáng AppKey sẽ
được chia sẻ giữa công tắc đèn và bóng đèn, nhưng không được chia sẻ với bộ điều nhiệt
 hoặc cảm biến chuyển động. AppKey được sử dụng để giải mã và xác thực thông báo ở
cấp ứng dụng, nhưng nó chỉ hợp lệ trong một mạng Mesh, không phải trên nhiều mạng.
 Khóa thiết bị (DevKey)
Đây là khóa dành riêng cho thiết bị được sử dụng trong quá trình cấp phép để đảm
bảo thông tin liên lạc giữa unprovisioned và provisioner.

Loại bỏ nút, Làm mới khóa và Các cuộc tấn công thùng rác

Nếu một nút bị lỗi và cần phải được xử lý hoặc nếu Master sở hữu quyết định bán nút cho một
Master sở hữu khác, thì điều quan trọng là khóa cũ không thể được sử dụng để thực hiện một
cuộc tấn công vào mạng mà nút đó đã được lấy. Do đó, quy trình loại bỏ một nút khỏi mạng
được xác định. Các Provisioner thêm các nút vào một Reject list và sau đó một thủ tục
Key Refresh được bắt đầu.

Thủ tục làm mới khóa đưa ra tất cả các nút trong mạng, ngoại trừ những nút thuộc Reject list, nó
làm mới khóa mạng, khóa ứng dụng và tất cả dữ liệu dẫn xuất có liên quan. Nói cách khác, toàn
bộ bộ khóa bảo mật tạo cơ sở cho bảo mật mạng và ứng dụng được thay thế.

Do đó, một nút đã bị xóa khỏi mạng và chứa một NetKey cũ và bộ AppKey cũ, không còn là
thành viên của mạng và không gây ra mối đe dọa nào.

Sự riêng tư

Khóa bảo mật, bắt nguồn từ NetKey, được sử dụng để làm xáo trộn các giá trị tiêu đề PDU của
mạng, chẳng hạn như địa chỉ nguồn, nó đảm bảo rằng việc nghe trộm thông thường, thụ động
không thể được sử dụng để theo dõi các nút và những người sử dụng chúng. Nó cũng làm cho
các cuộc tấn công dựa trên phân tích lưu lượng trở nên khó khăn.

Phát lại các cuộc tấn công

Trong an ninh mạng, tấn công phát lại là một kỹ thuật mà kẻ nghe trộm chặn và chụp một hoặc
nhiều bản tin và chỉ cần truyền lại chúng sau đó, với mục đích lừa người nhận thực hiện hành
động nào đó mà thiết bị tấn công không được phép thực hiện.

Bluetooth mesh chống lại các cuộc tấn công phát lại bằng cách sử dụng hai trường PDU mạng
được gọi là Sequence Number (SEQ) và IV Index. Các element tăng giá trị SEQ mỗi khi chúng
xuất bản một bản tin. Nút nhận được bản tin từ một element có chứa giá trị SEQ nhỏ hơn hoặc
bằng giá trị của bản tin hợp lệ cuối cùng sẽ loại bỏ nó vì nó có khả năng liên quan đến một cuộc
tấn công phát lại. Tương tự, IV Index là một trường riêng biệt được xem xét cùng với SEQ. Giá trị
IV Index trong thông báo từ một phần tử nhất định phải luôn bằng hoặc lớn hơn thông báo hợp
lệ cuối cùng từ phần tử đó.
Hộp công cụ mật mã

Hầu hết các tính năng bảo mật của Bluetooth mesh dựa trên các thuật toán và quy trình mật mã
tiêu chuẩn công nghiệp.

Có 2 chức năng bảo mật chính được sử dụng trong ngăn xếp Bluetooth mesh: AES-CMAC và AES-
CCM. Đây là các chức năng mã hóa và xác thực cơ bản, và tất cả các chức năng khác được sử
dụng để tạo khóa đều dựa trên chúng.

AES-CMAC

Mã xác thực bản tin dựa trên mật mã (CMAC) là một thuật toán có thể tạo ra giá trị xác thực bản
tin 128 bit có độ dài cố định cho bất kỳ đầu vào có độ dài thay đổi nào. Công thức tạo mã xác
thực bản tin MAC bằng thuật toán AES-CMAC được viết như sau:
MAC = AES-CMACk(m)
Các đầu vào cho AES-CMAC là:
k - khóa 128 bit
m - dữ liệu có độ dài thay đổi được xác thực
AES-CMAC có khả năng phát hiện lỗi tuyệt vời. Các kỹ thuật khác, liên quan đến việc xác minh
tổng kiểm hoặc sử dụng mã phát hiện lỗi, chỉ có thể phát hiện các sửa đổi ngẫu nhiên của dữ
liệu. AES-CMAC được thiết kế để phát hiện các sửa đổi có Master đích, trái phép đối với dữ liệu,
cũng như các sửa đổi ngẫu nhiên.

AES-CCM

AES-CCM là một thuật toán mã hóa chung, được xác thực, được thiết kế để sử dụng với các mật
mã khối mật mã. Trong thông số kỹ thuật Bluetooth mesh , AES-CCM được sử dụng làm chức
năng xác thực và mã hóa cơ bản trong mọi trường hợp. Công thức sử dụng nó như sau:
ciphertext, MIC = AES-CCMk(n, m, a)
Có 4 đầu vào cho AES-CCM:
k - khóa 128 bit
n - một nonce 104 bit 
m - dữ liệu có độ dài thay đổi được mã hóa và xác thực
a - dữ liệu có độ dài thay đổi được xác thực nhưng không được mã hóa, còn được gọi
là Dữ liệu bổ sung . Tham số đầu vào này có thể có độ dài bằng không byte
Có hai đầu ra từ AES-CCM:
ciphertext - dữ liệu có độ dài thay đổi sau khi nó đã được mã hóa
MIC - giá trị Kiểm tra tính toàn vẹn của bản tin của m và a
Hình 1 cho thấy một trọng tải văn bản thuần túy, có thể từ lớp mạng Bluetooth mesh hoặc lớp
truyền tải phía trên, đang được AES-CCM xử lý bằng khóa mã hóa đầu vào, trọng tải nonce và
văn bản rõ ràng. Một trọng tải được mã hóa và MIC là đầu ra.
 Hình 19: AES-CCM được sử dụng để mã hóa và xác thực tải trọng gói.

Bộ tạo SALT

Bảo mật Bluetooth mesh xác định một chức năng tạo SALT được gọi là s1, sử dụng chức năng
AES-CMAC. Như đã giải thích ở trên, AES-CMAC có hai tham số đầu vào: k và m.  Tuy nhiên, khi
được sử dụng để tạo SALT, chỉ có tham số đầu vào m là thay đổi. k luôn được đặt thành giá trị
128-bit: 0x0000 0000 0000 0000 0000 0000 0000 0000 0000, được gọi là ZERO trong đặc tả
Bluetooth mesh.

Hình 20: Chức năng tạo SALT.

Đầu vào cho hàm tạo SALT là:

m - mảng octet có độ dài khác 0 hoặc chuỗi được mã hóa ASCII.
Đầu ra là giá trị MAC 128 bit và công thức s1 được viết là:
s1(m) = AES-CMACZERO(m)
Các chức năng bảo mật khác:
Trong phần thông số kỹ thuật mạng Bluetooth mesh 3.8.2, Hộp công cụ bảo mật , bạn sẽ tìm thấy
các chức năng bảo mật khác được định nghĩa, chẳng hạn như các chức năng dẫn xuất khóa khác
nhau. Tất cả chúng đều dựa trên AES-CMAC và chức năng tạo SALT, s1 (chức năng tạo SALT cũng
dựa trên AES-CMAC).
nRF5 SDK cho Mesh
Tổng quan về kiến trúc
Mục tiêu của SDK là cung cấp cho nhà phát triển một bộ API để giúp việc triển khai dễ dàng hơn
và loại bỏ   mọi phức tạp không cần thiết trong ngăn xếp bên dưới. Dưới đây là sơ đồ hiển thị
kiến trúc của SDK nRF5 cho Mesh:

Hình 1: Kiến trúc của SDK nRF5 cho Mesh

Hãy đi qua từng lớp trong kiến trúc.
 Models: các mô hình xác định các hành vi và bản tin cụ thể cho một ứng dụng nhất
định. Các mô hình tương tự như GATT trong BLE theo nghĩa là có các mô hình tiêu chuẩn được
xác định bởi Bluetooth SIG, nhưng nhà phát triển cũng có quyền tự do xác định và phát triển của
riêng họ (thường là để triển khai một ứng dụng hoặc chức năng tùy chỉnh mà bất kỳ chức năng
tiêu chuẩn nào không đáp ứng mô hình).
 Access: nghĩ về lớp Access như một lớp ghép kênh mô hình. Nó chịu trách nhiệm xác định
bản tin Mesh nào dành cho một mô hình cụ thể và chuyển tiếp nó cùng với mô hình dự định.
 DSM (Device State Manager):  DSM xử lý nhiệm vụ lưu trữ các khóa mã hóa và địa chỉ
được sử dụng bởi ngăn xếp Mesh. Đối với mỗi mô hình được định cấu hình và gán các khóa và
địa chỉ ứng dụng, DSM lưu trữ các giá trị này trong bộ nhớ liên tục (để chúng có thể được truy
xuất sau một chu kỳ nguồn). Nó cung cấp các chốt cho các giá trị này để cho phép các mô hình
sử dụng chúng.
 Core: lớp Core trong SDK nRF5 cho Mesh bao gồm   lớp truyền tải và  mạng.
o Lớp truyền tải: lớp này có nhiệm vụ mã hóa các gói Mesh bằng các khóa ứng dụng
(AppKeys) và tách chúng thành các gói Mesh để truyền qua không khí. Nó cũng xử lý việc tập hợp
lại các phân đoạn gói đến và kết hợp chúng thành một định dạng có thể được chuyển cho lớp
Access.
o Lớp mạng: lớp này mã hóa tất cả các phân đoạn gói tin của lớp truyền tải
bằng  khóa mạng (NetKey) và điền địa chỉ nguồn và địa chỉ đích trước khi chuyển nó đến lớp
Bearer để gửi qua mạng. Ở đầu nhận, nó giải mã các gói, xem xét địa chỉ nguồn và đích để xác
định xem gói có nên được chuyển tiếp lên ngăn xếp hay không.
 Cung cấp:  cung cấp  là một yêu cầu đối với bất kỳ mạng Mesh nào. Mỗi thiết bị cần phải
trải qua quá trình cung cấp trước khi tham gia vào mạng. Ngăn xếp Mesh cung cấp 2 cách cung
cấp thiết bị: trực tiếp thông qua PB-ADV (người mang cung cấp advertising) hoặc thông qua cấp
phép từ xa. Việc cấp phép PB-ADV chỉ có thể xảy ra giữa 2 thiết bị nằm trong phạm vi phủ sóng
của nhau. Cung cấp từ xa cho phép 2 thiết bị hoàn thành quá trình mà không nằm trong phạm vi
của nhau, với sự trợ giúp của các thiết bị khác trong mạng Mesh.
Lưu ý quan trọng:  hãy nhớ rằng tính năng cấp phép từ xa dành riêng cho Bắc Âu và không thể
sử dụng với các thiết bị của các nhà cung cấp khác.
 DFU:  lớp/module này xử lý quá trình cập nhật firmware của thiết bị. Nó cho phép truyền
phần sụn xác thực, đồng thời đến tất cả các thiết bị trong mạng Mesh mà không ảnh hưởng đến
hoạt động của ứng dụng. Điều này khác và không tương thích với quy trình DFU được sử dụng
trong SDK nRF5 cho thiết bị BLE.
Lưu ý quan trọng:  hãy nhớ rằng tính năng nRF5 Mesh DFU cũng dành riêng cho Bắc Âu và
không thể sử dụng với các thiết bị của các nhà cung cấp khác.
 Bearer:  mức/mô-đun này chỉ được sử dụng trong nội bộ và không thể truy cập vào lớp
ứng dụng. Nó xử lý các hoạt động của bộ điều khiển vô tuyến mức thấp cần thiết để tuân thủ
định thời gian và định dạng gói của BLE.
Cài đặt và cấu hình SDK
Có một số công cụ bắt buộc cần được cài đặt trước khi có thể xây dựng ứng dụng hoặc ví dụ
Mesh nRF5. Các công cụ này được tóm tắt trong bảng sau:

Bảng 1: Danh sách các công cụ cần thiết cho SDK nRF5 cho Mesh
 
Liên kết tải xuống
 Công cụ dòng lệnh nRF5x
 Gói phần mềm SEGGER J-Link
 Python 2.7
 Python 3
Ngoài các công cụ bắt buộc này, có 2 tùy chọn cho môi trường xây dựng: sử dụng CMake hoặc sử
dụng SES (Segger Embedded Studio). Chúng tôi sẽ tập trung vào giải pháp SES vì nó dễ sử dụng
hơn và dễ sử dụng hơn.
Từ tài liệu của Nordic:
Python  không  bắt buộc phải xây dựng ngăn xếp Mesh và các ví dụ, nhưng nó được yêu cầu khi
làm việc với DFU,  PyACI tương tác, tạo các dự án SEGGER Embedded Studio và khi xây dựng tài
liệu. SDK nRF5 cho Mesh sử dụng  Python 3,  tuy nhiên,   công cụ nrfutil được sử dụng để truyền
DFU qua nối tiếp yêu cầu  Python 2.7.
Để cài đặt hoạt động hoàn toàn, hãy làm theo hướng dẫn được trình bày trên trang sau:
Xây dựng ngăn xếp Mesh và các ví dụ
Tương thích phần cứng
Các chipset và bộ công cụ phát triển sau được hỗ trợ bởi SDK nRF5 cho Mesh:

Bảng 2: Danh sách phần cứng được hỗ trợ cho SDK nRF5 cho Mesh
 
Trong các ví dụ triển khai của chúng tôi, chúng tôi sẽ sử dụng kết hợp các bộ phát triển
nRF52840 và nRF52832.
Ví dụ về Bluetooth mesh nRF52
Có khá nhiều ví dụ được cung cấp với SDK nRF5 cho Mesh. Mỗi loại yêu cầu một số bộ công cụ
phát triển (hoặc thiết bị) khác nhau và thể hiện các khái niệm và tính năng khác nhau trong
Bluetooth mesh. Một số ví dụ này bao gồm:
 Công tắc đèn
 Thử nghiệm làm mờ
 Ứng dụng khách cấp phép từ xa
 Máy Master cấp phép từ xa
 Beaconing
 và hơn thế nữa …
Tóm lược
Trong bài đăng này, chúng tôi đã đề cập đến một số kiến thức cơ bản về SDK nRF5 cho
Mesh. Trong bài đăng tiếp theo của loạt bài này, chúng ta sẽ xem xét các ví dụ khác nhau chuyên
sâu hơn, chọn một trong số chúng và bắt đầu triển khai nó.
Bluetooth mesh (Phần 5)
Trong bài đăng cuối cùng của loạt bài này về Bluetooth mesh (tìm thấy tại đây), chúng tôi đã
cung cấp tổng quan cấp cao về SDK nRF5 cho Bluetooth mesh. Chúng tôi cũng liệt kê các ví dụ
khác nhau được cung cấp như một phần của SDK Bắc Âu. Ví dụ đầy đủ nhất trong số những ví dụ
này là ví dụ về ánh sáng và đây là ví dụ mà chúng tôi sẽ tiếp tục demo và giải thích.  Trong bài
đăng của tuần này, chúng ta sẽ xem xét quá trình xây dựng và chạy ví dụ này và tìm hiểu các
phần khác nhau bên trong nó. Trong các bài viết sắp Slavei, chúng ta sẽ đi vào chi tiết mã nguồn
của từng thiết bị.
Đây là sơ đồ hiển thị mạng và các thiết bị chúng tôi sẽ sử dụng trong đó:

Hình 1: Sơ đồ mạng Mesh nRF

 
Yêu cầu phần cứng và phần mềm
Các thiết bị phần cứng khác nhau được yêu cầu trong ví dụ này bao gồm:
 2 bảng nRF52 (Tôi sẽ sử dụng các bảng phát triển nRF52840). Một bảng sẽ được lập trình
với máy Master proxy và bảng còn lại với máy khách proxy. Chúng tôi sẽ sử dụng các node
proxy để cho phép điện thoại di động phát hiện và cung cấp chúng (vì hệ điều hành di động
không hỗ trợ giao tiếp với các thiết bị Mesh không proxy).
 Điện thoại di động (iOS hoặc Android) chạy ứng dụng di động nRF Mesh.
 Một PC để xây dựng mã ví dụ, giao diện và lập trình các bảng phát triển.
Các gói phần mềm khác nhau cần thiết để xây dựng các ví dụ là:
 Segger Embedded Studio (SES) (tìm thấy  ở đây).
 Nordic nRF5 SDK phiên bản 15.0.0 (tìm thấy  tại đây).
 Nordic nRF5 SDK cho Mesh phiên bản 2.2.0 (tìm thấy  tại đây).
 nRF Mesh ứng dụng iOS hoặc Android được cài đặt trên điện thoại di động của bạn (tìm
thấy  tại đây cho iOS  và  tại đây cho Android).
SDK nRF5 cho Mesh yêu cầu SDK nRF5 phiên bản 15.0.0 để tạo. Các bước cần thiết để hoàn
thành việc này là:
 Đảm bảo bạn tải xuống cả SDK nRF5 cho Mesh và SDK nRF5.
 Đặt các thư mục đã giải nén (từ các tệp ZIP) trong cùng một thư mục. Đây là cấu trúc thư
mục của tôi trông như thế này:
└── nRF Mesh Project /
│ ├── nRF5_SDK_15.0.0_a53641a /
│ └── nrf5_SDK_for_Mesh_v2.2.0_src /
 Theo mặc định, Segger Embedded Studio (SES) sẽ chọn SDK nRF5 nếu nó được đặt cùng
với SDK Mesh nRF5. Tuy nhiên, bạn có thể đặt nó ở một vị trí khác và sửa đổi macro SDK_ROOT
từ bên trong SES để trỏ đến đường dẫn khác này (bằng cách làm theo hướng dẫn tại đây).
Ví dụ về Mesh chuyển đổi ánh sáng
Mô tả chung về hoạt động
Hoạt động cơ bản của ví dụ này là tạo thành một mạng Bluetooth mesh bao gồm một điện thoại
thông minh (được sử dụng như một thiết bị dự phòng) và 2 bảng phát triển nRF52: một bảng
dùng làm công tắc đèn và bảng kia dùng làm bóng đèn. Provisioner (trong trường hợp này là
điện thoại thông minh) định cấu hình toàn bộ mạng bằng cách:
 Gán cho mỗi thiết bị một địa chỉ duy nhất.
 Phân phối các khóa ứng dụng và mạng cần thiết phù hợp với từng thiết bị.
 Cấu hình các mô hình Mesh cho từng thiết bị.
Ứng dụng di động nRF Mesh (mà chúng tôi sẽ sử dụng làm provisioner) cung cấp cho chúng tôi
rất nhiều sự linh hoạt và kiểm soát đối với từng bước của quy trình cung cấp. Điều này có thể hơi
khó hiểu và choáng ngợp lúc đầu, nhưng nó là một cách tuyệt vời để tìm hiểu về các khái niệm và
hoạt động khác nhau trong mạng Bluetooth mesh.
Chạy ví dụ từng bước
Trước khi xây dựng và nhấp nháy bảng phát triển với ví dụ này lần đầu tiên, chúng ta sẽ cần xóa
flash.
Xóa các Ban Phát triển
Để làm điều đó, hãy làm theo các bước sau cho từng bảng trong số 2 bảng phát triển:
 Đầu tiên, chỉ connection một trong các bảng phát triển với máy tính của bạn qua cáp USB.
 Mở Segger Embedded Studio (SES). Nếu bạn chưa hoàn thành quá trình tải xuống và thiết
lập SES, trước tiên bạn có thể muốn xem hướng dẫn trước của tôi: Hướng dẫn phát triển nRF đa
nền tảng hoàn chỉnh
 Mở một trong các Giải pháp cho ví dụ: ứng dụng khách proxy công tắc đèn hoặc máy
Master proxy công tắc đèn:
└── nrf5_SDK_for_Mesh_v2.2.0_src /
│ ├── ví dụ
│ ├── light_switch
│ ├── proxy_client
│ ├── light_switch_proxy_client_nrf052840_nrf0. emProject
│ ├── proxy_server
│ ├── light_switch_proxy_server_nrf52840_xxAA_s140_6_0_0.emProject
 Điều hướng đến  mục menu Target và chọn  Connect J-Link:
 Hình 2: Connection J-Link trong SES
 Tiếp theo, điều hướng đến  menu Target một lần nữa và xác minh rằng J-Link hiện đã
được connection. Bây giờ bạn sẽ thấy rằng các tùy chọn khác (chẳng hạn như Đặt lại, Tải xuống,
Xóa tất cả và Tải xuống) đều có sẵn (không bị chuyển sang màu xám nữa). Chọn  Xóa tất
cả. Thao tác này sẽ mất vài giây, tối đa một phút, nhưng cần thiết để đảm bảo rằng bảng phát
triển đã xóa mọi phiên bản SoftDevice cũ hơn trước đó và dữ liệu được lưu trong bộ nhớ.

Hình 3: Tùy chọn Erase All trong SES

 Chờ thao tác kết thúc (thường là khi thông báo sau hiển thị):
 Hình 4: Xóa tất cả đã xong
Xây dựng và nhấp nháy ví dụ
Khi bạn đã hoàn thành việc xóa từng bảng phát triển, bây giờ bạn đã sẵn sàng để xây dựng máy
Master proxy và các dự án máy khách proxy và chuyển từng người trong số chúng vào bảng phát
triển.
Các bước:
 Đảm bảo rằng bạn chỉ có một bảng phát triển được connection với máy tính của mình.
 Mở một trong các tệp Giải pháp SES cho máy khách proxy công tắc đèn hoặc máy
Master proxy công tắc đèn.
 Xây dựng và phát triển dự án. Bạn có thể sử dụng  tùy chọn Build and
Debug  trong  menu Build cho việc này.
 Khi bạn đã flash bảng và bắt đầu quá trình gỡ lỗi, bạn sẽ thấy rằng ứng dụng tạm dừng
ở main () để chờ bạn tiếp tục thực thi. Bạn cũng sẽ thấy thông tin sau trong cửa sổ đầu ra đầu
cuối gỡ lỗi:
Máy Master ủy quyền chuyển đổi ánh sáng:

Hình 5: Đầu ra gỡ lỗi demo của Proxy Server

Ứng dụng khách ủy quyền chuyển đổi ánh sáng:

Hình 6: Đầu ra gỡ lỗi trình diễn Proxy Client

 Tại thời điểm này, bạn có thể chỉ cần tắt bảng phát triển (hoặc ngắt connection) và chuyển
sang nhấp nháy bảng khác. Bật bảng phát triển sau đó sẽ chạy ứng dụng vì nó đã được flash và
không cần phải thực thi nó từ máy tính nữa.
 Nếu bạn thấy thông báo cho biết rằng khởi động RAM có thể được điều chỉnh đến một địa
chỉ khác, thì bạn sẽ phải sửa đổi macro dự án để phù hợp với các giá trị được đề xuất.  Bạn có thể
làm điều này bằng cách:
o Nhấp chuột phải vào tên Dự án
o Nhấp vào Chỉnh sửa tùy chọn
o Từ menu thả xuống Cấu hình, chọn Chung
o Chọn  trình liên kết
o Bấm đúp vào Macro Vị trí Phần
o Sửa đổi RAM Bắt đầu để khớp với giá trị được in trong cửa sổ Debug Terminal
 Đảm bảo rằng bạn có gắn nhãn mỗi bảng phát triển hoặc ít nhất là được công nhận với vai
trò mà nó được hiển thị (Máy khách/Chuyển mạch hoặc Máy Master/Đèn). Điều này sẽ giúp bạn
dễ dàng xác định sau này khi cung cấp và khi vận hành và kiểm tra mạng.
 Khi bạn đã có bảng phát triển với các ví dụ máy Master và máy khách, bạn đã sẵn sàng để
chuyển sang chạy ví dụ và định cấu hình mạng Mesh.
Định cấu hình mạng (Cấp phép)
Bây giờ, chúng tôi đã sẵn sàng định cấu hình mạng Mesh của mình và cung cấp từng máy Master
proxy công tắc đèn và thiết bị khách proxy.
 Trước tiên, hãy đảm bảo rằng bạn đã cài đặt ứng dụng Mesh nRF iOS hoặc Android trên
điện thoại thông minh của mình
 Khởi chạy ứng dụng Mesh nRF
 Nhấp vào  Thêm thiết bị mới
 Ứng dụng sẽ bắt đầu scanning các thiết bị chưa được cấp phép và phát tín hiệu  ở khu vực
xung quanh
 Bạn sẽ thấy cả thiết bị Mesh Light nRF5x Mesh và nRF5x Mesh Switch hiển thị trong
danh sách
 Nhấp vào một trong số họ trong danh sách và sau đó nhấp vào  Xác định
 Chờ quá trình kết thúc và điền thông tin, sau đó nhấn  Cung cấp
 Quá trình này sẽ mất vài giây, tối đa một phút (tiến trình sẽ được hiển thị ở góc dưới cùng
bên phải của màn hình cho biết tỷ lệ phần trăm đã hoàn thành)
 Lặp lại quá trình cấp phép đã hoàn tất cho thiết bị kia
Đây là video cho thấy quá trình:
 Khi bạn đã cấp phép cả 2 thiết bị, bạn đã sẵn sàng định cấu hình chúng.
 Từ  tab Network, bạn sẽ thấy danh sách 2 thiết bị: nRF5x Mesh Switch và nRF5x Mesh
Light.
 Nhấp vào Công tắc Mesh nRF5x. Đây là thiết bị chúng tôi muốn cấu hình để hoạt động
như một máy khách (một công tắc đèn điều khiển các bóng đèn khác trong mạng).
 Nhấp vào  Máy khách OnOff Chung. Mô hình GenericOnOff là mô hình được định nghĩa
bởi Bluetooth SIG, trường hợp sử dụng của công tắc bật/tắt cơ bản (chẳng hạn như công tắc
đèn).
 Tiếp theo, chúng tôi muốn liên kết Khách hàng với một AppKey. Hãy chọn cái đầu tiên
trong danh sách (AppKey 1). Khi nó được ràng buộc, bạn sẽ thấy rằng nó được liệt kê là  Chỉ mục
chính 0000.
 Vì đây là một Khách hàng, chúng tôi muốn nó  xuất bản đến một địa chỉ. Vì vậy, hãy xác
định điều đó. Chọn Địa chỉ xuất bản và nhập địa chỉ nếu chưa được đặt (tôi đã nhập CEEF trong
trường hợp của mình). Sau khi nhập xong, bạn có thể nhấn  Áp dụng Xuất bản.
 Nếu thành công, bạn sẽ thấy nó được liệt kê trong  Địa chỉ xuất bản.
 Bây giờ, hãy cấu hình Máy Master. Quay lại  tab Mạng  và chọn  thiết bị Mesh Light
nRF5x  trong danh sách.
 Nhấp vào  Máy Master Bật tắt Chung. Chọn  AppKey Binding và chọn khóa đầu tiên
trong danh sách (AppKey 1).
 Tiếp theo, chúng tôi muốn đặt Địa chỉ đăng ký  vì thiết bị này sẽ hoạt động như một  Máy
Master, có nghĩa là nó sẽ lắng nghe và hoạt động trên các thông báo và lệnh được gửi đến nó
từ  Khách hàng.
 Nhập cùng một địa chỉ (CEEF trong trường hợp của tôi). Bây giờ bạn sẽ thấy nó được liệt
kê trong  Địa chỉ đăng ký.
Đây là bản ghi của quá trình này:
Kiểm tra hoạt động mạng
 Bây giờ, bạn đã sẵn sàng để kiểm tra hoạt động của mạng.
 Nhấn Node # 1 trên bảng Máy khách/Công tắc đèn.
 Bạn sẽ thấy rằng đèn LED # 1 trên bảng khác (Máy Master/Bóng đèn) bật sáng.
 Nhấn Node # 2  trên bảng Máy khách/Công tắc đèn và nó sẽ tắt LED số 1 trên bảng khác
(Máy Master/Bóng đèn).
Bluetooth mesh (Phần 6)
Bây giờ chúng ta đã trình bày những kiến thức cơ bản về Bluetooth mesh và cũng đã xem xét
cách chạy một ví dụ đơn giản trên nền tảng nRF52, đã đến lúc chúng ta tìm hiểu sâu hơn về mã
nguồn của từng loại thiết bị/node liên quan đến mạng Mesh.
Nếu bạn đã bỏ lỡ các bài viết trước trong loạt bài này, bạn có thể tìm thấy tất cả chúng tại đây:
 Hướng dẫn Bluetooth mesh (phần 1): bao gồm các kiến thức cơ bản cũng như một số
thuật ngữ khác nhau như Node, Element, Trạng thái, Thuộc tính, Bản tin, Địa chỉ, Xuất bản/Đăng
ký và Lũ lụt được quản lý.
 Hướng dẫn về Bluetooth mesh (phần 2): bao gồm các thuật ngữ như Mô hình, Cảnh, Node
chuyển tiếp, Node proxy, Node kết bạn, Node công suất thấp và kiến trúc của Bluetooth mesh.
 Hướng dẫn Bluetooth mesh (phần 3) : bao gồm khái niệm Cấp phép và cách xử lý bảo mật
trong Bluetooth mesh.
 Hướng dẫn Bluetooth mesh (phần 4): bao gồm SDK nRF5 cho Mesh ngoài các điều kiện
tiên quyết và yêu cầu để chạy ví dụ Bluetooth mesh cho nền tảng nRF52 Bắc Âu.
 Hướng dẫn Bluetooth mesh (phần 5): bao gồm thiết lập và chạy ví dụ về Công tắc đèn-
Bóng đèn trên nền tảng nRF52.
Trong bài đăng hôm nay, chúng ta sẽ xem qua một phần mã nguồn cho ví dụ mà chúng tôi đã
trình diễn trong Phần 5 để hiểu rõ hơn về cách triển khai ví dụ Bluetooth mesh (và có thể sửa đổi
nó để đáp ứng yêu cầu của riêng bạn).
Ứng dụng Demo
Mô tả chung
Điều này ứng dụng bản demo cụ các ONOFF Generic  Khách hàng và  Generic
ONOFF  server  Mesh mô hình. Đây là những mô hình Mesh đơn giản nhất tồn tại trong tiêu
chuẩn và chúng đại diện cho trạng thái Bật hoặc Tắt đơn giản.
Máy Master nắm giữ trạng thái, theo dõi nó và hoạt động dựa trên giá trị của nó.
Mặt khác, Máy khách sẽ gửi các thông báo để Đặt hoặc Lấy giá trị trạng thái.
Giá trị 0x00 đại diện cho trạng thái Tắt và giá trị 0x01 đại diện cho trạng thái Bật.
Mã nguồn
Ví dụ mà chúng tôi đang làm việc được cung cấp bởi Nordic Semiconductor trong SDK nRF5 cho
Mesh. Vị trí của ví dụ và mã nguồn như sau:
└── nrf5_SDK_for_Mesh_v2.2.0_src /
│ ├── ví dụ
│ ├── light_switch
│ ├── proxy_client
│ ├── proxy_server
│ ├── provisioner
Các loại node được sử dụng
Ví dụ mà chúng tôi đã demo trong bài đăng tuần trước bao gồm ba loại node:
 Một node Máy khách Proxy (“Công tắc đèn” được triển khai trên bảng phát triển
nRF52840)
 Một node Máy Master proxy (“Bóng đèn” được triển khai trên bảng phát triển nRF52840)
 Một node Provisioner (điện thoại di động hoặc một bảng phát triển nRF52 khác)
Trong một bài trước trong loạt bài này, chúng ta đã xem xét các loại node khác nhau trong
Bluetooth mesh.
2 trong số các node này là các node Công suất thấp (LPN) và các friend node.
Cả 2 node này đều chưa được triển khai trong Nordic nRF5 SDK cho Mesh (kể từ phiên bản
2.2.0). Các node này là tùy chọn trong triển khai mạng Bluetooth mesh, vì vậy chúng không bắt
buộc và có thể được đưa vào phiên bản Mesh SDK trong tương lai.
Hãy xem qua mã nguồn được sử dụng trong các node máy khách proxy và máy Master
proxy để hiểu sâu hơn về việc triển khai Bluetooth mesh trên nền tảng nRF52.
Trong bài tiếp theo, chúng ta sẽ tiếp tục bằng cách trình bày về  node cấp phép.
Node máy khách proxy
Hãy xem xét các yếu tố chính trong mã nguồn cho  node máy khách proxy.
Bất cứ khi nào bạn đang cố gắng hiểu hoạt động bên trong của một ứng dụng nhúng, thì
hàm main () (thường trong main.c) là nơi tốt nhất để bắt đầu. Đây là hàm main ():

int main (void)

{
khởi tạo ();
thực hiện_start (bắt đầu);

vì (;;)
{
(vô hiệu) sd_app_evt_wait ();
}
}

Bạn sẽ nhận thấy ba lệnh gọi hàm chính:

 khởi tạo ()
 execute_start (bắt đầu)
 (void) sd_app_evt_wait ()
Chúng ta hãy xem xét từng điều này.
khởi tạo ()
Đây là một hàm tĩnh (cục bộ) với mã nguồn sau:
static void khởi tạo (void)
{
__LOG_INIT (LOG_SRC_APP | LOG_SRC_ACCESS, LOG_LEVEL_INFO, LOG_CALLBACK_DEFAULT);
__LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “----- Bản trình diễn ứng dụng khách chuyển đổi ánh
sáng Mesh BLE Mesh ----- \ n”);

ERROR_CHECK (app_timer_init ());

hal_leds_init ();

#if BUTTON_BOARD
ERROR_CHECK (hal_buttons_init (button_event_handler));
#endif
uint32_t err_code = nrf_sdh_enable_request ();
APP_ERROR_CHECK (err_code);
#if đã định nghĩa S140 // việc cần làm hãy xóa cái đó sau khi sửa mức độ ưu tiên S140
softdevice_irq_priasty_checker ();
#endif

uint32_t ram_start = 0;
/* Đặt cấu hình mặc định (như được định nghĩa thông qua sdk_config.h). * /
err_code = nrf_sdh_ble_default_cfg_set (MESH_SOFTDEVICE_CONN_CFG_TAG, & ram_start);
APP_ERROR_CHECK (err_code);

err_code = nrf_sdh_ble_enable (& ram_start);

APP_ERROR_CHECK (err_code);

gap_params_init ();
conn_params_init ();

mesh_init ();
}

Tại đây chúng tôi:

 Bật mô-đun ghi nhật ký, định cấu hình nó và hiển thị thông báo nhật ký đầu tiên  ”—– BLE
Mesh Light Switch Client Demo —–”   [Dòng 3-4].
 Bật  mô-đun hẹn giờ, đèn LED  và các node [Dòng 6-11].
 Gọi một hàm SDK nội bộ cho phép  SoftDevice và báo cáo các sự kiện cho ứng dụng của
chúng tôi [Dòng 12-13].
 Thực hiện một giải pháp thay thế cần thiết cho S140 SoftDevice (dành cho bo mạch phát
triển nRF52840) [Dòng 15].
 Đặt các cấu hình khác nhau cho ngăn xếp BLE trong SoftDevice. Điều này bao gồm số
lượng liên kết (thiết bị ngoại vi và thiết bị trung tâm được định cấu hình), kích thước MTU, số
lượng UUID của nhà cung cấp cụ thể (cho các dịch vụ và đặc điểm), v.v. Biến ram_start   được sử
dụng để trả về vị trí bắt đầu RAM được sử dụng trong lần tiếp theo gọi hàm [Dòng 18-21].
 Bật ngăn xếp BLE [Dòng 23-24].
 Định cấu hình tên thiết bị được advertising (“nRF5x Mesh Switch”) và các thông số
connection khác nhau (bao gồm khoảng connection tối thiểu và tối đa ưu tiên, độ trễ phụ và thời
gian chờ giám sát connection) thông qua 2 hàm cục bộ:  gap_params_init ()  và conn_params_init
()  [Dòng 26-27 ].
execute_start (bắt đầu)
Lệnh gọi hàm này nhận một con trỏ hàm (trong trường hợp này là start () ) và đảm bảo rằng các
phần quan trọng bị vô hiệu hóa cho đến khi nó hoàn thành việc thực thi (để ngăn chặn bất kỳ sự
gián đoạn nào trong khi chạy hàm). Hãy xem xét hàm  start ():

khởi động void tĩnh (void)

{
rtt_input_enable (rtt_input_handler, RTT_INPUT_POLL_PERIOD_MS);
ERROR_CHECK (mesh_stack_start ());

if (! m_device_provisoned)
{
static const uint8_t static_auth_data [NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
mesh_provisionee_start_params_t prov_start_params =
{
.p_static_data = static_auth_data,
.prov_complete_cb = cung cấp_complete_cb,
.p_device_uri = NULL
};
ERROR_CHECK (mesh_provisionee_prov_start (& prov_start_params));
}

const uint8_t * p_uuid = nrf_mesh_configure_device_uuid_get ();

__LOG_XB (LOG_SRC_APP, LOG_LEVEL_INFO, “UUID thiết bị”, p_uuid, NRF_MESH_UUID_SIZE);

hal_led_mask_set (LEDS_MASK, LED_MASK_STATE_OFF);

hal_led_blink_ms (LEDS_MASK, LED_BLINK_INTERVAL_MS, LED_BLINK_CNT_START);
}

Trong chức năng này, chúng tôi:

 Bật chức năng RTT để cho phép tương tác với ứng dụng thông qua gửi lệnh đến cổng nối
tiếp [Dòng 3].
 Bắt đầu ngăn xếp Mesh. Thao tác này liên quan đến việc tạo UUID thiết bị, định cấu hình
ngăn xếp, cũng như gán các chức năng gọi lại cần thiết để xử lý các sự kiện Mesh khác
nhau  [Dòng 4].
 Định cấu hình và bắt đầu hoạt động Beacon cho phép thiết bị được cấp phép (nếu thiết bị
chưa được cấp phép) [Dòng 6-16].
Hoạt động này bao gồm Beacon thông qua người mang advertising cũng như người mang
GATT  (vì chúng tôi đang chạy một   node proxy).
 Nhận UUID (duy nhất) của thiết bị này từ ngăn xếp Mesh [Dòng 18].
 Đặt trạng thái của các đèn LED khác nhau [Dòng 21].
 Nháy đèn LED một số lần nhất định (LED_BLINK_CNT_START ) với độ
trễ LED_BLINK_INTERVAL_MS  [Dòng 22].
(void) sd_app_evt_wait ()
Đây là một chức năng SDK nội bộ về cơ bản đặt ứng dụng của chúng tôi ở trạng thái không hoạt
động cho đến khi có bất kỳ sự kiện nào được ngăn xếp báo cáo và cần được ứng dụng xử lý.
Chức năng gọi lại
Phần còn lại của mã trong ứng dụng này nằm trong các hàm gọi lại được gọi bất cứ khi nào một
sự kiện được ngăn xếp báo cáo và cần được ứng dụng xử lý. Điều quan trọng nhất là:
 cung cấp_complete_cb ():

 static void provisinstall_complete_cb (void)

 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Đã cấp phép thành công \ n”);

 /* Khôi phục các thông số ứng dụng sau khi chuyển từ dịch vụ Cấp phép sang Proxy * /
 gap_params_init ();
 conn_params_init ();

 dsm_local_unicast_address_t node_address;
 dsm_local_unicast_addresses_get (& node_address);
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Địa chỉ node: 0x% 04x \ n”,
node_address.address_start);

 hal_led_mask_set (LEDS_MASK, LED_MASK_STATE_OFF);
 hal_led_blink_ms (LEDS_MASK, LED_BLINK_INTERVAL_MS, LED_BLINK_CNT_PROV);

o Được gọi khi quá trình cấp phép hoàn tất thành công.
o Khôi phục các thông số connection.
o Nhấp nháy đèn LED để cho biết quá trình cấp phép đã hoàn tất.
 app_generic_onoff_client_status_cb ():

 / * Giao diện mô hình máy khách OnOff chung: Xử lý thông báo trạng thái đã nhận trong
cuộc gọi lại này * /
 static void app_generic_onoff_client_status_cb (const generic_onoff_client_t * p_self,
 const access_message_rx_meta_t * p_meta,
 const generic_onoff_status_params_t * p_in)
 {
 nếu (p_in-> còn lại_time_ms> 0)
 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Máy Master bật tắt: 0x% 04x, Bật tắt hiện
tại:% d, Bật tắt mục tiêu:% d, Thời gian còn lại:% d ms \ n”,
 p_meta-> src.value, p_in-> present_on_off, p_in-> target_on_off, p_in-> còn
lại_time_ms);
 }
 khác
 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Máy Master OnOff: 0x% 04x, Hiện tại OnOff:
% d \ n”,
 p_meta-> src.value, p_in-> present_on_off);
 }

o Điều này báo cáo một thông báo trạng thái được gửi đến Khách hàng.
o Trạng thái chứa  người gửi (Máy Master),  giá trị trạng thái hiện tại,  giá trị
trạng thái đích, cũng như bất kỳ thời gian còn lại nào  nếu thao tác sẽ được thực hiện sau này.
 config_server_evt_cb ():

 static void config_server_evt_cb (const config_server_evt_t * p_evt)

 {
 if (p_evt-> type == CONFIG_SERVER_EVT_NODE_RESET)
 {
 node_reset ();
 }

o Báo cáo bất kỳ sự kiện nào được Máy Master dự định xử lý. Điều này bao gồm
thông báo  Node Reset được gửi khi thiết bị bị xóa khỏi mạng (chưa được cấp phép).
o Trong trường hợp  nhận được thông báo Đặt lại node, máy Master đặt lại ngăn xếp
Mesh thông qua hàm node_reset () cục bộ :

o static void node_reset (void)

o {
o __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “----- Đặt lại node ----- \ n”);
o hal_led_blink_ms (LEDS_MASK, LED_BLINK_INTERVAL_MS, LED_BLINK_CNT_RESET);
o /* Chức năng này có thể trở lại nếu có các hoạt động flash đang diễn ra. * /
o mesh_stack_device_reset ();

 button_event_handler ():

 static void button_event_handler (uint32_t button_number)

 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Node% u được nhấn \ n”, số node);

 uint32_t status = NRF_SUCCESS;
 generic_onoff_set_params_t set_params;
 mô_trình_tuyển_triển;
 static uint8_t tid = 0;

 /* Node 1: BẬT, Node 2: Tắt, Máy khách [0]
 * Node 2: BẬT, Node 3: Tắt, Máy khách [1]
 */

 switch (button_number)
 {
 trường hợp 0:
 trường hợp 2:
 set_params.on_off = APP_STATE_ON;
 nghỉ;

 trường hợp 1:
 trường hợp 3:
 set_params.on_off = APP_STATE_OFF;
 nghỉ;
 }

 set_params.tid = tid ++;
 transfer_params.delay_ms = APP_CONFIG_ONOFF_DELAY_MS;
 transfer_params.transition_time_ms = APP_CONFIG_ONOFF_TRANSITION_TIME_MS;
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Đang gửi bản tin: ONOFF SET% d \ n”,
set_params.on_off);

 switch (button_number)
 {
 trường hợp 0:
 trường hợp 1:
 /* Thể hiện giao dịch được thừa nhận, sử dụng phiên bản mô hình khách hàng đầu
tiên * /
 /* Trong ví dụ này, người dùng sẽ không bị chặn nếu mô hình đang bận * /
 (void) access_model_reliable_cancel (m_clients [0].model_handle);
 status = generic_onoff_client_set (& m_clients [0], & set_params, &
transfer_params);
 hal_led_pin_set (BSP_LED_0, set_params.on_off);
 nghỉ;

 trường hợp 2:
 trường hợp 3:
 /* Thể hiện giao dịch chưa được thừa nhận, sử dụng phiên bản mô hình khách hàng
thứ 2 * /
 status = generic_onoff_client_set_unack (& m_clients [1], & set_params,
 & chuyển tiếp_params, APP_UNACK_MSG_REPEAT_COUNT);
 hal_led_pin_set (BSP_LED_1, set_params.on_off);
 nghỉ;
 }

 chuyển đổi (trạng thái)
 {
 trường hợp NRF_SUCCESS:
 nghỉ;

 trường hợp NRF_ERROR_NO_MEM:
 trường hợp NRF_ERROR_BUSY:
 trường hợp NRF_ERROR_INVALID_STATE:
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Máy khách% u không thể gửi \ n”,
button_number);
 hal_led_blink_ms (LEDS_MASK, LED_BLINK_SHORT_INTERVAL_MS,
LED_BLINK_CNT_NO_REPLY);
 nghỉ;

 trường hợp NRF_ERROR_INVALID_PARAM:
 /* Chưa kích hoạt xuất bản cho ứng dụng khách này. Một (hoặc nhiều) điều sau đây
là sai:
 * - Thiếu khóa ứng dụng hoặc không có khóa ứng dụng nào liên kết với kiểu máy
 * - Máy khách chưa đặt trạng thái xuất bản
 *
 * Nó là provisioner thêm một khóa ứng dụng, liên kết nó với mô hình và thiết lập
 * trạng thái xuất bản của mô hình.
 */
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Ấn bản không được định cấu hình cho
máy khách% u \ n”, button_number);
 nghỉ;

 vỡ nợ:
 ERROR_CHECK (trạng thái);
 nghỉ;
 }

o Chức năng này xử lý 4 node được sử dụng bởi 2  Khách hàng theo cách sau:
 Các node # 1 và  # 2 lần lượt gửi thông báo Bật và Tắt với tư cách là Ứng
dụng khách số 1.
 Các node # 3 và # 4 lần lượt gửi thông báo Bật và Tắt với tư cách là Ứng
dụng khách số 2.
 Các node số 1 và số 2 chứng tỏ việc gửi một bản tin “đáng tin cậy” yêu cầu
người nhận xác nhận đã nhận được bản tin.
 Các node # 3 và # 4  thể hiện việc gửi một bản tin chưa được xác nhận mà
không yêu cầu phản hồi từ người nhận.
o Nó cũng đặt các đèn LED trên bảng phát triển cục bộ ở trạng thái được chỉ định (để
đưa ra phản hồi cho người dùng rằng một thông báo hoạt động đã được gửi đến Máy
Master). Ví dụ, nhấn node # 1 sẽ gửi On bản tin Slavei  máy Master nhưng cũng sẽ biến On LED
# 1 để chỉ ra cho người dùng rằng các hoạt động được thực hiện.
 rtt_input_handler ():

 static void rtt_input_handler (int key)

 {
 if (key> = '0' && key <= '3')
 {
 uint32_t button_number = key - '0';
 button_event_handler (button_number);
 }

o Cho phép người dùng tương tác và kích hoạt các lần nhấn node bằng cách gửi lệnh
qua thiết bị đầu cuối nối tiếp thay vì nhấn node vật lý.
 models_init_cb ():

 static void models_init_cb (void)

 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Khởi tạo và thêm mô hình \ n”);

 cho (uint32_t i = 0; i <CLIENT_MODEL_INSTANCE_COUNT; ++ i)
 {
 m_clients [i].settings.p_callbacks = & client_cbs;
 m_clients [i].settings.timeout = 0;
 m_clients [i].settings.force_segmented = APP_CONFIG_FORCE_SEGMENTATION;
 m_clients [i].settings.transmic_size = APP_CONFIG_MIC_SIZE;

 ERROR_CHECK (generic_onoff_client_init (& m_clients [i], i + 1));
 }

o Chức năng này xử lý việc khởi tạo các mô hình thích hợp cho ứng dụng. Trong
trường hợp này, chúng tôi đang khởi tạo 2  Máy khách OnOff Chung [Dòng 12].
o Nếu bạn cần triển khai các mô hình bổ sung, đây sẽ là nơi để làm điều đó.
Node máy Master proxy
Các  Proxy Server Node mã nguồn là gần giống như  Proxy Client Node  mã với một vài ngoại
lệ đáng chú ý:
 models_init_cb ():

 static void models_init_cb (void)

 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Khởi tạo và thêm mô hình \ n”);
 app_model_init ();

mà gọi app_model_init ():

static void app_model_init (void)

{
/* Khởi tạo máy Master không hoạt động trên chỉ mục Element 0 * /
ERROR_CHECK (app_onoff_init (& m_onoff_server_0, 0));
}

o Ở đây, mô hình được khởi tạo là mô hình Máy Master OnOff Chung thay vì mô
hình Máy khách OnOff Chung.
 button_event_handler ():

 static void button_event_handler (uint32_t button_number)

 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Node% u được nhấn \ n”, số node);
 switch (button_number)
 {
 /* Nhấn SW1 trên Bộ phát triển sẽ dẫn đến trạng thái đèn LED để chuyển đổi và kích
hoạt
 thông báo TRẠNG THÁI để thông báo cho khách hàng về sự thay đổi trạng thái. Đây là
một minh chứng của
 công bố thay đổi trạng thái do sự kiện địa phương. * /
 trường hợp 0:
 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Hành động của người dùng \ n”);
 hal_led_pin_set (ONOFF_SERVER_0_LED,! hal_led_pin_get (ONOFF_SERVER_0_LED));
 app_onoff_status_publish (& m_onoff_server_0);
 nghỉ;
 }

 /* Bắt đầu thiết lập lại node * /
 trường hợp 3:
 {
 /* Xóa tất cả các trạng thái để đặt lại node. * /
 if (mesh_stack_is_device_provisions ())
 {
 (vô hiệu) proxy_stop ();
 mesh_stack_config_clear ();
 node_reset ();
 }
 khác
 {
 __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Thiết bị chưa được cấp phép. Việc đặt
lại không có tác dụng. \ N”);
 }
 nghỉ;
 }

 vỡ nợ:
 nghỉ;
 }

o Node # 1 bật LED # 1 trên bảng phát triển cục bộ và đồng thời kích hoạt thông báo
trạng thái được gửi đến  Node máy khách để thông báo về sự thay đổi trạng thái.
o Node số 3 được sử dụng để đặt lại node và “hủy cấp phép” nó khỏi mạng.
 Hàm start ()   không bao gồm nhấp nháy của đèn LED như trong  mã ví dụ Proxy Client
Node.
 Việc thực hiện 2 chức năng:
o app_onoff_server_set_cb ()   để thiết lập trạng thái LED:

o / * Gọi lại để cập nhật trạng thái phần cứng * /

o static void app_onoff_server_set_cb (const app_onoff_server_t * p_server, bool onoff)
o {
o /* Giải quyết trường hợp máy Master tại đây nếu được yêu cầu, ví dụ này chỉ sử dụng 1
trường hợp. * /
o
o __LOG (LOG_SRC_APP, LOG_LEVEL_INFO, “Đặt giá trị GPIO:% d \ n”, onoff)
o
o hal_led_pin_set (ONOFF_SERVER_0_LED, onoff);

o app_onoff_server_get_cb ()  để nhận trạng thái LED:

o / * Gọi lại để đọc trạng thái phần cứng * /

o static void app_onoff_server_get_cb (const app_onoff_server_t * p_server, bool *
p_present_onoff)
o {
o /* Giải quyết trường hợp máy Master tại đây nếu được yêu cầu, ví dụ này chỉ sử dụng 1
trường hợp. * /
o
o * p_present_onoff = hal_led_pin_get (ONOFF_SERVER_0_LED);

Tóm lược
Trong bài đăng này, chúng tôi đã đề cập đến mã nguồn cho 2 trong số các node trong mạng
Mesh:
 Node máy khách proxy
 Node máy Master proxy
Chúng ta đã nói về cách mô hình Generic OnOff được khởi tạo và định cấu hình cho từng node
máy khách và máy Master.
Trong ví dụ này, chúng tôi đã thử nghiệm trong bài trước, chúng tôi sử dụng điện thoại di động
có ứng dụng nRF Mesh làm thiết bị hỗ trợ. Tuy nhiên, SDK nRF5 cho Mesh cũng cung cấp một ví
dụ cấp chứng chỉ chạy trên bộ phát triển nRF52. Trong bài đăng của tuần Slavei, chúng tôi sẽ
kiểm tra provisioner dựa trên nRF và xem mã nguồn cho node này.
Hãy chắc chắn nhập email của bạn vào biểu mẫu bên dưới để được thông báo khi bài hướng dẫn
tiếp theo được xuất bản!
 Bluetooth mesh (Phần 7)
Trong hướng dẫn hôm nay:
 Trước tiên, chúng tôi sẽ lùi lại một bước và nói một chút về khả năng tương tác và khả
năng tương thích trong Bluetooth mesh.
 Sau đó, chúng ta sẽ xem qua bản demo về cách thiết lập mạng Mesh bao gồm kết hợp các
thiết bị bán sẵn.
 Cuối cùng, chúng ta sẽ xem qua mã nguồn từng bước và những thay đổi cần thiết để triển
khai chức năng cho bản trình diễn này.
Khả năng tương thích và khả năng tương tác
Sức mạnh của việc có tiêu chuẩn như Bluetooth mesh mà thiết bị được chứng nhận phải tuân
thủ là:
 Khả năng thêm các thiết bị từ các nhà sản xuất khác nhau vào bất kỳ mạng Mesh nào.
 Khả năng trong mạng để các thiết bị tương tác với những thiết bị khác triển khai một chức
năng chung một cách gần như liền mạch.
Điều này mang lại cho cả nhà sản xuất và người tiêu dùng sự linh hoạt tuyệt vời trong ba khía
cạnh chính:
 Chọn loại thiết bị sẽ được sử dụng trong mạng Mesh, bao gồm các ứng dụng phần mềm
có thể được triển khai trên các thiết bị như máy tính bảng và điện thoại di động tương tác với
mạng (ví dụ: provisioner dịch vụ).
 Tự do cho các nhà sản xuất cung cấp nhiều loại provisioner các chức năng khác nhau.
 Tính linh hoạt cho người dùng cuối trong việc định cấu hình mạng theo sở thích của họ.
Khái niệm về các mô hình, mà chúng ta đã thảo luận trong Phần 2 của loạt bài hướng dẫn này
(tìm thấy ở đây), ngoài các địa chỉ nhóm giúp cung cấp tính linh hoạt này.
Thiết bị Bluetooth mesh tiêu dùng
Tôi đã tìm kiếm trên thị trường các thiết bị, đặc biệt là bóng đèn, được chứng nhận Bluetooth
mesh. Tôi đã xem qua danh sách công khai sau đây về các thiết bị được chứng nhận Mesh,
nhưng 99% sản phẩm được liệt kê là mô-đun hoặc chipset.
Đó là một cuộc đấu tranh để tìm kiếm một sản phẩm tiêu dùng thực sự mà bất kỳ ai cũng có thể
mua và sử dụng ngay lập tức. Điều này là dễ hiểu (tôi đoán) vì tiêu chuẩn này rất mới.
Tôi đã xem danh sách cho LEDVANCE, hóa ra là công ty đứng sau thương hiệu Sylvania. Tôi đã
liên hệ với họ trên Twitter và họ đã có thể chỉ cho tôi đi đúng hướng. Cuối cùng, tôi đã hạ cánh
trên bóng đèn Sylvania SMART +. Tôi đã mua một vài trong số chúng để bắt đầu xây dựng mạng
Bluetooth mesh trong nhà của mình, nhưng cũng để xem việc tạo mạng từ nhiều thiết bị của các
công ty khác nhau sẽ dễ/khó như thế nào.
Mạng Mesh chiếu sáng Bluetooth mesh trong nhà
Khả năng tương thích và tương tác giữa các thiết bị được chứng nhận là chìa khóa thành công
của bất kỳ tiêu chuẩn connection nào. Trải nghiệm của tôi cho đến nay với khía cạnh này của
Bluetooth mesh là rất tốt.
Sau đây là sơ đồ của một mạng Bluetooth mesh đơn giản mà tôi đã bắt đầu xây dựng. Kể từ đó,
tôi đã mở rộng số lượng thiết bị trong mạng và sẽ thử nghiệm nó rộng rãi hơn, đặc biệt là về  độ
tin cậy và phạm vi.

Hình 1: Mạng Mesh chiếu sáng Bluetooth mesh

Mạng bao gồm những thứ sau:
 Một thiết bị hỗ trợ iOS hoặc Android chạy ứng dụng cung cấp Bluetooth mesh chung
(chẳng hạn như ứng dụng Mesh nRF của Bắc Âu hoặc ứng dụng Bluetooth mesh của Silicon
Labs).
 2 bóng đèn được chứng nhận Bluetooth mesh bán sẵn từ Sylvania:
o SYLVANIA SMART + Bluetooth Ánh sáng LED A19 mềm có thể thay đổi ánh sáng
màu trắng. Chúng tôi sẽ gọi ánh sáng này là “ F1 ”.
o SYLVANIA SMART + Bluetooth Đèn LED A19 đủ màu . Chúng tôi sẽ gọi ánh sáng này
là “ C1 ”.
 Bộ phát triển Nordic nRF52840 (DK) làm công tắc đèn. Việc triển khai công tắc đèn sẽ là
phiên bản điều chỉnh của ví dụ do Nordic cung cấp trong SDK nRF5 cho Mesh (mà chúng tôi đã
thử nghiệm trong Phần 5), nhưng có thêm một số chức năng:
o Node # 1: Bật về F1. Cũng biến trên LED # 1 trên bộ phát triển.
o Node # 2: Rẽ vào C1. Cũng biến trên LED # 2 trên bộ phát triển.
o Node # 3: Bật cả F1 và C1 (với tư cách là một nhóm). Cũng lần lượt  trên đèn LED #
1 và # 2 trên bộ phát triển.
o Node # 4: Tắt cả F1 và C1 (với tư cách là một nhóm). Đồng thời  tắt đèn LED #
1 và # 2 trên bộ phát triển.

Hình 2: Gán địa chỉ node

Công tắc đèn Mesh dựa trên nRF52 (Điều khiển từ xa)
Đảm bảo rằng bạn làm theo các bước cài đặt và thiết lập trong  Phần 5  trước.
Ứng dụng LightSwitch ban đầu được cung cấp trong các ví dụ Bluetooth mesh nRF chỉ hỗ trợ 2
ứng dụng khách Generic OnOff. Trong ví dụ của chúng tôi, chúng tôi cần triển khai ba khách
hàng:
 Một ứng dụng khách OnOff chung để điều khiển F1.
 Một ứng dụng khách OnOff chung để điều khiển C1.
 Một ứng dụng khách OnOff chung để kiểm soát nhóm (F1 + C1).
Hãy xem qua các thay đổi mã nguồn để thực hiện điều này.
Bước 1: Thay đổi số lượng khách hàng (từ 2 thành 3)
Số lượng khách hàng được xác định trong tệp tiêu đề nrf5_SDK_for_Mesh_v2.2.0_src
/amples/light_switch/include/light_switch_example_common.h.
Thay đổi nó thành 3 (thay vì 2):

/ ** Số lượng kiểu máy khách Bật-Tắt trên Node chuyển * /

#define CLIENT_MODEL_INSTANCE_COUNT (3)

Bước 2: Thay đổi hành vi của các node và đèn LED trên bộ công cụ phát triển
Tất cả những thay đổi chúng ta cần thực hiện đều nằm trong hàm static void
button_event_handler (uint32_t button_number).
 Thay đổi trạng thái được thiết lập bởi các lần nhấn node thành  bật cho các node 1,2 và
3.  Tắt cho node 4.

 /* Node 1: LED 1 BẬT, Máy khách [0]

 * Node 2: LED 2 BẬT, Máy khách [1]
 * Node 3: Đèn LED 1 + 2 BẬT, Máy khách [2]
 * Node 4: Đèn LED 1 + 2 TẮT, Máy khách [2]
 */

 switch (button_number)
 {
 trường hợp 0:
 trường hợp 2:
 trường hợp 1:
 set_params.on_off = APP_STATE_ON;
 nghỉ;

 trường hợp 3:
 set_params.on_off = APP_STATE_OFF;
 nghỉ;

 Sửa đổi để node 2 gửi bản tin dưới dạng  ứng dụng khách số 2 (được lập chỉ mục ở vị trí
1). Ngoài ra, hãy thực hiện thay đổi để bật LED 2 (được lập chỉ mục ở 1).

 trường hợp 1:
 /* Thể hiện giao dịch được thừa nhận, sử dụng phiên bản mô hình khách hàng đầu
tiên * /
 /* Trong ví dụ này, người dùng sẽ không bị chặn nếu mô hình đang bận * /
 (void) access_model_reliable_cancel (m_clients [1].model_handle);
 status = generic_onoff_client_set (& m_clients [1], & set_params, &
transfer_params);
 hal_led_pin_set (BSP_LED_1, set_params.on_off);

nghỉ;

 Sửa đổi để có node 3 và 4 để gửi bản tin dưới dạng ứng dụng khách số 3 (được lập chỉ
mục ở vị trí 2). Ngoài ra, hãy thực hiện thay đổi để đặt trạng thái của cả đèn LED 1 & 2 (được lập
chỉ mục lần lượt là 0 & 1).

 trường hợp 2:
 trường hợp 3:
 /* Thể hiện giao dịch chưa được thừa nhận, sử dụng phiên bản mô hình khách hàng
thứ 2 * /
 /* Thể hiện giao dịch được thừa nhận, sử dụng phiên bản mô hình khách hàng đầu
tiên * /
 /* Trong ví dụ này, người dùng sẽ không bị chặn nếu mô hình đang bận * /
 (void) access_model_reliable_cancel (m_clients [2].model_handle);
 status = generic_onoff_client_set (& m_clients [2], & set_params, &
transfer_params);
 hal_led_pin_set (BSP_LED_0, set_params.on_off);
 hal_led_pin_set (BSP_LED_1, set_params.on_off);

nghỉ;

Hướng dẫn cung cấp và thiết lập mạng

Hãy đi qua các bước khác nhau để cung cấp các node và thiết lập mạng từ đầu.
Bước 1: Đảm bảo rằng tất cả các thiết bị đã được đặt lại và chưa được cấp phép
 Đối với bảng phát triển nRF52, bạn có thể thực hiện việc này bằng cách điều hướng
đến  menu Target trong SES, sau đó chọn  Connect J-Link, sau đó chọn  Erase All. Khi bạn đã
xóa bảng phát triển (có thể mất một hoặc 2 phút), bây giờ bạn có thể xóa bảng này bằng ví dụ
Máy khách Proxy Công tắc đèn được cập nhật mà chúng tôi đã sửa đổi trong phần trước.
 Đối với bóng đèn Sylvania, bạn có thể làm điều này bằng cách chuyển ra khỏi quyền lực
và sau đó trở lại trên 5 lần liên tiếp. Lần cuối cùng (thứ 5) khi bạn bật đèn, bạn sẽ thấy độ trễ
ngắn (tối đa 3 giây), sau đó đèn sẽ nhấp nháy một vài lần cho biết hiện nó đã được thiết lập lại.
Bước 2: Sử dụng ứng dụng nRF Mesh iOS hoặc Android để tìm kiếm provisioner cho chúng
 Khởi chạy ứng dụng Mesh nRF và chuyển đến  tab Máy scanning 
 Hình 3: Tìm kiếm thiết bị (tất cả các thiết bị chưa được cung cấp)
Bước 3: Cung cấp các thiết bị khác nhau
 Nhấp vào từng thiết bị và xác định nó:
Hình 4: Nhận dạng thiết bị
 Hình 5: Nhận dạng thiết bị
 Cung cấp thiết bị:
Hình 6: Cung cấp thiết bị
 Hình 7: Quá trình cung cấp đang diễn ra
  Bây giờ bạn sẽ thấy màn hình sau sau khi cấp phép bo mạch nRF52:
 Hình 8: Bộ phát triển nRF52 được cung cấp
 
 Lặp lại quy trình cho từng bóng đèn. Cuối cùng, bạn sẽ thấy những điều sau:
 Hình 9: Tất cả các thiết bị được cấp phép
Bước 4: Định cấu hình Máy khách và Máy Master
Bây giờ chúng ta đã cung cấp tất cả các thiết bị, chúng ta cần định cấu hình các máy khách và
máy Master khác nhau.
 Đầu tiên, hãy cấu hình công tắc đèn (nRF52x Mesh Switch). Nhấp vào thiết bị trong  chế độ
xem Mạng:
 Hình 10: Chế độ xem chính của Công tắc Mesh nRF5x
 Chúng tôi sẽ định cấu hình  Máy khách OnOff Chung như sau:
o Yếu tố 1:
 Hình 11: Ứng dụng khách OnOff chung # 1
o Yếu tố 2:
 Hình 12: Ứng dụng khách OnOff chung # 2
o Yếu tố 3:
 Hình 13: Ứng dụng khách OnOff chung # 3
o Sau khi hoàn tất, bạn sẽ thấy những điều sau trong giao diện chính của Node
chuyển đổi Mesh nRF5x:
 Hình 14: Cấu hình công tắc Mesh nRF5x
 Chúng tôi sẽ định cấu hình Máy Master OnOff Chung như sau:
o Định cấu hình  FM SYLVANIA A19  như sau:
 Hình 15: Bóng đèn Sylvania Filament chung Cấu hình máy Master OnOff
o Định cấu hình  SYLVANIA A19 CM  như sau:
 Hình 16: Bóng đèn đủ màu Sylvania Cấu hình máy Master OnOff chung
Bước 5: Kiểm tra mạng Bluetooth mesh
Bây giờ chúng tôi đã sẵn sàng để bắt đầu thử nghiệm thực tế của mạng. Đây là video cho thấy
quá trình thử nghiệm:
Hướng dẫn đầy đủ bằng video để cấp phép, định cấu hình và kiểm tra
Nếu bạn muốn làm theo các bước cấp phép, cấu hình và thử nghiệm qua video, bạn có thể làm
như vậy tại đây:
Tóm lược
Trong các bài đăng sau, chúng tôi sẽ thực hiện một số thử nghiệm mở rộng với mạng Bluetooth
mesh:
 Thêm nhiều đèn và các thiết bị Mesh khác.
 Thử nghiệm với phạm vi mạng và cách thêm thiết bị và xóa chúng ảnh hưởng đến phạm
vi.
Đừng quên nhập email của bạn bên dưới để luôn cập nhật tin tức BLE mới nhất cũng như được
thông báo khi các bài đăng và hướng dẫn mới trên blog được xuất bản.