idnits 2.17.1 draft-wang-open-service-access-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There is 1 instance of too long lines in the document, the longest one being 217 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (18 March 2021) is 1132 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force B. Wang, Ed. 3 Internet-Draft S.P. Zhou, Ed. 4 Intended status: Standards Track Hikvision 5 Expires: 19 September 2021 C. Li, Ed. 6 Guangzhou University 7 C.M. Wu, Ed. 8 Z.Z. Wang, Ed. 9 Zhejiang University 10 18 March 2021 12 Open Service Access Protocol for IoT Smart Devices 13 draft-wang-open-service-access-protocol-00 15 Abstract 17 With the development of IoT(Internet of Things) technology, 18 everything is interconnected. Mass IoT data, devices, businesses, 19 and services adopt different data descriptions and service access 20 methods, resulting in fragmentation issues, such as data 21 heterogeneous, device heterogeneous, and application heterogeneous, 22 which hinders the development of the industry. In order to solve the 23 problem, this draft proposes the requirements for IoT smart devices 24 to transmit and control, as well as transmission and protocol 25 interfaces. It is for the program design, system testing and 26 acceptance, and related research. Structured, unified, and 27 standardized open service interconnection model reduces business 28 replication cost and removes service barriers to push industrial 29 development. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 19 September 2021. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. requirements for Consistency . . . . . . . . . . . . . . . . 3 66 2.1. Terms and Definitions . . . . . . . . . . . . . . . . . . 3 67 2.1.1. Area . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1.2. Attribute . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1.3. Operation . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1.4. Event . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1.5. Resource . . . . . . . . . . . . . . . . . . . . . . 4 72 2.1.6. IoT Device Management Platform . . . . . . . . . . . 4 73 2.1.7. Device Access Service . . . . . . . . . . . . . . . . 4 74 2.1.8. IoT Smart Devices . . . . . . . . . . . . . . . . . . 4 75 2.2. Abbreviations and Acronyms . . . . . . . . . . . . . . . 5 76 3. Framework of Device Communication Protocol . . . . . . . . . 5 77 4. Interface protocol structure . . . . . . . . . . . . . . . . 6 78 5. Device certification . . . . . . . . . . . . . . . . . . . . 7 79 6. Get access service . . . . . . . . . . . . . . . . . . . . . 15 80 7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 10. Informative References . . . . . . . . . . . . . . . . . . . 17 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Preface 88 With the development of the IoT technology, everything is widely 89 interconnected, human-machine interact deep, including autonomous 90 vehicles, telemedicine, smart factories, smart cities and other 91 innovative applications. With the development of business, Mass IoT 92 data, devices, businesses, and services adopt different data 93 descriptions and service access methods, resulting in fragmentation 94 issues, such as data heterogeneous, device heterogeneous, and 95 application heterogeneous, which hinders the development of the 96 industry, which mainly refers to: 98 1. Low value of data: IoT data has the characteristics of multi- 99 source heterogeneity and huge scale, making it difficult for data 100 analysis and sharing. At the same time, the lack of business 101 relevance between massive amounts of data leads to inefficient 102 use of data. 104 2. High cost of business replication: different devices use 105 different access standards. The cost of device access is too 106 high and the time is too long. With the growth quantity of 107 applications and devices, new device needs to be customized and 108 developed multiple times for different standards, resulting in 109 increased business replication cost. 111 3. Difficulty in industrial chain cooperation: There are different 112 access protocols and data models between different manufacturers. 113 The internal industrial chain has its own system, which makes it 114 difficult for industrial chain to collaborate, for devices to be 115 linked, maintained, for service to be compatible, Which seriously 116 affects the user experience. 118 In order to solve the problem, this draft proposes the requirements 119 for IoT smart devices to transmit and control, as well as 120 transmission and protocol interfaces. It is for the program design, 121 system testing and acceptance, and related research. Structured, 122 unified, and standardized open service interconnection model reduces 123 business replication cost and removes service barriers to push 124 industrial development. 126 2. requirements for Consistency 128 2.1. Terms and Definitions 130 2.1.1. Area 132 A set of related functions, which is business independent. 134 2.1.2. Attribute 136 Used to describe the sustainable state of the devices during 137 operation, which can be read and set. 139 2.1.3. Operation 141 A method that can be called externally by a device or platform. The 142 operation includes "input parameters" and "output parameters". The 143 input parameters are the instruction information that needed to 144 perform the operation, and the output parameters are the feedback 145 information after the instruction is executed. 147 2.1.4. Event 149 Information actively reported by the device. This type of 150 information needs to be reported in real time and processed by the 151 platform in time. If the device network is interrupted, it can be 152 cached and reported after recovery. 154 2.1.5. Resource 156 An entity that is a relatively independent component of the device 157 and can independently handle user requirements. User applications 158 can independently show or manage the resources of the device. For 159 example, the video channel of NVR device. 161 2.1.6. IoT Device Management Platform 163 A system that connects a large number of diverse and heterogeneous 164 sensing devices and can unify access management of devices, collect, 165 process and store data. 167 2.1.7. Device Access Service 169 Services for managing, controlling and configing device functions and 170 support attributes, operations, and events. 172 2.1.8. IoT Smart Devices 174 Physical entities with video, image, and information perception 175 capabilities, including: video equipment, access control, radar, etc. 176 It can be directly connected to the IoT device management platform, 177 or be a gateway that connects the agent sub-device and the IoT device 178 management platform. 180 2.2. Abbreviations and Acronyms 182 +============================+=====================================+ 183 | Abbreviations and Acronyms | Full Name | 184 +============================+=====================================+ 185 | JSON | Java Script Object Notation | 186 +----------------------------+-------------------------------------+ 187 | MQTT[MQTT2016] | Message Queuing Telemetry Transport | 188 +----------------------------+-------------------------------------+ 189 | TLS[RFC8446] | Transport Layer Security | 190 +----------------------------+-------------------------------------+ 191 | UTF-8 | 8-bit Unicode Transformation Forma | 192 +----------------------------+-------------------------------------+ 193 | URL | Uniform Resoure Locator | 194 +----------------------------+-------------------------------------+ 196 Table 1 198 3. Framework of Device Communication Protocol 200 The framework of the protocol is shown below: 202 Bussiness Protocol-------------------------------------------+ 203 | +------+ +-----+ +-------+ +----+ +--------+ | 204 | | | | | | | |area| |Resource| | 205 | |store/| |Media| |Upgrate| +----+ +--------+ | 206 | |file | | | | | +---------+ +---------+ +-----+ | 207 | | | | | | | |attribute| |operation| |event| | 208 | +------+ +-----+ +-------+ +---------+ +---------+ +-----+ | 209 +------------------------------------------------------------+ 211 Fundamental communication protocol---------------------------+ 212 | +---------------------------+ | 213 | | +-----------------------+ +----------------------------+ | 214 | | | store | media |update | | attribute|operation| event | | 215 | | |channel|channel|channel| | channel | channel |channel| | 216 | | +-----------------------+ +----^-----+----^---------^--+ | 217 | +---------------------------+ | | | | 218 | ^ ^ ^ | | | | 219 | | | +---+---------+----------+---------+--+ | 220 | | | | MQTT | | 221 | | | +-----------------^---------------^---+ | 222 | | | | | | 223 | | | | +----+---+ | 224 | | | | | TLS | | 225 | | | | +----^---+ | 226 | | | | | | 227 | +---+---+ +--+---------------------+---------------+---+ | 228 | |HTTP(S)| | TCP | | 229 | +-------+ +--------------------------------------------+ | 230 +------------------------------------------------------------+ 232 Figure:Framework of Device Communication Protocol 234 The business is separated from the protocol. In the bottom layer, it 235 adopts MQTT to transmit data. Different transmission channels are 236 used for authentication, media, storage and attributes, operations, 237 and events. 239 4. Interface protocol structure 241 In this draft, the session channel interface adopts MQTT protocol. 242 Structure of MQTT protocol is divided into three sections: fixed 243 header, variable header and payload. Structure of MQTT protocol is 244 shown below. 246 --------+---------------------------+----------------------------------- 247 | | 248 | Header | Payload 249 structre|------------+--------------+----------------+------------------ 250 | | | | 251 |Fixedheader |Variableheader|GeneralPayload |ApplicationPayload 252 --------+------------+--------------+-------+--------+------------------ 253 name |Fixedheader |Variableheader|length |content |content 254 --------+------------+--------------+-------+--------+------------------ 255 symbol |FixedHEADER |VariableHEADER|LEN |Gernal |Func 256 --------+------------+--------------+-------+--------+------------------ 257 length |2-5 bytes |variable |2 bytes|variable|variable 258 --------+------------+--------------+-------+--------+------------------ 259 des- |Depending |Different |The |See |The format 260 cription|on the |control |length |defi- |depends on 261 |length of |message has |of |nition |specific 262 |the variable|different |general|for its |transaction 263 |header and |variable |payload|format | 264 |payload, the|headers | | | 265 |length of | | | | 266 |the fixed | | | | 267 |header | | | | 268 |varies | | | | 269 |between 2 | | | | 270 |and 5 bytes | | | | 271 --------+------------+--------------+-------+--------+------------------ 273 Table: MQTT protocol structure 275 General protocols and business protocol bodies need AES (128) 276 encryption during transmission, and UTF-8 encoding is used uniformly 277 for character strings. 279 5. Device certification 281 The overall protocol format of the authentication process is shown as 282 follows: 284 --------+--------------------------+------------------------------------ 285 | | 286 | Header | Payload 287 structre|-----------+--------------+-----------------+------------------ 288 | | | | 289 |Fixedheader|Variableheader|GeneralPayload |ApplicationPayload 290 --------+-----------+--------------+---------+-------+------------------ 291 name |Fixedheader|Variableheader|version |con+ | 292 | | | |tent | 293 --------+-----------+--------------+---------+-------+------------------ 294 symbol |FixedHEADER|VariableHEADER|PROTOCOL-| |PROTOCOL- 295 | | |VERSION |Func |VERSION 296 | | | | | 297 --------+-----------+--------------+---------+-------+------------------ 298 length |2|5 bytes |Variable |3 bytes |Va- |3 bytes 299 | | | |riable | 300 | | | | | 301 --------+-----------+--------------+---------+-------+------------------ 302 des- |Depending |Different |The |See |The 303 cription|on the |control |version |tran- |version 304 |length of |message has |of |saction|of 305 |the |different |protocol |for its|protocol 306 |variable |variable | |format | 307 |header and |headers | | | 308 |payload, | | | | 309 |the | | | | 310 |length of | | | | 311 |the fixed | | | | 312 |header | | | | 313 |varies | | | | 314 |between 2 | | | | 315 |and 5 bytes| | | | 316 --------+-----------+--------------+---------+-------+------------------ 318 Table: MQTT protocol format 320 The protocol version definition is shown as follows: 322 +===================+======+=======================================+ 323 | name | type | description | 324 +===================+======+=======================================+ 325 | FORM_VERSION | char | version number of protocol form | 326 +-------------------+------+---------------------------------------+ 327 | HIGH_TYPE_VERSION | char | version number of protocol type(high) | 328 +-------------------+------+---------------------------------------+ 329 | LOW_TYPE_VERSION | char | version number of protocol type(low) | 330 +-------------------+------+---------------------------------------+ 332 Table 2: Protocol version definition 334 Device access adopts bidirectional negotiation protocol process. 335 Devices sends the supported type of protocol group to the balance 336 load service, and the server will determine which way to communicate 337 depending on its own situation. After the device being 338 authenticated, it can establish an MQTT connection with the device 339 access service (Das) through the sessionkey to communicate with the 340 bussiness protocol. The specific bidirectional negotiation diagram 341 is as follows: 343 +------+ +------+ 344 |device| |server| 345 +---+--+ +------+ 346 | | 347 | | 348 | | 349 | | 350 +----------------------+----------+ | | 351 | negotiation request | | | | 352 +----------------------+ | +--negotiation request---> +--+ 353 | Control message type:0x1 | | | | 354 | | | | | 355 | Control flag:0x1 | | | | 356 | | | | | 357 | protocol type:1 | | | | 358 | | | | | 359 | protocol group:(1,2,4,8) | | | | 360 | | | <--negotiation response--+ | 361 | transaction content:xxxxxx | | | | 362 +---------------------------------+ | +--+ 363 | | 364 | | 365 +----------------------+----------+ | | 366 | negotiation response | | | | 367 +----------------------+ | | | 368 | Control message type:0x2 | | | 369 | | | | 370 | Control flag:0x1 | | | 371 | | | | 372 | protocol type:1 | | | 373 | | | | 374 | transactionocontent:xxxxxx | | | 375 +---------------------------------+ | | 377 Figure 1: bidirectional negotiation diagram - consistence 378 +------+ +------+ 379 |device| |server| 380 +---+--+ +------+ 381 +----------------+-+ | | +----------------+-+ 382 | negotiation | | | | | negotiation | | 383 | request2 | | | | | response2 | | 384 +----------------+ | | negotiation | +----------------+ | 385 |Control | +-- request1 --> | |Control | 386 |message type:0x1 | | | |message type:0x2 | 387 | | | | | | 388 |Control flag:0x1 | | | |Control flag:0x1 | 389 | | | | | | 390 |protocol type:2 | | | |protocol type:2 | 391 | | | | | | 392 |protocol | | negotiation | |protocol | 393 |group:(1,2,4,8) | | <-- response1--+ |group:(2,4,8) | 394 | | | | | | 395 |transaction | | | |transaction | 396 |content:xxxx | | | |content:xxxx | 397 +------------------+ | | +------------------+ 398 | | 399 +------------------------------------------------------------------+ 400 | negotiation | 401 disconnect +-- request2 --> | 402 | | 403 +----------------+-+ | | +----------------+-+ 404 | negotiation | | | | | negotiation | | 405 | request2 | | | | | response2 | | 406 +----------------+ | | | +----------------+ | 407 |Control | | | |Control | 408 |message type:0x1 | | negotiation | |message type:0x2 | 409 | | | <-- response2--+ | | 410 |Control flag:0x1 | | | |Control flag:0x1 | 411 | | | | | | 412 |protocol type:2 | | | |protocol type:2 | 413 | | | | | | 414 |protocol | | | |transaction | 415 |group:(1,2,4,8) | | | |content:xxxx | 416 | | | | | | 417 |transaction | | | | | 418 |content:xxxx | | | | | 419 +------------------+ | | +------------------+ 420 | | 421 | | 422 + + 424 Figure 2: bidirectional negotiation diagram - inconsistence 426 bidirectional negotiation can be divided into two conditions: 428 (1) If the service supports this type of protocol, select the most 429 secure protocol in the device's protocol group to complete the 430 negotiation and communicate with the device; 432 (2) If the service does not support the type of protocol, return the 433 message to the device,which contains the type of protocol and 434 protocol group supported by the service. And then, interupt TCP 435 connection. If the device supports it, use again the type of 436 protocol and protocol group supported by the service to go through 437 the authentication process. Otherwise, the device should give up 438 authentication with the service. 440 In order to ensure forward compatibility with the ECDH key 441 interaction mode, Bit1 of the control flag bit is enabled. When Bit1 442 is 0, the control message type remains in the original mode, and when 443 Bit1 is 1, it means that the ECDH key mode is used for interaction. 444 The key algorithm of secret key in the authentication process: 446 sharekey:pdkdf2_SHA256(md5(md5(MD5(verification code + device serial 447 number)+www.88075998.com))) Device masterkey: ecdh_NID_secp384r1 448 (lbs_publickey, device_privatekey) Server masterkey: 449 ecdh_NID_secp384r1 (device_publickey, lbs_privatekey) 451 a) First Authentication 453 When the device requires for working online the first time, 454 useexchange algorithm of ECDH secret key to initialize DEVID and 455 MasterKey. The process is shown as follows: 457 +------+ +-----------+ 458 |Device| |Lbs service| 459 +------+ +------+----+ 460 | | 461 +-----------------Privatekey exchange------------------------+ 462 +-----+ | 463 | |Generate privatekey and publickey | 464 <-----+ | 465 +-----+ | 466 | |Generate sharekey | 467 <-----+ | 468 |-------Request for privatekey interaction-------> 469 <-------Reponse for privatekey interaction-------+ 470 +-----+ | 471 | |Decrypt lbs_publickey from response | 472 <-----+ | 473 +-----+ | 474 | |Generate materkey | 475 <-----+ | 476 +-------------------- apply devid---------------------------+ 477 |-------| Request for applying devid |-----------> 478 <---------Reponse for applying devid-------------+ 479 +-----+ | 480 | |Decrypt devid and sessionkey from response| 481 <-----+ | 482 |---|Request for getting Das service address-----> 483 <----Reponse for getting Das service address-----+ 484 | | 485 + + 487 Figure 3: First Authentication 489 b) Reauthentication 491 When the device is disconnected and ask for reauthenticated, it needs 492 to request reauthentication from the platform and update the 493 sessionkey. The specific process is shown as follows: 495 +------+ +-----------+ 496 |Device| |Lbs Service| 497 +------+ +-----+-----+ 498 | | 499 +-------------------------------------------------------------+ 500 +------+ Update request for sessionkey +----------> 501 | | 502 <------+ Update respond for sessionkey +----------+ 503 | | 504 +-----+ | 505 | Decrypt sessionkey | 506 | | from response | 507 <-----+ | 508 +-------------------------------------------------------------+ 509 | | 510 +---------+ Get service address request +---------> 511 | | 512 <---------+ Get service address response +--------+ 513 | | 515 Figure 4: Re-authenticate 517 c) Define the ECDH control message type as follows: 519 +============+=======+================================+=============+ 520 |message |control| name | description| 521 |direction |message| | | 522 +============+=======+================================+=============+ 523 |Dev<--->Lbs |0x1 | Authentication_ECDH_Req | request for| 524 | | | |ECDH exchange| 525 +------------+-------+--------------------------------+-------------+ 526 |Dev<--->Lbs |0x2 | Authentication_ECDH_Rsp | response for| 527 | | | |ECDH exchange| 528 +------------+-------+--------------------------------+-------------+ 529 |Dev<--->Lbs |0x3 | Rsrv | reserve| 530 +------------+-------+--------------------------------+-------------+ 531 |Dev<--->Lbs |0x4 | Refresh_SessionKey_Req | refresh| 532 | | | | SessionKey| 533 | | | | request| 534 +------------+-------+--------------------------------+-------------+ 535 |Dev<--->Lbs |0x5 | Rsrv | reserve| 536 +------------+-------+--------------------------------+-------------+ 537 |Dev<--->Lbs |0x6 | Refresh_SessionKey_Rsp | refresh| 538 | | | | SessionKey| 539 | | | | response| 540 +------------+-------+--------------------------------+-------------+ 541 |Dev<--->Lbs |0x7 | Authentication_apply_devid_Req | request| 542 | | | | device ID| 543 +------------+-------+--------------------------------+-------------+ 544 |Dev<--->Lbs |0x8 | Authentication_apply_devid_Rsq | response| 545 | | | | device ID| 546 +------------+-------+--------------------------------+-------------+ 547 |Dev<--->Lbs |0x9 | Authentication_apply_devid_Cfm | confirm| 548 | | | | device ID| 549 +------------+-------+--------------------------------+-------------+ 551 Table 3 553 Table: Protocol version definition 555 6. Get access service 557 As the number of device accesses increases, there will be bottlenecks 558 in the performance of single-node accesses, so the platform needs to 559 support the mode of multiple device accesses. To support this mode, 560 the devices are redirected to multiple access services by load 561 balancing server. After the device obtains the sessionKey through 562 two-way authentication, it initiates a request for access service 563 within the same TCP connection, and the message in the request is 564 encrypted with the sessionKey. 566 +------------+ +-------------+ 568 +------+ |Balance load| |Device access| |Device| | ser^ice | | 569 service | +------+ +------+-----+ +------+------+ | | | 570 Redirect---------------------------------+ | | +--- F1:Request for 571 getting a -----> | | | | device access service 572 address | | | | | | | | | <--- F2:Return a device access 573 ----+ | | | | ser^ice information | | | 574 +----------------------------------------+ | | | | Bussiness--------- 575 --------------------------------------------+ | | | | | | <------- 576 Business message:AES128(message)----------> | | | AES128 577 privatekey:sessionkey | | | | | | | 578 +-------------------------------------------------------------+ + + + 580 Figure: Get access service 582 # Registration and Deregistration 583 After the device completes two-way authentication to obtain a specific access service address, the device initiates a request to register online through the MQTT protocol, and the application message body in the request is encrypted using the sessionKey obtained by two-way authentication. 585 +-------------+ +------------+ 586 | Device | | Platform | 587 |(MQTT Client)| |(MQTT Sever)| 588 +-----+-------+ +------+-----+ 589 | | 590 +------- F1:Device register and login(MQTT CONNECT) -------> 591 | | 592 <-------- F2:Register and respond(MQTT CONNACK) -----------+ 593 | | 594 <---------------- Business interaction --------------------> 595 | | 596 +---- F3:Send request for disconnect(MQTT DISCONNECT) -----> 597 | | 598 + + 600 Figure 5: Registration and Deregistration 602 a) F1: After the device and platform network connection is 603 established, the device sends a online request to the platform via 604 MQTTCONNECT, of which payload contains one or more encoded fields, 605 including: unique identifier of the client, Will subject, Will 606 message, username and password. 608 b) F2: The platform returns the response message to the device via 609 MQTTCONNACK to inform it whether it succeeded or not; 611 c) F3: Before disconnecting, the device sends a DISSCONNECT message 612 to the platform, indicating that it wants to disconnect normally, and 613 the platform will close the TCP/IP connection after receiving the 614 request. 616 7. Heartbeat 618 After the device has registered with the platform, it needs to send 619 heartbeat requests periodically according to the heartbeat interval 620 indicated in the registration request. The interval is usually 30s. 621 Used for: 623 a) Inform the platform that the device is alive when no other control 624 messages are sent from the device to the platform 626 b) Request the platform to send a response confirming that it is 627 alive. 629 c) Use the network to confirm that the network connection is not 630 disconnected. 632 +------+ +--------+ 633 |Device| |Platform| 634 +------+ +----+---+ 635 | | 636 +------ F1: Send a heartbeat request(MQTT PINGREQ) -----------> 637 | | 638 <--- F2: Respond to the heartbeat request MQTT PINGRESP) -----+ 639 | | 641 Figure 6: Heartbeat 643 8. Security Considerations 645 This entire memo deals with security issues. 647 9. IANA Considerations 649 This documents has no IANA actions. 651 10. Informative References 653 [MQTT2016] ISOIEC, "Information technology — Message Queuing 654 Telemetry Transport", . 657 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 658 Version 1.3", DOI 10.17487/RFC8446, August 2018, 659 . 661 Authors' Addresses 662 Bin Wang (editor) 663 Hikvision 664 555 Qianmo Road, Binjiang District 665 Hangzhou 666 310051 667 China 669 Phone: +86 571 8847 3644 670 Email: wbin2006@gmail.com 672 Shaopeng Zhou (editor) 673 Hikvision 674 555 Qianmo Road, Binjiang District 675 Hangzhou 676 310051 677 China 679 Phone: +86 571 8847 3644 680 Email: zhoushaopeng@hikvision.com 682 Chao Li (editor) 683 Guangzhou University 684 230 Wai Huan Xi Road 685 Guangzhou 686 510006 687 China 689 Email: lichao@gzhu.edu.cn 691 Chunming Wu (editor) 692 Zhejiang University 693 866 Yuhangtang Rd 694 Hangzhou 695 310058 696 China 698 Email: wuchunming@zju.edu.cn 699 Zizhao Wang (editor) 700 Zhejiang University 701 866 Yuhangtang Rd 702 Hangzhou 703 310058 704 China 706 Email: 22021272@zju.edu.cn