Bài toán truyền thông trong IoT chủ yếu liên quan tới những vấn đề phát sinh trong việc truyền thông giữa 3 nhóm: thiết bị, gateways và Cloud. Cụ thể hơn thì quá trình truyền thông đó chủ yếu liên quan tới trao đổi message(thông điệp). Việc trao đổi message thường tuân theo một mô hình truyền thông nhất định. Và với mỗi mô hình truyền thông thì cách trao đổi message lại khác nhau đôi chút. Để lựa chọn được giải pháp truyền thông phù hợp cho sản phẩm IoT, chúng ta nên xem xét đầy đủ các mô hình truyền thông IoT.
Việc làm tuyển dụng iot không cần kinh nghiệm
Dựa vào cách thức trao đổi message, ta có thể chia các mô hình truyền thông IoT thành 4 nhóm như sau:
- Telemetry: dữ liệu (message) di chuyển 1 chiều từ thiết bị đến hệ thống. Mục đích là gửi trạng thái của thiết bị lên phía hệ thống.
- Inquiry: gửi các request của device lên hệ thống, các request này liên quan tới việc thu thập các thông tin mà thiết bị hiện tại không thu thập được. Các thông tin đó được dùng để kích hoạt một sự kiện nào đó được mô tả từ trước.
- Command: gửi mệnh lệnh từ hệ thống tới thiết bị hoặc 1 nhóm thiết bị để bắt các thiết bị đó thực thi một công việc cụ thể, đồng thời yêu cầu trả về trạng thái thực thi công việc
- Notification: gần giống với Telemetry, ở mô hình này, thông tin cũng di chuyển 1 chiều, nhưng là từ hệ thống tới các thiết bị (chiều ngược lại so với Telemetry),
Ta có thể hình dung một cách trực quan về 4 mô hình này như sau:
Mỗi mô hình trên có thể cần đến việc lưu trữ dữ liệu. Khi đó, các cơ chế store & forward (lưu trữ và chuyên tiếp) sẽ được tận dụng (ví dụ: hàng đợi, topic/subscription trong các broker). Nếu bên gửi và bên nhận cùng online, ta có thể dùng các giải pháp direct message.
Cơ chế store & forward thường được áp dụng trong mô hình Command. Bởi vì khi gửi lệnh cho một device thì device đó có thể không online… Tình huống này lại phát sinh ra một giải pháp khác, đó là sử dụng thuộc tính TTL cho message (Time To Live). Khi device trở lại trạng thái online, TTL giúp device tránh được việc thực thi các lệnh quá cũ. Direct message thì lại được áp dụng cho mô hình Telemetry (mặc dù đôi khi lưu trữ các dữ liệu gửi bằng mô hình Telemetry vẫn có ích).
#1 Mô hình Telemetry
Giao thức HTTP có thể implement mô hình này theo 2 cách: hoạt động như một client, gửi PUT/POST request chứa các thông tin trạng thái cần cập nhật sang một hệ thống khác hoặc hoạt động như một server, nhận GET requests từ các hệ thống khác để thu thập dữ liệu. Trong bất kì trường hợp nào, việc implement này xoay quanh 2 hành động chính là request / reply.
Có 2 hạn chế đáng chú ý ở đây
HTTP là giao thức text-based, dài dòng và không hỗ trợ QoS – Quality of Service.
Khi hoạt động với vai trò là server, HTTP gặp vấn đề về kết nối với thiết bị trong mạng nếu có NAT hoặc roaming(mạng điện thoại di động)
Giao thức triển khai mô hình Telemetry phổ biến nhất chính là MQTT. MQTT implement luôn cả mô hình publish/subscribe. Với MQTT, các device được xem như publisher – người xuất bản. Nội dung xuất bản là các dữ liệu mà device đó thu thập hoặc xử lý được. Đích đến của các dữ liệu đó là các broker. Để gom nhóm các dữ liệu thành 1 “kênh”, MQTT sử dụng khái niệm topic. Các hệ thống/thiết bị khác muốn lấy thông tin thì sẽ hoạt động như subscriber – người theo dõi. Hành động theo dõi này và các message tương ứng được giới hạn theo từng topic.
MQTT hỗ trợ đầy đủ các QoS level.
Nói về nhược điểm, MQTT không hỗ trợ xử lý logic. Vì không hỗ trợ xử lý logic nên một broker có thể bị quá tải (flooded) bởi các message mà không làm cách nào để dừng nhận các message này.
Một giao thức đáng chú ý khác cũng implement mô hình này, đó là AMQP. AMQP cung cấp cả 2 phương pháp trao đổi message là request/reply và publish/subscribe.
So với MQTT, AMQP có một lợi thế lớn. Đó là khả năng thiết đặt một luồng logic điều khiển cho 2 mức khác nhau: mức byte và mức message.
#2 Inquiry
Sử dụng HTTP để implement mô hình này khá đơn giản vì bản thân giao thức HTTP đã hoạt động dưới hình thức gửi request – nhận response. Do đó, khi implement theo mô hình Inquiry, việc trao đổi thông điệp với HTTP chỉ xoay quanh các GET request từ device lên hệ thống để lấy thông tin.
Việc implement MQTT theo mô hình Inquiry khó khăn hơn vì ta sẽ phải define các ngữ nghĩa mới ở tầng ứng dụng để đảm bảo việc truyền thông giữa device và hệ thống tuân thủ đúng mô hình Inquiry.
Device cần subscribe một topic để nhận thông tin. Tuy nhiên không phải là nhận một cách thụ động! Khi nào device có nhu cầu thì device mới gửi request lên hệ thống. Và khi đó thì device lại đóng vai trò là publisher. Vì vậy, với giao thức MQTT, ta cần tạo thêm một mối tương quan trong hành động gửi request và reply tại tầng ứng dụng.
Khác với MQTT và HTTP, AMQP đáp ứng tốt yêu cầu của việc implement mô hình Inquiry.
Điều đáng chú ý là các AMQP message (message được tạo theo chuẩn của giao thức AMQP) đều chứa nhiều thông tin hữu ích (dưới dạng metadata). Đầu tiên có thể kể đến message ID và thuộc tính reply-to. Do đó, khi device gửi yêu cầu cho hệ thống, nó có thể đưa thêm thông tin về địa điểm nhận message (address). Hệ thống sẽ hồi đáp bằng một message khác kèm theo ID tương ứng (có thể sử dụng message ID của request).
Một điểm mạnh của AMQP khi implement mô hình Inquiry là tính asynchronous của giao thức này. Nhờ đặc tính asynch vốn có, các thông điệp hồi đáp từ phía hệ thống có thể đến device theo bất kỳ thứ tự nào mà không làm mất đi sự tương quan của message hồi đáp với request yêu cầu nó.
#3 Mô hình Command
Mô hình này hơi ngược so với Inquiry, bên bắt đầu quá trình truyền thông lại là hệ thống chứ không phải device.
Với giao thức HTTP, mô hình này có thể implement bằng cách cho device nhận một trong 2 vai trò: client hoặc server. Nếu device hoạt động như một server, hệ thống sẽ gửi POST request và chờ đợi response tương ứng (synchronous) từ phía device để biết quá trình thực thi mệnh lệnh có diễn ra suôn sẻ không… Nếu device hoạt dộng như client, device sẽ gửi GET request lên hệ thống để hỏi xem có mệnh lệnh nào cần thực thi không. Nếu không có lệnh nào, client sẽ phải đợi (synchronous). Sau khi nhận và thực thi lệnh, device sẽ gửi POST request lên hệ thống để thông báo kết quả thực thi mệnh lệnh.
Với giao thức MQTT, nếu muốn implement theo mô hình Command, ta cũng phải đưa ra một số ngữ nghĩa mới ở tầng ứng dụng.
Bản thân MQTT không hỗ trợ kiểu truyền thông request/reply nên ta cần đưa ra một số ngữ nghĩa mới như: thiết bị subscribe một topic để nhận command, hệ thông sẽ gửi command vào topic đó. Phần payload của command (từ phía hệ thống) sẽ phải chứa request ID. Sau khi thực thi mệnh lệnh, device publish kết quả kèm theo request ID tương ứng.
Nếu device offline, ta có thể dùng “retain” flag, nhờ đó, mệnh lệnh cuối cùng từ phía hệ thống sẽ được chuyển đến khi device online trở lại.
Một lần nữa, AMQP lại tỏ ra vượt trội hơn khi implement mô hình Command.
Hệ thống có thể gửi message chứa mệnh lệnh, kèm theo message ID và thuộc tính reply-to. Sau khi thực thi mệnh lệnh, device gửi kết quả trong một message khác, kèm theo ID tương ứng với message ID của mệnh lệnh từ phía hệ thống. Message từ phía device sẽ được gửi đúng về địa chỉ mà hệ thống mong muốn nhờ thuộc tính reply-to. Việc truyền thông này cũng diễn ra không đồng bộ (asynchronous), do đó hệ thống có thể gửi hàng loạt mệnh lệnh mà vẫn nhận được response tương ứng của từng mệnh lệnh đã gửi.
Nếu device offline và ta chỉ muốn nó thực thi mệnh lệnh mới nhất từ phía hệ thống? Để giải quyết tình huống này, hãy sử dụng thuộc tính TTL (Time To Live) cho các mệnh lệnh gửi đi từ hệ thống.
#4 Mô hình Notification
Mô hình này ngược với Telemetry, luồng lưu thông message thì lại gần giống với mô hình Command, tuy nhiên việc trao đổi message theo mô hình Notification không cần reply cho mỗi message nhận được.
Với giao thức HTTP, device nhận notification từ hệ thống. Trong quá trình truyền thông với device, hệ thống hoạt động như một server (hệ thống sẽ gửi POST request) hoặc client (hệ thống sẽ gửi GET request). Nếu hệ thống hoạt động như một client, nó chỉ có thể reply khi notification từ phía thiết bị đã sẵn sàng (long polling) hoặc reply ngay lập tức. (device has to poll the server aditional times). Tất nhiên, khi sử dụng HTTP, các vấn đề liên quan tới NAT và roaming đưa ra ở đầu bài viết là không thể tránh khỏi.
Với giao thức MQTT, device sẽ subscribe một topic. Server publish notification vào topic đó. Mọi thứ diễn ra suôn sẻ vì mô hình Notification này rất gần với cơ chế publish/subscribe của MQTT. Tuy nhiên, nếu ta không define thêm phần logic xử lý ở tầng ứng dụng, device có thể bị quá tải do liên tục nhận các notification từ topic đang subscribe.
Cuối cùng, với AMQP, device vừa có thể nhận notificaiton vừa có thêm phần logic xử lý giúp device ngừng nhận notification khi không đủ khả năng xử lý.
Nguồn: Techtalk Via Techmaster
