IEEE 802.15.4的信道接入机制<三>信标网络中的GTS

八.信标网络中的GTS信道接入管理

1.基本概念和要点

1.1 GTS基本概念

GTS，guaranteed time slot，保证时隙 。它用来管理基于时隙 的 信标网络中非CSMA-CA信道接入。

GTS作用于超帧的CFP期间，它是信标网络中TDMA信道接入实现机制的具体单位。

在超帧的CFP竞争空闲期间，将CFP划分为多个 保证时隙(GTS)，各个设备请求并获取该 保证时隙(GTS)，而 保证时隙是时分多路复用的，被获取的设备所独占。

GTS可以看做一种如RAM空间一样的稀缺资源。

一旦设备或许到GTS后，就可以在GTS时期内收发数据，而不考虑信道竞争冲突。

1.2 GTS使用要点

• GTS只能用于其它设备与PAN协调器之间的通信，且该设备已经和PAN协调器关联。
• 在分配的GTS中传输的数据帧只能使用短寻址。
• 已经分配了GTS的设备也可以在CAP中运行。

1.3 发送GTS和接收GTS

GTS分为发送GTS(transmit GTS)和接收GTS(receive GTS)，这是由 信标帧中GTS  fields和命令帧中GTS Characteristics的子域 GTS direction来标识的 ，

发送GTS(transmit GTS)和接收GTS(receive GTS)含义如下(参见"在IEEE 802.15.4--2006" P193):

GTS方向（相对于拥有GTS设备的数据流）被指定为发送或接收。 因此，设备地址和方向应该能唯一标识每个GTS。

每个设备可以请求一个发送GTS和/或一个接收GTS。 对于每一个分配的GTS，设备应能够存储起始时隙、长度和方向。 

如果一个设备已经分配了一个接收GTS，设备应该在整个GTS周期内使能它的接收器。 同样的，如果一个设备被分配了

一个发送GTS， PAN协调器应该在整个GTS周期内使能它的接收器。 如果在接收GTS( receive-only GTS) 期间接收到数据帧， 并且请求确认， 则设备将照常发送确认帧。  同样，一个设备应该能够在发送GTS( transmit-only GTS) 期间接收一个确认帧。

也即：

如果GTS direction为1，表明占用该GTS的设备在此GTS期间只能发送数据；为0，则只能接收数据。

以下两种情况作为特例：

1) 接收GTS(receive-only GTS)期间接收到数据帧， 并且请求确认， 则设备将照常发送确认帧。

2) 一个设备应该能够在发送GTS(transmit-only GTS)期间接收一个确认帧。

上面描述中的"设备地址和方向应该唯一的标识每个GTS"，即GTS域中，如果地址相同，但方向不同，也被视为不同的GTS。

上述的“发送”和“接收”是相对于设备来说的。即在协调器一端，方向刚好相反。 

GTS的实现机制分为两部分：

• 协调器周期广播信标，信标帧中包含GTS的划分结构和占用情况
• 设备通过GTS请求命令帧获取GTS

下面就此分别 予以 讨论。

2.信标帧中的GTS域

超帧中包含的TS数由超帧规范来定义，超帧规范域中的 bit8-11 Final CAP Slot定义了CAP的边界，

CFP的TS由此开始，包含了16个TS中剩余的部分，而 每个 GTS 包含(持续时间为)一个或多个CFP TS。

GTS 只能由 PAN 协调器分配， GTS 最多只能同时有 7 个 。

信标帧中的GTS域是用来管理GTS的，它包含了GTS资源的分配占用情况。

信标中GTS域的格式如下图：

GTS Specifications：GTS规格

• bit 0-2：GTS Descriptor Count，GTS描述符计数；
• bit 3-6：保留
• bit 7   ：GTS Permit是GTS允许位，指示PAN协调器可否接受GTS请求。1表示允许，反之为拒绝。

GTS Direction：GTS方向

• bit 0-6：分别表示对应GTS的方向，1--receive-only GTS；0--transmit-only GTS
               方向是相对于设备端来说的。即1表示从PAN协调器到设备，0表示从设备到PAN协调器。
• bit 7   ：保留

GTS List：GTS列表，由若干个GTS描述符( GTS descriptor)组成， 每个描述符对应一个GTS

• bit 0-15  ：拥有该GTS的设备的短地址。
• bit 16-19：GTS的开始时隙。
• bit 20-23：GTS的长度。

3. GTS请求命令帧格式(该帧是命令帧，参见帧类型中的命令帧格式)：

• Command Frame Identifier，指示命令帧类型，此处为0x09，表示GTS request。
• GTS Characteristic，指示GTS特性。
  • bit 0-3 GTS Length   ：请求的GTS长度，占多少个超帧时隙。
  • bit 4    GTS Direction：GTS的方向。1表示从PAN协调器到设备，0表示从设备到PAN协调器。
  • bit 5    Characteristics Type：命令类型指示是申请分配GTS还是申请删除GTS。1表示分配，0表示删除。

4. GTS分配：

GTS分配过程如下：

 1)设备向PAN协调器发送GTS请求命令帧。命令帧中GTS characteristics字段的子域Characteristics type设置为1，

     方向和长度根据需要设置。

 2)PAN协调器判断是否要分配GTS，若PAN决定分配GTS，则在信标帧中携带所分配的GTS信息。

• GTS应按先到先得的原则进行分配。
• PAN协调器判断是否分配GTS的依据为：没有到达最大的GTS数(7个)，且所期望分配的GTS长度不能减少CAP到小于aMinCAPLength。
• 如果分配成功，PAN协调器应将GTS描述符中的起始时隙设置为GTS开始的超帧时隙，并将GTS描述符中的长度设置为GTS的长度。

        没有足够的容量来分配所请求的GTS，GTS描述符中的起始时隙应设置为零，并且长度可以是当前所能支持的
        最大GTS长度。

• PAN协调器应该将这个GTS描述符包含在其信标中，并相应地更新信标帧的GTS规范（Specification）字段。
• PAN协调器还应该更新信标帧超帧规范的Final CAP Slot子域。指示减少的CAP使用的最后超帧时隙。
• GTS描述符应在信标帧中保留aGTSDescPersistenceTime(4次)超帧周期，之后它会被自动移除。aGTSDescPersistenceTime是超帧次数，IEEE 802.15.4--2006规定为4次。

 3)设备通过监听信标，来判断GTS请求是否成功。

• 当收到对GTS请求命令的确认，设备将继续跟踪信标，并等待最多4次超帧时间，

        如果在此期间内没有包含该设备GTS描述符的信标帧出现，MLME会通知上层失败。

• 如果收到包含与macShortAddress对应的GTS描述符的信标帧，设备将处理该描述。
  设备的MLME会通知上层GTS分配是否成功：
  如果GTS描述符中的起始时隙大于0， MLME就发出发出状态为SUCCESS的MLMEGTS.confirm原语；
  如果GTS描述符中的开始时隙为0，或者其中的长度不匹配请求的长度，MLME就发出发出状态为DENIED的MLMEGTS.confirm原语。

GTS分配过程中的相关原语：

上述通信过程如下：

• 高层向MAC层发MLME-GTS.request原语。
• MAC层向物理层发PD-DATA.request原语。
• 设备物理层向PAN协调器物理层发GTS请求命令帧。
• PAN协调器物理层向MAC层发PD-DATA.indication。
• PAN协调器向设备发应答帧。
• PAN协调器通过MLME-GTS.indication原语将GTS请求传递给高层。
• PAN协调器发送信标帧，帧中携带所分配的GTS信息
• 设备收到信标后，向高层发送MLME-GTS-confirm原语。

5.GTS使用

因GTS的方向是针对设备方来说的，所以GTS的使用包括：

• 设备作为数据发送方使用发送GTS和设备作为数据接收方来使用接收GTS。
• 协调器作为数据接收方使用发送GTS和协调器作为数据发送方来使用接收GTS。

针对接收GTS来说，无论是协调器还是设备，必须在该GTS期间使能接收器。

针对发送GTS来说，无论是协调器还是设备，必须保证在该GTS期间数据能被完全发送，否则剩余的数据会推延到下一个超帧中的该GTS期间发送。

6. GTS解除分配(deallocation，或称为释放，下面的表述中视情况会混用”解除分配“和”释放“)：

从GTS释放的那一点开始，解除的GTS不能再被使用，它存储的特性(characteristics)应被重置。

GTS解除分配 的 发起或者来源于设备的命令请求，或者来源于协调器本身。

1)设备向PAN协调器发送GTS解除分配请求命令，请求解除分配GTS。

 该命令帧中GTS Characteristics的 Characteristics Type子域应被设置为0 ( 即 解除分配 )，长度和方向子域应该和所要求 解除分配 的GTS特性一致。

 

 协调器动作如下：

 协调器收到此请求应该予以应答确认。

  一旦收到GTS 解除分配 请求 ，PAN协调器将尝试 解除分配 该GTS。

 如果GTS请求命令中包含的GTS特性与已知GTS的特性不匹配，则PAN协调器将忽略该请求。如果GTS请求命令中

 包含的GTS特性与已知GTS的特性相匹配，则PAN协调器的MLME应释放指定的GTS，并将此更改通知更高层。

 如果该解除分配来自上层的请求，则需要确认。

 PAN协调器应更新信标帧的超帧规范字段的最终CAP时隙子域，指示增加 的CAP所使用的最终超帧时隙。

 它不应该向信标帧添加一个描述符来描述解除分配(因为是设备发起的，设备默认就不应再使用请求释放的GTS)。

 

如果PAN协调器未正确接收到GTS请求命令，则应通过下面3)中的规则确定设备已停止使用其GTS。

2)GTS释放由协调器发起

此时，PAN协调器由于GTS到期或由于CAP维护(如因CAP长度小于aMinCAPLength)而发起GTS释放。

PAN协调器将解除分配GTS，并将GTS描述符添加到与解除分配的GTS 相对应的信标帧中，但其起始时隙设置为零。 

GTS描述符应在信标帧中 保留 aGTSDescPersistenceTime(4次)超帧周期。

设备如果收到信标帧中GTS描述符的starting slot为0，且描述符中的地址和自己地址相匹配， 就停止使用GTS，

并使用MLMEGTS.indication原语通知上层。

3)长期没有收到数据，PAN协调器自动解除GTS。

•  对于发送GTS，PAN协调器在连续2n个超帧没有收到设备的数据，就认为GTS过期。
•  对于接收GTS，PAN协调器在连续2n个超帧没有收到设备的应答，就认为GTS过期。
   这时，如果在GTS中发送的数据帧不需要确认帧，PAN协调器将无法检测到设备是否正在使用其接收GTS。
   但是，PAN协调器可以随时解除GTS。
•  n的取值：BO为0-8时，n=28-BO；BO为9-14时，n=1。

GTS解除分配过程中的相关原语：

7. GTS重分配(reallocation)

GTS的解除分配可能导致超帧碎片。 如下图所示的过程：

在阶段2中，由于删除了GTS 2，在CFP内留下了GTS碎片。

为了解决这个问题， GTS 3将不得不转移填补空白，从而增加CAP的大小 ( 阶段3）。

重分配之后的变更要使用信标帧通知各设备。设备在收到变更通知后，更新自己的GTS。