Internet vạn vật, hay Mạng lưới vạn vật kết nối Internet hoặc là Mạng lưới thiết bị kết nối Internet (Internet of Things - IoT) là một liên mạng, trong đó các thiết bị, phương tiện (thiết bị kết nối, thiết bị thông minh), và các trang thiết bị khác được nhúng với các bộ phận điện tử, phần mềm, cảm biến, cơ cấu chấp hành cùng với khả năng kết nối mạng máy tính giúp cho các thiết bị này có thể thu thập và truyền tải dữ liệu. [1].
Hình 1. Mô tả tương tác của hệ thống IoT
Hệ thống IoT cho phép vật được cảm nhận hoặc được điều khiển từ xa thông qua hạ tầng mạng hiện hữu, tạo cơ hội cho thế giới thực được tích hợp trực tiếp hơn vào hệ thống điện toán, hệ quả là hiệu năng, độ tin cậy và lợi ích kinh tế được tăng cường bên cạnh việc giảm thiểu sự can dự của con người.
Một số đặc điểm chung của Mạng lưới IoT:
- IoT cho phép đối tượng vật lý có thể xem, nghe, suy nghĩ và thực hiện công việc bằng cách cho chúng “nói chuyện” với nhau, chia sẻ thông tin và phối hợp các quyết định.
- Ứng dụng cần phải phát triển tương ứng để phù hợp với nhu cầu thị trường và nhu cầu khách hàng. Hơn nữa, thiết bị cần phải được phát triển để phù hợp với yêu cầu về sự sẵn có bất cứ nơi nào và bất cứ lúc nào.
- Các giao thức mới được yêu cầu cho khả năng tương thích giao tiếp giữa các thiết bị khác loại với nhau.
- Kiến trúc Internet cần phải được sửa đổi để phù hợp với những thách thức IoT do số lượng lớn của các đối tượng kết nối với Internet. Vì vậy, sử dụng một không gian địa chỉ lớn (ví dụ: IPv6) trở nên cần thiết để đáp ứng nhu cầu của khách hàng cho các đối tượng thông minh.
- Kiến trúc tiêu chuẩn để tạo ra xương sống cho IoT.
- An ninh bảo mật và sự riêng tư là yêu cầu quan trọng cho IoT do sự không đồng nhất vốn có của đối tượng kết nối Internet và khả năng quản lý các đối tượng vật lý.
- Điều khiển và giám sát của IoT đảm bảo việc cung cấp các dịch vụ chất lượng cao cho khách hàng với chi phí hiệu quả. (Hình 2 và 3)
| |
1. Kiến trúc của IoT:
Kiến trúc IoT có thể chia ra làm 5 tầng cơ bản sau:
1.1. Tầng đối tượng
Lớp đầu tiên, các đối tượng (thiết bị) hoặc lớp nhận thức, đại diện cho các bộ cảm biến vật lý và cơ cấu chấp hành của IoT mà mục đích là để thu thập và xử lý thông tin.
Cơ chế plug-and-play tiêu chuẩn cần phải được sử dụng bởi lớp nhận thức để cấu hình các đối tượng không đồng nhất [3], [4].
Các dữ liệu lớn tạo ra bởi các IoT được đề xuất tại lớp này.
1.2. Tầng khái quát đối tượng
- Truyền dữ liệu từ lớp đối tượng đến đến lớp quản lý dịch vụ thông qua các kênh bảo mật.
- Dữ liệu có thể được chuyển giao thông qua các công nghệ như RFID, 3G, GSM, UMTS, WiFi, Bluetooth Low Energy, hồng ngoại, ZigBee,…
- Các chức năng khác như điện toán đám mây và quy trình quản lý dữ liệu được xử lý ở lớp này [3].
1.3. Tầng quản lý dịch vụ
- Lớp này cho phép các lập trình viên ứng dụng IoT làm việc với các đối tượng không đồng nhất mà không cần xem xét đến nền tảng phần cứng cụ thể.
- Ngoài ra, lớp này xử lý dữ liệu nhận được, ra quyết định và cung cấp các dịch vụ cần thiết trên giao thức mạng dây [4], [5], [6].
1.4. Tầng ứng dụng
- Lớp ứng dụng cung cấp các dịch vụ theo yêu cầu của khách hàng.
- Tầm quan trọng của lớp này cho IoT là nó có khả năng cung cấp dịch vụ thông minh chất lượng cao để đáp ứng nhu cầu của khách hàng. Các lớp ứng dụng bao gồm nhiều thị trường như nhà thông minh, tòa nhà thông minh, giao thông, tự động hóa công nghiệp và y tế thông minh [3], [4], [7].
1.5. Tầng kinh doanh (dịch vụ)
- Lớp quản lý IoT tổng thể các hoạt động hệ thống và dịch vụ.
- Trách nhiệm của lớp này là để xây dựng một mô hình kinh doanh, biểu đồ, sơ đồ, dựa trên các dữ liệu đã nhận từ lớp ứng dụng.
- Nó cũng là nghĩa vụ để thiết kế, phân tích, thực hiện, đánh giá, giám sát và phát triển hệ thống liên quan đến IoT.
- Hỗ trợ việc phân tích Big data.
- Giám sát và quản lý bốn lớp cơ bản.
- So sánh đầu ra của mỗi lớp với sản lượng dự kiến để nâng cao dịch vụ và duy trì sự riêng tư của người sử dụng [4], [5].
Bài báo sẽ tập trung giới thiệu các quy tắc chuẩn dành cho việc biểu diễn dữ liệu, chứng thực và phát tín hiệu, những việc cần thiết để gửi thông tin qua các kênh truyền thông trong 2 tầng liên quan đến việc triển khai các dịch vụ trong các thiết kế ứng dụng về IoT.
2. Các chuẩn truyền thông của tầng ứng dụng và tầng khám phá dịch vụ của IoT
Chuẩn chung cho IoT được đưa ra bởi World Wide Web Consortium (W3C), Internet Engineering Task Force (IETF), EPCglobal, Institute of Electrical and Electronics Engineers (IEEE) và European Telecommunications Standards Institute (ETSI).
2.1. Chuẩn truyền thông trong tầng ứng dụng
Các giao thức để trao đổi thông tin trong tầng ứng dụng rất đa dạng, mỗi một loại có những đặc điểm khác nhau, như:
- MQTT là giao thức truyền thông N-N để chuyển các thông điệp giữa publisher và subscriber thông qua broker trung tâm. Còn CoAP là giao thức 1-1 để chuyển trạng thái thông tin giữa client và server. MQTT tạo kết nối TCP lâu dài đến đến broker. Client và server trong CoAP đều gửi và nhận các gói tin UDP.
- Đánh giá hiệu suất của XMPP trên HTML5 WebSocket cho kết quả XMPP là một lựa chọn tốt cho các ứng dụng web yêu cầu giao tiếp thời gian thực. Sử dụng số trung bình của các thông điệp trao đổi giữa khách hàng và máy chủ trong một khoảng thời gian cụ thể để đánh giá hiệu suất của AMQP và REST. Theo một số lượng lớn các trao đổi tin nhắn, AMQP chứng minh kết quả tốt hơn so với các dịch vụ web RESTful.
- Các thử nghiệm đánh giá sự triển khai của DDS chỉ ra giao thức có quy mô tốt khi số lượng các node mạng tăng lên.
Mỗi giao thức truyền thông không phải là chuẩn duy nhất cho các thiết kế IoT mà nó sẽ thực hiện tốt trong những ứng dụng cụ thể vì thế tùy từng điều kiện, trường hợp để áp dụng. Sau đây là các phần chi tiết về kiến trúc đặc trưng và hoạt động của các chuẩn kết nối trong tầng ứng dụng của IoT.
2.1.1. Giao thức ứng dụng ràng buộc CoAP (Constrained Application Protocol)
CoAP là một giao thức truyền tải tài liệu theo mô hình client/server trên Internet tương tự như giao thức HTTP nhưng được thiết kế cho các thiết bị ràng buộc. Giao thức này hỗ trợ một giao thức one-to-one để chuyển đổi trạng thái thông tin giữa client và server [8].
Các gói CoAP nhỏ hơn nhiều so với dòng HTTP TCP. Các trường bit và ánh từ chuỗi các số nguyên được sử dụng rộng rãi để tiết kiệm không gian. Các gói rất đơn giản có thể được tạo ra và phân tích tại chỗ mà không tốn thêm RAM trong các thiết bị bị hạn chế.
CoAP sử dụng UDP (User Datagram Protocol), không hỗ trợ TCP, ngoài ra còn hỗ trợ địa chỉ broadcast và multicast, truyền thông CoAP thông qua các datagram phi kết nối (connectionless) có thể được sử dụng trên các giao thức truyền thông dựa trên các gói.
UDP có thể dễ dàng triển khai trên các vi điều khiển hơn TCP nhưng các công cụ bảo mật như SSL/TSL không có sẵn, tuy nhiên ta có thể sử dụng Datagram Transport Layer Security (DTLS) để thay thế.
CoAP theo mô hình client/server, client gửi yêu cầu đến máy chủ, sau đó máy chủ gửi lại phản hồi. Client có thể GET, PUT, POST và DELETE các tài nguyên.
CoAP có tính linh động và hỗ trợ đàm phán nội dung. Điều này cho phép client và máy chủ có thể nâng cấp, thêm mới một cách độc lập mà ko ảnh hưởng gì đến phía còn lại.
CoAP đưa ra các yêu cầu quan sát tài nguyên. Cả hai bên đều có thể tác động hoặc xóa các yêu cầu quan sát. Khi cờ quan sát được thiết lập, máy chủ vẫn có thể tiếp tục hồi đáp sau khi các dữ liệu đã truyền đi.
Với CoAP, máy chủ cung cấp một hệ thống các tài nguyên cho phép client khám phá tài nguyên và các phương tiện truyền thông.
Trong CoAP một nút cảm biến thường là một máy chủ. Chúng có khả năng nhận các gói tin gửi đến để hoạt động đúng đằng sau NAT, thiết bị đầu tiên phải gửi yêu cầu đến máy chủ, như được thực hiện trong LWM2M, cho phép các router liên kết chúng lại.
2.1.2. Giao thức giao vận tầm xa MQTT (Message Queuing Telemetry Transport)
MQTT (Message Queuing Telemetry Transport) là một giao thức gửi dạng publish/subscribe sử dụng cho các thiết bị Internet of Things với băng thông thấp, độ tin cậy cao và khả năng được sử dụng trong mạng lưới không ổn định.
Do giao thức MQTT sử dụng các tin nhắn gọn nhẹ nên MQTT thường được sử dụng để liên lạc giữa các thiết bị. Ban đầu, MQTT chỉ được sử dụng cho các mạng SCADA. Với sự phát triển của IoT thì MQTT đang dần trở nên phổ biến do nhu cầu kết nối giữa nhiều thiết bị với nhau. [9]
MQTT gồm 2 thành phần chính là Broker và Clients:
- Broker: Đóng vai trò như một nơi trung tâm hay một Hub - điểm giao nhau của tất cả các kết nối đến Clients. Broker sẽ nhận thông điệp/ tin nhắn (message) từ publisher, sắp xếp chúng rồi chuyển thông điệp đến một địa chỉ cụ thể.
- Clients: Bất kỳ publisher hoặc subscriber nào kết nối với broker tập trung qua mạng đều được coi là khách hàng. Điều quan trọng cần lưu ý là có các máy chủ và máy khách trong MQTT. Cả publisher và subscriber đều được gọi là khách hàng vì họ kết nối với dịch vụ tập trung, khách hàng có thể liên tục hoặc tạm thời. Khách hàng liên tục duy trì một phiên với broker trong khi khách hàng tạm thời không được broker theo dõi. Khách hàng thường kết nối với broker thông qua thư viện và SDK có sẵn cho C, C++, Go, Java, C#, PHP, Python, Node.js và Arduino.
- Publisher: Mỗi Client sẽ nhận được dữ liệu khi bất kỳ trạm nào khác gửi dữ liệu và các kênh đăng ký. Khi mỗi client gửi dữ liệu tới kênh đó, gọi là Publisher.
- Subscriber: Publisher sẽ gửi tin báo tới broker, các nhà subscriber sẽ đăng ký đến và theo dõi, nhận bản tin.
Ưu điểm của MQTT: Giao thức MQTT cho phép hệ thống SCADA truy cập dữ liệu IoT. MQTT mang lại nhiều lợi ích:
- Chuyển thông tin hiệu quả;
- Tăng khả năng mở rộng;
- Giảm tiêu thụ băng thông mạng;
- Giảm tốc độ cập nhật xuống;
- Tối đa hóa băng thông có sẵn;
- Chi phí và thời gian phát triển thấp;
- An toàn và bảo mật.
2.1.3. Giao thức XMPP (Extensible Messaging and Presence Protocol )
Được đề xuất bởi IETF instant messaging (IM). Extensible Messaging and Presence Protocol (XMPP), trước đây là Jabber, là giao thức mở và dựa trên nền tảng XML dùng trong nhắn tin nhanh (instant messaging) và thông tin hiện diện trực tuyến (presence information). Theo Hội Tiêu chuẩn XMPP (XMPP Standards Foundation, trước đây là Jabber Software Foundation, JSF), phần mềm dựa trên Jabber được triển khai tại hàng ngàn máy phục vụ trên Internet và được hơn 10 triệu người trên khắp thế giới sử dụng [10].
Jeremie Miller khởi đầu dự án vào năm 1998; phiên bản đầu tiên được công bố vào tháng năm 2000. Sản phẩm chính của dự án là jabberd, một trình phục vụ (server) để từ đó các trình khách (client) kết nối đến và trao đổi tin nhắn. Trình phục vụ này có thể tạo mạng Jabber riêng tư (như sau tường lửa) hoặc có thể tham gia vào mạng Jabber công cộng toàn cầu. Đặc tính cốt lõi của Jabber là bản chất của hệ thống tin nhắn nhanh phân tán và việc sử dụng streaming XML.
Điểm đặc trưng của hệ thống Jabber là nó có các transport, còn được gọi là gateway (cổng), cho phép người dùng truy cập mạng với các giao thức khác - như AIM và ICQ (dùng OSCAR), MSN Messenger và Windows Messenger (dùng Dịch vụ nhắn tin.NET - .NET Messenger Service), Yahoo! Messenger, SMS hay E-mail. Không như các trình khách đa giao thức như Trillian hay Gaim, việc truy cập đến các giao thức khác được Jabber cung cấp ở cấp độ trình phục vụ bằng cách truyền thông tin qua các dịch vụ cổng đặc biệt chạy trên một máy tính ở xa. Bất cứ người dùng nào cũng có thể đăng ký với một trong các cổng này bằng cách cung cấp thông tin cần thiết để đăng nhập vào mạng đó, và từ đó có thể liên lạc với người dùng của mạng khác như thể họ là người dùng Jabber. Điều này có nghĩa là bất cứ trình khách nào hỗ trợ đầy đủ giao thức Jabber đều có thể được dùng để truy cập bất cứ mạng nào có cổng kết nối, mà không cần thêm dòng mã lệnh nào từ trình khách.
Nền tảng của giao thức Jabber, hiện được Tổ chức Phần mềm Jabber quản lí, đã được IETF chấp nhận làm giao thức standards-track dưới tên XMPP, với RFC 3920. Nó thường được xem là đối thủ cạnh tranh với SIMPLE, dựa trên giao thức SIP, để làm giao thức chuẩn cho nhắn tin nhanh và thông báo hiện diện; tuy nhiên, thiết kế của XMPP được nhắm đến việc cung cấp các tiện ích trình trung gian (middleware) liên ứng dụng và mục đích tổng quát.
Người dùng Jabber được xác định bằng tên người dùng và tên máy phục vụ, cách nhau bằng dấu @. Căn cước này được gọi là Jabber ID hay JID.
2.1.4. Giao thức AMQP (Advanced Message Queuing Protocol)
AMQT là một chuẩn mở giao thức lớp ứng dụng cho IoT tập trung vào môi trường theo định hướng truyền tải thông điệp. AMQP đòi hỏi một giao thức truyền tải tin cậy như TCP để trao đổi tin nhắn. Bằng việc xác định wire-level protocol, triển khai AMQP là có thể tương tác với nhau. Truyền thông được xử lý bởi hai thành phần chính: Trao đổi và xếp hàng thông điệp. Trao đổi được sử dụng để định tuyến các thông điệp đến hàng đợi thích hợp. Định tuyến giữa trao đổi và hàng đợi tin nhắn được dựa trên một số nguyên tắc và điều kiện được xác định trước. Tin nhắn có thể được lưu trữ trong hàng đợi tin nhắn và sau đó được gửi cho người nhận. Ngoài kiểu truyền thông point-to-point, AMQP cũng hỗ trợ các mô hình truyền thông publish/subscribe [11].
2.1.5. Giao thức Dịch vụ phân phối dữ liệu DDS (Data Distribution Service)
DDS là giao thức dạng publish-subscribe cho các giao tiếp M2M thời gian thực được phát triển bởi Object Management Group (OMG). Khác với dạng publish-subscribe của AMQP và MQTT, DDS dựa trên kiến trúc broker ít hơn và sử dụng multicasting để mang lại chất lượng dịch vụ (QoS) và độ tin cậy cao cho các ứng dụng của nó. DDS phù hợp với kiến trúc ràng buộc thời gian cho IoT và truyền thông M2M. DDS hỗ trợ 23 chính sách QoS theo đó một loạt các thông tin liên lạc các tiêu chí như an ninh, tính cấp bách, ưu tiên, độ bền, độ tin cậy... có thể được giải quyết bởi các nhà phát triển [12].
Kiến trúc của DDS gồm 2 lớp: Data-Centric Publish-Subscribe (DCPS) and Data-Local Reconstruction Layer (DLRL). DCPS có trách nhiệm cung cấp thông tin cho các thuê bao. DLRL là một lớp tùy chọn và phục vụ như giao diện với chức năng DCPS. Nó tạo điều kiện cho việc chia sẻ dữ liệu phân tán giữa các đối tượng phân phối.
Năm thực thể liên quan với các dòng dữ liệu trong lớp DCPS: (1) Publisher phổ biến dữ liệu; (2) DataWriter được sử dụng bởi các ứng dụng tương tác với Publisher về các giá trị và thay đổi dữ liệu cụ thể cho một loại nhất định; (3) Subscriber nhận dữ liệu được công bố và cung cấp chúng cho các ứng dụng; (4) DataReader là nhân viên của thuê bao để truy cập vào các dữ liệu nhận được; (5) Chủ đề liên quan từ DataWriters đến DataReaders xác định bởi một kiểu dữ liệu và một tên. Truyền dữ liệu được cho phép trong một DDS là một môi trường ảo để xuất bản kết nối và đăng ký các ứng dụng.
2.2. Các giao thức truyền thông trong tầng khám phá dịch vụ (Service Discovery Protocols)
Khả năng mở rộng của IoT đòi hỏi một cơ chế quản lý nguồn tài nguyên có thể đăng ký, khám phá các nguồn lực dịch vụ hiệu quả, năng động và tự cấu hình. Các giao thức chiếm ưu thế nhất trong lĩnh vực này là multicast DNS (mDNS) và DNS Service Discovery (DNS-SD) có thể khám phá các nguồn lực và dịch vụ được cung cấp bởi các thiết bị IoT [13], [14].
IoT cần một số kiến trúc không phụ thuộc vào cơ chế cấu hình. Thiết bị thông minh có thể tham gia đóng vai trò nền tảng hoặc rời bỏ mà không ảnh hưởng đến hành vi của toàn bộ hệ thống. mDNS và DNS-SD có thể phát triển cho mục tiêu này. Tuy nhiên, nhược điểm chính của hai giao thức này là sự cần thiết cho các mục DNS caching đặc biệt khi nói đến các thiết bị có nguồn lực hạn chế. Tuy vậy, thời gian đệm cho một khoảng cụ thể có thể giải quyết vấn đề này.
2.2.1. Multicast DNS (mDNS)
mDNS là một dịch vụ cơ bản cho một số ứng dụng IOT có thể thực hiện các nhiệm vụ của máy chủ DNS unicast [15]. Một dịch vụ mDNS là linh hoạt do thực tế không gian tên DNS sử dụng tại địa phương không cần thêm chi phí hoặc cấu hình. mDNS là sự lựa chọn thích hợp cho các thiết bị nhúng dựa trên Internet do không cần phải cấu hình lại, có thể chạy không cần cơ sở hạ tầng, có thể tiếp tục làm việc nếu cơ sở hạ tầng thất bại. mDNS truy vấn bằng cách gửi một tin nhắn IP multicast cho tất cả các nút trong miền địa phương. Bằng cách này, các khách hàng yêu cầu thiết bị được đặt để trả lời lại. Khi các máy tính mục tiêu nhận được tên của nó, sẽ multicast một tin nhắn phản ứng, trong đó có địa chỉ IP của nó. Tất cả các thiết bị trong mạng có được các tin nhắn phản ứng cập nhật tại bộ nhớ đệm địa phương của nó bằng tên và địa chỉ IP.
2.2.2. DNS-SD (DNS Service Discovery)
Chức năng kết nối các dịch vụ theo yêu cầu của khách hàng sử dụng mDNS được gọi là dịch vụ khám phá dựa trên DNS (DNS-SD). Sử dụng giao thức này, khách hàng có thể khám phá ra một tập hợp các dịch vụ mong muốn trong một mạng cụ thể bằng cách sử dụng các thông điệp DNS chuẩn [16].
Về cơ bản, DNS-SD sử dụng mDNS để gửi các gói tin DNS đến các địa chỉ multicast cụ thể thông qua UDP. Có hai bước chính để xử lý Service Discovery: Tìm tên máy chủ của dịch vụ cần thiết như máy in và các cặp địa chỉ IP với tên máy chủ sử dụng mDNS. Tìm tên máy chủ là quan trọng vì địa chỉ IP có thể thay đổi, còn máy chủ thì không. Các chức năng ghép file đính kèm mạng multicast chi tiết như IP, và số cổng để mỗi máy chủ có liên quan. Sử dụng DNS-SD, tên trong mạng có thể được giữ liên tục miễn là có độ tin cậy. Ví dụ, nếu một số khách hàng biết và sử dụng một máy in cụ thể ngày hôm nay, họ sẽ có kích hoạt để sử dụng nó sau đó mà không cần cài đặt lại hay gặp vấn đề gì khác.
3. Kết luận
Khi bất cứ vật gì đó được kết nối với Internet, điều đó có nghĩa là nó có thể gửi thông tin hoặc nhận thông tin, hoặc cả hai. Với IoT khả năng gửi hoặc nhận thông tin này làm cho mọi thứ trở nên thông minh, và thông minh luôn là xu hướng của công nghệ. Kết quả của bài báo sẽ cung cấp kiến thức liên quan và các đánh giá về giao thức tầng ứng dụng và tầng khám phá dịch vụ. Việc lựa chọn sử dụng và triển khai chuẩn truyền thông nào trong mỗi lớp phụ thuộc vào công nghệ sẵn có và nhu cầu thực tế, đồng thời khiến cho các kỹ sư hay nhà cung cấp giải pháp sẽ thuận lợi và chuyên nghiệp hơn khi thiết kế, chế tạo và sản xuất ra các sản phẩm IoT.
TÀI LIỆU THAM KHẢO:
[1].https://vi.wikipedia.org/wiki/Internet_V%E1%BA%A1n_V%E1%BA%ADt.
[2]. J. Manyika et al., Disruptive Technologies: Advances that Will Transform Life, Business, and the Global Economy. San Francisco, CA, USA: McKinsey Global Instit., 2013.
[3]. Z. Yang et al., “Study and application on the architecture and key technologies for IOT,” in Proc. ICMT, 2011, pp. 747-751.
[4] M. Wu, T. J. Lu, F. Y. Ling, J. Sun, and H. Y. Du, “Research on the architecture of Internet of Things,” in Proc. 3rd ICACTE, 2010, pp. V5-484–V5-487.
[5] R. Khan, S. U. Khan, R. Zaheer, and S. Khan, “Future Internet: The Internet of Things architecture, possible applications and key challenges,” in Proc. 10th Int. Conf. FIT, 2012, pp. 257–260.
[6]. M. A. Chaqfeh and N. Mohamed, “Challenges in middleware solutions for the Internet of Things,” in Proc. Int. Conf. CTS, 2012, pp. 21-26.
[7]. L. Tan and N. Wang, “Future Internet: The Internet of Things,” in Proc. 3rd ICACTE, 2010, pp. V5-376-V5-380.
[8]. Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “Constrained Application Protocol (CoAP).draft-ietf-core-coap-18,” Internet Eng. Task Force (IETF), Fremont, CA, USA, 2013.
[9]. U. Hunkeler, H. L. Truong, and A. Stanford-Clark, “MQTT-S-A publish/subscribe protocol for wireless sensor networks,” in Proc. 3rd Int. Conf. COMSWARE, 2008, pp. 791-798.
[10]. D. Evans, “The Internet of things: How the next evolution of the Internet is changing everything,” CISCO, San Jose, CA, USA, White Paper, 2011.
[11]. “OASIS Advanced Message Queuing Protocol (AMQP) Version 1.0,” Adv. Open Std. Inf. Soc. (OASIS), Burlington, MA, USA, 2012.
[12]. Data distribution services specification, V1.2, Object Manage. Group (OMG), Needham, MA, USA, Apr. 2, 2015. [Online]. Available:http://www.omg.org/spec/DDS/1.2/.
[13] A. J. Jara, P. Martinez-Julia, and A. Skarmeta, “Light-weight multicast DNS and DNS-SD (lmDNS-SD): IPv6-based resource and service discovery for the web of things,” in Proc. 6th Int. Conf. IMIS Ubiquitous Comput., 2012, pp. 731-738.
[14] R. Klauck and M. Kirsche, “Chatty things-Making the Internet of Things readily usable for the masses with XMPP,” in Proc. 8th Int. Conf. CollaborateCom, 2012, pp. 60-69.
[15] S. Cheshire and M. Krochmal, “Multicast DNS,” Internet Eng. Task Force (IETF), Fremont, CA, USA, Request for Comments: 6762, 2013.
[16]. M. Krochmal and S. Cheshire, “DNS-based service discovery,” Internet Eng. Task Force (IETF), Fremont, CA, USA, Request for Comments: 6763, 2013.
ThS. Nguyễn Thanh Tùng, ThS. Nguyễn Thị Dung
Chuyên đề Công nghệ và Ngân hàng số, số 4/2020
