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)上运行的所有设备应能够根据高层的轮询协调器以获取数据；当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时间内发送确认帧，
在接收到帧挂起子字段设置为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使用的最终超帧时隙；同时不应该向信标帧添加描述符来描述释放
在接收到包含对应于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章节