## 3 Proposed Mechanism
### Path Update (PU)  
In LPMC, a single TB uses only one channel, which ensures that a node does not need to switch channels to receive or forward packets. Therefore, whenever an overloaded channel is used by only one TB, CAD cannot allocate a new channel to that TB. A single TB using one channel can be overloaded due to many reasons, which include: (i) randomness of the node deployment, which place many nodes in a small area, (ii) dynamic path selection of the routing protocol, and (iii) nodes from a small portion of a large-scale dense network (usually far away from the sink) generating data at a very high rate. In such cases, LPMC partitions an overloaded TB into two TBs, and assigns a new channel to the newly created TB (_i.e._, a new TB consisting of some nodes of the overloaded TB). Therefore, paths are updated for a group of nodes in the overloaded TB, which will now use a new CDN to reach the sink. The path update component needs to find leaf nodes (_i.e._, a node that does not forward the data of other nodes) through which paths to the sink can be established. In case of failure to find such a node, we assume that a rate control mechanism is in place to restrict the source rates which will eventually decrease the channel load. The _path update_ module is initiated from the sink when the sink learns that an overloaded channel is used by a single TB. The sink first sends a unicast _path update message_ (PUM) to the CDN of the overloaded TB. The PUM contains the following fields: \(<source\), \(destination\), \(type\), \(tb\_ID>\). The \(source\) is the address of the PUM sender/forwarder, and \(destination\) is the address of an upstream node of the sender. LPMC assumes that every forwarding node keeps a list of its upstream nodes. The forwarding of a PUM is controlled by the value in \(type\) field. The \(type\) field has the value 1 or 2, and sink sets the type value to 1 while initiating a PUM. After receiving a PUM, a node either forwards it (when \(type\) value is 1) to its upstream node(s) or generates a PUM reply (when \(type\) value is 2). There may be cases where a PUM forwarder has multiple upstream nodes. In such cases, the PUM forwarder changes the \(type\) value to 2 and forwards the PUM to a randomly selected half of the upstream node(s). Because two or more branches join in this node, LPMC creates a new path for one of the branches and creates a new TB. If a node receives a PUM with \(type\) value 2, it is forced to broadcast a _path update message reply (PUMR)_ message. This PUMR creates a path from the node (_i.e._, PUMR generator) to the sink. The PUMR has the following fixed fields set by the source of the PUMR: \(<source\), \(destination\), and \(tb\_ID>\). The \(source\) is the address of PUMR generator, \(destination\) is the broadcast address, and \(tb\_ID\) is copied from the PUM. Every PUMR forwarding node (including the PUMR generator) appends the following fields to the PUMR: \(<forward\_node\_addr\), \(channel\_ID\), and \(hop>\), where \(forward\_node\_addrr\) is the address of the PUMR forwarder, \(channel\_ID\) is its current channel, and \(hop\) is the hop count of the node from the sink. Using the PUMR messages, the PUMR generator tries to find leaf nodes that can further forward the PUMR. However, such a node might be using a different channel. Therefore, PUMR is broadcasted in all of the channels one after another in order to find leaf nodes. The only leaf nodes that can forward a PUMR message are those with a hop count to the sink that is not greater than the value of the \(hop\) field in the last entry of the PUMR. A node broadcasts the PUMR in a channel and hears the channel for some period. If no leaf node forwards the PUMR within this period, it broadcasts in another channel. Therefore, nodes first forward the PUMR in the receiving channel to ensure that the upstream node (previous broadcaster) hears it. Eventually, the PUMR is received by the sink. If the sink receives multiple PUMRs, it chooses the shortest path.