## 5 The ATLAS MAC Protocol
### Medium Access Design
#### 5.2.1 Cluster-Head to Gateway (Ch-to-G) Communication  
As mentioned earlier, upon estimating the traffic load-status, each cluster-head piggy-backs the load index information (_i.e._, \(LN\)-bits) at each outgoing beacon and data packet. Hence, the gateway node \(G\) is well aware of the traffic load of the network and coordinates the medium access at each superframe accordingly. Note that the very first initial beacon (\(B\)) from node \(G\) at each superframe serves three purposes: (i) includes clock information for time synchronization; (ii) acts as a data request message; and (iii) serves for time-slot assignment purposes. The MAC operations for Ch-to-G are described below for each traffic load state:  
* _Low-load_ (Use of CAP and IP): In low-load state, the gateway \(G\) operates only in contention access period (CAP) mode, as shown in Figure 3(a). To do so, node \(G\) sets the data request field at the initial transmitted beacon \(B\) and waits for a time-out period (given by \(T_{to}\)) for possible data reception. The \(T_{to}\) period includes the maximum back-off interval plus one extra time slot as a guard time. However, in reply to the beacon if any cluster-head transmits a data packet, then node \(G\) accepts it and acknowledges its acceptance with a data-Ack beacon (setting the ACK bit in the beacon packet). In this case, the later beacon acts as another request for data reception in CAP mode. After a data request beacon transmission, the gateway always waits for \(T_{to}\) to receive data, otherwise it would goes into inactive period (IP) mode until the next superframe. In contrast, at the beginning of a superframe, each cluster-head \(Ch_{i}\) listens to the medium for the initial beacon \(B\) from \(G\) and determines the mode of medium access operation. A cluster-head with data remains awake until it is able to send the data or goes into IP otherwise. However, if the data request bit is found set in the received beacon, each \(Ch_{i}\) performs a random back-off to avoid collision with other potential cluster-heads (senders). A cluster-head with early back-off expiration sends a data packet and waits for a _short intra-frame space_ (SIFS) to receive a data-Ack from the gateway. If any cluster-head loses the contention, it pauses the back-off and updates the _network allocation vector_ (NAV) until the ongoing data transmission finishes. Another data-request beacon (_i.e._, data-Ack for the previous transmission) from the gateway resumes the back-off for such cluster-heads. Hence, the contention access period (CAP) in ATLAS is dynamically adjusted, where the inactive period of the nodes starts whenever there is no data available to send or receive. Unlike LDTA-MAC [3], the given load-adaptive approach is able to maximize the capacity utilization under low traffic. * _Moderate-load_ (Use of CAP, IP and CFP): At moderate-load, the gateway sequentially and dynamically uses the contention access period, inactive period and contention free period in a single superframe (Figure 3(b)). Furthermore, during CAP, a cluster-head is allowed to set a request in the data packet header for a guaranteed CFP time-slot (_i.e._, given by \(TS_{c}\)). The rationale behind using both CAP and CFP is to ensure maximum capacity utilization. This is because, as the load increases the contention also increases, hence a few cluster-heads might require additional slots for further data transmission in addition to CAP. The CAP operation in this case is similar to that in the low-load state. However, the inactive period starts here following the CAP and lasts until the CFP. The CFP in this current superframe continues until the start of the next superframe. The assignment of guaranteed time-slots in ATLAS duringmoderate-load is very simple and straightforward. Assuming \(C\) time-slots are required in the CFP of moderate-load status of the network. Hence, whenever the gateway receives a time-slot request from a cluster-head, it simply assigns the \(C\)-th time-slot \(TS_{c}\) using the data-Ack beacon during CAP.