Release Notes for Cisco Resilient Mesh Release 5.6.21

These release notes contain the latest information about using Cisco Resilient Mesh (formerly known as CG-Mesh) software with IPv6 Resilient Mesh Endpoints (RMEs) such as meters, and the Cisco IR509 WPAN Gateway and IR529 WPAN Range Extender.

Cisco Resilient Mesh is an embedded network stack for Smart Grid assets within a Neighborhood Area Network. Cisco Resilient Mesh provides end-to-end IPv6 communication and implements open-standard protocols at every layer in the network stack, including but not limited to IEEE 802.15.4e/g, 6LoWPAN, IPv6, RPL, UDP, and CoAP. In Smart Grid assets such as residential electric meters, the Cisco Resilient Mesh software functions within a dedicated Communications Module that connects to an Application Module through a PPP link.

New Features for RME Modules

The following table lists the enhancements specific to this release.

Table 1. Enhancements for RME Modules



First Cisco IOS/CG-OS Release that Supports the Feature

PRN message delivery enhancement

Enhancement of fast PRN message delivery by increasing broadcast PRN delay period and relay waiting time, reducing fast sync beacon request maximum waiting time, and reducing PRN relay times.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

PAN selection and migration enhancement

Enhancement of better PAN selection by balancing the weights of PAN size and route cost for PAN selection. Accelerating necessary migration, and reducing unnecessary migration, to avoid slow migration when the RPL route poisoning event occurs.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

Intra-PAN parent selection enhancement

Enhancement of better parent selection by reducing the possibility of selecting a parent with bad link quality if any better choice exists, and maintaining the RPL nature to avoid sudden or frequent changes.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

Fast reformation enhancement

Enhancement of Cisco Resilient Mesh fast reformation after power restoration without rebooting CGR manually.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

RF mesh stability

Improving the mesh stability especially after firmware upgrade.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

DAG size issue (IOS only)

Making the DAG size matching the actual number of DAGW nodes in the PAN and not to count the routing entries for their Ethernet interfaces.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

TLV 66 support

Provides the statistics of the mesh firmware upgrade process.

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

System Requirements

If you plan to run Cisco Resilient Mesh Release 5.6.21, you must have the following required hardware and software components:


Minimum Cisco IOS/CG-OS Software Release Required

Cisco 1000 Series Connected Grid Router

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

Cisco IR509 (SL-IR509-K9-10)


Cisco IR529 (SL-IR529-K9-10)




Supported Software Features

This section covers the supported software features.

Compromised Node Eviction

A compromised node is one where the device can no longer be trusted by the network and/or operators. Nodes within an IEEE 802.15.4 PAN must possess the currently valid Group Temporal Key (GTK) to send and receive link-layer messages. The GTK is shared among all devices within the PAN and is refreshed periodically or on-demand. By communicating new GTKs to only trusted devices, compromised nodes may be evicted from the network.


In its route-over architecture, Cisco Resilient Mesh performs routing at the network layer using the Routing Protocol for Low-Power and Lossy Networks (RPL).

Cisco Resilient Mesh requires a Cisco 1000 Series Connected Grid Router (CGR) to provide connectivity to other IPv6 networks. The CGR (Field Area Router (FAR)) must serve as a RPL Directed Acyclic Graph (DAG) root and store information reported in DAO messages to forward datagrams to individual nodes within the mesh network.


The 6LoWPAN adaptation layer adapts IPv6 to operate efficiently over low-power and lossy links such as IEEE 802.15.4. The adaptation layer sits between the IPv6 and IEEE 802.15.4 layers and provides IPv6 header compression, IPv6 datagram fragmentation, and optimized IPv6 Neighbor Discovery.

Frequency Hopping

Cisco Resilient Mesh implements frequency hopping across 64 channels with 400-kHz spacing in the 902 to 928 MHz ISM band. The frequency-hopping protocol used by Cisco Resilient Mesh maximizes the use of the available spectrum by allowing multiple sender-receiver pairs to communicate simultaneously on different channels. The frequency hopping protocol also mitigates the negative effects of narrowband interferers.

Firmware Upgrade Procedure

The Cisco Resilient Mesh bridge firmware can be installed by CLI or from IoT FND.

For more information on upgrading the firmware, see the latest Release Notes for Cisco 1000 Series Connected Grid Routers for Cisco IOS Release at:

FND Configuration

Cisco Resilient Mesh solution is managed and monitored by the Cisco IoT Field Network Director (FND), which provides the necessary backend network configuration, monitoring, event notification services, network stack firmware upgrade, as well as FND outage and meter registration. IoT FND also retrieves statistics on network traffic from the interface.

For more information on using IoT FND, refer to the latest version of Cisco IoT Field Network Director User Guide at:


CoAP Simple Management Protocol

Cisco Resilient Mesh implements the CoAP Simple Management Protocol (CSMP) for remote configuration, monitoring, and event generation over the IPv6 network. The CSMP service is exposed over both the mesh and serial interfaces.

Power-outage Notification

Cisco Resilient Mesh supports timely and efficient reporting of power outages and restorations.

In the event of a power outage, Cisco Resilient Mesh enters power-outage notification mode and the node stops listening for traffic to conserve energy. Cisco Resilient Mesh triggers functions to conserve energy by notifying the communication module and neighboring nodes of the outage. The outage notification is sent using the same security settings as any other UDP/IPv6 datagram transmission.

In the event of a power restoration, a Cisco Resilient Mesh node sends a restoration notification using the same communication method as the outage notification. The communication modules unaffected by the power outage event deliver the restoration notification.

Registration of Endpoint

You can register and manage Cisco Resilient Mesh Endpoints (RMEs) such as (meters) using the CSMP protocol.

Limitations and Restrictions

Cisco recommends that you review this section before you begin working with the module. These are known limitations that will not be fixed, and there is not always a workaround for these issues. Some features might not work as documented, and some features might be affected by recent changes to the CG-OS router hardware or software.

  • CSCub49104

    Symptom: Output from show mesh-security session all does not show all current mesh security sessions.

    Conditions: This issue occurs in the output of the show mesh-security session all command.

    Workaround: To find out the mesh-key status of a meter, use the show mesh-security session mac <mac-address> command.

Known Issues

This section summarizes known issues to the Cisco Resilient Mesh.

  • CSCvp83516

    Symptom: For Release 5.6.21, when a meter migrates to a better PAN, the event "Migrated to Better PAN" is not reported to FND by the meter.

    Workaround: There is no workaround.


This section addresses the Open and Resolved caveats that are relevant to Cisco Resilient Mesh. This section also provides information on how to use the Bug Tool Kit to find further details on the caveats.

Open Caveats

This section summarizes open caveats to the Cisco Resilient Mesh.

  • CSCvh62236

    Symptom: Configuring the DHCP server with lease time “infinite” for meters will cause slowness in the fast reformation.

    Workaround: Configure the lease time with any value other than “infinite”.

Resolved Caveats

This section summarizes resolved caveats specific to the this release.

  • CSCvd69068

    Symptom: IR529 cannot boot up until BBU completed drained when t-bit clear in 5.5.74.

    Conditions: This issue occurs when setting t-bit to clear via TLV 201, then posting unsupported TLV to IR529, and reload IR529. The IR529 cant bootup until BBU completed drained. Some unsupported TLV will cause IR529 to run into dead loop and can not boot until BBU is drained.

    Workaround: Wait for the BBU to complete drained.

  • CSCva80766

    Symptom: Nodes failed to join after outage on CGR and nodes. When the BBUs failed, the CGRs were expected to restart and the 5.6.10 meters should reboot. And the network should continue to reform as expected with meters recovering gradually. However, a majority of the 5.6 meters did not recover with just the power restoration of the meter. A manual reboot of the CGRs was required to recover them.

    Conditions: This issue is caused due to that mesh nodes were started earlier than the CGR/bridge, and the bridge may have responded before the initialization was done.

    Workaround: None.

  • CSCvg24253

    Symptom: After power outage, T1/T2 timer gets reset to a default value. When the T1/T2 timer gets reset, the leasing timer might be expired before the meter reach out to the DHCP server for IP renewal. As a result, DHCP might release the IP address from the pool and reassign it to another meter.

    Conditions: This issue occurs on the meters with firmware 5.6.10.

    Workaround: None.

  • CSCuz62996

    Symptom: Activating backup firmware in slot 3 may not work at all.

    Conditions: When a node receives a LoadRequest from FND for the particular firmware image in the backup slot, it may respond with an OK status but no action may be taken on the node side to activate the backup firmware and reload the node. The backup firmware may not be activated at all.

    Workaround: None.

  • CSCuu99714

    Symptom: Node RPL version increment fails to start over at 1 after reaching 255. After reaching 255, the node RPL version got stuck, while the rpl_version file in the persistent storage indicated that it had actually rolled over. In WPANpm debug, the node RPL version is out of sync:

    "2015 Jun 23 14:01:34.873098 wpanpm: recv RPL DIO from fe80::207:8108:3d:3e02, ver 255 (FAR ver 24), rank 256, dag_size 84, hops 1, etx 256"

    Conditions: When DAG version roll over from 255 to 1, node may remove all parents (preferred parent) and join other parents again later (that's why it's got shed from the RPL tree).

    Workaround: Reload the WPAN module.

  • CSCve67971

    Symptom: CGR WPAN Reload resolves Heard Not Read (HNR) issue. The affected meters are shown as UP on NMS, while fails to be read from Collection Engine. After reload the WPAN module or reload/power-cycle the affected meter, it becomes readable again. Also, some of those meters are recovered by themselves after some time (~2-3weeks).

    Conditions: Meters may allocate some global IP used by other neighbors before, which could cause the parent node fail to refresh the global IP and eui64 mapping.

    Workaround: Use eui64 as the suffix of the global IP. To minimize the impact, make sure nodes inside a PAN can allocate DHCP address from a pool with range of 64bits.

  • CSCvd25416

    Symptom: PRN not meeting the requirement that 90% of the PRN should be received in 15 min within 7 hops.

    Conditions: PRN test results show that when there are 287 nodes at the first hops with antenna, fast reformation fails to finish within 15 minutes. However, most node at first hops finished in 30 minutes (just before fast reformation timeout).

    Workaround: None.

  • CSCvc20306

    Symptom: Mesh PAN size is given more priority than the Mesh during mesh formation. Need to balance with route cost too.

    Workaround: None.

  • CSCuv84583

    Symptom: Convergence time for moving between CGRs is very high.

    Conditions: The issue occurs when the IR509s were connected a CGR which was powered off. The IR509s were not able to move over to another CGR in the vicinity even within an hour, mainly because it was stuck to its existing PANID.

    Workaround: None.

  • CSCvd25417

    Reduce the possibility of selecting a parent with a bad link if any better choice exists. Meanwhile, maintain RPL nature and avoid sudden or frequent changes.

    Workaround: None.

  • CSCve36625

    Symptom: CGE cannot sync new mesh key after clearing all the old mesh key in CGR.

    Conditions: The issue occurs when node is online with security enabled and synced with CGR old mesh key. Clear the old existing mesh key in CGR, node cannot sync new mesh key.

    Workaround: None.

  • CSCvh23355

    Symptom: Cisco Resilient Mesh FW 5.6.10 meters join the PAN, but after several hours will drop off from the Mesh.

    Conditions: The issue occurs when CGR WPAN or Range Extender and meters are running Cisco Resilient Mesh FW 5.6.10.

    Workaround: None. (Downgrade is not recommended.)

Accessing Bug Search Tool

You can use the Bug Search Tool to find information about caveats for this release, including a description of the problems and available workarounds. The Bug Search Tool lists both open and resolved caveats.

To access Bug Search Tool, you need the following items:

  • Internet connection

  • Web browser

  • user ID and password

To access the Bug Search Tool, enter the following URL:

Feature History


Cisco IOS/CG-OS Release

Feature information

Cisco Resilient Mesh firmware 5.6.21

Cisco IOS Release 15.6(3)M or CG-OS Release CG4(5)

Cisco Resilient Mesh enhancement.

Related Documentation

Consult the following resources for related information about the Connected Grid WPAN Module for technical assistance.