idnits 2.17.1 draft-wang-core-opcua-transmission-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 03, 2018) is 2240 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) == Unused Reference: 'RFC8075' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-coap-pubsub' is defined on line 526, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-wang-core-opcua-transmition-requirements-02 == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CoRE P. Wang 2 Internet Draft C. Pu 3 Intended status: Standards Track H. Wang 4 Expires: September 4, 2018 J. Wu 5 Y.Yang 6 L. Shao 7 Chongqing University of 8 Posts and Telecommunications 9 J. Hou 10 Huawei Technologies 11 March 03, 2018 13 OPC UA Message Transmission Method over CoAP 14 draft-wang-core-opcua-transmission-03 16 Abstract 18 OPC Unified Architecture (OPC UA) is a data exchange specification 19 that provides interoperability in industrial automation. With the 20 arrival of Industry 4.0, it is of great importance to implement the 21 exchange of semantic information utilizing OPC UA Transmitting in 22 CoAP. This document provides some transmission methods for message 23 of OPC UA over CoAP. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on September 4, 2018. 48 Copyright Notice 50 Copyright (c) 2018 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 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction ................................................ 2 66 1.1. Conventions and Terminology ............................ 3 67 2. Overview of OPC UA .......................................... 3 68 2.1. Protocol Stack ......................................... 3 69 2.2. Request/Response Model ................................. 5 70 3. Specification of OPC UA over CoAP ........................... 6 71 4. Transmission scheme ......................................... 7 72 4.1. Direct transmission .................................... 7 73 4.2. REST transmission for OPC UA ........................... 8 74 5. Publish subscription for OPC UA over CoAP ................... 9 75 6. Use Cases of OPC UA over CoAP ............................... 9 76 6.1. Factory data monitoring based on web pages ............. 9 77 6.2. Offline/Online diagnostic system for resource-constrained 78 factories .................................................. 10 79 6.3. Factory data analysis based on cloud .................. 11 80 7. Security Considerations .................................... 11 81 8. IANA Considerations ........................................ 11 82 9. References ................................................. 11 83 9.1. Normative References .................................. 11 84 9.2. Informative References ................................ 12 85 Authors' Addresses ............................................ 13 87 1. Introduction 89 Internet of things is one of the attractive applications for CoAP 90 [RFC7252]. Utilizing OPC UA [IEC TR 62541-1] Transmitting over CoAP 91 could meet the demand for industry 4.0 based on the exchange of 92 semantic information [I-D.wang-core-opcua-transmition-requirements]. 93 In resource-constrained scenarios, OPC UA can effectively use energy, 94 improve productivity and shorten the product manufacturing cycle by 95 building information model and using its cross-platform 96 characteristic. Similar to OPC UA, CoAP message is exchanged in 97 server/client mode. However, both of them have specific clients and 98 servers. Driven by this, to implement OPC UA Transmitting over CoAP, 99 the main problem to be solved is how OPC UA packets are transmitted 100 over CoAP. For the transport layer of OPC UA, the main message 101 transmission method is TCP or HTTP. It is worth noting that the 102 design of CoAP is inspired by HTTP, thus, there are some 103 similarities in transmission method between them. This document 104 provides some transmission methods for message of OPC UA over CoAP, 105 so that the communication between OPC UA client and OPC UA server 106 could be established. 108 1.1. Conventions and Terminology 110 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in 113 [RFC2119]. 115 OPC: OLE for Process Control 117 OPC UA: OPC Unified Architecture 119 SOAP: Simple Object Access Protocol 121 REST: Representational State Transfer 123 HMI: Human Machine Interface 125 2. Overview of OPC UA 127 OPC Unified Architecture (OPC UA), standardized as IEC 62541, is a 128 client-server communication protocol developed by OPC Foundation for 129 safety, reliable data exchange in industrial automation. It is the 130 evolution product of OPC (OLE for Process Control, where OLE denotes 131 Object Linking and Embedding), the widely used standard process for 132 automation technology, and is of great importance in realizing 133 industry 4.0. By introducing Service-oriented architecture (SOA), 134 OPC UA enables an open, cross-platform communication with the 135 advantages of web services, robust security and integrated data 136 model. 138 2.1. Protocol Stack 140 OPC UA is an application layer protocol that can be built on 141 existing layers 5, 6 or 7 protocols such as TCP/IP, TLS or HTTP. The 142 OPC UA application layer consists of four sublayers: UA Application, 143 Serialization Layer, Secure Channel Layer and Transport Layer (see 144 Figure 1). 146 Serialization Layer includes two kinds of data encoding methods: UA 147 Binary and UA XML. The UA XML, based on SOAP/HTTP or SOAP/HTTPS, is 148 firewall friendly. On the other hand, the UA Binary, with least 149 overhead and resource cost, offers an optimized speed and throughput. 151 The security layer varies according to the selected encoding format. 152 For the HTTPS-based situation, security is implemented at TLS but 153 Security Channel should still be presented even empty. It is 154 worthwhile noting that the communication based on SOAP/HTTP has been 155 deprecated since 2015, due to the lack of industrial approbation in 156 the WS Secure Conversation. 158 For the transport layer (not the layer in OSI 7 layer model), 159 options can be UA TCP, HTTPS, SOAP/HTTPS, and SOAP/HTTP. OPC UA 160 defines a UA TCP protocol, which differs from HTTP in two main 161 features: the allowance of responses to be returned in any order and 162 to be returned on a different TCP transport end-point. In addition, 163 UA TCP defines the interaction with the upper security channel. 165 +-------------------------------------------------------+ ------ 166 | UA Application | 167 +-------------------------------------------------------+ 168 +--------------------------+ +--------------------------+ 169 | UA Binary | | UA XML | 170 +--------------------------+ +--------------------------+ 171 +--------------+ +--------------+ App 172 | UA Secure | | WS Secure | 173 | Conversation | | Conversation | Layer 174 +--------------+ +--------------+ 175 +--------------+ +---------+ +---------+ +--------------+ 176 | | | | | SOAP | | SOAP | 177 | UA TCP | | HTTPS | |---------| |--------------| 178 | | | | | HTTPS | | HTTP | 179 +--------------+ +---------+ +---------+ +--------------+ ------ 180 +-------------------------------------------------------+ 181 | TCP/IP | 182 +-------------------------------------------------------+ 184 Figure 1: Layering of OPC UA over TCP/IP 186 2.2. Request/Response Model 188 The message exchange in UA binary mode is illustrated in Figure 2. 189 After opening the socket, the client starts the connection with the 190 server by using "hello" (HEL) and "acknowledge" (ACK) messages. 191 Afterwards, a pair of messages is needed to open the security 192 channel and define the encryption property. Then another two pairs 193 of messages are exchanged so as to create and activate a session 194 between the client and the server respectively. After these steps, 195 the connection is initiated and the client can send request messages 196 for services. When the request/response process is finished, a 197 reverse process is required for disconnection. 199 Client Secure UA UA Secure Server 200 Channel TCP TCP Channel 201 | | | Open Socket | | | 202 | | | - - - - - - - - - > | | | 203 | | | Hello | | | 204 | | | - - - - - - - - - > | | | 205 | | | Acknowledge | | | 206 | | | < - - - - - - - - - | | | 207 | | | | | | 208 | | |OpenSecureChannelReq | | | 209 | | - - - - - - - - - - - - - - - - - > | | 210 | | |OpenSecureChannelRes | | | 211 | | < - - - - - - - - - - - - - - - - - | | 212 | | | | | | 213 | | | CreateSessionReq | | | 214 | - - - - - - - - - - - - - - - - - - - - - - - - - > | 215 | | | CreateSessionRes | | | 216 | < - - - - - - - - - - - - - - - - - - - - - - - - - | 217 | | | ActivateSessionReq | | | 218 | - - - - - - - - - - - - - - - - - - - - - - - - - > | 219 | | | ActivateSessionRes | | | 220 | < - - - - - - - - - - - - - - - - - - - - - - - - - | 221 | | | | | | 222 | | | Request | | | 223 | = = = = = = = = = = = = = = = = = = = = = = = = = > | 224 | | | Response | | | 225 | < = = = = = = = = = = = = = = = = = = = = = = = = = | 227 Figure 2: Request/Response Process of UA TCP 229 3. Specification of OPC UA over CoAP 231 As mentioned in section 2.1, OPC UA communications can be conducted 232 through four options, among which two are related to HTTPS: HTTPS => 233 UA Binary; HTTPS => SOAP => UA XML. 235 Constrained Application Protocol (CoAP) is an application layer 236 protocol for constrained nodes and networks, which is designed to 237 easily translate to HTTP for integration with the web. Although CoAP 238 is built on the unreliable transport layer UDP, it offers a security 239 mode binding to Datagram Transport Layer Security (DTLS). This 240 document proposes a transmission scheme based on CoAPs (CoAP + DTLS) 241 for constrained scenarios. The transmission based on CoAP over 242 Transport Layer Security (TLS) is available [RFC8323]. 244 The protocol stack of the CoAP based OPC UA is illustrated in Figure 245 3, including two options at Serialization Layer: UA Binary and UA 246 XML. OPC UA packets are encoded in either binary or xml format, and 247 the option field in the CoAP header can specify parameters that 248 support both formats. Therefore, according to the format specified 249 by the CoAP header, the entire packet of the OPC UA can be 250 encapsulated in the payload of the CoAP message for direct 251 transmission. 253 +-------------------------------+ ------ 254 | UA Application | 255 +-------------------------------+ 256 +--------------+ +--------------+ 257 | UA Binary | | UA XML | App 258 +--------------+ +--------------+ 259 +-------------------------------+ 260 | Secure Channel | Layer 261 +-------------------------------+ 262 +-------------------------------+ 263 | CoAP | 264 +-------------------------------+ ------ 265 +-------------------------------+ 266 | UDP, DTLS | 267 +-------------------------------+ 269 Figure 3: Layering of OPC UA over UDP 271 Both binary and XML encoding modes are based on the CoAP with an 272 empty UA secure channel in between. For the XML encoding mode, since 273 CoAP layer supports XML encoding format, the SOAP layer in the 274 original stack is not needed. 276 4. Transmission scheme 278 4.1. Direct transmission 280 The transmission of OPC UA supports TCP protocol and HTTP protocol. 281 CoAP is seen as a simplified HTTP protocol so that it can be applied 282 to resource-constrained network. Therefore, this document considers 283 the use of CoAP to directly transfer OPC UA messages. OPC UA packets 284 are encoded in either binary or xml format, and the optional fields 285 in the CoAP header specify parameters to support these two formats. 286 Therefore, according to the format specified by the CoAP header, the 287 entire packet of the OPC UA can be encapsulated in the payload of 288 the CoAP message for direct transmission, as shown in Figure 4. 289 According to CoAP, noted that this method of transmission needs to 290 be modified on the server side and the client side of the OPC UA 291 according to CoAP. 293 + - - - - - - + CoAP Request + - - - - - - + 294 | UA client | - - - - - - - - - - > | UA server | 295 | | < - - - - - - - - - - | | 296 + - - - - - - + CoAP Response + - - - - - - + 298 Figure 4: Direct transmission OPC UA based on CoAP 300 For supporting HTTP, a CoAP proxy can be established between OPC UA 301 client and OPC UA server. 303 As shown in Figure 5, assuming all OPC UA servers are based on CoAP, 304 and all OPC UA-CoAP servers can be considered to form a constrained 305 network, then introducing a UA-to-CoAP proxy at the boundary of the 306 network. When a traditional OPC UA client initiates an HTTP request 307 to the UA-CoAP servers which is in the constrained network mentioned 308 above, the UA-to-CoAP proxy maps the http request to the 309 corresponding CoAP request and sends it to the UA-CoAP server in the 310 network. After receiving the request, the UA-CoAP server sends a 311 response to the UA-CoAP proxy. The proxy maps the CoAP response to 312 the HTTP response and returns it to the UA client. For the UA client, 313 the network proxy and conversion are transparent, in this way, the 314 transfer of OPC UA in CoAP does not need to make any changes to the 315 UA Client. 317 - - - - - - - - - - - - - - - - 318 // + - - - - + \\ 319 || | UA-CoAP | || 320 || // | server | || 321 || // + - - - - + || 322 || // || 323 || // || 324 + - - - + HTTP Request + - - - - - - + CoAP Request + - - - +|| 325 | UA | - - - - - - - - > | HTTP-to-CoAP| - - - - - - - > |UA-CoAP||| 326 | client| < - - - - - - - - | PROXY | < - - - - - - - | server||| 327 + - - - + HTTP Response + - - - - - - + CoAP Response + - - - +|| 328 || \\ || 329 || \\ || 330 || \\ || 331 || \\ + - - - - + || 332 || \\ | UA-CoAP | || 333 || | server | || 334 \\ + - - - - + // 335 - - - - - - - - - - - - - - - - 336 Figure 5: Proxy for OPC UA to CoAP 338 4.2. REST transmission for OPC UA 340 OPC UA is a set of data which exchange specifications for industrial 341 communication, the core of the OPC UA protocol are information 342 modeling and transmission, which marks each node in the address 343 space with a unique identifier. A series of state interactions are 344 needed before performing normal reading and writing, including 345 message handshaking, opening a secure channel, creating a session, 346 activating a session, etc. Besides, some states also need to be 347 maintained during read and write operations. 349 In OPC UA, each node has an independent identifier in the address 350 space, and different types of nodes can establish contact with each 351 other by referencing. OPC UA defines a variety of services, and 352 these services are fixed, because of this, the users cannot modify 353 OPC UA services according to their own ideas. In general, services 354 in OPC UA cannot be considered stateless, but many of them which are 355 also commonly used are inherently stateless, e.g. FindServers, Read, 356 Write [RICO]. The above features are in line with the REST 357 architecture, due to CoAP is based on the REST architecture. 358 Therefore, it is possible to simplify the interaction before the OPC 359 UA performs the normal communication, and carry the OPC UA message 360 by using the communication mode of the CoAP. Communication process 361 is shown in Figure 6. 363 + - - - - + + - - - - + 364 | client | | server | 365 + - - - - + + - - - - + 366 | | 367 | | 368 | CoAP Request | 369 | - - - - - - - - - > | 370 | CoAP Response | 371 | < - - - - - - - - - | 373 Figure 6: REST architecture communication of OPC UA 375 In Figure 2, the traditional OPC UA requires a series of 376 interactions between normal read and write operations. Figure 6 377 shows that when using CoAP to carry OPC UA message, the interaction 378 process is significantly reduced, which is conducive to the 379 application of OPC UA in the restricted scenes. The cost of 380 simplifying the interaction process is that the secure channel 381 number is set to 0 by default, how to conduct secure data 382 interaction needs further discussion. 384 5. Publish subscription for OPC UA over CoAP 386 As an application sublayer, CoAP provides publish-subscribe 387 functionality, primarily for resource or network-constrained 388 scenarios. Introducing proxy into the network [I-D.ietf-core-coap- 389 pubsub], when a node needs to sleep, the node information is sent to 390 the proxy agent, when another node requests to obtain information of 391 this node, the broker release function can provide information. OPC 392 UA defines the publish-and-subscribe function as a service in the 393 service set. The client initiates the subscription request directly 394 to the server, and the server periodically sends the information to 395 the client. Comparing the characteristics of the two protocols, it 396 is found that each of them has its own advantages. Joint design can 397 be conducted for constrained applications. 399 TODO. 401 6. Use Cases of OPC UA over CoAP 403 6.1. Factory data monitoring based on web pages 405 Description: At present, the monitoring and management systems of 406 the factory mostly exist in the form of software on the PC and the 407 mobile. The drawback is that when the whole factory system is needed 408 to upgrade, the monitoring software must be upgraded as well. It may 409 cause the huge workload that will bring the time and financial 410 burden on the factory. CoAP is a HTTP-like communication protocol 411 designed specifically for resource-constrained environments so that 412 can be used in the factory because the sensor nodes in the factory 413 mostly are resource-constrained. CoAP can easily transform to HTTP 414 and OPC UA can consolidate the different protocols in the plant by 415 building a unified information model. 417 Goal: PC and mobile devices can check and monitor the data by 418 visiting WEB pages after CoAP is converted to HTTP. Avoiding large- 419 scale software upgrades caused by system upgrades, while also 420 reducing the development of mobile software, thereby reducing 421 factory costs. 423 Requirements: the OPC UA information model should be encapsulated 424 into CoAP data load. Because of the capacity limitation of UDP 425 packet (MTU is 1472 bytes), in some cases, it is needed to compress, 426 fragment, and reassemble packets. 428 6.2. Offline/Online diagnostic system for resource-constrained 429 factories 431 Description: There are two modes existing in the factory's self- 432 diagnosis system, the offline mode and the online mode. In the 433 offline mode, the self-diagnostic device could use getHistorical, a 434 service from OPC UA, to get historical Data. In the online mode, 435 Both OPC UA and CoAP support pub/sub so that the monitoring system 436 can obtain the data from a specific device in a short reaction time 437 to determine its operating status. CoAP, as a resource-constrained 438 factory transmission protocol, can easily access many web services 439 APIs, add functionality that the factory can implement and let the 440 system have a certain degree of expansibility. OPC UA could create a 441 unified information model that realizes factory interoperability and 442 protocol uniformity. 444 At same time, the controller node can diagnose and regulate other 445 nodes by receiving their data rather than transferring them to HMI 446 (The M2M Communication). Generally, using UDP is the best choice, 447 however, CoAP's UDP not only has excellent stability but also has 448 relatively few packet loss rates. The unified model of OPC UA 449 enables all nodes to communicate without obstacles. 451 Goal: Using OPC UA over CoAP to enable factory offline history data 452 diagnostics, online real-time monitoring, publish subscriptions and 453 Achieving network nodes M2M communication. 455 Requirements: OPC UA uses SOA architecture, while CoAP uses REST 456 architecture, it is necessary to design a reasonable architecture 457 for OPC UA over CoAP. 459 6.3. Factory data analysis based on cloud 461 Description: Currently, there are many clouds (AWS, Windows Azure, 462 etc.) which have different kinds of APIs. These clouds could achieve 463 machine learning, data-flow analysis and so on for factory's data. 464 Using CoAP can effectively access these interfaces and fully take 465 advantage of clouds capabilities. At present, many factories have 466 begun to use the cloud to improve production status, So the biggest 467 benefit to use CoAP in factories is that CoAP could let devices to 468 use cloud's applications in resource-constrained factories so that 469 to achieve intelligent control. OPC UA can consolidate the different 470 protocols in the plant by building a unified information model. 471 Based on the content mentioned above, the field devices in the 472 factories can transfer their data directly and immediately to the 473 cloud without sending them to border routers or HMI. 475 Goal: Using OPC UA over CoAP to transfer field devices' data to the 476 cloud. 478 Requirements: Using OPC UA to modeling the different types of data 479 in the plant and then using CoAP to directly transfer the factory's 480 data to the cloud. 482 7. Security Considerations 484 This document does not add any new security considerations beyond 485 what the referenced technologies already have. 487 8. IANA Considerations 489 This memo includes no request to IANA. 491 9. References 493 9.1. Normative References 495 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 496 Application Protocol", RFC 7252, June 2014, 497 . 499 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 500 Requirement Levels", RFC 2119, March 1997, 501 . 503 [RFC8075] Castellani, A., Loreto, S., and A. Rahman, "Guidelines for 504 HTTP-to-CoAP Mapping Implementations", RFC 8075, November 505 2016, . 507 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 508 Silverajan, B., and B. Raymor, "CoAP (Constrained Application 509 Protocol) over TCP, TLS, and WebSockets", RFC8323, February 510 2018. 512 9.2. Informative References 514 [IEC TR 62541-1] 515 IEC, "OPC unified architecture-Part1:Overview and concepts- 516 IEC 62541", 2016, < 517 https://webstore.iec.ch/preview/info_iec62541- 518 1%7Bed2.0%7Den.pdf>. 520 [I-D.wang-core-opcua-transmition-requirements] 521 Wang, H., Pu, C., Wang, P., Yang, Y., and D. Xiong, 522 "Requirements Analysis for OPC UA over CoAP", draft-wang- 523 core-opcua-transmition-requirements-02 (work in progress), 524 December 2016. 526 [I-D.ietf-core-coap-pubsub] 527 Koster, M., Keranen, A., and J. Jimenez, "Publish-Subscribe 528 Broker for the Constrained Application Protocol(CoAP)", 529 draft-ietf-core-coap-pubsub-03 (work in progress), February 530 2018. 532 [RICO] Gruner, Sten, Julius Pfrommer, and Florian Palm. "RESTful 533 industrial communication with OPC UA." IEEE Transactions on 534 Industrial Informatics 12.5 (2016):1832-1841. 535 537 Authors' Addresses 539 Ping Wang 540 Chongqing University of Posts and Telecommunications 541 2 Chongwen Road 542 Chongqing, 400065 543 China 545 Phone: (86)-23-6246-1061 546 Email: wangping@cqupt.edu.cn 548 Chenggen Pu 549 Chongqing University of Posts and Telecommunications 550 2 Chongwen Road 551 Chongqing, 400065 552 China 554 Phone: (86)-23-6246-1061 555 Email: mentospcg@163.com 557 Heng Wang 558 Chongqing University of Posts and Telecommunications 559 2 Chongwen Road 560 Chongqing, 400065 561 China 563 Phone: (86)-23-6248-7845 564 Email: wangheng@cqupt.edu.cn 566 Junrui Wu 567 Chongqing University of Posts and Telecommunications 568 2 Chongwen Road 569 Chongqing, 400065 570 China 572 Phone: (86)-18580183135 573 Email: wjr930914@gmail.com 574 Yi Yang 575 Chongqing University of Posts and Telecommunications 576 2 Chongwen Road 577 Chongqing, 400065 578 China 580 Phone: (86)-23-6246-1061 581 Email: 15023705316@163.com 583 Lun Shao 584 Chongqing University of Posts and Telecommunications 585 2 Chongwen Road 586 Chongqing, 400065 587 China 589 Phone: (86)-23-6246-1061 590 Email: yjsslcqupt@163.com 592 Jianqiang Hou 593 Huawei Technologies CO.,LTD 594 101 Software Avenue, 595 Nanjing 210012 596 China 598 Phone: (86)-15852944235 599 Email: houjianqiang@huawei.com