在我們所提出的 CR-MAC protocol 中，我們將時間分為多個 frame，並由數 個 frame 構成一個 superframe。在控制信號頻帶上每個 frame 包含以下幾個區段：
Beacon (B), Association Period for SUs (ASPSU), Report Collection Period (RCP), Association Period for SDs (ASPSD), and Resource Request Period (RRP). 在我們的 實作中，考量硬體的限制與同步的準確性，我們插入一個 10ms 的 guard time 在 連續的兩個區段之中。而在 data channel 上每個 frame 包含以下幾個區段： Quiet Period (QP), DownLink data transmissions (DL), and UpLink data transmissions (UL). 同樣的我們在 UL 與 DL 之中插入一個 10ms guard time。
在我們的設計中，CR AP 會定期的在控制信號頻帶上 broadcast beacon 去通 知使用者 CR AP 的存在並且管理頻帶的使用，而 SU 與 SD 都必須在存取頻帶使 用前與感測頻帶前加入 CR AP，並且與 CR AP 時間同步。而 beacon 包含三部分：
CR AP address (AddrAP), the list of associated SUs and SDs, and data channel assignments。而 ASPSU 與 ASPSD 分為多個 slots，能夠分別讓 SU 與 SD 在對應 時間內以 contention-based 的機制來傳送註冊請求給 CR AP。
在 QP 時，已經加入網域的所有 SDs 會在 QP 同時且依序地對所有的 data channels 進行感測，此時已加入的 SUs 不能使用 data channels 傳送資料。之後 CR AP 使用 RCP 來 poll 加入的 SDs 回報頻譜感測資料，而回報的資料包含：RSSI
readings of data channels, coordinates, and timestamp。而在頻帶可以使用的情況下，
SU 可以在 UL 發送 data packet 給 CR AP，其中包含：packet length in byte (Length), source SU address (Src_addr), destination SU address (Dest_addr), and data payload (Data)。而 CR AP 也可以在 DL 發送 data packet 給對應的目的端。
圖 The flowchart of the designed Cloud-based CR-MAC protocol Protocol Operation
在所提出的網路層協定提案中，我們的流程包含了四個部分：(1) Initialization，
AP、SU、SD 的註冊與時間同步控制 (2) Sensing report collection，SD 在 QP 感 測 頻帶並透過 AP polling 來回報 (3) Data channel coordination，由 AP 以演算法排 程 結果來協調 SU 使用頻帶的情況 (4) Mobility management，透過雲端與 AP 來 管理 SU 的 mobility。在接下來將對各部份進行詳述的介紹。
1. Initialization
在此階段，CR APs、SUs、SDs 會先啟動註冊與時間同步的機制。CR AP 會 先送出註冊請求到雲端的 home agent。當 home agent 收到註冊請求時，會更新其 對應的 binging cache 並且回應 CR AP 註冊成功與時間標籤。而 CR AP 收到註冊 成功訊息並根據時間標籤進行系統時間的校正之後，就能夠開始廣播 beacon 並
且服務 SUs。
對於 SU 與 SD 來說，會先在控制信號頻帶上聆聽 CR AP 的 beacon 後，在對 應的時間 ASP SU 與 ASP SD 送出註冊請求給 CR AP。同樣的，CR AP 會維護目前 網域內的 SUs 與 SDs 的 membership table，並且將 membership table 中的成員註 冊到雲端的 home agent。因此在 home agent 中，會記錄 CR AP 與其所管理的使 用者資訊在 binding cache 中，以便於未來 home agent 在於使用者 Communication 與 Mobility management 的維護上。SU、SD 在發出註冊請求後，透過聆聽下一 次 beacon 中 associated list of SUs and SDs 來判斷是否有順利地註冊成功，否則就 會持續的發送註冊請求給 CR AP。在 SU 順利註冊成功後，即可以發出請求頻帶 使用的請求，之後透過 CR AP 的管理跳至對應的頻帶傳送資料。而 SD 順利註冊 成功後，即在對應的頻帶進行感測並且透過 AP polling 來回報。
對於 home agent 的 binding cache 與 CR AP 的 membership table 採取 ”soft - state ” 的方式，會因應網路拓樸的改變而動態改變 membership，因此對於 CR APs、
SUs、SDs 都需定期的發送註冊請求以刷新使用者狀態，而 CR AP 也會定期的確 認使用者目前的狀態來判斷是否使用者正在使用頻帶或是已經離開該網域。
2. Sensing report collection
在此階段，已經加入網域的所有 SDs 會在 QP 同時且依序地對所有的 data channels 進行感測，同時已加入的 SUs 不能使用 data channels 傳送資料，而新加 入的 SUs 則可在控制信號頻帶傳送 join 的請求。在 SDs 感測之後，在 RCP 所有 SDs 會跳回控制信號頻帶來等待 CR AP 的 polling 以便回報感測資料。透過 CR AP polling 來讓感測資料能夠準確回報，以期讓之後的頻譜估測能有更高的準確性。
在所有 SDs 回報之後，CR AP 透過 Internet 來將所有感測資料回報雲端，雲端啟 動 CSS Engine 來進行頻譜估測並且更新頻譜估測結果。
3. Data channel coordination
SU 在加入網域之後，並不能夠馬上得到頻帶的使用權。當 SU 需要資料傳送 時，會先在控制信號頻道聆聽 beacon，beacon 中的 channel assignment 數值會依 據雲端與 CR AP 的演算法排程結果來給定，而 SU 透過 channel assignment 來跳 至對應的頻帶上傳送資料。而當 PU 出現，channel assignment 會填入沒有頻帶可 以使用的訊息，因此當 SU 接收到該 beacon 後，會先將資料 buffer 在使用者端直
到 PU 離開之後，才會重新跳至對應的 data channel 傳送資料。
4. Mobility management
隨著使用者的移動，使用者會加入到另個 CR AP(新 CR AP)，但對於使用者 原先所在的 CR AP(舊 CR AP)而言，並不知道該個使用者已經離開其所管理的區 域，並且在此時所有傳送給該使用者的資料都會遺失。
為了因應上述情形，我們採取 ” soft - state ” 的 membership 維護，CR AP 可 以透過定期的檢查 membership table 來確認使用者是否離開。若使用者已經離開 但此時仍有資料欲透過 CR AP 傳送給該名使用者，此時 CR AP 會將該筆資料傳 送給 home agent，而 home agent 會幫使用者 buffer 資料直到 timeout。當使用者 重新加入另個 CR AP 時，home agent 會在 CR AP 註冊使用者的請求的時候，同 時判斷是否有該使用者的資料，若有則進行資料傳送。之後若有 CR AP 向 home agent 詢問該使用者所在位置，home agent 會通知使用者新註冊的 CR AP 位址。