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.

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.

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: www.cisco.com/go/cgr1000-docs.

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:

https://www.cisco.com/c/en/us/support/cloud-systems-management/iot-field-network-director/products-installation-and-configuration-guides-list.html

Note	For a detailed description on the Cisco Resilient Mesh CLI, refer to Cisco Connected Grid WPAN Module for CGR 1000 Series Installation and Cisco Resilient Mesh Configuration Guide (Cisco IOS).

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.

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.

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

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”.

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.)

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

• Cisco.com user ID and password

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

https://tools.cisco.com/bugsearch/search

You can look up explanations for console error message strings found in system logs at the following location:

http://www.cisco.com/en/US/partner/support/tsd_most_requested_tools.html

• Cisco CG-OS Release Notes for CGR 1000

  http://www.cisco.com/go/cgr1000-docs

• Cisco Connected Grid Module Guides

  http://www.cisco.com/go/cg-modules

• Cisco CGR 1240 Hardware Installation Guide

  http://www.cisco.com/go/cgr1000-docs

• Cisco CGR 1120 Hardware Installation Guide

  http://www.cisco.com/go/cgr1000-docs

Cisco CGR 1000 and 2000 Series Connected Grid Antennas Guides

http://www.cisco.com/en/US/docs/routers/connectedgrid/antennas/installing/cg_antenna_install_guide.html

Cisco Network Modules and Interface Cards Regulatory Compliance and Safety Information

http://www.cisco.com/en/US/docs/routers/access/interfaces/rcsi/IOHrcsi.html