anchor.diff:  node, depending on configuration parameters provided to the `rbc_mesh_init()`
   function at runtime. Each mesh value will operate with their own instance of
   the Trickle algorithm, meaning that they will be rebroadcasted independently.
  -The handles addressing the values are stored as standard Bluetooth SIG
  -namespace descriptors, where the enumeration of each value is used as
  -mesh-global handles for this value. This descriptor may be read by external
  -nodes.
  +The handles addressing the values are stored as standard https://developer.bluetooth.org/gatt/Pages/GattNamespaceDescriptors.aspx[Bluetooth SIG
  +namespace descriptors], where the enumeration of each value is used as
  +a mesh-global handle.
  +
  +_NOTE:_ Because the Bluetooth SIG has defined namespace descriptor 0 as
  +"unknown", the handles start at 1, and trying to access handle 0 returns an
  +NRF_ERROR_INVALID_ADDR error.
   
   ==== Mesh metadata
   For ease of use, the service also provides a Metadata characteristic, providing
  
positive.code: 
  == Basic concepts
  
  This framework provides a connection-less, rebroadcasting infrastructure for
  synchronizing states across a set of BLE enabled nodes. All nodes receive all
  messages that are transmitted within their range, and any node may update the
  mesh-global states. There is no hierarchy, and no directed data links. 
  
negative.code: 
  
  === Trickle Algorithm
  The Trickle Algorithm was first presented by P. Levis of Stanford University
  and T. Clausen of LIX, Ecole Polytechnique in March 2010, and has since seen
  several revisions until it was published as RFC6202 in March 2011. The Trickle
  Algorithm provides a method of controlled packet flooding across a mesh of
  low-power lossy network nodes, by letting the nodes dynamically decide when to
  broadcast their values based on network activity and when the last update to
  state values arrived. 
  
  ==== A brief overview
  The algorithm operate in exponentially growing time intervals of size I, starting at
  interval size Imin, growing up to Imax. During an interval, it registers all
  incoming messages, where each message may be either consistent or inconsistent
  with the nodes current state (the definition of consistency is left for the 
  user to decide). For each consistent message, a counter value, C is increased
  by one, and for each inconsistent message, if the interval size I is larger
  than Imin, the interval timer is reset, and I is set to Imin. At the start of
  each interval, a timer T is set for a random time in the range `[I/2, I)`. When
  this timer expires, the node shall broadcast its state if the consistent
  message counter C is less than some redundancy constant K. At the end of each
  interval, the interval length (I) is doubled if `I * 2 < Imax`, and C is reset.
  
  The exponential growth and insconsistency reset functionality allows the nodes
  in the network to grow exponentially more silent as the state remains
  unchanged, but still stays responsive, as new information arrives. The
  consistency counter C and redundancy constant K allows the system to
  dynamically adjust to network density, as nodes will choose not to transmit if
  they've heard the same message from other nodes several times.
  
  ==== Usage in the framework
  The framework provides one instance of the Trickle Algorithm for each handle
  value pair (dubbed a Trickle instance). This means that when one value is frequently updated, while another
  one remains unchanged, the node only rebroadcasts the active value frequently,
  keeping the interval times for the static value high. Each handle-value pair
  also comes with a version number, which increases by one for each fresh write
  to a value. This version number, along with a checksum allows the framework to
  distinguish value consistency. If the node recevies a value update with a
  higher version number than its own, it will automatically overwrite the
  contents of the value data and notify the user. Any inconsistencies to both
  version number and checksum results in a reset of interval timing for the value
  in question. 
  
  ==== Weaknesses in algorithm and implementation
  While the algorithm in its intended form provides a rather robust and
  effective packet propagation scheme, some necessary adjustments introduces a
  few weaknesses. First off, using several instances of the algorithm on the same
  set of nodes yields a growth in on-air collisions and poorer frequency
  utilization control, as the individual instances take no consideration to
  the others' activity. This means that the scheme doesn't scale that well with
  several handle value pairs, and the user is asked to consider this during
  implementation. The choice of doing separate trickle instances is, however a
  result of a tradeoff: If the entire node state shared one trickle instance, the
  entire state would be rebroadcasted each time a part of it is updated, 
  and the amount of shareable data would be severely limited by packet size and
  packet chaining possibilities.
  
  Another weakness in the adaption is caused by the fact that the Softdevice Timeslot API
  won't let the framework get free access to the radio at all times, resulting in
  a significantly reduced on-air time for mesh related operations. When the
  Softdevice operates in an advertising state, this problem only has an impact of
  5-25% reduction in potential on-air time for mesh operations, but in a
  connected state with a short connection interval, the Softdevice may reduce
  timeslots by as much as 80%. This results in a lot of missed packets to the
  affected node, and may dramatically increase propagation time to this
  node. 
  
  === Timeslots
  The framework does all mesh-related transmissions in timeslots granted by the
  Softdevice Multiprotocol Timeslot API, operating directly on the radio hardware
  module. Timeslots are ordered and extended in chunks of 25ms, and the framework
  will attempt to seize the radio for as much as the Softdevice will allow.
  At the beginning of each timeslot, the framework samples the RTC0 Low Frequency
  Timer, and checks whether any timers related to the Trickle Algorithm have
  expired since the end of the previous timeslot. If this is the case, the
  framework does all pending operations immediately. After this initial "catch
  up" operation, the framework handles all operations as they appear for the
  remainder of the timeslot.
  
  For details about the Softdevice Multiprotocol Timeslot API, plese refer to the
  Softdevice Specification, available on the Nordic Semiconductor homepage.
  
  === Air interface packets
  === Resource allocation
  Yip Yip
  
  == Forum
  http://devzone.nordicsemi.com/[Nordic Developer Zone]
  