STK, AT Command và luồng OTA cho thiết bị nhúng

1. Lệnh AT (AT Commands) là gì

AT viết tắt từ “ATtention” — tập lệnh văn bản chuẩn dùng để giao tiếp và điều khiển modem/thiết bị truyền thông, ra đời từ modem quay số Hayes những năm 1980, sau này mở rộng chuẩn hóa cho modem di động GSM (chuẩn 3GPP TS 27.007, 27.005).

Cách hoạt động: Máy tính/vi điều khiển gửi chuỗi ký tự bắt đầu bằng AT qua cổng serial (UART), USB, hoặc Bluetooth tới module modem (SIMCom, Quectel…), module thực thi và trả về OK hoặc ERROR.

Một số lệnh AT phổ biến (chuẩn công khai):

• AT — kiểm tra modem có phản hồi không.
• AT+CPIN? — kiểm tra trạng thái SIM.
• AT+CSQ — đo cường độ tín hiệu.
• AT+CMGS — gửi SMS.
• AT+CMGR — đọc SMS.
• ATD<số>; — thực hiện cuộc gọi.
• AT+COPS? — xem nhà mạng đang kết nối.

Đây là lớp giao tiếp giữa thiết bị chủ (host) và module modem — khác lớp hoàn toàn với STK. AT command do ứng dụng bên ngoài gửi tới modem để điều khiển modem; không phải cơ chế SIM tự thực thi lệnh.

2. STK (SIM Toolkit) là gì

STK (SIM Application Toolkit, ETSI TS 102.223 / GSM 11.14) là bộ lệnh cho phép chính con chip SIM chủ động điều khiển ngược lại điện thoại — ngược với luồng thông thường.

Ý tưởng thiết kế: SIM không chỉ lưu trữ thụ động, mà chạy applet nhỏ (Java Card) cung cấp dịch vụ tương tác — ví dụ menu “Dịch vụ nhà mạng” (tra số dư, nạp thẻ…) chính là STK menu do applet trên SIM tạo ra.

Các lệnh STK phổ biến:

• DISPLAY TEXT — hiển thị thông báo trên màn hình.
• SETUP MENU — tạo mục menu trên điện thoại.
• SEND SHORT MESSAGE — yêu cầu điện thoại gửi SMS thay cho SIM.
• SETUP CALL — yêu cầu điện thoại thực hiện cuộc gọi.
• PROVIDE LOCAL INFORMATION — lấy vị trí/Cell ID từ điện thoại trả về SIM.
• LAUNCH BROWSER — mở trình duyệt tới một URL.

Cơ chế giao tiếp: Điện thoại và SIM trao đổi qua giao thức APDU trên kênh vật lý ISO 7816. SIM gửi Proactive Command yêu cầu điện thoại hành động, điện thoại phản hồi qua Terminal Response.

Bảng phân biệt AT command và STK

3. Luồng bình thường: SIM Toolkit khi tra cứu số dư

Ví dụ kinh điển của STK hoạt động hợp pháp hàng ngày:

1. Bật máy, SIM khởi động — SIM gửi lệnh SETUP MENU (Proactive Command) ngay khi có nguồn.
2. Hiển thị menu dịch vụ — Điện thoại render menu SIM (mục “Dịch vụ SIM”/“SIM Toolkit”).
3. Người dùng chọn mục — Điện thoại gửi gói ENVELOPE (Menu Selection) về SIM báo người dùng chọn mục nào.
4. SIM xử lý yêu cầu — SIM gửi lệnh Proactive Command SEND SHORT MESSAGE yêu cầu điện thoại gửi hộ tin nhắn tra cứu.
5. Gửi SMS tới tổng đài — Điện thoại gửi SMS tới tổng đài dịch vụ, nhận phản hồi số dư.
6. Hiển thị kết quả — Tin nhắn phản hồi đưa vào giao diện, người dùng thấy số dư trên màn hình.

Về AT command trong luồng này: Hoàn toàn không xuất hiện — vì AT command chỉ tồn tại khi có thiết bị host bên ngoài giao tiếp với module modem rời qua UART/USB. Smartphone tự giao tiếp trực tiếp hệ điều hành ↔ baseband bằng driver nội bộ, không qua AT command.

Ví dụ AT command chỉ xuất hiện khi có module rời (ví dụ máy chấm công dùng SIM7600 tự gửi SMS báo cáo):

1. Host gửi AT+CMGF=1 (chế độ text).
2. Gửi AT+CMGS="0987xxxxxx" kèm nội dung tin nhắn.
3. Module tự đóng gói và gửi SMS qua mạng GSM.
4. Module trả về OK xác nhận.

4. Luồng nhà mạng gửi lệnh OTA tới SIM

1. Nền tảng OTA của nhà mạng — Soạn lệnh, ký bằng khóa OTA riêng cho từng SIM (sinh từ khóa gốc Master Key + ICCID qua thuật toán diversification, giống nguyên lý sinh Ki).
2. Đóng gói SMS nhị phân — Gửi qua SMSC bằng giao thức SMPP (Short Message Peer-to-Peer).
3. Định tuyến qua mạng lõi — SMSC tra HLR/HSS để biết trạm phát sóng đang phục vụ thuê bao.
4. Điện thoại nhận gói tin — Baseband nhận diện SMS Class 2 tới Port 2048, chuyển thẳng tới SIM qua APDU (thực chất đóng gói thành lệnh ENVELOPE (SMS-PP DOWNLOAD)).
5. SIM xác thực và thực thi — SIM dùng khóa OTA riêng kiểm tra chữ ký/MAC và bộ đếm chống replay, rồi thực thi (cập nhật APN, đổi số trung tâm SMS, cài applet mới…).
6. Gửi phản hồi xác nhận (PoR) — SIM dùng Proactive Command SEND SHORT MESSAGE gửi SMS phản hồi về nhà mạng xác nhận đã áp dụng lệnh.

5. STK hay AT — làm rõ vị trí của OTA

Trong khung STK có hai chiều lệnh:

OTA không phải cơ chế tách biệt — nó dùng đúng “đường ống” APDU/STK sẵn có, chỉ là gói tin cụ thể (SMS-PP DOWNLOAD) đi qua chiều Envelope. Khi SIM cần gửi PoR về nhà mạng, nó quay sang dùng Proactive Command SEND SHORT MESSAGE — chính là cơ chế trong ví dụ tra cứu số dư.

AT command hoàn toàn không xuất hiện trong luồng SIM Toolkit/OTA — vì AT command chỉ tồn tại khi có thiết bị host ngoài giao tiếp với module modem rời qua UART/USB.

Tóm gọn: STK không phải một lệnh đơn lẻ mà là cả bộ khung giao thức hai chiều (Proactive + Envelope); OTA là một loại nội dung cụ thể được truyền qua chiều Envelope của khung đó, còn AT command là một thế giới hoàn toàn khác — chỉ dùng khi có thiết bị host rời điều khiển modem từ bên ngoài.

6. Có tích hợp được luồng OTA bằng AT cho thiết bị nhúng kho hàng không?

Không thể “tích hợp” theo nghĩa gộp chung — khóa OTA thuộc sở hữu và kiểm soát của nhà mạng; doanh nghiệp triển khai IoT không có quyền truy cập khóa đó, dù đang sở hữu SIM và trả cước. Kênh SIM Toolkit (OTA) và kênh AT Command không giao tiếp trực tiếp với nhau — hai thế giới độc lập trong cùng một con chip modem.

Giải pháp thực tế: tự xây “OTA riêng” ở tầng ứng dụng, hoàn toàn nằm trong kênh AT Command, không đụng đến SIM Toolkit.

Hướng 1 — Kết nối dữ liệu thường trực (khuyến nghị cho kho hàng)

Module modem hỗ trợ sẵn client MQTT/HTTP trong tập lệnh AT:

• AT+CGDCONT — cấu hình APN.
• AT+NETOPEN / AT+CIICR — mở kết nối dữ liệu.
• AT+CMQTTSTART, AT+CMQTTCONNECT, AT+CMQTTSUB — kết nối và subscribe topic MQTT trên server doanh nghiệp.
• Server đẩy lệnh cấu hình xuống topic, module nhận qua AT+CMQTTRCV, vi điều khiển xử lý.

Đây là dựng hạ tầng OTA riêng của doanh nghiệp, dùng đúng đường truyền dữ liệu di động, nhưng khóa xác thực/mã hóa (TLS, token) tự quản lý — không liên quan khóa OTA của nhà mạng.

Hướng 2 — SMS làm tín hiệu đánh thức (phù hợp thiết bị tiết kiệm pin)

Vì sao dùng SMS thay vì giữ kết nối thường trực: Thiết bị dùng pin (máy quét cầm tay, cảm biến kệ hàng, thẻ theo dõi pallet…) phần lớn thời gian ở chế độ ngủ sâu. Giữ kết nối dữ liệu (MQTT/HTTP) liên tục tốn điện vì phải duy trì phiên PDP context và gửi keep-alive định kỳ. SMS là cách đánh thức tiết kiệm năng lượng hơn — mạng GSM vẫn “đánh thức” được module ngay cả khi module ở chế độ tiết kiệm điện.

Luồng chi tiết:

1. Server phát hiện cần cập nhật khẩn — Gửi SMS trigger tới số thiết bị, nội dung ngắn kèm chữ ký, ví dụ: CMD:CFG_UPDATE;TS:1755150000;SIG:a3f9c1...

2. Module nhận SMS, báo URC, đánh thức MCU:

   • Module cấu hình sẵn AT+CNMI=2,1,0,0,0 — khi có SMS mới, tự gửi URC dạng +CMTI: "SM",<index> ra UART.
   • Nếu MCU đang ngủ sâu, chân RI (Ring Indicator) trên module tự chuyển trạng thái điện áp khi có SMS đến, dùng làm ngắt phần cứng đánh thức MCU.

3. MCU đọc và xác minh SMS:

   • MCU dậy, gửi AT+CMGF=1 (chế độ text) rồi AT+CMGR=<index> để đọc nội dung và số người gửi.
   • Kiểm tra hai lớp: (a) số gửi có nằm trong whitelist server hợp lệ; (b) chữ ký SIG có khớp HMAC tính từ nội dung lệnh + khóa bí mật chia sẻ trước (pre-shared key) giữa firmware và server.
   • Kiểm tra timestamp TS — nếu lệch quá ngưỡng cho phép (ví dụ 5 phút), từ chối để chống replay attack.

4. Mở kết nối dữ liệu nếu hợp lệ:

   • Mở PDP context: AT+CGDCONT=1,"IP","<apn>" → AT+CGACT=1,1 (hoặc AT+CIICR với dòng cũ hơn).
   • Dùng bộ lệnh HTTP: AT+HTTPINIT → AT+HTTPPARA="URL","https://server-cua-ban/api/config?device_id=..." → AT+HTTPACTION=0 (GET), qua HTTPS.

5. Server trả về cấu hình đầy đủ — Xác thực token thiết bị (lớp xác thực độc lập khác với chữ ký SMS), trả về JSON chứa cấu hình/lệnh chi tiết.

6. MCU áp dụng và dọn dẹp:

   • Đọc dữ liệu bằng AT+HTTPREAD, đóng phiên AT+HTTPTERM.
   • Xóa SMS đã xử lý bằng AT+CMGD=<index> tránh đầy bộ nhớ SIM.
   • MCU quay lại chế độ ngủ.

Cân nhắc thêm: SMS liên mạng có độ trễ vài giây đến vài phút, không đảm bảo real-time. Nếu nghiệp vụ cần phản hồi tức thời (ví dụ khóa cửa kho ngay lập tức), nên kết hợp: giữ kết nối MQTT thường trực cho lệnh khẩn cấp thực sự, SMS chỉ dùng cho thiết bị ở xa vùng phủ sóng yếu hoặc cần tiết kiệm pin tối đa.

7. Phần vận chuyển SMS vẫn đi qua nhà mạng

Phần vận chuyển SMS trong Hướng 2 100% vẫn đi qua hạ tầng nhà mạng — SMS là dịch vụ do nhà mạng vận hành hoàn toàn (SMSC, định tuyến, tính cước). Chỉ có nội dung và cách xử lý sau khi tin nhắn đến tay thiết bị là do doanh nghiệp tự kiểm soát.

Điểm giống nhau giữa OTA và Hướng 2 — cùng đi qua carrier

• Đi qua SMSC của nhà mạng.
• Định tuyến qua mạng lõi (HLR/HSS tra vị trí thuê bao) như một SMS thường.
• Chịu cước SMS (văn bản hay nhị phân).
• Phụ thuộc độ trễ/độ tin cậy mạng GSM (không đảm bảo real-time).

Điểm khác nhau — ai xử lý và ai xác thực nội dung

Ý nghĩa thực tế

Để server gửi SMS trigger, cần một trong hai cách:

• Gắn một SIM/modem gửi SMS ở phía server (module GSM riêng cắm vào máy chủ/gateway).
• Dùng dịch vụ SMS Gateway/API của nhà mạng hoặc bên thứ ba (SMS Brandname tại Việt Nam, hoặc nền tảng quốc tế) — gửi qua API HTTP.

Vì SMS này không được nhà mạng xác thực nội dung (khác OTA — nơi SIM tự kiểm tra chữ ký trước khi tin), về lý thuyết bất kỳ ai biết số điện thoại SIM trên thiết bị cũng gửi được SMS y hệt định dạng lệnh. Đây là lý do lớp xác thực HMAC + whitelist ở firmware là bắt buộc, chứ không phải tùy chọn — vì bản thân kênh vận chuyển (nhà mạng) không đảm bảo tính toàn vẹn nội dung giúp bạn như OTA làm cho SIM.

Tài liệu tổng hợp mang tính kỹ thuật/tham khảo cho việc thiết kế hệ thống IoT nhúng dùng module modem di động (SIMCom, Quectel…) trong bài toán quản lý kho hàng.