6. MAC功能描述
6.1 信道訪問
802.15.4使用的物理無線電信道的訪問機制有下面兩種:
- 基於競爭的訪問機制: 設備使用CSMA-CA退避算法以分布式方式訪問信道
- 無競爭的訪問機制: PAN協調器通過使用GTS來控制
6.1.1 超幀結構
6.1.1.1 介紹
PAN協調器可以選擇使用超幀結構(Superframe Struct)綁定其信道時間
超幀以信標幀的傳輸為界，有活動部分和非活動部分
協調器只能在超幀的活動部分與PAN交互，因此，在非活動部分可以進入低功耗(休眠)模式
超幀結構用macBeaconOrder和macSuperframeOrder的值來描述
macBeaconOrder描述了協調器傳輸其信標幀的間隔，BO(macBeaconOrder)和BI(Beacon Interval)關系如下:
- 0≤BO≤14, BI = aBaseSuperframeDuration * 2 - BO = 15, 不存在超幀, 忽略macSuperframeOrder的值
macSuperframeOrder描述了超幀的活動時間，SO(macSuperframeOrder)和SD(Superframe Duration)關系如下:
- 0 ≤ SO ≤ BO ≤ 14, SD = aBaseSuperframeDuration * 2^SO - SO = 15, 在信標幀之后超幀將不保持活動狀態 - BO = 15, 不存在超幀, macRxOnWhenIdle定義了在收發器不活動期間是否啟用接收器
每個超幀的活動部分應被划分為等間距、持續時間為2^SO * aBaseSlotDuration的插槽
插槽由三個部分組成：Beacon、CAP、CFP
Beacon無需使用CSMA直接在第0插槽開始時發送，CAP在Beacon之后立即發送；如果存在CFP，則緊接在CAP之后發送，並持續到超幀活動部分的結束
使用超幀結構的PAN應進行如下設置
macBeaconOrder: 0~14 macSuperframeOrder: 0~macBeaconOrder
不使用超幀結構(即不支持信標的PAN)的PAN應該將macBeaconOrder和macSuperframeOrder都設置為15
此時，協調器不應傳輸Beacon；所有傳輸，除了確認幀和確認幀之后的數據幀之外，都應使用無槽的CSMA-CA機制訪問信道；此外，GTSs也不被允許使用
超幀結構示例如下圖；其中，信標間隔BI是活動超幀持續時間SD的兩倍，而CFP包含兩個GTS
6.1.1.2 CAP
CAP(Contention Access Period)應在信標之后立即開始，並在超幀時隙邊界上的CFP開始之前完成；如果CFP長度為零，則CAP應在超幀結束時完成
CAP應至少為aMinCAPLength長度，除非需要額外的空間來臨時適應執行GTS維護所需的信標幀長度的增加，並且應動態縮小或增長以適應CFP的大小
在CAP內發送的設備應在CAP結束前一個IFS期間確保其傳輸(即包括確認幀的接收)完成；如果無法做到這一點，設備應將其傳輸推遲到下一個超幀的CAP
MAC命令幀應始終在CAP中傳輸
6.1.1.3 CPF
CPF(Contention-Free Period)應在緊隨CAP之后的時隙邊界上開始，並且應在下一個信標開始之前完成
如果PAN協調器已經分配了GTS，它們應位於CFP內並占用連續的時隙；因此，CFP應根據所有組合GTS的總長度增長或縮小
CFP內的任何傳輸都不得使用CSMA-CA機制來訪問該信道；在CFP中傳輸的設備應確保其傳輸在其GTS結束之前的一個IFS周期內完成
6.1.2 IFS
MAC層需要一定的時間來處理PHY接收的數據；為了實現這一點，傳輸幀之后應是IFS周期；如果傳輸幀需要確認，則IFS周期應在確認幀之后
IFS(Interframe Space/Spacing)周期的長度取決於剛剛傳輸的幀的大小，比如
當MPDU長度為aMaxSIFSFrameSize時，IFS周期的長度至少為aMinSIFSPeriod
當MPDU長度大於aMaxSIFSFrameSize時，IFS周期的長度至少為aMinLIFSPeriod
6.1.3 CSMA-CA算法
CSMA-CA(Carrier Sense Multiple Access-Collision Avoidance)算法應在CAP內傳輸數據幀或MAC命令幀的傳輸之前使用；同時不得用於在CFP中傳輸信標幀、確認幀、數據幀
如果在PAN中使用信標，則MAC層應使用CSMA-CA算法的時隙版本用於超幀的CAP中的傳輸
如果在PAN中沒有使用信標，或信標不能位於啟用信標的PAN中，則MAC層將使用CSMA-CA算法的非時隙版本進行發送
在這兩種情況下，算法使用稱為退避周期的時間單位來實現；其中，一個退避周期應等於aUnitBackoffPeriod
在時隙CSMA-CA中，PAN中每個設備的退避時段邊界應與PAN協調器的超幀時隙邊界對齊；即，每個設備的第一個退避時段的開始與信標發送的開始對齊；同時，MAC層應確保PHY在退避周期的邊界上開始其所有傳輸
在非時隙CSMA-CA中，設備的退避時段與PAN中任何其他設備的退避時段無關
每個設備應為每次傳輸嘗試維護三個變量：NB，CW和BE
NB是嘗試當前傳輸時CSMA-CA算法需要退避的次數；在每次新的傳輸嘗試之前，該值應初始化為0
CW是爭用窗口長度，定義了在傳輸開始之前需要清除信道活動的退避周期數；在每次傳輸嘗試之前，該值應初始化為2，並在每次評估信道忙時重置為2；CW變量僅用於時隙CSMA-CA。
BE是退避指數，它與設備在嘗試評估信道之前應等待多少退避周期有關；在非時隙CSMA-CA或macBattLifeExt設置為FALSE的時隙CSMA-CA中，BE應初始化為macMinBE；在macBattLifeExt設置為TRUE的時隙系統中，該值應初始化為2和macMinBE中的較小值；注意，如果macMinBE設置為0，則在此算法的第一次迭代期間將禁用沖突避免
盡管在該算法的信道評估部分期間啟用了設備的接收器，但是設備應丟棄在此期間接收的任何幀
下圖顯示了時隙CSMA-CA算法的步驟
下圖顯示了非時隙CSMA-CA算法的步驟
6.2 PAN的啟動和維護
6.2.1 信道掃描
所有設備都應能夠在指定的通道列表中執行被動和孤兒掃描；此外，FFD應能夠執行ED和主動掃描
設備通過MLME-SCAN.request原語開始信道掃描；在掃描期間，設備應暫停信標傳輸；在掃描結束時，設備應重新開始信標傳輸；掃描結果應通過MLME-SCAN.confirm原語進行反饋
6.2.1.1 ED掃描
ED掃描允許FFD獲得每個所請求信道中的能量值，PAN協調器可以在開始新PAN之前使用它來選擇准備操作的信道
在ED掃描期間，MAC層應丟棄通過PHY數據服務接收的所有幀
FFD通過使用MLME-SCAN.request(ScanType=0x00)原語請求對指定的一組邏輯信道進行ED掃描；
對於每個邏輯信道，MLME應首先切換到該信道，相應地設置phyCurrentChannel，然后執行[aBaseSuperframeDuration * (2n + 1)]時間長度的ED測量，其中n是參數ScanDuration的值
ED掃描的執行由MLME發出PLME-ED.request給PHY層，該請求會保證一個返回值
在進入通道列表中的下一個通道之前，應記錄在此期間測量的最大ED值
當存儲的ED測量值等於能量能達到的最大值或在每個指定的邏輯信道上檢測到能量時，ED掃描應終止
6.2.1.2 主動掃描
主動掃描允許FFD定位在其POS內發送信標幀的任何協調器；這可以由預期的PAN協調器用於在開始新的PAN之前選擇PAN標識符，或者是設備在關聯之前使用；在主動掃描期間，MAC層應丟棄通過PHY數據服務接收的非信標幀的所有幀
在開始主動掃描之前，MAC層應存儲macPANId的值，然后在掃描期間將其設置為0xffff；這使接收過濾器能夠接受所有信標，而不僅僅接受當前PAN的信標；掃描完成后，MAC層應將macPANId的值恢復為掃描開始前存儲的值
FFD通過使用MLME-SCAN.request(ScanType=0x01)原語請求對指定的一組邏輯信道進行主動掃描；
對於每個邏輯信道，應首先切換到該信道，相應地設置phyCurrentChannel，並發送信標請求命令值；然后，應使能其接收器最多[aBaseSuperframeDuration *（2n + 1）]時間，其中n是0到14之間的值；在此期間，FFD設備應拒絕所有非信標幀並在PAN描述符結構中記錄所有唯一信標中包含的信息；FFD設備應能夠存儲一個和定義的最大數量的PAN描述符；當信標幀包含的PAN標識符和源地址是在當前信道掃描期間未見過的，則應假設信標幀是唯一的
如果接收到信標幀的幀控制字段中安全使能字段設置為1，則設備應嘗試以安全的方式處理信標幀；在信標幀的安全處理期間遇到的任何錯誤應忽略，並且應將信標信息記錄在PAN描述符中，相應地設置SecurityUse，ACLEntry和SecurityFailure字段
如果啟用信標的PAN協調器接收到信標請求命令，則它應忽略該命令並繼續像往常一樣發送其信標
如果未啟用信標的PAN協調器接收到信標請求命令，則它應使用非時隙CSMA-CA發送單個信標幀
當發現的信標數等於定義的最大數量或信道掃描時長已用完時，特定信道上的主動掃描應終止
如果滿足后一條件，則應認為信道已被掃描；在可能的情況下，應在每個通道上重復掃描
當存儲的PAN描述符的數量等於定義的最大值或者掃描了可用信道中的每個信道時，整個掃描將終止
6.2.1.3 被動掃描
被動掃描允許設備定位在其POS內發送信標幀的任何協調器；該掃描不發送信標請求命令；用於設備關聯之前；在被動掃描期間，MAC層應丟棄通過PHY數據服務接收的非信標幀的所有幀
在開始被動掃描之前，MAC層應存儲macPANId的值，然后在掃描期間將其設置為0xffff；這使接收過濾器能夠接受所有信標，而不僅僅接受當前PAN的信標；掃描完成后，MAC子層應將macPANId的值恢復為掃描開始前存儲的值
設備通過使用MLME-SCAN.request(ScanType=0x02)原語請求對指定的一組邏輯信道進行被動掃描；對於每個邏輯信道，應首先切換到該信道，相應地設置phyCurrentChannel，並發送信標請求命令值；然后，應使能其接收器最多[aBaseSuperframeDuration *（2n + 1）]時間，其中n是0到14之間的值；在此期間，應拒絕所有非信標幀並在PAN描述符結構中記錄所有唯一信標中包含的信息；設備應能夠存儲一個和定義的最大數量的PAN描述符；當信標幀包含的PAN標識符和源地址是在當前信道掃描期間未見過的，則應假設信標幀是唯一的
如果接收到信標幀的幀控制字段中安全使能字段設置為1，則設備應嘗試以安全的方式處理信標幀；在信標幀的安全處理期間遇到的任何錯誤應忽略，並且應將信標信息記錄在PAN描述符中，相應地設置SecurityUse，ACLEntry和SecurityFailure字段
當發現的信標數等於定義的最大數量或信道掃描時長已用完時，特定信道上的主動掃描應終止如果滿足后一條件，則應認為信道已被掃描；在可能的情況下，應在每個通道上重復掃描
當存儲的PAN描述符的數量等於定義的最大值或者掃描了可用信道中的每個信道時，整個掃描將終止
6.2.1.4 孤兒掃描
孤立掃描允許設備在失去同步后嘗試重新定位其協調器；在孤立掃描期間，MAC層應丟棄通過PHY數據服務接收的非協調器重新調整MAC命令幀的所有幀
設備通過使用MLME-SCAN.request(ScanType=0x03)原語請求對指定的一組邏輯信道進行孤兒掃描；
對於每個邏輯信道，應首先切換到該信道，相應地設置phyCurrentChannel，然后發送孤立通知命令；然后，使能其接收器最多aResponseWaitTime時間；如果設備在此時間內成功收到協調器重新調整命令，則設備應禁用其接收器；
如果協調器收到孤立通知命令，它將在其設備列表中搜索發送命令的設備
- 如果協調器找到設備記錄，應向孤立設備發送協調器重新調整命令；搜索設備和發送協調器重新調整命令的過程應在aResponseWaitTime時間內進行；協調器重新調整命令應包含其當前PAN標識符、macPANId、當前邏輯信道、孤立設備的短地址
- 如果協調器沒有找到設備的記錄，它將忽略該命令並且不發送協調器重新調整命令
當設備接收到協調器重新調整命令或掃描了指定的一組邏輯信道時，孤立掃描將終止
6.2.2 PAN沖突
在某些情況下，可能發生兩個PAN存在於具有相同PAN標識符的相同POS中；如果發生此沖突，協調器及其設備應執行PAN標識符沖突解決(PAN Identifier Conflict Resolution)過程
6.2.2.1 檢測
如果以下任一情況適用，PAN協調器應斷定存在PAN標識符沖突：
- 接收信標幀, 並且該信標幀Superframe-Specification::PAN-Coordinator字段為1, PAN標識符等於macPANId
- 從其PAN上的設備接收PAN ID沖突通知命令
如果以下情況適用，設備應斷定存在PAN標識符沖突：
- 接收信標幀, Superframe-Specification::PAN-Coordinator字段為1, PAN標識符等於macPANId, 地址不等於macCoordShortAddress或macCoordExtendedAddress
6.2.2.2 解決
在檢測到PAN標識符沖突時，協調器應首先執行主動掃描，然后使用來自掃描的信息選擇新的PAN標識符；然后，協調器應廣播包含新PAN標識符的協調器重新調整命令，其中源PAN標識符字段等於macPANId中的值；一旦發送了協調器重新調整命令，協調器就應將macPANId設置為新的PAN標識符
在設備檢測到PAN標識符沖突時，它應生成PAN ID沖突通知命令並將其發送給PAN協調器；如果正確接收到PAN ID沖突通知命令，則PAN協調器應發送確認幀，從而確認接收；然后，PAN協調器按照上面的辦法來解決沖突
6.2.3 PAN啟動
只有在執行了信道主動掃描並且已經選擇了適當的PAN標識符之后，才能由FFD啟動PAN；此外，FFD應將macShortAddress設置為小於0xffff的值
FFD通過使用MLME-START.request原語開始操作PAN；其中PANCoordinator參數設置為TRUE，CoordRealigment參數設置為FALSE；收到此原語后，MAC層應設置phyCurrentChannel和macPANId；完成此操作后，MAC層將使用MLME-START.confirm原語進行響應，並開始作為PAN協調器運行6.2.4 信標生成
僅當macShortAddress不等於0xffff時，才允許設備發送信標幀
FFD應使用MLME-START.request原語開始發送信標；FFD可以作為新PAN的PAN協調器或作為已經建立的PAN上的設備開始信標傳輸，這取決於PANCoordinator參數的設置；在接收到該原語時，MAC層應在macPANId中設置PAN標識符，並在信標幀的源PAN標識符字段中使用該值；如果macShortAddress等於0xfffe，則信標幀的源地址字段中使用的地址為aExtendedAddress的值，否則應包含macShortAddress
最近信標的傳輸時間應記錄在macBeaconTxTime中，並應進行計算，
以使其值在每個信標幀中的相同符號邊界處獲取，其位置是特定於實現的；符號邊界應選擇與輸入信標幀的時間戳中使用的符號邊界相同
所有信標幀應在每個超幀的開頭以等於aBaseSuperframeDuration * 2macBeaconOrder的時間間隔發送
信標傳輸應優先於所有其他發送和接收操作
6.2.5 設備發現
FFD可以通過在PAN上發送信標幀來告知其他設備其存在；這允許其他設備執行設備發現
不是PAN協調器的FFD只有在與PAN成功關聯時才開始發送信標幀；設備的信標幀的傳輸是通過使用MLME-START.request(PANCoordinator=FALSE)原語來執行的；收到該原語后，MLME將使用的已關聯的PAN的標識符、macPANId、macShortAddress來發送信標
信標幀應以每aBaseSuperframeDuration * 2macBeaconOrder時間一個信標幀的速率進行發送
6.3 關聯和解除關聯
6.3.1 關聯
設備只有在完成下面的步驟后才能嘗試進行關聯
- 執行MAC層復位(MLME-RESET.request) - 完成主動掃描或被動掃描 - 使用信道掃描的結果來選擇合適的PAN
協調器僅當macAssociationPermit為TRUE時才允許關聯；同理，設備應僅嘗試與當前允許關聯的PAN(在掃描過程的結果中指示)相關聯；如果macAssociationPermit為FALSE的協調器從設備接收到關聯請求命令，則應忽略該命令
在選擇要關聯的PAN之后，高層應請求MLME將以下PHY和MAC PIB屬性配置為關聯所需的值
- phyCurrentChannel: 設置為要關聯的邏輯信道 - macPANId: 設置為要關聯的PAN的標識符 - macCoordExtendedAddress/macCoordShortAddress: 根據與其希望關聯的協調器的Becon幀設置為適當的值
為了優化啟用信標的PAN上的關聯過程，設備可以開始跟蹤它希望與之關聯的協調器的信標，通過發出MLME-SYNC.request(TrackBeacon=TRUE)原語來實現的
設備通過MLME-ASSOCIATE.request原語與現有PAN關聯，並且不應嘗試啟動其自己的PAN
非關聯設備通過向現有PAN的協調器發送關聯請求命令來啟動關聯過程；如果協調器正確接收到關聯請求命令，應發送確認幀來確認接收
協調器對關聯請求命令的確認並不意味着設備已關聯，它需要時間來確定PAN上可用的當前資源是否足以允許另一設備關聯，但應在aResponseWaitTime時間內做出決定
如果協調器發現該設備先前已在其PAN上關聯，則應刪除所有先前獲得的設備特定信息
- 當有足夠的資源可用，協調器應為設備分配一個短地址，並生成一個關聯響應命令(包含新地址和指示成功關聯的狀態)
- 當沒有足夠的資源，協調器應生成一個包含指示失敗狀態的關聯響應命令
關聯響應命令應使用間接傳輸發送到請求關聯的設備，即關聯響應命令幀應被添加到協調器上存儲的待處理事務列表中，並由相關設備自行使用
章節
中的方法提取
如果關聯請求命令的CapabilityInformation-AllocateAddress字段設置為1，則協調器應分配一個16位地址，其范圍取決於協調器支持的尋址模式，如下表所述
如果關聯請求命令的CapabilityInformation-AllocateAddress字段設置為0，則協調器分配的地址應等於0xfffe，表示設備已關聯，但尚未分配短地址；在這種情況下，設備應僅使用其64位擴展地址在網絡上運行
設備在收到對關聯請求命令的確認后，應等待最多aResponseWaitTime符號，以便協調器做出關聯決定
如果設備正在跟蹤信標，它將從協調器提取關聯響應命令一旦該命令出現信標幀中時
如果設備沒有跟蹤信標，它將在aResponseWaitTime時間后從協調器提取關聯響應命令
如果設備未在aResponseWaitTime時間內從協調器中提取關聯響應命令幀，則它應發出MLME-ASSOCIATE.confirm(status=NO_DATA)原語，並且關聯將被視為失敗；在這種情況下，高層應通過發出MLME-SYNC.request(TrackBeacon=FALSE)原語終止對信標的任何跟蹤
在接收到關聯響應命令時，請求關聯的設備應發送確認幀來確認接收
如果命令的關聯狀態字段指示關聯成功，則設備應存儲與其關聯的協調器的地址，同時還應分別存儲如下地址
- macCoordShortAddress: 協調器的短地址, 位於設備選擇關聯的原始信標幀中 - macCoordExtendedAddress: 協調器的擴展地址, 位於關聯響應命令幀的MHR中 - macShortAddress: 分配短地址, 關聯響應命令中
如果命令的關聯狀態字段指示關聯不成功，則設備應將macPANId設置為默認值0xffff
6.3.2 解除關聯
解除關聯過程由高層通過向MLME發布MLME-DISASSOCIATE.request原語來啟動
當協調器希望其關聯設備之一離開PAN時，它應使用間接傳輸向設備發送解除關聯通知命令，即解除關聯通知命令幀應添加到協調器上存儲的待處理事務列表中，由相關設備自行提取；如果設備請求並正確接收解除關聯通知命令，則應通過發送確認幀確認其接收；即使未收到確認，協調器也應認為該設備已取消關聯
如果關聯設備想要離開PAN，則它應向其協調器發送解除關聯通知命令；如果協調器正確接收到解除關聯通知命令，則它應通過發送確認幀來確認其接收；即使沒有收到確認，設備也應認為自己已取消關聯
如果解除關聯通知命令中的源地址等於macCoordExtendedAddress，則接收方應認為自己已取消關聯；如果協調器接收到解除關聯通知命令且源地址不等於macCoordExtendedAddress，則它應驗證源地址是否與其關聯的設備之一；如果是這樣，協調器應認為該設備已解除關聯；如果不滿足上述條件，則應忽略該命令
關聯設備應通過刪除對PAN的所有引用來解除其關聯；協調器應通過刪除對該設備的所有引用來取消關聯設備
請求設備的高層應通過MLME-DISASSOCIATE.confirm原語通知解除關聯過程的結果
6.4 同步
對於支持信標的PAN，通過接收和解碼信標幀來執行同步；對於不支持信標的PAN，通過輪詢協調器獲取數據來執行同步
6.4.1 信標同步
在啟用信標的PAN(macBeaconOrder <15)上運行的所有設備應能夠獲取信標同步，以便檢測任何待處理消息或跟蹤信標；允許設備僅使用包含macPANId中指定的PAN標識符的信標獲取信標同步；如果macPANId指定的是廣播PAN標識符(0xffff)，則設備不應嘗試獲取信標同步
設備可通過MLME-SYNC.request原語獲取信標
如果在原語中指定了跟蹤，則設備應通過定期激活其接收器來獲取信標並跟蹤它
如果在原語中未指定跟蹤，則設備應嘗試僅獲取一次信標，並停止先前跟蹤信標
要獲取信標同步，設備應啟用其接收器並最多搜索[aBaseSuperframeDuration *（2macBeaconOrder + 1）]時間；如果未接收到包含設備的當前PAN標識符的信標幀，則MLME將重復該搜索；一旦丟失的信標數達到aMaxLostBeacons，MLME將通過發出MLME-SYNC-LOSS.indication(LossReason=BEACON_LOSS)原語來通知高層
MLME應在每個幀內的相同符號邊界處對每個接收到的信標幀加時間戳；符號邊界應選擇與存儲在macBeaconTxTime中的傳出信標幀的時間戳中使用的符號邊界相同
如果安全使能字段設置為1，則MLME應處理接收到的信標幀以確保安全性；如果安全處理失敗，則應丟棄該幀，並且MLME應發出指示錯誤的MLME-COMM-STATUS.indication原語
當接收到信標幀，設備應驗證信標幀是否來自與其關聯的協調器；因此，如果信標幀的MAR的源地址和源PAN標識符字段與協調器源地址(macCoordShortAddress/macCoordExtendedAddress，取決於尋址模式)和設備的PAN標識符(macPANId)不匹配，則MLME應丟棄信標幀
如果接收到有效的信標幀並且macAutoRequest被設置為FALSE，則MLME將通過發出MLME-BEACON-NOTIFY.indication原語向高層指示信標參數
如果接收到信標幀並且macAutoRequest設置為TRUE，當信標包含任何有效載荷，MLME應首先發出MLME-BEACON-NOTIFY.indication原語；然后，將其地址與信標幀的地址列表字段中的那些地址進行比較；如果地址列表字段包含設備的短地址或擴展地址，並且源PAN標識符與macPANId匹配，則MLME應開始從協調器中提取待處理數據
如果激活信標跟蹤，則MLME應在下一個預期的信標幀傳輸之前，即恰好在下一個超幀的已知開始之前的時間啟用其接收器；
如果MLME遺漏的連續信標的數量達到aMaxLostBeacons，則MLME將以MLME-SYNC-LOSS.indication(LossReason=BEACON_LOSS)原語響應
6.4.2 非信標同步
在非啟用信標的PAN(macBeaconOrder = 15)上運行的所有設備應能夠根據高層的
Discretion
輪詢協調器以獲取數據；當MLME接收到MLME-POLL.request原語時，指示設備輪詢協調器；收到此原語后，MLME應從協調器中提取待處理數據
6.4.3 孤兒設備重新調整
如果高層在其傳輸數據的請求之后接收到重復的通信故障，則可以斷定它已經是孤兒
當設備事務未能到達協調器時，比如在aMaxFrameRetries次發送數據未收到確認，可認為發生了單方通信故障
如果高層斷定它已經是孤兒，它可以指示MLME執行孤兒設備重新調整過程，或者重置MAC層然后執行關聯過程
如果高層已做出決定以執行孤立設備重新調整過程，則它應發出一個MLME-SCAN.request(ScanType=0x03, ScanChannel=待掃描通道列表)；MAC層收到該原語后，應開始孤兒掃描；如果孤兒掃描成功(即，其PAN已被定位)，則設備應使用協調器重新調整命令中包含的PAN信息更新其MAC PIB；如果孤兒掃描不成功，則高層將決定需要采取什么進一步的動作，比如，重試孤立掃描或嘗試重新關聯
6.5 事務處理
因為IEEE Std 802.15.4-2003支持非常低成本的設備，通常將由電池供電，所以可以從設備本身而不是從協調器發起事務；換句話說，協調器需要在其信標中指示何時消息正在等待設備，或者設備本身需要輪詢協調器以確定它們是否具有待處理的消息；這種傳送稱為間接傳輸
協調器應通過MCPS-DATA.request原語或通過來自MLME的請求開始處理接收到間接傳輸請求的事務，以發送由來自高層的原語發起的MAC命令，例如MLME-ASSOCIATE.response原語；在事務完成時，MAC層應將狀態通知高層；如果請求原語發起間接傳輸，則應使用相應的確認原語來返回適當的狀態值；相反，如果響應原語啟動了間接傳輸，則應使用MLME-COMM-STATUS.indication原語來返回適當的狀態值
間接傳輸請求中包含的信息形成一個事務，協調器應能夠存儲至少一個事務；在接收到間接傳輸請求時，如果沒有存儲另一個事務的容量，則MAC層應在MLME-COMM-STATUS.indication原語中向高層指示TRANSACTION_OVERFLOW的狀態
如果協調器能夠存儲多個事務，則應確保同一設備的所有事務按照它們到達MAC層的順序發送；對於發送的每個事務，如果同一設備存在另一個事務，則MAC層應將其幀掛起字段設置為1，表示還有待處理數據
每個事務應在協調器中持續最多macTransactionPersistenceTime時間；如果在該時間內沒有由適當的設備提取事務，則應丟棄事務信息，並且MAC層通過MLME-COMM-STATUS.indication(Status=TRANSACTION_EXPIRED)原語通知高層
如果協調器發送信標，則它應在地址列表字段中列出每個事務所關聯的設備的地址，並指定信標幀的待處理地址字段中的地址數；如果協調器能夠存儲七個以上的待處理事務，它應以先來先服務的方式在其信標中指示它們，確保信標幀最多包含七個地址；對於需要GTS的事務，PAN協調器不應將接收者的地址添加到信標幀中的待處理地址列表中；相反，它應在為設備分配的GTS中傳輸事務
在啟用信標的PAN上，接收信標的其待處理地址列表中包含自身地址的設備應嘗試從協調器中提取數據
在啟用非信標的PAN上，設備應在接收到MLME-POLL.request原語時嘗試從協調器中提取待處理數據
當事務完成時，應丟棄其數據，並將數據傳輸結果的指示發送到高層；如果事務需要確認並且未收到確認，則MAC層應指示NO_ACK的狀態；如果事務成功，MAC層應指示SUCCESS的狀態
6.6 傳輸、接收和確認
6.6.1 傳輸
每次生成數據或MAC命令幀時，MAC層應將macDSN的值復制到輸出幀的MHR的序列號字段中，然后將其遞增1
每次生成信標幀時，MAC子層應將macBSN的值復制到輸出幀的MHR的序列號字段中，然后將其遞增1。
源地址字段(如果存在)應包含發送幀的設備的地址；當設備已經關聯並且已經分配了短地址(即macShortAddress不等於0xfffe或0xffff)時，它應盡可能使用短地址而不是其擴展地址(即aExtendedAddress)；當設備尚未與PAN關聯或macShortAddress等於0xffff時，它應在所有需要源地址字段的通信中使用其擴展地址；如果源地址字段不存在，則應假定幀的發起者是PAN協調器，並且目的地地址字段應包含接收者的地址
目標地址字段(如果存在)應包含幀的預期接收者的地址，該地址可以是16位短地址或64位擴展地址；如果目標地址字段不存在，則應假定幀的接收者是PAN協調器，並且源地址字段應包含發送者的地址
如果存在目的地和源尋址信息，則MAC層應比較目的地和源PAN標識符。如果PAN標識符相同，則幀控制字段的Intra-PAN字段應設置為1，並且從發送的幀中省略源PAN標識符；如果PAN標識符不同，則幀控制字段的Intra-PAN字段應設置為0，並且目的地和源PAN標識符字段都應包括在發送的幀中
如果要在啟用信標的PAN上發送幀，則發送設備應在發送之前嘗試找到信標；如果未跟蹤信標，因此設備不知道信標將出現在何處，它應啟用其接收器並最多搜索[aBaseSuperframeDuration *（2macBeaconOrder + 1）]時間，以便找到信標；如果在此時間之后未找到信標，則設備應在成功應用CSMA-CA算法的非時隙版本后發送幀；一旦找到信標，無論是在搜索之后還是由於其被跟蹤，幀都應在超幀的適當部分中傳輸；CAP中的傳輸應遵循CSMA-CA算法的時隙版本，並且GTS的傳輸不應使用CSMA-CA
如果在不支持信標的PAN上發送幀，則應在成功應用CSMA-CA算法的非時隙版本后發送幀
6.6.2 接收和拒絕
每個設備可以選擇MAC層是否在空閑期間啟用其接收器；在這些空閑期間，MAC層仍將服務來自高層的收發器任務請求
收發器任務應被定義為具有確認接收的傳輸請求或接收請求；在完成每個收發器任務后，MAC層將請求PHY啟用或禁用其接收器，具體取決於macRxOnWhenIdle是分別設置為TRUE還是FALSE；如果macBeaconOrder小於15，則僅在CAP的空閑期間考慮macRxOnWhenIdle的值
由於無線電通信的性質，啟用接收器的設備將能夠接收和解碼符合IEEE Std 802.15.4-2003的所有設備的傳輸，這些設備當前在相同的信道上運行並且在其POS中，以及來自其他來源的干擾；因此，MAC層應能夠過濾輸入幀並僅呈現上層感興趣的幀
對於第一級過濾，MAC層應丟棄在MFR的FCS字段中不包含正確值的所有接收幀；下一級過濾應取決於MAC層當前是否以混雜模式運行；在混雜模式下，MAC層應將第一級過濾后接收的所有幀直接傳遞到上層，而不再應用任何過濾；如果macPromiscuousMode設置為TRUE，則MAC層應處於混雜模式
如果MAC層未處於混雜模式(即macPromiscuousMode為FALSE)，則它只接受滿足以下所有要求的幀：
- 幀控制字段的幀類型字段不應包含非法幀類型 - 如果幀類型指示幀是信標幀, 則源PAN標識符應匹配macPANId, 除非macPANId等於0xffff; 在這種情況下, 無論源PAN標識符為何值都應接受信標幀 - 如果目標PAN標識符包含在幀中, 則它應匹配macPANId或者應該是廣播PAN標識符(0xffff) - 如果幀中包含短目標地址, 則它應匹配macShortAddress或廣播地址(0xffff); 否則, 如果幀中包含擴展目標地址, 則它應與aExtendedAddress匹配 - 如果數據或MAC命令幀中僅包含源尋址字段, 則僅當設備是PAN協調器且源PAN標識符與macPANId匹配時才應接受該幀
如果不滿足上面列出的任何要求，MAC層應丟棄傳入幀；如果滿足上面列出的所有要求，則該幀應被視為有效並進一步處理
對於有效幀，如果幀類型子字段指示數據或MAC命令幀並且幀控制字段的確認請求子字段被設置為1，則MAC子層將發送確認幀；在確認幀的傳輸之前，包括在接收數據或MAC命令幀中的序列號應被復制到確認幀的序列號字段中；此步驟將保證事務發起方知道它已收到適當的確認幀
如果安全使能字段設置為1，則MAC層應處理接收到的幀以確保安全性；在對信標進行主動或被動掃描期間，接收到的未通過安全處理的信標幀中包含的信息仍將被置於PAN描述符中，相應地設置SecurityUse，ACLEntry和SecurityFailure字段，並傳遞給高層
如果幀控制字段的Intra-PAN字段被設置為1並且目的地和源尋址信息都包括在幀中，則MAC層將假設省略的源PAN標識符字段與目的地PAN標識符字段相同
如果幀成功處理，MAC層應通過發出包含幀信息的MCPS-DATA.indication原語將幀傳遞到高層
6.6.3 數據提取
啟用信標的PAN上的設備可以通過檢查接收到的信標幀的內容來確定是否有任何待處理幀；如果設備的地址包含在信標幀的地址列表字段中，則設備的MLME應在CAP期間向協調器發送幀控制的AcknowledgmentRequest字段為1的數據請求命令
還有另外兩種情況，MLME應向協調器發送數據請求命令:
- MLME收到MLME-POLL.request原語
- 設備可以在請求命令確認之后aResponseWaitTime時間向協調器發送數據請求命令, 例如在關聯過程期間
僅當數據請求命令不是發往PAN協調器時，它才應包含目標地址信息
在成功接收數據請求命令后，協調器應發送確認幀，從而確認其接收；如果協調器有足夠的時間來確定設備是否具有掛起的幀並且仍然能夠在macAckWaitDuration時間內發送確認幀，
則它應相應地設置確認幀的幀控制字段的幀掛起字段以指示幀是否實際上正在等待該設備；如果這不可能，協調器應將確認幀的幀掛起子字段設置為1
在接收到幀掛起子字段設置為0的確認幀時，設備應認為協調器沒有待處理的數據
在接收到確認幀的幀掛起字段設置為1的情況下，設備應使其接收器在啟用/非啟動信標的PAN中最多啟用aMaxFrameResponseTime CAP時間，以從協調器接收相應的數據幀；如果協調器存在請求設備的待處理的數據幀，則協調器應使用下面描述的機制之一將幀發送到設備；如果協調器沒有請求設備的待處理的數據幀，則協調器應使用下面描述的機制之一發送有效載荷長度為0並且不包含設備請求確認的數據幀，指示不存在數據
確認數據請求命令后的數據幀應使用以下機制之一傳輸
- 使用CSMA-CA, 如果MAC層可以在退避時間邊界和退避時隙邊界上的aTurnaroundTime和(aTurnaroundTime + aUnitBackoffPeriod)之間開始傳輸數據幀, 並且CAP中有剩余時間用於消息, 適當的IFS和確認; 如果在該數據幀之后沒有接收到所請求的確認幀, 則應使用CSMA-CA發送所有后續重傳
- 使用CSMA-CA, 其他情況
如果請求設備沒有在aMaxFrameResponseTime CAP時間內從啟用/非啟用信標的PAN中的的協調器接收數據幀，或者請求設備從協調器接收數據幀有效載荷長度為0，則應認為協調器沒有待處理的數據；如果請求設備確實從協調器接收數據幀，它將發送確認幀來確認接收
如果從協調器接收的數據幀的幀控制字段的幀掛起字段被設置為1，則該設備在協調器上有更多待處理數據；在這種情況下，它可以通過使用上面描述的相同過程向協調器發送新的數據請求命令來提取數據
6.6.4 使用確認
數據或MAC命令幀，其幀控制字段的Acknowledgment Request字段應該被設置為1；信標或確認幀，Acknowledgment Request字段應設置為0；類似地，任何廣播的幀都應在其Acknowledgment Request字段設置為0的情況下發送
6.6.4.1 無確認
Acknowledgment Request字段設置為0的幀不需要其接收者進行確認，發送設備應假定幀的傳輸是成功的
下面的消息序列圖顯示了不需要確認的單幀數據場景(Acknowledgment Request為0)
6.6.4.2 確認
Acknowledgment Request字段設置為1的幀需要其接收者進行確認；如果預期的接收者正確地接收到幀，則它應該從正被確認的數據或MAC命令幀生成並發送包含相同DSN的確認幀
在非信標啟用的PAN或CFP中的確認幀的傳輸應在接收到數據或MAC命令幀的aTurnaroundTime時間之后；CAP中確認幀的傳輸應在退避時隙邊界處開始；在這種情況下，在接收到數據或MAC命令幀后，確認幀的傳輸應在aTurnaroundTime和(aTurnaroundTime + aUnitBackoffPeriod)之間開始
下面的消息序列圖顯示了需要確認的單幀數據場景(Acknowledgment Request為1)
6.6.5 重傳
發送幀的設備的幀控制字段的AR字段設置為0的設備應假定傳輸已成功接收，因此不執行重傳過程
發送數據或MAC命令幀及其AR字段設置為1的設備應等待最多macAckWaitDuration時間以接收相應的確認幀；如果在macAckWaitDuration時間內接收到確認幀並且包含與原始傳輸相同的DSN，則認為傳輸成功，設備不應采取進一步的動作；如果在macAckWaitDuration時間內未收到確認或收到包含與原始傳輸不同的DSN的確認，則設備應斷定單次傳輸嘗試失敗
如果單次傳輸失敗並且傳輸是間接的，則協調器不應重新傳輸數據或MAC命令幀；
同時
，幀應保留在協調器的事務隊列中
如果單次傳輸失敗並且傳輸是直接的，則設備應重復傳輸數據或MAC命令幀並等待確認的過程，最多aMaxFrameRetries次
設備應該在超幀的相同部分內完成每次重傳，即CAP或原始傳輸的GTS；如果不能進行此定時，則應將重傳推遲到下一個超幀中的相同部分
如果在aMaxFrameRetries重傳之后仍未收到確認，則MAC層應假設傳輸失敗並通知高層；這種情況可認為是通信故障
6.6.6 混雜模式
設備可以通過設置macPromiscuousMode來激活混雜模式
如果請求MLME將macPromiscuousMode設置為TRUE，則MLME還應將macRxOnWhenIdle設置為TRUE，然后請求PHY啟用其接收器；可以通過MLME發出PLME-SET-TRX-STATE.request(state=RX_ON)原語來實現該請求
如果請求MLME將macPromiscuousMode設置為FALSE，則MLME還應將macRxOnWhenIdle設置為FALSE，然后請求PHY禁用其接收器；這是通過MLME發出TRX_OFF的PLME-SET-TRX-STATE.request(state=TRX_OFF)原語來實現
6.6.7 傳輸場景
由於無線電介質的不完美性質，發送的幀不總是到達其預期目的地，下面說明了三種不同的數據傳輸場景
- 成功的數據傳輸: 發送方MAC層通過PHY數據服務將數據幀發送給接收方; 在等待確認時, 發送方MAC層啟動一個定時器, 該定時器將在macAckWaitDuration時間后到期; 接收方MAC層接收數據幀, 將確認發送回發送方, 並將幀傳遞給高層; 發送方MAC層在其計時器到期之前接收來自接收方的確認, 然后禁用並重置計時器, 數據傳輸完成后向高層發出成功確認 - 丟失數據幀: 發送方MAC層通過PHY數據服務將數據幀發送給接收方; 在等待確認時, 發送方MAC層啟動一個定時器, 該定時器將在macAckWaitDuration時間后到期; 接收方MAC層沒有接收到數據幀, 因此不響應確認; 發送方MAC層的定時器在接收到確認之前到期; 數據傳輸失敗, 發送方重新傳輸數據, 該序列可以重復最多aMaxFrameRetries次; 如果數據傳輸嘗試總共(1 + aMaxFrameRetries次仍然失敗, 則發送方MAC層將向高層發出失敗確認 - 失去確認幀: 發送方MAC層通過PHY數據服務將數據幀發送給接收方; 在等待確認時, 發送方MAC層啟動一個定時器, 該定時器將在macAckWaitDuration時間后到期; 接收方MAC層接收數據幀, 將確認發送回發起方, 並將幀傳遞給高層; 發送方MAC層沒有接收到確認幀並且其定時器到期; 數據傳輸失敗, 發起方將重新傳輸數據; 該序列可以重復最多aMaxFrameRetries次; 如果數據傳輸嘗試總共(1 + aMaxFrameRetries)次仍然失敗, 則發送方MAC層向高層發出失敗確認
6.7 GTS分配和管理
GTS允許設備在超幀專用於該設備的部分信道上進行操作；GTS只能由PAN協調器分配，並且只能用於PAN協調器和設備之間的通信；單個GTS可以在一個或多個超幀時隙上延伸；如果超幀中有足夠的容量，PAN協調器可以同時分配多達七個GTS
在使用之前應分配GTS，PAN協調器根據GTS請求的要求和超幀中的當前可用容量來決定是否分配GTS；GTS應按先到先得的原則分配，所有GTS應連續放置在超幀的末端和CAP之后；當不再需要GTS時，每個GTS應被釋放，並且可以由PAN協調器或最初請求GTS的設備隨時釋放GTS；已經分配了GTS的設備也可以在CAP中操作
在分配的GTS中發送的數據幀應僅使用短尋址模式
GTS的管理只能由PAN協調器進行；為了促進GTS管理，PAN協調器應能夠存儲管理七個GTS所需的所有信息；對於每個GTS，PAN協調器應能夠存儲其起始時隙、長度、方向和關聯的設備地址
GTS方向與擁有GTS的設備的數據流相關，被指定為發送或接收；因此，設備地址和方向應唯一地標識每個GTS；每個設備可以請求一個發送GTS和/或一個接收GTS；對於每個分配的GTS，設備應能夠存儲其起始時隙、長度和方向；如果設備已經分配了接收GTS，則它應該為其整個GTS啟用其接收器；同樣，如果已經為設備分配了發送GTS，則PAN協調器應該為整個GTS啟用其接收器；如果在接收GTS期間接收到數據幀並且請求確認，則設備應照常發送確認幀；類似地，設備應能夠在發送GTS期間接收確認幀；只有當設備正在跟蹤信標(通過MLME-SYNC.request(TrackBeacon=TRUE))時，設備才會嘗試分配和使用GTS；如果設備與PAN協調器失去同步，則其所有GTS分配都將丟失
RFD設備對GTS的使用是可選的
6.7.1 CAP維護
PAN協調器應保存最小CAP長度aMinCAPLength，並在不滿足最小CAP時采取預防措施；但是，應允許例外情況以適應執行GTS維護所需的信標幀長度的臨時增加；如果需要采取預防措施，則可選擇的如下操作的一項或多項
- 限制信標中包含的待處理地址的數量 - 不包括信標幀中的有效載荷字段 - 解除分配一個或多個GTS
6.7.2 GTS分配
設備可以通過MLME-GTS.request(GTSCharacteristics->CharacteristicsType=1)原語請求分配新的GTS
要請求分配新的GTS，MLME應將GTS請求命令發送給PAN協調器；其中GTSCharacteristics字段的CharacteristicsType字段應設置為1(GTS分配)，並且長度和方向子字段應根據所需GTS的期望特性來設置；如果正確接收到GTS請求命令，則PAN協調器應發送確認幀來確認接收
在接收到指示GTS分配請求的GTS請求命令時，PAN協調器應首先基於CAP的剩余長度和所請求的GTS的期望長度來檢查當前超幀中是否存在可用容量；如果尚未達到最大GTS數量，則超幀應具有可用容量，並且分配所需長度的GTS不會將CAP的長度減小到小於aMinCAPLength；如果有足夠的可用帶寬，則由PAN協調器以先到先得的方式分配GTS；PAN協調器應在aGTSDescPersistenceTime超幀內做出此決定
在收到對GTS請求命令的確認后，設備將繼續跟蹤信標並等待最多aGTSDescPersistenceTime超幀；如果在此時間內信標中沒有出現設備的GTS描述符，則設備的MLME應通過MLME-GTS.confirm(status=NO_DATA)原語通知高層
當PAN協調器確定容量是否可用於所請求的GTS時，它應生成具有所請求規范和請求設備的短地址的GTS描述符；如果GTS被成功分配，則PAN協調器應將GTS描述符中的起始時隙設置為GTS開始的超幀時隙，並將GTS描述符中的長度設置為GTS的長度；此外，PAN協調器應通過MLME-GTS.indication(GTSCharacteristics=)原語通知新GTS的高層；如果沒有足夠的容量來分配所請求的GTS，則應將起始時隙設置為0，並將長度設置為當前可支持的最大GTS長度；然后，PAN協調器應在其信標中包括該GTS描述符，並相應地更新信標幀的GTS規范字段；PAN協調器還應更新信標幀的超幀規范字段的最終CAP時隙子字段，指示減少的CAP使用的最終超幀時隙；GTS描述符應保留在aGTSDescPersistenceTime超幀的信標幀中，之后應自動刪除；應允許PAN協調器將其CAP降低到aMinCAPLength以下，以適應由於包含GTS描述符而導致的信標幀長度的臨時增加
在接收到包含對應於macShortAddress的GTS描述符的信標幀時，設備應處理該描述符；然后，設備的MLME應通過MLME-GTS.confirm(status=SUCCESS/DENIED)原語通知高層GTS分配請求是否成功；其中SUCCESS表示GTS描述符中的起始時隙大於零，DENIED表示起始時隙等於零或長度為0
6.7.3 GTS使用
當設備的MAC層接收到帶有指示GTS傳輸的TxOptions參數的MCPS-DATA.request原語時，它應首先確定它是否具有有效的GTS；如果設備是PAN協調器，則它應確定它是否具有與所請求的目的地址的設備相對應的接收GTS；如果設備不是PAN協調器，則它應確定是否已經分配了發送GTS；如果找到有效的GTS，則MAC層應在GTS期間，即在其起始時隙和其起始時隙加上其長度之間發送數據；此時，如果所請求的事務可以在GTS結束之前完成，MAC層必須立即發送MPDU而不使用CSMA-CA；如果在當前GTS結束之前無法完成所請求的事務，則MAC層應將傳輸推遲到下一個超幀中的指定GTS
如果設備具有任何接收GTS，則設備的MAC層應確保在GTS開始之前和GTS持續時間內啟用接收器，由其起始時隙和其長度所示；PAN協調器應發送接收GTS內的所有幀，同時將幀控制字段的AR字段設置為1
當PAN協調器的MAC層接收具有指示GTS傳輸的TxOptions參數的MCPS-DATA.request原語時，它應將傳輸推遲到預期接收者的接收GTS的開始；在這種情況下，具有要求GTS傳輸的消息的設備的地址不應被添加到信標幀中的待處理地址列表中；對於所有分配的發送GTS(相對於設備)，PAN協調器的MAC層應確保在每個GTS的開始和持續時間之前啟用其接收器
在開始在GTS中傳輸之前，每個設備應確保數據傳輸、確認和適合於數據幀大小的IFS可以在GTS結束之前完成
如果設備在超幀開始時錯過了信標，則在正確接收后續信標之前，它不應使用其GTS；如果由於信標丟失而導致同步丟失，則設備應認為其所有GTS被釋放
6.7.4 GTS釋放
設備可以使用MLME-GTS.request(GTSCharacteristics->CharacteristicsType=0)原語來釋放分配的GTS；原語下發后，設備不應使用要取消分配的GTS，並且應重置其存儲的屬性
要請求釋放現有GTS，MLME應將GTS請求釋放命令發送給PAN協調器；並且應根據要解除分配的GTS的屬性設置長度和方向子字段；如果正確接收到GTS請求釋放命令，則PAN協調器應發送確認幀來確認接收；收到對GTS請求釋放命令的確認后，MLME應通過MLME-GTS.confirm(status=SUCCESS)原語通知高層的GTS的釋放；如果GTS請求釋放命令未被PAN協調器正確接收，它應通過GTS expiration章節中描述的過程確定設備已停止使用其GTS
在接收GTS請求釋放命令時，PAN協調器將嘗試釋放GTS；如果GTS請求釋放命令中包含的GTS屬性與已知GTS的屬性不匹配，則PAN協調器應忽略該請求；如果GTS請求釋放命令中包含的GTS特性與已知GTS的特性匹配，則PAN協調器的MLME應釋放指定的GTS並通過MLME-GTS.indication(GTSCharacteristics)通知高層；PAN協調器還應更新最終的CAP信標幀的超幀規范字段的時隙子字段，指示增加的CAP使用的最終超幀時隙；同時不應該向信標幀添加描述符來描述釋放
當PAN協調器啟動GTS釋放時，MLME應通過MLME-GTS.indication(GTSCharacteristics)通知下一個更高層的更改，然后PAN協調器應釋放GTS並將GTS描述符添加到釋放的GTS的信標幀，但其起始時隙設置為0；描述符應保留在aGTSDescPersistenceTime超幀的信標幀中；應允許PAN協調器將其CAP降低到aMinCAPLength以下，以適應由於包含GTS描述符而導致的信標幀長度的臨時增加
在接收到包含對應於macShortAddress的GTS描述符並且起始時隙等於0的信標幀時，設備應立即停止使用GTS；然后，設備的MLME應通過MLME-GTS.indication(GTSCharacteristics)原語通知高層的GTS的釋放
6.7.5 GTS重新分配
GTS的釋放可能導致超幀變得碎片化
例如，下圖顯示了具有分配的GTS的超幀的三個階段；在階段1)中，分別從時隙14,10和8開始分配三個GTS；在階段2)中釋放GTS 2，超幀中將存在間隙； 為了解決這個問題，必須改變GTS 3以填補空白，從而增加CAP的大小，參考階段3)
PAN協調器應確保消除由於GTS的釋放而出現的CFP中的任何間隙，以最大化CAP的長度
當PAN協調器釋放GTS時，它應將GTS描述符添加到其信標幀中，指示GTS已被釋放；如果釋放是由設備發起的，則PAN協調器不應將GTS描述符添加到其信標幀中以指示釋放；對於具有分配的GTS的每個設備，其具有低於釋放的GTS的起始時隙，PAN協調器將用新的起始時隙更新GTS，並將GTS描述符添加到與該調整的GTS相對應的信標；計算新的起始時隙，以保證在GTS之間或GTS和CFP的末尾之間沒有間隙
在多個重新分配同時發生的情況下，PAN協調器可以選擇分階段執行重新分配；PAN協調器應將每個GTS描述符保留在其信標中，以用於aGTSDescPersistenceTime超幀
在接收到包含對應於macShortAddress的GTS描述符的方向和長度的信標幀時，設備應調整對應於GTS描述符的GTS的起始時隙並立即開始使用它
在PAN協調器必須在其信標中包括GTS描述符的情況下，應允許其將CAP減小到低於aMinCAPLength以適應信標幀長度的臨時增加；在aGTSDescPersistenceTime超幀之后，PAN協調器將從信標中移除GTS描述符
6.7.6 GTS到期
PAN協調器的MLME應使用如下規則嘗試檢測設備何時停止使用GTS：
- 對於發送GTS, 當沒有從GTS中的設備接收到至少每2*n個超幀的數據幀, PAN協調器的MLME應認為設備不再使用其GTS
- 對於接收GTS, 當在至少每2*n個超幀中沒有從設備接收到確認幀, 則PAN協調器的MLME應認為設備不再使用其GTS
其中n定義如下
6.8 幀安全
MAC層為高層請求負責在指定的傳入和傳出幀上提供安全服務；IEEE Std 802.15.4-2003支持以下安全服務
- Access control: 訪問控制, 通過ACL來維護期望通信的的設備列表 - Data encryption: 數據加密, 使用共享的密鑰對信標載荷、命令載荷或者數據載荷進行加密 - Frame integrity: 幀完整性, 使用Message Integrity Code(MIC)來保護數據不被沒有加密密鑰的設備修改 - Sequential freshness: 序列號的更新, 使用有序的輸入序列來保證幀的最新, 同時拒絕已使用過序列號的幀
該協議還提供以下安全模式
- Unsecured mode: 不安全模式, 不提供安全服務 - ACL mode: ACL(Access Control List)模式, 提供有限的安全服務, 高層應實現其他機制以確保發送設備的身份 - Secured mode: 安全模式, 提供上面的四種安全服務, 特定的安全服務依賴於正在使用的安全套件
6.8.1 ACL條目
MAC PIB安全屬性包含單個默認ACL條目和許多補充ACL條目；PAN中的每個設備都知道默認ACL條目，該條目用於設備需要與第二個/多個設備通信的情況；單個ACL條目用於設備與特定已知設備共享密鑰的情況。
默認ACL條目由如下部分組成
- macDefaultSecurity: 指示安全性是否用於不在ACL中的設備 - macDefaultSecuritySuite: 指示用於從不在ACL中的設備發送或接收幀的默認安全套件 - macDefaultSecurityMaterial: 指示在安全通信中使用的密鑰材料, 涉及要從不在ACL中的設備發送或接收的幀
如果macDefaultSecurity設置為FALSE，則不應使用macDefaultSecuritySuite和macDefaultSecurityMaterial
補充ACL條目包含在macACLEntryDescriptorSet中；每個ACL條目對應一個可信設備，由其PAN標識符、64位擴展地址、短地址(如果該地址未知，為0xffff)及其安全套件和相關密鑰資料組成
6.8.2 不安全模式
不安全模式是MAC層的默認安全模式，即不提供MAC層安全性
以不安全模式運行的設備不應使用ACL條目，也不得對傳入幀執行任何與安全相關的操作；當設備在此模式下接收幀時，MAC層應在檢查安全使能字段之前對輸入幀執行其過濾操作，如【6.6.2 接收和拒絕】中所述
如果幀中的安全使能字段設置為1且設備未執行主動或被動掃描，則MAC層應通過MCPS-DATA.indication(SecurityUse=TRUE，ACLEntry=0x08)原語將幀傳遞到高層
如果設備正在執行主動或被動掃描，則設備應接受安全使能字段設置為1的信標幀，並將與該信標對應的PAN描述符的SecurityUse，ACLEntry和SecurityFailure字段分別設置為TRUE，0x08和TRUE
如果MAC層接收到安全使能字段設置為0的數據幀，則它應通過MCPS-DATA.indication(SecurityUse=FALSE，ACLEntry=0x08)原語將幀傳遞給更高層
6.8.3 ACL模式
ACL模式為MAC層提供了一種機制，用於向更高層指示所聲稱的接收幀是否源自ACL中的設備
以ACL模式運行的設備不得對MAC幀進行任何修改或執行任何加密操作；因此，ACL模式僅提供設備根據幀中的源地址過濾接收到的幀的手段，但不是安全地確定幀的發送者的手段
當設備在此模式下接收幀時，MAC層應在檢查安全使能字段之前對輸入幀執行其過濾操作，如【6.6.2 接收和拒絕】中所述
如果幀中的安全使能字段設置為1且設備未執行主動或被動掃描，則MAC層應通過MCPS-DATA.indication(SecurityUse=TRUE，ACLEntry=?)原語將幀傳遞到高層，其中ACLEntry字段設置為與數據幀發送方關聯的ACL條目中的macSecurityMode參數值(如果存在)；如果在ACL中未找到數據幀的發送方，則ACLEntry字段應設置為0x08
如果設備正在執行主動或被動掃描，則設備應接受安全使能字段設置為1的信標幀並將對應於該信標的PAN描述符的SecurityUse和SecurityFailure字段設置為TRUE，並將ACLEntry字段設置為與數據幀的發送方相關聯的ACL條目的macSecurityMode參數值(如果存在)，如果在ACL中未找到數據幀的發送方，則應在ACLEntry字段中使用值0x08
如果MAC層接收到安全使能字段設置為0的數據幀，則MAC層應通過MCPS-DATA.indication(SecurityUse=FALSE，ACLEntry=?)原語將幀傳遞到高層，其中ACLEntry字段設置為與數據幀發送方關聯的ACL條目中的macSecurityMode參數值(如果存在)；如果在ACL中未找到數據幀的發送方，則ACLEntry字段應設置為0x08
設備應通過在macACLEntryDescriptorSet中搜索具有與接收到的PAN標識符匹配的ACLPANId值以及與接收到的源地址匹配的ACLExtendedAddress或ACLShortAddress值的單個ACL條目來確定設備是否在ACL中；如果幀中沒有源地址，則ACLEntry字段應設置為0x08
6.8.4 安全模式
安全模式為MAC層提供了一種機制，既可以使用ACL功能，也可以對傳入和傳出幀提供加密保護；在此模式下，如果MAC層接收到輸入幀或來自高層的請求以發送幀，則MAC層應按照下面的規定處理幀
6.8.4.1 傳出幀的處理
細節可參考<IEEE 802.15.4-2003>的7.5.8.4.1 Processing outgoing frames in secured mode章節
6.8.4.2 輸入幀的處理
細節可參考<IEEE 802.15.4-2003>的7.5.8.4.2 Processing incoming frames in secured mode章節
7. 安全套件
細節可參考<IEEE 802.15.4-2003>的7.6 Security suite specifications章節