idnits 2.17.1 draft-wang-open-service-access-protocol-02.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (20 March 2022) is 765 days in the past. Is this intentional? 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: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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. Zhou, Ed. 4 Intended status: Standards Track Hikvision 5 Expires: 21 September 2022 C. Li, Ed. 6 Guangzhou University 7 C. Wu, Ed. 8 Z. Wang, Ed. 9 Zhejiang University 10 20 March 2022 12 Open Service Access Protocol for IoT Smart Devices 13 draft-wang-open-service-access-protocol-02 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 21 September 2022. 48 Copyright Notice 50 Copyright (c) 2022 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 Revised BSD License text as 59 described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Revised 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. Load Balancing Service . . . . . . . . . . . . . . . 4 74 2.1.8. Device Access Service . . . . . . . . . . . . . . . . 4 75 2.1.9. Picture Service . . . . . . . . . . . . . . . . . . . 5 76 2.1.10. Video Service . . . . . . . . . . . . . . . . . . . . 5 77 2.1.11. Event Service . . . . . . . . . . . . . . . . . . . . 5 78 2.1.12. IoT Smart Devices . . . . . . . . . . . . . . . . . . 5 79 2.2. Abbreviations and Acronyms . . . . . . . . . . . . . . . 5 80 3. Framework of Device Communication Protocol . . . . . . . . . 5 81 4. Interface protocol structure . . . . . . . . . . . . . . . . 6 82 5. Device certification . . . . . . . . . . . . . . . . . . . . 7 83 6. Get access service . . . . . . . . . . . . . . . . . . . . . 15 84 7. Registration and Deregistration . . . . . . . . . . . . . . . 16 85 8. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 87 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 88 11. Informative References . . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Preface 93 With the development of the IoT technology, everything is widely 94 interconnected, human-machine interact deep, including autonomous 95 vehicles, telemedicine, smart factories, smart cities and other 96 innovative applications. With the development of business, Mass IoT 97 data, devices, businesses, and services adopt different data 98 descriptions and service access methods, resulting in fragmentation 99 issues, such as data heterogeneous, device heterogeneous, and 100 application heterogeneous, which hinders the development of the 101 industry, which mainly refers to: 103 1. Low value of data: IoT data has the characteristics of multi- 104 source heterogeneity and huge scale, making it difficult for data 105 analysis and sharing. At the same time, the lack of business 106 relevance between massive amounts of data leads to inefficient 107 use of data. 109 2. High cost of business replication: different devices use 110 different access standards. The cost of device access is too 111 high and the time is too long. With the growth quantity of 112 applications and devices, new device needs to be customized and 113 developed multiple times for different standards, resulting in 114 increased business replication cost. 116 3. Difficulty in industrial chain cooperation: There are different 117 access protocols and data models between different manufacturers. 118 The internal industrial chain has its own system, which makes it 119 difficult for industrial chain to collaborate, for devices to be 120 linked, maintained, for service to be compatible, Which seriously 121 affects the user experience. 123 In order to solve the problem, this draft proposes the requirements 124 for IoT smart devices to transmit and control, as well as 125 transmission and protocol interfaces. It is for the program design, 126 system testing and acceptance, and related research. Structured, 127 unified, and standardized open service interconnection model reduces 128 business replication cost and removes service barriers to push 129 industrial development. 131 2. requirements for Consistency 133 2.1. Terms and Definitions 135 2.1.1. Area 137 A set of related functions, which is business independent. 139 2.1.2. Attribute 141 Used to describe the sustainable state of the devices during 142 operation, which can be read and set. 144 2.1.3. Operation 146 A method that can be called externally by a device or platform. The 147 operation includes "input parameters" and "output parameters". The 148 input parameters are the instruction information that needed to 149 perform the operation, and the output parameters are the feedback 150 information after the instruction is executed. 152 2.1.4. Event 154 Information actively reported by the device. This type of 155 information needs to be reported in real time and processed by the 156 platform in time. If the device network is interrupted, it can be 157 cached and reported after recovery. 159 2.1.5. Resource 161 An entity that is a relatively independent component of the device 162 and can independently handle user requirements. User applications 163 can independently show or manage the resources of the device. For 164 example, the video channel of NVR device. 166 2.1.6. IoT Device Management Platform 168 A system that connects a large number of diverse and heterogeneous 169 sensing devices and can unify access management of devices, collect, 170 process and store data. 172 2.1.7. Load Balancing Service 174 Responsible for equipment certification. The device actively 175 authenticates to the load balancing service. After passing the 176 authentication, the device will balance the load to multiple devices 177 to access the service through redirection. 179 2.1.8. Device Access Service 181 Services for managing, controlling and configing device functions and 182 support attributes, operations, and events. 184 2.1.9. Picture Service 186 Responsible for image storage services, support upload, download 187 images and other functions. 189 2.1.10. Video Service 191 Responsible for media data transmission, support real-time preview, 192 video playback, voice intercom and other functions. 194 2.1.11. Event Service 196 Responsible for receiving and handling events. 198 2.1.12. IoT Smart Devices 200 Physical entities with video, image, and information perception 201 capabilities, including: video equipment, access control, radar, etc. 202 It can be directly connected to the IoT device management platform, 203 or be a gateway that connects the agent sub-device and the IoT device 204 management platform. 206 2.2. Abbreviations and Acronyms 208 +============================+=====================================+ 209 | Abbreviations and Acronyms | Full Name | 210 +============================+=====================================+ 211 | IP | Internet Protocol | 212 +----------------------------+-------------------------------------+ 213 | JSON | Java Script Object Notation | 214 +----------------------------+-------------------------------------+ 215 | MQTT[MQTT2016] | Message Queuing Telemetry Transport | 216 +----------------------------+-------------------------------------+ 217 | TLS[RFC8446] | Transport Layer Security | 218 +----------------------------+-------------------------------------+ 219 | UTF-8 | 8-bit Unicode Transformation Forma | 220 +----------------------------+-------------------------------------+ 221 | URL | Uniform Resoure Locator | 222 +----------------------------+-------------------------------------+ 224 Table 1: Abbreviations and Acronyms 226 3. Framework of Device Communication Protocol 228 The framework of the protocol is shown below: 230 Bussiness Protocol-------------------------------------------+ 231 | +------+ +-----+ +-------+ +----+ +--------+ | 232 | | | | | | | |area| |Resource| | 233 | |store/| |Media| |Upgrate| +----+ +--------+ | 234 | |file | | | | | +---------+ +---------+ +-----+ | 235 | | | | | | | |attribute| |operation| |event| | 236 | +------+ +-----+ +-------+ +---------+ +---------+ +-----+ | 237 +------------------------------------------------------------+ 239 Fundamental communication protocol---------------------------+ 240 | +---------------------------+ | 241 | | +-----------------------+ +----------------------------+ | 242 | | | store | media |update | | attribute|operation| event | | 243 | | |channel|channel|channel| | channel | channel |channel| | 244 | | +-----------------------+ +----^-----+----^---------^--+ | 245 | +---------------------------+ | | | | 246 | ^ ^ ^ | | | | 247 | | | +---+---------+----------+---------+--+ | 248 | | | | MQTT | | 249 | | | +-----------------^---------------^---+ | 250 | | | | | | 251 | | | | +----+---+ | 252 | | | | | TLS | | 253 | | | | +----^---+ | 254 | | | | | | 255 | +---+---+ +--+---------------------+---------------+---+ | 256 | |HTTP(S)| | TCP | | 257 | +-------+ +--------------------------------------------+ | 258 +------------------------------------------------------------+ 260 Figure 1: Framework of Device Communication Protocol 262 The business is separated from the protocol. In the bottom layer, it 263 adopts MQTT to transmit data. Different transmission channels are 264 used for authentication, media, storage and attributes, operations, 265 and events. 267 4. Interface protocol structure 269 In this draft, the session channel interface adopts MQTT protocol. 270 Structure of MQTT protocol is divided into three sections: fixed 271 header, variable header and payload. Structure of MQTT protocol is 272 shown below. 274 --------+---------------------------+----------------------------------- 275 | | 276 | Header | Payload 277 structre|------------+--------------+----------------+------------------ 278 | | | | 279 |Fixedheader |Variableheader|GeneralPayload |ApplicationPayload 280 --------+------------+--------------+-------+--------+------------------ 281 name |Fixedheader |Variableheader|length |content |content 282 --------+------------+--------------+-------+--------+------------------ 283 symbol |FixedHEADER |VariableHEADER|LEN |Gernal |Func 284 --------+------------+--------------+-------+--------+------------------ 285 length |2-5 bytes |variable |2 bytes|variable|variable 286 --------+------------+--------------+-------+--------+------------------ 287 des- |Depending |Different |The |See |The format 288 cription|on the |control |length |defi- |depends on 289 |length of |message has |of |nition |specific 290 |the variable|different |general|for its |transaction 291 |header and |variable |payload|format | 292 |payload, the|headers | | | 293 |length of | | | | 294 |the fixed | | | | 295 |header | | | | 296 |varies | | | | 297 |between 2 | | | | 298 |and 5 bytes | | | | 299 --------+------------+--------------+-------+--------+------------------ 301 Figure 2: MQTT protocol structure 303 General protocols and business protocol bodies need AES (128) 304 encryption during transmission, and UTF-8 encoding is used uniformly 305 for character strings. 307 5. Device certification 309 The overall protocol format of the authentication process is shown as 310 follows: 312 --------+--------------------------+------------------------------------ 313 | | 314 | Header | Payload 315 structre|-----------+--------------+-----------------+------------------ 316 | | | | 317 |Fixedheader|Variableheader|GeneralPayload |ApplicationPayload 318 --------+-----------+--------------+---------+-------+------------------ 319 name |Fixedheader|Variableheader|version |con+ | 320 | | | |tent | 321 --------+-----------+--------------+---------+-------+------------------ 322 symbol |FixedHEADER|VariableHEADER|PROTOCOL-| |PROTOCOL- 323 | | |VERSION |Func |VERSION 324 | | | | | 325 --------+-----------+--------------+---------+-------+------------------ 326 length |2|5 bytes |Variable |3 bytes |Va- |3 bytes 327 | | | |riable | 328 | | | | | 329 --------+-----------+--------------+---------+-------+------------------ 330 des- |Depending |Different |The |See |The 331 cription|on the |control |version |tran- |version 332 |length of |message has |of |saction|of 333 |the |different |protocol |for its|protocol 334 |variable |variable | |format | 335 |header and |headers | | | 336 |payload, | | | | 337 |the | | | | 338 |length of | | | | 339 |the fixed | | | | 340 |header | | | | 341 |varies | | | | 342 |between 2 | | | | 343 |and 5 bytes| | | | 344 --------+-----------+--------------+---------+-------+------------------ 346 Figure 3: MQTT protocol format 348 The protocol version definition is shown as follows: 350 +===================+======+=======================================+ 351 | name | type | description | 352 +===================+======+=======================================+ 353 | FORM_VERSION | char | version number of protocol form | 354 +-------------------+------+---------------------------------------+ 355 | HIGH_TYPE_VERSION | char | version number of protocol type(high) | 356 +-------------------+------+---------------------------------------+ 357 | LOW_TYPE_VERSION | char | version number of protocol type(low) | 358 +-------------------+------+---------------------------------------+ 360 Table 2: Protocol version definition 362 Device access adopts bidirectional negotiation protocol process. 363 Devices sends the supported type of protocol group to the balance 364 load service, and the server will determine which way to communicate 365 depending on its own situation. After the device being 366 authenticated, it can establish an MQTT connection with the device 367 access service (Das) through the sessionkey to communicate with the 368 bussiness protocol. The specific bidirectional negotiation diagram 369 is as follows: 371 +------+ +------+ 372 |device| |server| 373 +---+--+ +------+ 374 | | 375 | | 376 | | 377 | | 378 +----------------------+----------+ | | 379 | negotiation request | | | | 380 +----------------------+ | +--negotiation request---> +--+ 381 | Control message type:0x1 | | | | 382 | | | | | 383 | Control flag:0x1 | | | | 384 | | | | | 385 | protocol type:1 | | | | 386 | | | | | 387 | protocol group:(1,2,4,8) | | | | 388 | | | <--negotiation response--+ | 389 | transaction content:xxxxxx | | | | 390 +---------------------------------+ | +--+ 391 | | 392 | | 393 +----------------------+----------+ | | 394 | negotiation response | | | | 395 +----------------------+ | | | 396 | Control message type:0x2 | | | 397 | | | | 398 | Control flag:0x1 | | | 399 | | | | 400 | protocol type:1 | | | 401 | | | | 402 | transactionocontent:xxxxxx | | | 403 +---------------------------------+ | | 405 Figure 4: bidirectional negotiation diagram - consistence 406 +------+ +------+ 407 |device| |server| 408 +---+--+ +------+ 409 +----------------+-+ | | +----------------+-+ 410 | negotiation | | | | | negotiation | | 411 | request2 | | | | | response2 | | 412 +----------------+ | | negotiation | +----------------+ | 413 |Control | +-- request1 --> | |Control | 414 |message type:0x1 | | | |message type:0x2 | 415 | | | | | | 416 |Control flag:0x1 | | | |Control flag:0x1 | 417 | | | | | | 418 |protocol type:2 | | | |protocol type:2 | 419 | | | | | | 420 |protocol | | negotiation | |protocol | 421 |group:(1,2,4,8) | | <-- response1--+ |group:(2,4,8) | 422 | | | | | | 423 |transaction | | | |transaction | 424 |content:xxxx | | | |content:xxxx | 425 +------------------+ | | +------------------+ 426 | | 427 +------------------------------------------------------------------+ 428 | negotiation | 429 disconnect +-- request2 --> | 430 | | 431 +----------------+-+ | | +----------------+-+ 432 | negotiation | | | | | negotiation | | 433 | request2 | | | | | response2 | | 434 +----------------+ | | | +----------------+ | 435 |Control | | | |Control | 436 |message type:0x1 | | negotiation | |message type:0x2 | 437 | | | <-- response2--+ | | 438 |Control flag:0x1 | | | |Control flag:0x1 | 439 | | | | | | 440 |protocol type:2 | | | |protocol type:2 | 441 | | | | | | 442 |protocol | | | |transaction | 443 |group:(1,2,4,8) | | | |content:xxxx | 444 | | | | | | 445 |transaction | | | | | 446 |content:xxxx | | | | | 447 +------------------+ | | +------------------+ 448 | | 449 | | 450 + + 452 Figure 5: bidirectional negotiation diagram - inconsistence 454 bidirectional negotiation can be divided into two conditions: 456 (1) If the service supports this type of protocol, select the most 457 secure protocol in the device's protocol group to complete the 458 negotiation and communicate with the device; 460 (2) If the service does not support the type of protocol, return the 461 message to the device,which contains the type of protocol and 462 protocol group supported by the service. And then, interupt TCP 463 connection. If the device supports it, use again the type of 464 protocol and protocol group supported by the service to go through 465 the authentication process. Otherwise, the device should give up 466 authentication with the service. 468 In order to ensure forward compatibility with the ECDH key 469 interaction mode, Bit1 of the control flag bit is enabled. When Bit1 470 is 0, the control message type remains in the original mode, and when 471 Bit1 is 1, it means that the ECDH key mode is used for interaction. 472 The key algorithm of secret key in the authentication process: 474 sharekey:pdkdf2_SHA256(md5(md5(MD5(verification code + device serial 475 number)+www.88075998.com))) Device masterkey: ecdh_NID_secp384r1 476 (lbs_publickey, device_privatekey) Server masterkey: 477 ecdh_NID_secp384r1 (device_publickey, lbs_privatekey) 479 a) First Authentication 481 When the device requires for working online the first time, 482 useexchange algorithm of ECDH secret key to initialize DEVID and 483 MasterKey. The process is shown as follows: 485 +------+ +-----------+ 486 |Device| |Lbs service| 487 +------+ +------+----+ 488 | | 489 +-----------------Privatekey exchange------------------------+ 490 +-----+ | 491 | |Generate privatekey and publickey | 492 <-----+ | 493 +-----+ | 494 | |Generate sharekey | 495 <-----+ | 496 |-------Request for privatekey interaction-------> 497 <-------Reponse for privatekey interaction-------+ 498 +-----+ | 499 | |Decrypt lbs_publickey from response | 500 <-----+ | 501 +-----+ | 502 | |Generate materkey | 503 <-----+ | 504 +-------------------- apply devid---------------------------+ 505 |-------| Request for applying devid |-----------> 506 <---------Reponse for applying devid-------------+ 507 +-----+ | 508 | |Decrypt devid and sessionkey from response| 509 <-----+ | 510 |---|Request for getting Das service address-----> 511 <----Reponse for getting Das service address-----+ 512 | | 513 + + 515 Figure 6: First Authentication 517 b) Reauthentication 519 When the device is disconnected and ask for reauthenticated, it needs 520 to request reauthentication from the platform and update the 521 sessionkey. The specific process is shown as follows: 523 +------+ +-----------+ 524 |Device| |Lbs Service| 525 +------+ +-----+-----+ 526 | | 527 +-------------------------------------------------------------+ 528 +------+ Update request for sessionkey +----------> 529 | | 530 <------+ Update respond for sessionkey +----------+ 531 | | 532 +-----+ | 533 | Decrypt sessionkey | 534 | | from response | 535 <-----+ | 536 +-------------------------------------------------------------+ 537 | | 538 +---------+ Get service address request +---------> 539 | | 540 <---------+ Get service address response +--------+ 541 | | 543 Figure 7: Re-authenticate 545 c) Define the ECDH control message type as follows: 547 +============+=======+================================+=============+ 548 |message |control| name | description| 549 |direction |message| | | 550 +============+=======+================================+=============+ 551 |Dev<--->Lbs |0x1 | Authentication_ECDH_Req | request for| 552 | | | |ECDH exchange| 553 +------------+-------+--------------------------------+-------------+ 554 |Dev<--->Lbs |0x2 | Authentication_ECDH_Rsp | response for| 555 | | | |ECDH exchange| 556 +------------+-------+--------------------------------+-------------+ 557 |Dev<--->Lbs |0x3 | Rsrv | reserve| 558 +------------+-------+--------------------------------+-------------+ 559 |Dev<--->Lbs |0x4 | Refresh_SessionKey_Req | refresh| 560 | | | | SessionKey| 561 | | | | request| 562 +------------+-------+--------------------------------+-------------+ 563 |Dev<--->Lbs |0x5 | Rsrv | reserve| 564 +------------+-------+--------------------------------+-------------+ 565 |Dev<--->Lbs |0x6 | Refresh_SessionKey_Rsp | refresh| 566 | | | | SessionKey| 567 | | | | response| 568 +------------+-------+--------------------------------+-------------+ 569 |Dev<--->Lbs |0x7 | Authentication_apply_devid_Req | request| 570 | | | | device ID| 571 +------------+-------+--------------------------------+-------------+ 572 |Dev<--->Lbs |0x8 | Authentication_apply_devid_Rsq | response| 573 | | | | device ID| 574 +------------+-------+--------------------------------+-------------+ 575 |Dev<--->Lbs |0x9 | Authentication_apply_devid_Cfm | confirm| 576 | | | | device ID| 577 +------------+-------+--------------------------------+-------------+ 579 Table 3: Protocol version definition 581 6. Get access service 583 As the number of device accesses increases, there will be bottlenecks 584 in the performance of single-node accesses, so the platform needs to 585 support the mode of multiple device accesses. To support this mode, 586 the devices are redirected to multiple access services by load 587 balancing server. After the device obtains the sessionKey through 588 two-way authentication, it initiates a request for access service 589 within the same TCP connection, and the message in the request is 590 encrypted with the sessionKey. 592 +------------+ +-------------+ 593 +------+ |Balance load| |Device access| 594 |Device| | ser^ice | | service | 595 +------+ +------+-----+ +------+------+ 596 | | | 597 Redirect---------------------------------+ | 598 | +--- F1:Request for getting a -----> | | 599 | | device access service address | | | 600 | | | | | 601 | <--- F2:Return a device access ----+ | | 602 | | ser^ice information | | | 603 +----------------------------------------+ | 604 | | | 605 Bussiness-----------------------------------------------------+ 606 | | | | | 607 | <------- Business message:AES128(message)----------> | 608 | | AES128 privatekey:sessionkey | | 609 | | | | | 610 +-------------------------------------------------------------+ 612 Figure 8: Get access service 614 7. Registration and Deregistration 616 After the device completes two-way authentication to obtain a 617 specific access service address, the device initiates a request to 618 register online through the MQTT protocol, and the application 619 message body in the request is encrypted using the sessionKey 620 obtained by two-way authentication. 622 +-------------+ +------------+ 623 | Device | | Platform | 624 |(MQTT Client)| |(MQTT Sever)| 625 +-----+-------+ +------+-----+ 626 | | 627 +------- F1:Device register and login(MQTT CONNECT) -------> 628 | | 629 <-------- F2:Register and respond(MQTT CONNACK) -----------+ 630 | | 631 <---------------- Business interaction --------------------> 632 | | 633 +---- F3:Send request for disconnect(MQTT DISCONNECT) -----> 634 | | 635 + + 637 Figure 9: Registration and Deregistration 639 a) F1: After the device and platform network connection is 640 established, the device sends a online request to the platform via 641 MQTTCONNECT, of which payload contains one or more encoded fields, 642 including: unique identifier of the client, Will subject, Will 643 message, username and password. 645 b) F2: The platform returns the response message to the device via 646 MQTTCONNACK to inform it whether it succeeded or not; 648 c) F3: Before disconnecting, the device sends a DISSCONNECT message 649 to the platform, indicating that it wants to disconnect normally, and 650 the platform will close the TCP/IP connection after receiving the 651 request. 653 8. Heartbeat 655 After the device has registered with the platform, it needs to send 656 heartbeat requests periodically according to the heartbeat interval 657 indicated in the registration request. The interval is usually 30s. 658 Used for: 660 a) Inform the platform that the device is alive when no other control 661 messages are sent from the device to the platform 663 b) Request the platform to send a response confirming that it is 664 alive. 666 c) Use the network to confirm that the network connection is not 667 disconnected. 669 +------+ +--------+ 670 |Device| |Platform| 671 +------+ +----+---+ 672 | | 673 +------ F1: Send a heartbeat request(MQTT PINGREQ) -----------> 674 | | 675 <--- F2: Respond to the heartbeat request MQTT PINGRESP) -----+ 676 | | 678 Figure 10: Heartbeat 680 9. Security Considerations 682 This entire memo deals with security issues. 684 10. IANA Considerations 686 This documents has no IANA actions. 688 11. Informative References 690 [MQTT2016] ISOIEC, "Information technology - Message Queuing 691 Telemetry Transport", . 694 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 695 Version 1.3", DOI 10.17487/RFC8446, August 2018, 696 . 698 Authors' Addresses 700 Bin Wang (editor) 701 Hikvision 702 555 Qianmo Road, Binjiang District 703 Hangzhou 704 310051 705 China 706 Phone: +86 571 8847 3644 707 Email: wbin2006@gmail.com 709 Shaopeng Zhou (editor) 710 Hikvision 711 555 Qianmo Road, Binjiang District 712 Hangzhou 713 310051 714 China 715 Phone: +86 571 8847 3644 716 Email: zhoushaopeng@hikvision.com 718 Chao Li (editor) 719 Guangzhou University 720 230 Wai Huan Xi Road 721 Guangzhou 722 510006 723 China 724 Email: lichao@gzhu.edu.cn 726 Chunming Wu (editor) 727 Zhejiang University 728 866 Yuhangtang Rd 729 Hangzhou 730 310058 731 China 732 Email: wuchunming@zju.edu.cn 734 Zizhao Wang (editor) 735 Zhejiang University 736 866 Yuhangtang Rd 737 Hangzhou 738 310058 739 China 740 Email: 22021272@zju.edu.cn