All posts tagged: application

Constrained Application Protocol, or CoAP, is an application-layer networking protocol aimed primarily at application in networks of small resource-constrained embedded devices, wireless sensor networks and similar Internet-of-Things applications – helping to enable efficient networking and Internet connectivity with low overheads.

This protocol is particularly well suited to low-power wireless sensor networks with lossy networking and embedded control and automation systems, where such systems need to be supervised or controlled remotely via standard Internet networks.

CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialised requirements such as multicast support, very low overhead, and simplicity. These are valuable, important features for Internet-of-Things and machine-to-machine networks which tend to be deeply embedded and have much less memory and power available than traditional Internet-connected computers and mobile devices, meaning that efficiency and low overheads are important.

Furthermore CoAP enables embedded web services for even the most constrained devices and networks, while integrating with the web architecture and HTTP. Optimised for applications such as smart energy, home and building automation, asset tracking and cellular M2M, CoAP is emerging as an increasingly popular and important, standardised and interoperable technology in the Internet-of-Things sector.

CoAP includes several HTTP-like functionalities, but they have been fundamentally redesigned for operation in resource-constrained Internet-of-Things and embedded networks. Like HTTP, CoAP identifies resources using a universal resource identifier, and allows resources to be manipulated using HTTP-style methods such as GET, PUT, POST, and DELETE.

The protocol’s transaction layer can include four types of messages: confirmable, where acknowledgement is required, non-confirmable, where acknowledgement is not required, acknowledgement for a confirmable message, or reset, which indicates that a confirmable message is received but the information that would provide the context to allow it to be processed is missing.

CoAP makes use of two message types, requests and responses – using a simple binary header format that is not demanding to parse, and it is at this request/response layer where the REST-based communication occurs. This request/response model may be contrasted with other models such as the publish/subscribe model employed by other significant transport protocols in Internet-of-Things technologies, such as MQTT.

The base header may be followed by further options in an optimised Type-Length-Value format. CoAP is bound to UDP by default and optionally to datagram transport layer security or DTLS, meaning that CoAP can run on many common devices that support UDP or a UDP analogue, whilst providing the optional capability for secure CoAP, which mandates the use of DTLS as the underlying security protocol, providing the potential for good security in applications where authentication and security is an important requirement.

The Internet Engineering Task Force’s Constrained RESTful environments (CoRE) Working Group has done the majority of formal standardisation work with CoAP so far, with a set of IETF Requests for Comments soon to be released surrounding CoAP standards. The standardisation of CoAP by the IETF is in its final stages, and the protocol is soon entering into IETF Internet Standards documents that are aimed at standards-building to better enable the Internet of Things.

In order to make the protocol best suited to Internet-of-Things and and machine-to-machine applications, various new functionalities have been added. The CoRE working group has proposed low header overhead and low parsing complexity as key goals of the CoAP standard-building effort, along with support for the discovery of resources provided by known CoAP services, and mechanisms for simple subscription to a resource and resulting push notifications from that resource.

The mapping of CoAP with HTTP is defined, with RESTful protocol design, allowing proxies to be built to provide access to CoAP resources via HTTP in a uniform way without difficulty.

Access to CoAP resources via RESTful HTTP over TCP is particularly attractive for connecting embedded devices in consumer premises to the Internet, given the near universal availability of HTTP stacks for various diverse platforms.

The RESTful HTTP approach has found success in smaller-scale networks, particularly low-power and lossy wireless networks where message latencies are required to be within the order of seconds, for example for home automation and smart energy management networks.

As some examples of significant adoption of CoAP by major commercial players in the emerging Internet-of-Things industry, CoAP has already found success as a key enabling technology for Advanced Metering Infrastructure (AMI) applications for electricity utility companies deployed within Cisco Systems’ Field Area Network ecosystem.

LX2

Sensinode’s NanoService solution uses CoAP, together with their semantic web linking, resource directory and EXI technology, to provide end-to-end embedded web services for the Internet of Things.

If CoAP appeals as a protocol for your next IoT-enabled product or design revision – or you’re interested in any or all stages of the process and need a partner to help meet your goals – the first step is to discuss your needs with our team of experienced engineers that can help you in all steps of product design, from the idea to the finished product.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Muhammad AwaisMinimal IoT nodes with the CoAP Protocol

The new ZigBee Smart Energy 2.0 (SEP2.0) ZigBee Application Profile brings with it powerful new ZigBee capabilities for smart energy metering and control networks. With its ability to transport rate, demand, and load management messages to and from networks of smart energy appliances and the “Smart Grid” across a wide variety of wired and wireless media, the profile promises to be a key element of residential energy management systems.

Capable of passing energy-related messages across a HAN, or Home Area Network, using numerous different types of wired or wireless physical media, SEP2.0 is aimed at enabling the next generation of interactive smart appliances, HVAC, lighting and energy management systems – a “Smart Grid” of energy-efficient technology.

An IP-based HAN enabled by ZigBee Smart Energy 2.0 makes it possible to manage every aspect of the energy consumption and production of a home or building, whilst moving the information around a network built entirely around the Internet Protocol and interconnected with existing networks and the Internet.

The ZigBee Smart Energy 1.0/1.1 Profile was originally developed to allow 802.15.4/ZigBee low-power wireless mesh networks to support communication between smart meters and products that monitor, control and automate the delivery and consumption of electricity – and potentially other household utilities such as gas and water, moving into the future.

The functionality of the Smart Energy 1.x Profile was primarily intended to support the functional requirements of smart meters being used by electricity, gas and water utilities to manage their distribution networks, automate their billing processes, and communicate with customers’ energy management systems.

ZigBee-enabled smart meters act as communications gateways between the utility and the consumer, enabling the exchange of messages about pricing, demand response and peak load management. At least this technical capacity exists in theory, but electricity retailers will only bother with it if they have a revenue model in implementing such technology.

The ZigBee Smart Energy 2.0 Profile was created in response to the need for a single protocol to communicate with the growing universe of energy-aware devices and systems that are becoming common in homes and commercial buildings. For that reason, a diverse range of Function Sets were defined under SEP2.0, including Demand Response and Load Control, Metering, Billing, Pre-Payment, Directed Messaging, Public Messaging, Price Information, Distributed Energy Resource Management and Plug-in Electric Vehicle Management.

One or more of these Function Sets can be used to implement one of the Device Types defined in SEP2.0, such as Meters, Smart Appliances, Load Controllers, Smart Thermostats, In-Premises Displays, Inverters and Plug-in Electric Vehicles to name just a few.

ZigBee Smart Energy 1.x access the MAC/PHY layers of the 802.15.4 radio hardware via the ZigBee Pro protocol stack, but SEP2.0 replaces the ZigBee Pro protocol stack with the ZigBee IP stack, which uses the 6LoWPAN protocol to encapsulate the proprietary ZigBee packet structure within a compressed IPv6 packet. At the transport layer, IP packets bearing messages containing standard ZigBee command and data packets are exchanged using the familiar HTTP and TCP protocols.

When used in combination with the SEP2.0 Application Profile, the ZigBee IP stack provides a media-independent interface between the network and MAC layers of the stack that allows SEP2.0 packets to be carried across nearly any IP-based network.

A recent version of SEP2.0 includes support for communication across ZigBee and 802.11 wireless LANs as well as powerline communication (PLC) networks. SEP2.0 will also have improved future support for 802.15.4g, where the physical layer of the ZigBee/802.15.4 network is a sub-gigahertz radio at, say, 900 MHz for long-range outdoor telemetry or environments where the 2.4 GHz spectrum is congested. Support is also improving for other popular network technologies such as Ethernet.

Amongst the first SEP2.0 enabled products to hit the market will be Energy Service Portals (ESPs) which serve as a bridge between an energy utility’s communication infrastructure and the IP-based Home Area Network. These portals are provided to consumers by utility companies, and use the SEP2.0 Energy Services Interface profile to provide a bridge between the SEP1.x protocol used by most existing smart meters and the home’s IP-based network.

Zigbee Smart Energy

A ZigBee-enabled home energy management system can employ multiple Application Profiles to provide unified control of all home energy systems. For example, a smart home energy management system may use the Smart Energy (SE) profile to pass the utility’s load management and demand response messages to the home’s major loads and energy sources.

The Home Automation (HA) and RF for Consumer Electronics (RF4CE) profiles may then be used to communicate with Smart Appliances, lighting systems and other consumer-controlled products. Energy-aware homes will also employ a large number of end-point applications such as smart thermostats, in-home energy displays (IHDs), and tablet-based control panels that use SEP2.0-enabled ZigBee or Wi-Fi radio links to communicate with the home’s ESI and other elements of its energy management system.

SEP2.0-equipped network endpoints may also be implemented with the physical layer of the network using power line communications, networking smart appliances without RF spectrum congestion.

The ZigBee Alliance has created well-defined provisions for interoperability with, and upgrade paths from, the earlier SEP1.x standard to SEP2.0, which is good news for engineers looking to upgrade or to interoperate with existing SEP1.x technology. There is no significant increase in the processing power required in your hardware, although the key generation and exchange functions in the SEP2.0 security layer may be tough for 8-bit microcontrollers to handle unless they have security acceleration capability, handling the cryptographic maths in dedicated hardware.

Unfortunately, in terms of memory, SEP2.0 and the applications it supports require significant increases in both flash and RAM over what is required for most SEP1.x applications. Storing the code for a SEP1.x stack, a small application profile and a simple user application requires roughly 160 kb of flash in a typical microcontroller, plus 10-12 kb of RAM. Implementing comparable functionality under SEP2.0 requires about 256 kb of flash and 24-32 kb of RAM.

As an example of an existing hardware reference solution targeting SEP2.0, Texas Instruments provides an example consisting of the CC2533 802.15.4 RF system-on-chip, which runs the MAC/PHY layers of the SEP2.0 stack on its built-in 8051 core, combined with one of TI’s ARM7 Stellaris 9000-series microcontrollers as the application processor, running the remainder of the network stack and the application code.

Most of the microcontrollers in this powerful family include a fully-integrated Ethernet MAC, CAN interface, USB host controller, and enough memory and processing power to implement many simple SEP2.0 applications.

It is also worth considering some of the highly integrated single-chip solutions on the market such as the Texas Instruments CC2538, which integrates a 2.4 GHz 802.15.4 radio, ARM Cortex-M3 32-bit microcontroller core, hardware security acceleration for SEP2.0 and plenty of flash and RAM to support the ZigBee IP stack, SEP2.0 profile and application code with support for over-the-air firmware flashing capability for updates in the field, all in a single chip.

As you have just read, the new profile offers a great amount of promise in terms of functionality and convenience for the end user. Here at the LX Group our engineers have an excellent understanding of the Zigbee platform and have put this to use to create various systems for a wide range of customers – and we can do this for you too.

To get started, join us for a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

Muhammad AwaisThe new Zigbee Smart Energy 2.0 Application Profile