"Pairwise:PairWise is a time hopping MAC that requires a node to form a separate channel for transmissionand reception with each of its neighbors. Note, in this paper, the term “channel” refers to a timeperiod as opposed to frequency or code. The resulting channels or RPs hop randomly in time,and nodes are only required to be awake during these periods to transmit or receive packetsto/from a given neighbor. Hence, given that these periods occur randomly, node pairs’communications are less likely to collide. As we will see later, nodes can precomputed their ownRPs schedule and compare that against their neighbors' RPs schedule in order to avoid collisions.Figure 1 shows how four sensor nodes use PairWise to communicate. Each pair of nodes has twochannels, one designated as {\\it uplink} and the other as downlink. The former channel is used toforward data to node-S, which in this example is acting as the sink node. On the other hand, thedownlink channel is used to transfer request messages from the sink to nodes in the WSNs.Notice that each link/channel in the WSN occurs randomly, and ideally, avoids each other.Moreover, nodes know exactly when they are supposed to rendezvous with a neighbor, andwhether a given period is used for transmission or reception. Lastly, the duty cycle of channels,i.e., the frequency of RPs, can be configured to match the rate of data flows. For example, nodesmay lower the duty cycle of their downlink channel if the sink node only communicates withthem occasionally.The following sections present key aspects of PairWise. 12 1) Neighbor Discovery: At startup, a node monitors the channel for Invite messages If after waiting forWaitNeighbor seconds and no Invite message arrives, the node broadcasts an Invite messageafter waiting for a random period of time, and waits a further WaitNeighbor seconds. Within thisperiod, if the node receives a channel request message (CRM), it proceeds according to the stepspresented in Step 2. Otherwise, it continues to monitor for WaitNeighbor seconds again, andrepeats the aforementioned process up to MaxInviteLimit times before going back to sleep. werefer to the node that sent an invite message as an inviter, and a neighboring node that wishes toreply as an invitee. Each Invite message is followed by a frame of NI slots, each of duration ?. Inaddition, each message has a number of seeds which are used by the invitee and inviter tocompute their RPs. A neighboring node intending to establish a channel with the inviter selectstwo seeds and two constants from the Invite message and a slot randomly. The invitee thentransmits its CRM in the chosen slot.2) Channel establishment: Recall that in every Invite message, there is a set of uplink and downlink seeds.Moreover, there are constants Ca and Cb. A sender decides on these parameters beforebroadcasting its Invite message. Upon receiving an Invite message, a node selects an uplink (Su)and downlink (Sd) seed, and constant Ca and Cb. These parameters are then stored in a tablecalled Neighbor_Tbl along with the start time of the last RP and the MRP.3) Broadcast support: channels we have created thus far are for unicast traffic. To support broadcast, a node canperform multiple unicast transmissions. Unfortunately, doing so creates unnecessary delays. Tosupport broadcast, each node advertises a broadcast seed Bs, which is then used by its neighborsto calculate a channel dedicated to broadcast traffic. This means each node has a uniquesequence of RPs which it uses to send broadcast messages. Conversely, each node knows thebroadcast periods of its neighbors, and hence knows when to wake up to receive broadcastpackets from a neighbor.4) Time Synchronization: 13PairWise does not require nodes to be synchronized. Hence, PairWise does not need atime synchronization protocol. Instead, a node maintains the clock drift between it and each of itsneighbors in a table. To ensure this table is up to date, all packets have a timestamp field, whichis then used by each node to calculate the time difference between it and the packet's sender.Figure 2 shows the transmit/receive RP of nodes A and B, where in this example node-A has apacket for node-B. Notice that node-B woke up earlier than node-A to account for anysynchronization errors that may have been caused by clock drifts. Hence, nodes using PairWiseare not required to maintain accurate clock drifts. After transmitting/receiving, a sensor nodecalculates the next RP for the corresponding node In order to conserve energy at each RP, a nodegoes back to sleep if no packet arrives after waiting for MaxWait seconds. From the figure, wecan see that a node only needs to be awake for a fraction of the RP. 14 "