标签: 6lowpan

6LoWPAN与Internet互联网规范 重庆邮电大学400065 1.目的，意义，必要性 将IPV6技术应用到无线传感器网是当前网联网领域的研究热点。2007年IETF正式发布6LoWPAN规范RFC4919。接着发布了RFC4919,6LoWPAN的邻居发现灯协议。并成立了专门组织LOLL讨论低功耗路由器协议。ISA100.11a在2008年发布了ISA100a标准。它支持8LoWPAN规范。ZIgBee早期并不支撑IPV6的传感网技术。 在6LoWPAN的相关规范不断推出之际，其与Internet互联互通的方法和规范。国内外尚处于研究的启动阶段。6LoWPAN子网内部能够采用压缩地址的模式并有单独优化的路由方法，如何实现与Internet上标准IPv6协议及现有协议的无缝对接与互联。成为6LoWPAN技术发展的重要问题。此外，现有Internet尚处于IPV4向IPV6的过度阶段，各种网络结构和网络运行方式并存，而6LoWPAN规范使传感器网络直接过渡到IPAV 6技术。如何实现基于IPV6技术的传感器网络节点与IPV4/IPV6并存夏的Internet终端的端到端的数据通讯。成为制约6LoWPAN应用的关键瓶颈问题之一。 开展对6LoWPAN网络与Internet互联网技术和规范的研究，有助于推进IPV6无线传感器节点的产业化进程。促进网联网与Internet之间的融合，为6LoWPAN网络的大规模应用奠定标准和规范机场。 2.适用范围，技术内容 本课题将对6LoWPAN网络和Internet互联的架构，关键技术和实施方法进行研究。包括互联的体系结构，多协议网关，端对端安全机制，基于互联网的网络管理方法等核心问题"（3）开展对基于ipv6的多协议适配和转换方法的研究 （4）开展对互联网关多协议共存机制和方法的研究。 （5）开展对互联网关的功能和性能目标，技术规范的研究。 3.对6LoWPAN网络与互联互联的关键技术进行研究 （1）对互联网为目标的轻量级IPV6网络管理方法进行研究。 （2）开展对支持互联网和融合低功耗的 μ IPsec 安全协议的研究。 （3）开展对6LoWPAN与Internet一体化管控平台及规范的研究。   IETF成立了专门的6LoWPAN工作组研究IPV6在低功耗，低速无线网络的传输问题。 2007年6LoWPAN发布了RFC4919,阐述了该规范的需求和目的。接着发布的RFC4919规范了6LoWPAN的格式和功能。随后又发布了6LoWPAN的报头压缩和邻居发现的文档。 2008年另组建了小组研究低功耗有损网络上路由技术。同年ISA开始讨论工业无线电领域的标准，即ISA100.11a。与ISA100.11a.。与ISA100.11a相对应的是ZIgBee,WirelessHART和WIA-PA标准。 但是目前还尚无专门机构出台6LoWPAN网络与Internet互联的技术规范，导致在部署6LoWPAN网络时，无缝采用统一的标准和规实现Interent节点或者后台服务器的互通，不利于6LoWPAN技术在不同行业的广泛应用。 本课题对此问题的研究，将有力于我国推进IPV6的无线传感器网络的规模化和产业化进程。 《重庆邮电大学——思科公司（CISCO)绿色科技联合研发中心》完善Contiki开发平台改进了6LoWPAN协议。支持自组织入网与动态入网功能，支持GST时隙机制和基于调度的路由协议。考虑了对IEEE802.15.4C/E/G/等系列新标准的支持能力，完全自主开发了拥有全部代码源的6LoWPAN协议软件。研制了基于6LoWPAN的WSN/3G(TD-SCDMA,CDMA2000.WCDMA)网关和系列传感器节点，时现了端对端全IPV6通讯。  

Connext DDS to the rescue? Real Time Innovations announcement that it would soon make available its new Connext DDS real time publish-subscribe communications framework is what got me thinking about the implications of the IPv6-based 6LoWPAN Internet of Things and what it will take for embedded developers to integrate the new protocols into their connected designs. RTI may have a pub/sub implementation that will meet many of the diverse requirements of the still emerging commercial embedded Internet of Things, although most details of its new Connext DDS are still under wraps. RTI has built its new Connext DDS framework around three essential elements: 1. The DDS Integrator used to link independently developed DDS and non-DDS applications and which acts as a middleware to transform data types to provide interoperability between independently developed DDS apps; 2. Connext Messaging, which includes a variety of enhanced messaging capabilities, including Java Message Service (JMS) and distributed logging APIs, real-time data recording and playback, and run-time services for federation and persistence, an important consideration in many wirelessly connected 6LoWPAN-based IoT apps. 3. A small-footprint messaging capability for use on resource-limited devices using a subset of its DDS API and its DDS-RTPS (real-Time P/S) wire protocol. This will make the scheme scalable across the diverse range of 6LoWPAN-based IoT apps. The RTPS subset built to operate in constrained sensor and controller environments should make it possible for developers to build apps that are independent of the underlying transport and protocol. Unlike some 6LoWPAN IoT implementations, TCP and IP are not required. I suspect its use of a reliability protocol that supports Disconnected, Intermittent, and Low-bandwidth (DIL) operation, all too common in wireless sensor networks, makes it more attractive in 6LoWPAN implementations. Data is sent in a compact binary representation, and most metadata is only exchanged once, at discovery time. But the linchpin that makes it all hang together is an updated and much improved version of a dynamically modifiable framework that incorporates elements of DDS and a Relational Database Management System. This allows data distributed by the DDS to be automatically stored in a relational database management system and accessed via SQL or ODBC interfaces, and, conversely, allows the contents of a RDBMS to be automatically distributed via DDS. Rules are specified for translating between a DBMS table record and the DDS wire format representation. It provides mechanisms for preventing publication of data seen by DDS, and for preventing application of changes already made in a DBMS table. By allowing relational database table updates to be propagated in real time to the embedded nodes, each small footprint Connext device can make use of the DDS API to subscribe to a DDS topic associated with a data table. When the table is altered, either by an enterprise application (via SQL) or an application as small as that on an MCU-based sensor using the DDS API, the local table is updated and the update information is published via DDS for consumption by all interested DDS subscribers. This allows information to be seamlessly bridged from an enterprise application to an embedded real-time application. What I have learned so far about the new Connext DDS tool suite makes me think it will be a valuable tool in the development of next-generation sensor net designs. But until more information is available, I have these questions: * Is Connext tied only to pub/sub configurations of its own design, or is it flexible enough to be useable with other variations? * What is the lower range of MCU capability on which it can be used, and is its use dependent upon particular architectural features? * The documents I have seen so far only indicate that neither TCP or IP are required for operation. Is that because Connext is based on the UDP subset and can't operate with the use of TCP/IP? Or can either TCP or IP be used as options? * Some of the 6LoWPAN applications operate with amazingly small amounts of resident memory. How memory-intensive are low-end MCU-based implementations of the Connext DDS? A lot of these questions are likely to be resolved when the company formally rolls out Connext DDS. But, what has emerged so far is tantalizing in what it implies about the range of applications in which it can be used. As commercial opportunities arise outside of current mil/aero and factory system controller management applications, it certainly looks like RTI will have a head-start in a variety of pub/sub based IoT designs.  

The pace of development of next-generation "Internet of Things" (IoT) networks of wirelessly distributed sensors is ramping up, fueled by a first wave of IoT devices from companies such as TI, STMicro, and Digi International. Embedded developers are starting to explore commercial IoTs based on the current TCP/IP standard, and using paradigms such as the lightweight MQTT protocol for delivery over current Wi-Fi and Zigbee wireless sensor networks. In addition, researchers are already working on hundreds of projects using the next-generation IPv6-based 6LoWPAN protocols in a variety of wired and wireless environments. Many of those projects, especially within military and government organizations, such as the Department of Defense, Department of Homeland Security, and Department of the Interior, are now deploying networks of many thousands of sensors in a variety of monitoring applications. But before commercially viable projects can be developed using this technology, there are many questions that remain to be answered, including: * How do you manage thousands of remote devices occupying URLs in IPv6-based 6LoWPAN networks? * How do you collect information from such devices and then distribute it to the correct locations? * How do you allow decision makers to quickly communicate about the use of this information? * Once a decision is made about the status and deployment of information collected, how do you send that information back to the appropriate locations, even to the remote sensors themselves, and how do you do so in a manner that is compatible with the real-time, deterministic nature of such communications? To deal with these and other questions, many developers are making use of communications links based on a number of ad hoc and just barely standardized variations of the common publish-subscribe paradigm, combining them with a User Datagram Protocol subset of the full TCP/IP suite to achieve some degree of real-time and deterministic operation. Publish/Subscribe A typical publish-subscribe system is organized around the concept of publishers and subscribers. A system or device broadcasts (publishes) "topic issues" over a network to receiving devices (subscribers) that have registered an interest in that topic. Pub/sub middleware manages such broadcasts so that the subscribing remote sensor applications simply respond to the messages that are appropriate. In that sense, pub/sub is similar to the common message queue paradigms such as Java Message Service (JMS) and RSS feeds. DARPA and the DDS But for most real-time and deterministic embedded IoT applications involving controllers, networked sensors, robotics, and remote control, the current pub/sub mechanisms are at best ad hoc and at worst inadequate. Researchers are developing work-arounds using a number of related 6LoWPAN sub-protocols and mechanisms, but for sophisticated solutions, the best place to look is within projects funded by the U.S. Department of Defense and its Advanced Research Projects Agency (DARPA). Much DARPA's work on pub/sub has been centered around frameworks based on the Object Management Group's Data Distribution Service (DDS). In fact, for the U.S. military establishment almost anything about the real-time, deterministic use of pub/sub and DDS is a case of "been there, done that." Examples of such projects include the Tactical Internet, the Global Information Grid (GIG), and the Sensor Cloud Project. GIG is a communications project defined as a globally interconnected, end-to-end set of information capabilities for collecting, processing, storing, disseminating, and managing information on demand to soldiers, manned and unmanned units in the field, manned and unmanned aircraft, policy makers, and support personnel. In GIG, "situationally aware" networks of sensors will play a major role. The aim of DARPA's Tactical Internet is the creation of a command and control capability down to the smallest device and system, supported by a horizontally and vertically integrated digital information network. The work being done under DARPA sponsorship on proposed net-centric "sensor clouds" of diverse wired or wireless sensor networks is particularly intriguing. These networks are integrated into a cloud computing infrastructure that allows real-time sensor data collection and the sharing of computational and storage resources for sensor data processing and management. Real-time embedded system developers who have worked with interfacing or bridging to the Global Information Grid (GIG) have been faced with the challenge of maintaining deterministic behavior while moving large quantities of information over non-deterministic network transports. For the military, when combined with sophisticated database management systems, DDS represents a middleware solution that has a number of advantages, chief among them simplified network programming. Nodes that produce information (publishers) create "topics" (e.g., temperature, location, pressure) and publish "samples." DDS takes care of delivering the samples to all subscribers that declare an interest in that topic. DDS handles all the transfer chores. But for many of the new Internet of Things applications distributed across thousands and even millions of sensors, this approach has limitations relating to scalability: from large computer systems to limited resource MCUs, from low speed home and wireless networks to high speed backbone networks, from embedded MCU device developers who work in environments that are real-time and resource constrained to IT personnel familiar with implementing large server-based corporate DDS systems across heterogeneous networks.      

  CoAP is a web transfer protocol optimised for resource constrained networks typical of IoT and M2M applications. It is based on a REST architecture in which resources are server-controlled abstractions made available by an application process and identified by Universal Resource Identifiers (URIs).   The first significant difference between HTTP and CoAP is in the transport layer upon which they rely. HTTP relies on the Transmission Control Protocol (TCP), which uses a flow control mechanism ill-suited for LLNs. Moreover, its overhead is considered too high for short-lived transactions.   By comparison, CoAP is built on top of the UDP and therefore has significantly lower overhead and is capable of multi-cast support. To maintain all of the performance and resource advantages of UDP without giving up the reliability of the full TCP/IP, CoAP is organised into two layers.   The Transaction layer handles the single message exchange between end points. Four types of messages are handled by this layer: Confirmable (requires an acknowledgment), Non-confirmable (does not need to be acknowledged), Acknowledgment (acknowledges a Confirmable message) and Reset (indicates that a Confirmable message has been receive but context is missing to be processed).   The Request/Response layer is responsible for the transmission of requests and responses for the resource manipulation and transmission. This is the layer where the REST-based communication occurs. A REST request is piggybacked on a Confirmable or Non-confirmable message, while a REST response is piggybacked on the related Acknowledgment message.   Everything I read by the proponents of COAP argues that the use of this dual layer approach allows it to provide reliability mechanisms even without the use of TCP as the transport protocol. This is because a Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends the Acknowledgement message. An important aspect of COAP as far as response time is that when a server receives a request which it is not able to handle immediately, it first acknowledges the reception of the message and sends back the response in an off-line fashion.   To keep the message overhead as small as possible and avoid the significant overhead that the standard HTTP mechanism requires, COAP uses a number of techniques that will require embedded developers to carefully parse their impact on system response times and deterministic operation.   First, CoAP uses a short, fixed-length, compact binary header of 4B followed by compact binary options. A typical request has a total header of about 10-20B. Because a resource on a CoAP server will more often than not change over time, the protocol's been designed to allow a client to constantly observe the resources. The way this is done is that the client (the observer) registers itself to the resource (the subject) by means of a modified GET request sent to the server.   The server establishes an observation relationship between the client and the resource. Whenever the state of the resource changes, the server notifies each client having an observation relationship with the resource. The duration of the observation relationship is negotiated during the registration procedure. While not as neat and efficient as a purely UDP approach, it seems to resolve many of the performance issues.   Second, CoAP also supports other payload encoding standards, such as the widely used Extensible Markup Language (XML), but not your common ordinary garden-varity version. As it is presently implemented, the verbosity and parsing complexity of XML makes it inappropriate for constrained devices. One alternative is the more compact data representation in JSON.   JSON (JavaScript Object Notation) is a lightweight, text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures. But what JSON lacks is the flexibility of XML. As a result there are ongoing efforts to develop more compact binary XML-based representations such as the Extensible XML Interchange (EXI).   There is still a lot to learn about the impact of 6LoWPAN, COAP, and other protocols and how embedded developers can take advantage of them. I am still wading my way through the many articles and standards documents trying to learn as much as I can as fast as I can. In relation to COAP and its use of UDP, I still have a lot of questions.   First, even with all the thought that's been put into 6LoWPAN and into such protocols as COAP, will it be enough to penetrate more than the a small portion of embedded applications, especially those in hard real-time and deterministic applications in machine control and industrial control? The original uses of UDP were in wired networking applications that were by-and-large isolated from the outside network and so could make compromises on security and reliability. Not so in 6LoWPAN environments, which are naked to the world and require connectivity to the wider Internet.   Second, compared to the minimalistic UDP implementations that I have seen in the past, the UDP implementation within COAP is positively pudgy. Would this eliminate its use in most sensor networks using 8- and 16bit MCUs?   Third, why was the UDP subset the one that was chosen? Because of the sparse resources it requires, it was certainly most obvious choice. However, there are other variations, such as the TCP extensions for Transactions (T/TCP) that might have been a better starting point. While more complicated and less resource-efficient, T/TCP would be a case of taking one step back in order to take two steps forward: Even though it requires slightly more memory and is less efficient in terms of bandwidth than UDP, it has features that the COAP implementers had to add in to their UDP-derived scheme after the fact.   What is missing in almost everything I have read is an informed embedded systems developer's perspective. For that I look to you, in your comments here.    

The addition of wireless sensor connectivity to the IPv6 protocol in the form of 6LoWPAN presents a plethora of challenges and opportunities to embedded systems developers. They are also faced with an array of specialized commands such as GET, POST and PUT; old protocols such as XML and JSON used in new ways; and a variety of newly minted and unfamiliar ones such as COAP, IoT. LLN. REST. ROLL, RPL and WoT. But if you dig deep enough you will find an old friend— UDP , a subset of the familiar TCP/IP that underpins the now ubiquitous Internet. When the Internet burst upon us in the early 1990s, embedded systems developers were among the first to jump on board and use its connectivity. But in addition, they started taking its protocols apart to see if there were other ways they could be used in their designs. The problem they ran into was that in the drive to guarantee reliability of transmissions, the full TCP/IP suite is anything but real time and deterministic. In simplistic terms, all it does is guarantee delivery of a packet, not when that packet is delivered. The sending device has to wait until there is a response from the receiving node that the packet has arrive. During that period, no new instances of the same connection can be established. Great for reliability, but death on deterministic response times. But embedded developers found ways to improve response time and make apps more deterministic. They did this by stripping away that portion of the TCP/IP responsible for guaranteeing the reliability and delivery and using only the UDP subset. Because of its lack of a reliability mechanism, UDP has nothing to slow it down, so packets can be sent at full speed and as fast as the underlying physical device can send them. In many resource-constrained embedded designs, UDP's lack of overhead makes a big difference in throughput when compared to TCP. Also, unlike TCP, UDP is connectionless and, therefore without a connection state to be maintained, so memory size/usage is not much of an issue. And because a UDP transaction requires only two UDP datagrams, one in each direction, load on the network is minimised, further reducing response times. The downside, of course, is reliability, since if a UDP datagram is dropped the transaction is not completed. But in these early designs UDP was used only within closed wired networks, where everything is known: the nature of the connections, the number and location of the recipients, what each needs to get from the transmission, and what the response time of each node is. In such cases, the thinking went, many of TCP's reliability mechanisms were not necessary because all of the characteristics and status of the senders – and receivers – are known and therefore no response was needed to guarantee delivery. If it was necessary for the data transfer to be reliable, this reliability was built into the application layer of the design at much lower cost in terms of resources and response time. So where does the UDP play a role in the 6LoWPAN -driven, largely wireless Internet of Things (IoT), and how pivotal it is to the success of the IoT and the Web of Things (WoT) ? To understand that you first have to understand the function of 6LoWPAN, which is to enable the use of IPv6 in what are called Low-power and Lossy Networks (LLNs), such as those based on IEEE 802.15.4, as well as a second one for smart object internetworking over LLNs, called IPv6 Routing Protocol for Low-power and Lossy networks (RPL) . Its aim is to enable the use of standard web services, such as REST, XML, JSON, and others over LLNs without using application server gateways, in configurations somewhat akin to what Sun called "confederations of devices." This combination makes it possible for smart objects sitting out on wireless phones or sensors to be not only integrated with the Internet but also with the WoT and the IoT. If it works as its designers plan, smart object applications can be built on top of familiar Representational State Transfer (REST) architectures, which will allow apps to take advantage of loosely coupled Web services which can be shared and reused. In REST there is something called a Universal Resource Intentifier (URI) which represents resources controlled by the server. In this framework, the resources are decoupled by the services and can be arbitrarily represented by means of various formats, such as the now familiar XML or JSON. The resources are accessed and manipulated by an application protocol based on client/server request/responses. While REST is not tied to a particular application protocol at present, most of the REST implementations I'm aware of still make use of the Hypertext Transfer Protocol (HTTP) to manipulate resources by means of GET, POST, PUT, etc. By this means, IoT and Machine-to-Machine (M2M) apps which can be shared and reused are developed on top of web services. Wirelessly connected sensors in such an environment become abstract resources identified by URIs, represented with arbitrary formats, and can be used with the same methods as HTTP. Such RESTful WSNs drastically reduce the application development complexity, an important factor in most embedded designs. But as a consequence of the differences between traditional Internet apps and often wirelessly connected IoT or M2M applications, the use of web services in LLNs is not straightforward especially when any degree of real-time or deterministic operation is required. Also complicating the issue is that a lot of embedded IoT or M2M applications are short-lived. Because of their wireless nature, the web services that may reside in battery operated sensors and devices will most of the time be in the sleep mode and will wake up and are available only when needed. To deal with such issues, the Internet Engineering Task Force (IETF) Constrained RESTful environments (CoRE) Working Group has come up with a REST- based web transfer protocol called Constrained Application Protocol (CoAP) , that seems to depend on the ability of UDP to achieve something close to real time and deterministic operation.