CN104427619A - 时隙分配方法和装置 - Google Patents

Abstract

本发明实施例提供一种时隙分配方法和装置，其中，所述方法包括：构建HELLO包，所述HELLO包包含本地节点请求预约的多个时隙的相关信息或者包含本地节点请求预约的多个时隙的相关信息和所述节点的至少一个邻居节点请求预约的多个时隙的相关信息；发送所述HELLO包，以便接收到该HELLO包的节点根据HELLO包中所包含的信息对所述节点请求预约的多个时隙进行认证。通过本发明实施例的方法和装置，提高了时隙利用率。

Description

时隙分配方法和装置

技术领域

本发明涉及无线通信、Ad hoc（点对点）网络、智能电网，尤其涉及一种时隙分配方法和装置。

背景技术

MAC（Media Access Control，媒体接入控制）层协议被设计为确保网络中的特殊发射器的无线资源，例如时隙、频率信道、扩频码等等，对于ad hoc网络，由于缺少中心管理，一般通过握手或协商来保证资源分配。

载波侦听多路访问（CSMA，Carrier sensing multiple access)是MAC层协议最通用的。每一个潜在的发射器节点在向网络实际发送包之前必须感应信道的状态。而当没有正确反映信道的实际状态时，会发生碰撞，这种碰撞被称之为隐藏终端问题。对于大量节点试图在同一时间发送包的大规模的网络来说，这个问题会变得非常严重。最后将导致服务质量（QoS，Quality of Service）的下降，以致无法满足应用需求。

时分多址（TDMA，Time division multiple access）为MAC层协议提供了一种替代方案。唯一的时隙被预留给传输使用以保证高的服务质量。在IEEE（Institute ofElectrical and Electronics Engineers，电气和电子工程师协会）802.15.4规范中，超帧的一部分，被称为无竞争周期（CFP，collision free period）被划分为TDMA传输。在该周期内最小的可用单元被称为保证时隙（GTS，Guaranteed Time Slot）。

然而，IEEE802.15.4规范只为星形拓扑的网络提供了基本的GTS调度结构，无法支持其他复杂类型网络中的时隙分配，尤其是大规模网络和ad hoc模式。

应该注意，上面对技术背景的介绍只是为了方便对本发明的技术方案进行清楚、完整的说明，并方便本领域技术人员的理解而阐述的。不能仅仅因为这些方案在本发明的背景技术部分进行了阐述而认为上述技术方案为本领域技术人员所公知。

发明内容

本发明实施例的主要目的在于提供一种时隙分配方法和装置，以解决背景技术所指出的问题。

根据本发明实施例的第一方面，提供了一种节点，其中，所述节点包括：

构建单元，其用于构建HELLO包，所述HELLO包包含所述节点请求预约的多个时隙的相关信息或者包含所述节点请求预约的多个时隙的相关信息和所述节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送单元，其发送构建单元构建的所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO所包含的信息对所述节点请求预约的多个时隙进行认证；

其中，

所述节点请求预约的多个时隙的相关信息包括：所述节点的地址、上述节点要发送的数据包的接收节点地址、所述节点请求预约多个时隙的起始时隙索引和时隙长度；

所述邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点的距离、以及邻居节点请求预约的多个时隙的确认信息。

根据本发明实施例的第二方面，提供了一种时隙分配方法，其中，所述方法包括：

构建HELLO包，所述HELLO包包含本地节点请求预约的多个时隙的相关信息或者包含本地节点请求预约的多个时隙的相关信息和本地节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO包中所包含的信息对所述本地节点请求预约的多个时隙进行认证。

本发明实施例的有益效果在于：通过本发明实施例的方法和装置，根据业务量提高了时隙利用率。

参照后文的说明和附图，详细公开了本发明的特定实施方式，指明了本发明的原理可以被采用的方式。应该理解，本发明的实施方式在范围上并不因而受到限制。在所附权利要求的精神和条款的范围内，本发明的实施方式包括许多改变、修改和等同。

针对一种实施方式描述和/或示出的特征可以以相同或类似的方式在一个或更多个其它实施方式中使用，与其它实施方式中的特征相组合，或替代其它实施方式中的特征。

应该强调，术语“包括/包含”在本文使用时指特征、整件、步骤或组件的存在，但并不排除一个或更多个其它特征、整件、步骤或组件的存在或附加。

附图说明

参照以下的附图可以更好地理解本发明的很多方面。附图中的部件不是成比例绘制的，而只是为了示出本发明的原理。为了便于示出和描述本发明的一些部分，附图中对应部分可能被放大或缩小。在本发明的一个附图或一种实施方式中描述的元素和特征可以与一个或更多个其它附图或实施方式中示出的元素和特征相结合。此外，在附图中，类似的标号表示几个附图中对应的部件，并可用于指示多于一种实施方式中使用的对应部件。

在附图中：

图1是HELLO包和数据包在时域上分布式传输的示意图；

图2是超帧被分为五组的帧结构的示意图；

图3A是HELLO包的格式的一个实施方式的示意图；

图3B是HELLO包的格式的另一个实施方式的示意图；

图4是HELLO包发送和接收的整体流程图；

图5是3跳冲突域的示意图；

图6是本发明实施例的时隙分配方法的流程图；

图7是构建HELLO包的一个实施方式的流程图；

图8是确定请求预约的多个时隙的流程图；

图9是选择空闲时隙的流程图；

图10是选择空闲时隙的一个实施方式的示意图；

图11是HELLO包的发送流程图；

图12是HELLO包的接收流程图；

图13是当周期为3时交织前和交织后的时隙示意图；

图14是扩展预约的时隙的示意图；

图15是本发明实施例的节点的组成示意图。

具体实施方式

参照附图，通过下面的说明书，本发明实施例的前述以及其它特征将变得明显。这些实施方式只是示例性的，不是对本发明的限制。

为了使本领域的技术人员能够容易地理解本发明的原理和实施方式，本发明实施例以Ad-hoc网络为例进行说明，但可以理解，本发明实施例并不限于Ad-hoc网络，例如，本发明实施例提供的方法和装置也适用于无线通信、智能电网等其他多跳网络。

在本发明实施例中，时隙分配以分布式的方式执行，由此更有助于ad hoc网络的实施。在时隙分配过程中涉及一种类型的控制包，也即HELLO包，其是一个广播包并且通常在路由协议中使用。为了为数据包传输预约有效的资源，该控制包被分开传输。换句话说，数据包和控制包在不同的频率或时隙或其他类型的信道中被传输。图1所示为IEEE802.15.4系统中在时间上分开传输的一个例子。

该时隙分配流程通过控制包也即HELLO包的交互来完成，每个节点通过发送和接收HELLO包来为数据传输预约有效时隙并避免冲突。为了保证分配的灵活性和有效性，在CAP中传输的HELLO包并不一定用于预约相同超帧中的时隙，这些HELLO包也可以用于预约之前的或之后的超帧中的时隙。在某些情况下，可以对一定数量的超帧进行分组来扩大网络规模。这就意味着在超帧中的任何一个中（CAP）发送的HELLO包被允许用来预约在这些超帧中（CFP）的任意的时隙。图2为在一个组中的超帧的数量被设置为5的示例。

为了避免其他节点使用相同的时隙用于数据传输，HELLO包被周期性的广播来指示其占用的特定时隙。该周期可以与应用需求一致。对于一个静态网络，例如智能网，节点的位置很少变化，此时，可以采用较长的周期。

在本发明实施例中，HELLO包可以被分为两部分，一部分为REQ部分，指示了HELLO包的发送方请求预约的时隙，也即本地节点请求预约的多个时隙的相关信息；第二部分称为RES部分，指示了对邻居节点请求的响应，也即本地节点的至少一个邻居节点请求预约的多个时隙的相关信息，对应每个邻居节点，包含一条对该邻居节点请求的响应。在第一部分中，该发送方请求预约的时隙包含了四个字段的信息，也即，本地源ID、本地目标ID、起始时隙索引以及时隙长度；在第二部分中，每个响应至少包含了以下六个字段的信息，也即，本地源ID、本地目标ID、起始时隙索引、时隙长度、距离以及确认信息。

图3A为本实施例的一个实施方式的HELLO包的格式示意图。如图3A所示，本地源ID（Local Source ID）代表了数据包的发送地址，如果HELLO包被发送来为自己预约时隙，则其与HELLO包的发送方的ID相同；本地目标ID（Destination ID）代表了数据包的接收方的地址，在多跳ad hoc网络中，其是指下一跳的ID，如果该网络是树形拓扑，其也指父节点的ID；起始时隙索引（Start slot Index）代表了本地源节点希望预约的首选的起始时隙，该时隙的选择要基于从HELLO包中提取的邻居节点的选择的观察；长度（Length）代表了本地源节点所希望预约的从起始时隙开始的期望的时隙长度；距离（Distance）代表了本地源节点与HELLO包的发送节点之间的跳数；确认信息（Confirmation）是从邻居节点得到的反馈，其代表了对本地源节点能否预约该期望的时隙的同意或不同意（也即反对），在接收到一个HELLO包后，如果本地源节点的ID与HELLO包的发送方的ID相同，则每个节点应该决定该确认信息。

图3B为本实施例的另外一个实施方式的HELLO包的格式示意图。如图3B所示，除了与图3A的HELLO包相同的信息以外，在该实施方式中，每一个信息条目还包括本地源节点的交织周期，以便各个本地源节点根据预定的交织方法将请求预约的多个时隙映射到物理时隙上进行数据传输。

在本发明实施例中，为了记录邻居节点的预约并跟踪每个时隙中的状态更新，每个节点需要维护一个本地表，在该本地表中包含多个条目，每个条目至少包括与接收到的HELLO包中的RES部分一样的项目，对应图3A的实施方式，本地请求表中的每个条目包括六个项目，也即，本地源节点ID、本地目标节点ID、起始时隙索引、长度、距离和确认信息；对应图3B的实施方式，本地请求表中的每个条目包括七个项目，除以上六个项目以外，还包括交织周期。

表1是对应图3A的实施方式的本地表的一个示例。另外，在本发明实施例中，将该本地表称为请求表或者本地请求表。

表1

本地源ID	本地目标ID	起始时隙索引	长度	距离	确认信息
						B	A	3	3	1	1
C	B	1	2	2	1
						D	C	6	1	3	1
E	A	2	1	1	0

在本发明实施例中，HELLO包的交互过程如图4所示。HELLO包的传输由本地定时器调度。当本地定时器启动时，一个HELLO包的发送节点首先决定HELLO包的如前所述的两部分的内容，并构建该HELLO包。当接收到该HELLO包时，一个HELLO包的接收节点应该基于本地观察，例如本地请求表，决定与该HELLO包中的REQ部分相关的确认值，也即是否同意该HELLO包的发送节点请求预约的该多个时隙的相关信息。另外，从HELLO包获取的所有信息应该被用于更新本地请求表。

在本发明实施例中，定义了n跳冲突域的概念。如果在一个冲突域内的两个节点同时发送包，将可能产生冲突。因此，本发明实施例在时间区域上分离这些节点，以避免这种情况发生。其中，每个节点将n跳范围内的邻居节点的信息保存到本地请求表中，并且不能选择这些被占用的时隙用于传输。另外，每个节点可以选择1、2至n-1跳的邻居节点构建其HELLO包的RES部分。并且，每个节点根据其1、2至n-1跳邻居的信息对邻居节点请求预约的多个时隙给予确认。

图5给出了3跳冲突域的一个示例。如图5所示，节点A和节点D不能预约相同时隙。节点D会将节点B和节点C（一跳和2跳邻居）的信息放到HELLO包的广播流程中，由此，节点E会接收到该HELLO包，并且不会选择与节点B、节点C和节点D相同的时隙。另外，节点E能够选择与节点A相同的时隙，因为节点A和节点E不在一个冲突域内。并且，如果节点E预约了与节点A相同的时隙，节点D会发现该情况，但是不能拒绝节点E。因为节点A是节点D的3跳邻居。

在本发明实施例中，每个节点还保存了其之前预约的多个时隙，以及邻居节点对其请求预约的多个时隙的相关信息的确认结果。以便在下次构建HELLO包时作为选择空闲时隙的参考。

在本发明实施例中，在HELLO包的传输过程中，节点需要寻找可用的空闲时隙来构建其HELLO包的REQ部分，并从请求表中寻找合适的信息来构建其HELLO包的RES部分。以下结合附图和具体实施例对本发明实施例的时隙分配方法和装置进行详细说明。

实施例1

本发明实施例提供了一种时隙分配方法，该方法应用于多跳网络中的节点。图6是该方法的流程图，请参照图6，该方法包括：

步骤601：构建HELLO包，所述HELLO包包含本地节点请求预约的多个时隙的相关信息或者包含本地节点请求预约的多个时隙的相关信息和本地节点的至少一个邻居节点请求预约的多个时隙的相关信息；

其中，本地节点请求预约的多个时隙的相关信息也即前面所描述的HELLO包的REQ部分，本地节点的至少一个邻居节点请求预约的多个时隙的相关信息也即前面所描述的HELLO包的RES部分。关于REQ部分和RES部分的内容已在前面做了说明，在此不再赘述。

在本实施例的一个场景中，本地节点首次发包，由于其没有接收过来自其他节点的HELLO包，因此其并没有存储本地请求表，此时，其构建的HELLO包只包括REQ部分。

在本实施例的其他场景中，本地节点接收过来自其他节点的HELLO包，并依据该HELLO包中的信息存储并更新了本地请求表，此时，其构建的HELLO包包括了REQ部分和RES部分。

步骤602：发送所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO包中所包含的信息对所述本地节点请求预约的多个时隙进行认证。

其中，如前所述，在本发明实施例中，构建上述HELLO包的目的在于预约时隙进行数据传输，构建好这样的HELLO包后，即可通过现有的手段广播发送出去。而接收到该HELLO包的节点即可根据该HELLO包中的信息对所述本地节点请求预约的多个时隙进行认证，另外还可以据此确认其请求预约的多个时隙是否有效，另外还可以更新其本地请求表或者更新其预约历史信息，并依照本实施例的方法构建其HELLO包。具体的接收流程将在以下进行说明。

在本实施例中，如前所述，本地节点请求预约的多个时隙的相关信息包括：本地节点的地址（也即本地节点要发送的数据包的发送节点的地址）、本地节点要发送的数据包的接收节点地址、请求预约多个时隙的起始时隙索引和时隙长度。邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址（也即邻居节点要发送的数据包的发送节点的地址）、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点（上述HELLO包的发送节点）的距离、以及邻居节点请求预约的多个时隙的确认信息。

在本实施例中，如前所述，除了以上内容以外，本地节点请求预约的多个时隙的相关信息还可以包括本地节点的交织周期；同样的，邻居节点请求预约的多个时隙的相关信息还可以包括邻居节点的交织周期。

在本实施例中，步骤601可以通过图7所示的方法实现，请参照图7，该方法包括：

步骤701：从路由表中选择本地节点要发送的数据包的接收节点，得到所述本地节点要发送的数据包的接收节点地址；

其中，每个节点维护有一张路由表，该路由表指示了该节点到达目标节点的多条路径，以及各条路径的路由花费。在本实施例中，可以选择路由花费最小的路径对应的接收节点作为要发送的数据包的接收节点，从而获得该接收节点的地址。

步骤702：根据本地预约历史信息和/或本地请求表确定请求预约的多个时隙，得到请求预约的多个时隙的起始时隙索引和时隙长度；

其中，步骤702是选择空闲时隙的步骤，当之前选择的空闲时隙有效，且在预定时间内没有收到来自邻居节点的反对时，可以采用之前选择的空闲时隙，否则可以重新选择空闲时隙，并确定选择的空闲时隙的起始时隙和时隙长度。具体将在以下进行说明。

步骤703：根据本地节点要发送的数据包的接收节点地址、请求预约的多个时隙的起始时隙索引和时隙长度以及本地节点的地址，得到所述本地节点请求预约的多个时隙的相关信息。

其中，通过步骤701获得了数据包的接收节点的地址，通过步骤702获得了请求预约的多个时隙的起始时隙和时隙长度，即可构建本地节点请求预约的多个时隙的相关信息，也即HELLO包的REQ部分。其中，在该REQ部分中，由于该HELLO包是为本地节点预约时隙，因此，该HELLO包的REQ部分的本地源ID即为本地节点的ID。

在本实施例中，如果本地表中存储了邻居节点对应的信息条目，则图7的方法还包括：

步骤704：根据预定策略，从本地请求表中选择至少一个邻居节点的信息条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

其中，可以从本地请求表中选择本地节点的n跳冲突域内的1～（n-1）跳邻居节点的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息；也可以从本地请求表中选择本地节点的n跳冲突域内的所有一跳邻居节点的条目以及2～（n-1）跳邻居节点的条目中确认信息为同意的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。构建到HELLO包中的条目越多，能够达到的包含于HELLO包中的预约信息的区域就越大，能够保证较低冲突的可能性。

在步骤702中，确定请求预约的多个时隙的步骤可以通过图8的方法来实现，请参照图8，该方法包括：

步骤801：计算所需的时隙长度；

其中，所需要的时隙长度可以基于业务量的绝对数计算获得，也可以基于n跳冲突域内的业务流的比值来计算获得。但本实施例并不以此作为限制，在本发明的精神和范围内，本领域技术人员想到的其他的计算所需的时隙长度的方法，都包含于本发明的保护范围之内。

其中，基于业务量的绝对数计算所需要的时隙长度，也即根据本地节点的所有子节点预约的时隙的长度之和计算所需的时隙长度。

假设每个节点生成了一个包并希望将其发送到汇聚（sink）节点。如果本地节点有K个子节点，并且子节点i申请了length_i个传输时隙，则本地节点所需的时隙长度可以通过以下公式计算获得：

$\mathrm{length}=1+\underset{i=1}{\overset{K}{\mathrm{\Σ}}}{\mathrm{length}}_i$

也即，子节点是本地表条目中的目的节点ID是本地节点的源节点ID所示的节点。

其中，基于n跳冲突域内的业务流的比值来计算所需要的时隙长度，也即根据本地节点的冲突域内的邻居节点的业务量计算所需的时隙长度。

假设邻居j在本地节点的n跳冲突域之内，并且其申请了length_j个传输时隙，并且本地节点在n跳冲突域内有N个邻居，则本地节点所需的时隙长度可以通过以下公式计算获得：

$\mathrm{length}=\frac{1+{\mathrm{\Σ}}_{i=1}^K\mathrm{lengt}{h}_i}{1+{\mathrm{\Σ}}_{i=1}^K{\mathrm{length}}_i+{\mathrm{\Σ}}_{j=1}^N{\mathrm{length}}_j}\·S_{\mathrm{total}}$

其中，S_total代表了冲突域内的保证时隙的总数，例如一个HELLO包间隔，或一个超帧等等，也即其是指可预约的时隙的周期。

步骤802：根据本地保存的预约历史信息确定所需的时隙长度是否发生变化；

其中，如前所述，每个节点可以保存之前预约的多个时隙的相关信息，例如，起始时隙、时隙长度、标志位等，在本实施例中称为预约历史信息。根据该预约历史信息，可以确定之前预约的时隙长度与计算出的所需的时隙长度相比，是否发生了变化。

步骤803：如果所需的时隙长度发生变化，则根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙的起始时隙和时隙长度；

其中，根据步骤802的判断，如果发生了变化，就需要重新选择空闲时隙。

在一个实施方式中，选择空闲时隙的步骤可以通过图9所示的方法来实现，请参照图9，该方法包括：

步骤901：选择起始时隙；

步骤902：以所述起始时隙为起点，根据本地请求表的信息，选择连续M个未被占用的时隙作为所述空闲时隙，其中，M小于等于计算出的所需的时隙长度。

在步骤901中，可以基于包含于请求表中的信息选择空闲的起始时隙。

在一个实施方式中，该起始时隙可以从未被n跳冲突域内的其他节点占用的时隙中随机选择，也即从预先配置的时隙集合中随机选择未被使用的时隙作为所述起始时隙。

在一个实施方式中，该起始时隙可以由本地节点的一个函数来确定，也即从预先配置的时隙集合中选择时隙索引为本地节点的地址的函数的时隙作为所述起始时隙，例如以下函数：

s_i=f(ID_i)=ID_imod K

其中，K指示了时隙的总数。

在一个实施方式中，该起始时隙可以由跳数的函数来确定，也即根据本地节点的跳数，从该跳数对应的时隙集合中选择未被使用的时隙作为所述起始时隙。如表2所示，第i跳的节点只能选择集合k_i中的起始空闲时隙。

表2

跳数(i)	可用时隙集合(ki)
		8	1,2,3,…,8
7	1,2,3,…,16
		6	1,2,3,…,32
5	1,2,3,…,64
		4	1,2,3,…,128
3	1,2,3,…,256
		2	1,2,3,…,512
1	123…1024

在一个实施方式中，该起始时隙还可以基于对占用的时隙的观察来确定。举例说明，选择的时隙可以是第一个未被其他节点占用的空闲时隙。或者找出两个占用的时隙之间的最大空闲时隙间隔，选择中间一个作为适当的时隙。在这种情况下，可以保证两个占用的时隙之间的最大空闲时隙间隔。

图10示意了选择起始时隙的一个示例。

需要说明的是，以上选择起始时隙的方法只是举例说明，本发明实施例并不以此作为限制。并且其中，预先配置的时隙集合可以是预先设定的HELLO包间隔中指定帧的数据部分；也可以是预先设定的HELLO包间隔中所有帧的数据部分。

在步骤902中，可以先根据本地请求表的信息，确定从起始时隙开始到经过所述所需的时隙长度的结束时隙为止的范围内的所有时隙是否空闲，如果所述范围内的所有时隙空闲，则确定包含所述起始时隙在内的连续M个时隙为所述空闲时隙，在这种情况下，M即为所述所需的时隙长度。另外，如果在该范围内有至少一个时隙被占用，也就是说以步骤901选择出的起始时隙为起点无法找出满足所需的时隙长度的多个连续的空闲时隙，则将该范围内最后一个被占用的时隙之后的第一个空闲时隙作为所述起始时隙，回到步骤902继续类似的处理。

在步骤902中，有一种情况是，根据本地请求表的信息，没有所需的时隙长度的个数的连续的未被占用的空闲时隙，此时，可以减小所需的时隙长度的数量，并回到步骤901继续类似的处理。

通过图9的方法可以选择出空闲时隙，从而确定该空闲时隙的起始时隙和时隙长度，由此可以构建HELLO包的REQ部分。

步骤804：如果所需的时隙长度没有发生变化，并且根据所述预约历史信息确定之前选择的时隙是有效的，则根据所述预约历史信息确定请求预约的多个时隙的起始时隙和时隙长度；

其中，根据步骤802的判断，如果时隙长度没有发生变化，并且之前选择的时隙是有效的，则可以直接将之前预约的时隙作为本次请求预约的空闲时隙，由此可以确定其起始时隙及其时隙长度。

步骤805：如果所需的时隙长度没有发生变化，但根据所述预约历史信息确定之前选择的时隙是无效的，则根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙的起始时隙和时隙长度。

其中，根据步骤802的判断，如果时隙长度没有发生变化，但是之前选择的时隙是无效的，则需要重新选择空闲时隙，选择的方法与步骤803中选择空闲时隙的方法相同，也可以通过图9的方法来实现，在此不再赘述。

为了使本实施例的方法更加清楚易懂，以下结合HELLO包的发送流程对本实施例的方法进行说明。

图11为根据本发明实施例的方法的HELLO包的发送流程图，请参照图11，该流程包括：

步骤1101：HELLO包的定时器启动；

步骤1102：从本地路由表获取本地目标节点地址；

如前所述，可以选择路由花费最小的路径的接收节点作为本地目标节点，从而得到本地目标地址。

步骤1103：更新长度需求；

如前所述，通过前述方法计算所需的时隙长度。

步骤1104：长度需求是否发生变化，如果没有发生变化，则执行步骤1105，如果发生了变化，则执行步骤1106；

如前所述，与本地保存的预约历史信息相比，判断所需的时隙长度是否发生变化。

步骤1105：之前选择的时隙是否有效，如果无效，则执行步骤1106，如果有效，则执行步骤1107：

步骤1106：选择新的空闲时隙；

如前所述，可以通过图9的方法选择新的空闲时隙。

步骤1107：构建HELLO包的REQ部分；

步骤1108：从本地请求表中选择条目；

如前所述，可以选择n跳冲突域内的1,2,…,（n-1）跳的邻居的条目，或者选择n跳冲突域内的所有一跳邻居的条目和2～（n-1）跳的邻居中确认信息为同意的条目。

步骤1109：构建HELLO包的RES部分；

步骤1110：发送HELLO包。

通过本实施例的方法构建HELLO包并发送，可以有效的进行时隙预约，提高了时隙利用率。

在本发明实施例中，如果接收到HELLO包，即可根据接收到的HELLO包对HELLO包的发送节点请求预约的多个时隙进行认证，例如同意或反对该HELLO包的发送方请求预约的多个时隙。另外，还可以根据接收到的HELLO包确定本地请求预约的多个时隙是否有效，另外，还可以根据接收到的HELLO包更新本地请求表或者本地预约历史信息。

其中，该接收到的HELLO包所包含的内容与前述构建出的HELLO包相同，也即可能仅包括REQ部分，也即HELLO的发送方请求预约的多个时隙的相关信息，也可能既包括REQ部分也包括RES部分，也即，既包括HELLO包的发送方请求预约的多个时隙的相关信息，也包括该HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息。

在本实施例中，根据接收到的HELLO包的REQ部分对HELLO包的发送方所请求预约的多个时隙进行认证（给出本地的是否同意的意见），可以通过将该REQ部分所请求预约的多个时隙与本地请求表中的部分条目进行比较的方式来实现。

在一个实施方式中，将接收到的HELLO包的REQ部分与本地请求表中确认信息为同意的n跳冲突域内的1,2,…,（n-1）跳的邻居节点的条目进行比较，以确定该HELLO包的发送方所请求预约的多个时隙是否已被占用，如果已被占用，则认为存在冲突，此时本地节点对该HELLO包的发送方所请求预约的多个时隙给出的意见是反对；相反，如果未被占用，则认为不存在冲突，此时本地节点对该HELLO包的发送方所请求预约的多个时隙给出的意见是同意。

其中，当本地节点对该HELLO包的发送方所请求预约的多个时隙给出本地的意见之后，可以据此更新本地请求表，例如，在反对的情况下，将确认信息置为反对（confirmation=0），并将该条目填入本地请求表；在同意的情况下，将确认信息置为同意（confirmation=1），并将该条目填入本地请求表。另一方面，在同意的情况下，本地节点还可以确认一下该HELLO包的发送方所请求预约的多个时隙是否与本地请求预约的多个时隙冲突，如果不冲突，则认为本地请求预约的多个时隙是有效的，此时以保持本地预约历史信息不变，如果冲突，则认为本地请求预约的多个时隙是无效的，此时需要修改本地预约历史信息，例如将本地预约历史信息所指示的状态修改为无效，或者将本地预约历史信息所指示的本地请求预约的多个时隙的索引修改为特定值，等等。

在本实施例中，可选的，在对所述本地节点请求预约的多个时隙进行认证之前，可以先确认是否接收过该REQ部分，如果是，则说明已经对其做过处理，该REQ部分是旧的，此时，直接结束；如果不是，则说明未对其做过处理，该REQ部分是新的，此时，对所述本地节点请求预约的多个时隙进行认证。其中，确认是否接收过该REQ部分，可以通过将其与本地请求表进行比较来实现，如果该REQ部分存在于本地请求表中（本地请求表中包含与接收到的REQ部分的Local Source ID、LocalDestination ID、Start index以及Length相同的信息条目），则认为接收过该REQ部分，否则认为没有接收过该REQ部分。

在本实施例中，可选的，在对所述本地节点请求预约的多个时隙进行认证之前，还可以先确认该REQ部分是否有效，例如，通过判断该REQ部分所指示的请求预约的时隙的索引是否大于等于0来确认该REQ部分是否有效，如果大于等于0，则说明该HELLO包的发送方请求预约了一个有效的时隙，则对所述本地节点请求预约的多个时隙进行认证；如果小于0，则说明该HELLO包的发送方请求预约了一个无效的时隙，或者说，该HELLO包的发送方不想预约时隙，此时可以直接在本地请求表中添加对应该REQ部分的信息条目即可，其中，该新增条目对应的确认信息可以是特定值。

以上实施方式只是举例说明，在本实施例的其他实施方式中，也可以不是与n跳冲突域内的第1,2,…,（n-1）跳的邻居节点的条目进行比较，而是根据预定策略与其他邻居的条目进行比较，从而确定所占用的时隙是否冲突。比较的方式类似，在此不再赘述。

通过以上处理，既完成了对接收到的HELLO包的发送方所请求预约的多个时隙的认证，又完成了基于接收到的HELLO包的REQ部分的本地请求表或本地预约历史信息的更新。

在本实施例中，根据该HELLO包中的RES部分的信息确认本地请求预约的多个时隙是否有效，并据此更新本地请求表或者本地预约历史信息，可以通过遍历该RES部分的每一个RES条目的方式来实现。

其中，本地源节点地址是本地节点的地址的RES条目即为本地节点请求预约的多个时隙的相关信息，并且，该RES条目所对应的确认信息即为其他节点对本地节点请求预约的多个时隙给出的认证结果。如果该认证结果为同意，则确认本地请求预约的多个时隙有效，此时，不需要修改本地预约历史信息；反之，如果该认证结果为反对，则确认本地请求预约的多个时隙无效，此时，需要修改本地保存的预约历史信息，例如将本地保存的预约历史信息中请求预约的多个时隙的标志位（flag）修改为无效，或者，直接将本地保持的预约历史信息中请求预约的多个时隙的起始时隙和时隙长度置为小于0的数，等等。

其中，对于本地源节点地址不是本地节点的地址的RES条目，要根据这些RES条目更新本地请求表。例如，对于某一个RES条目，通过将该RES条目与本地请求表中的各条目进行比较，在该RES条目的本地源节点地址是新的时，也即本地请求表中没有存储过该条目，则在本地请求表中添加这样一个条目，并将其距离加1；在该RES条目的本地源节点地址是旧的时，也即本地请求表中存储过该条目，将该RES条目的距离与本地请求表中所对应的条目的距离进行比较，如果该RES条目的距离大于或等于本地请求表中所对应的条目的距离，则对该RES条目的处理结束，可以获取下一个RES条目；如果该RES条目的距离小于本地请求表中所对应的条目的距离，则检查该RES条目所对应的确认信息，如果确认信息为反对（confirmation=0），则说明该RES条目不会对本地请求表中各条目所对应的请求预约的时隙造成影响，则直接将该RES条目的距离加1作为本地请求表中对应的条目的距离；如果确认信息为同意（confirmation=1），则需要据此更新本地请求表中所有一跳邻居节点的确认信息，例如，如果本地请求表中一跳邻居节点所对应的条目中请求预约的时隙与该RES条目所对应的请求预约的多个时隙冲突，则将该一跳邻居节点所对应的条目的确认信息修改为反对，否则将一跳邻居节点所对应的确认信息修改为同意，然后将该RES条目的距离加1作为本地请求表中对应的条目的距离。

其中，在针对每个RES条目做处理时，也要首先确定该RES条目是否有效，同样的，可以通过与本地请求表相比来确定，如果之前没有接收过这样一个条目，则认为该RES条目是新的，从而确定该RES条目有效，否则认为该RES条目是旧的，从而确定该RES条目无效。

图12为根据本发明实施例的方法的HELLO包的接收流程图。请参照图12，该流程包括：

步骤1201：开始接收；

步骤1202：是否得到了下一个RES条目，如果是，则执行步骤1203，否则执行步骤1214；

其中，如果得到了下一个RES条目，则继续对下一个RES条目进行处理，如果没有得到下一个RES条目，则说明所有的RES条目已经处理完毕，此时转到步骤1214处理REQ部分。

步骤1203：检查该RES条目是新的还是旧的，如果是新的，则执行步骤1204，否则回到步骤1202，继续获取下一个RES条目；

其中，确定该RES条目是新的还是旧的，可以通过与本地请求表中的各条目进行比较来确定，如果存储过该RES条目，且该RES条目所指示的信息没有发生变化，就说明该RES条目是旧的，否则说明该RES条目是新的。

步骤1204：判断该RES条目的本地源ID是否是本地的ID，如果是，则执行步骤1205，否则执行步骤1208；

其中，如果该RES条目的本地源ID是本地的ID，则说明该RES条目是对应本地请求预约的多个时隙的相关信息。并且，该RES条目包含了对本地请求预约的多个时隙的确认信息。

步骤1205：判断该RES条目的确认信息是否是同意，如果是反对，则执行步骤1206，如果是同意，则执行步骤1207；

步骤1206：确定本地请求预约的多个时隙无效，回到步骤1213；

其中，由于该RES条目是对应本地请求预约的多个时隙的相关信息，而本地请求预约的多个时隙的相关信息不在请求表中，而只在本地保存的预约历史信息中。因此回到步骤1213后不对本地请求表做任何处理，而是更新本地保存的预约历史信息，例如，如果本地保存的预约历史信息中标志位（flag）为有效，则将其改为无效，然后或同时回到步骤1202获取下一个RES条目。

步骤1207：确定本地请求预约的多个时隙有效，回到步骤1213；

其中，与步骤1206类似，回到步骤1213后不对本地请求表做任何处理，而是更新本地保存的预约历史信息，例如，如果本地保存的预约历史信息中标志位为无效，则将其改为有效，然后或同时回到步骤1202获取下一个RES条目。

步骤1208：判断该RES条目的本地源ID是否是新的，如果是，则执行步骤1212，否则执行步骤1209；

步骤1209：判断该RES条目的距离是否小于本地请求表中对应的条目的距离，如果是，则执行步骤1210，否则回到步骤1202；

步骤1210：判断该RES条目的确认信息是否是同意，如果是，则执行步骤1211，否则执行步骤1212；

步骤1211：更新本地请求表中所有一跳邻居的确认信息；

如前所述，将该RES条目与本地请求表中所有一跳邻居对应的条目进行比较，如果该RES条目所指示的请求预约的时隙与本地请求表的一跳邻居中，确认信息为同意的一跳邻居对应的条目所指示的请求预约的时隙冲突，则将该一跳邻居的确认信息修改为反对。

步骤1212：将对应该RES条目的本地请求表中的条目的距离设为该RES条目所指示的距离加1，回到步骤1213；

步骤1213：更新本地请求表或更新本地预约历史信息；

如前所述，由于该RES条目所指示的信息不同，则更新本地请求表或更新本地预约历史信息的方式也不相同。

步骤1214：得到REQ部分；

步骤1215：检测该REQ部分的条目是新的还是旧的，如果是旧的，则结束处理，如果是新的，则执行步骤1216；

其中，如果本地请求表中存储过该条目，并且该条目的指示的信息与REQ的各个信息相同，则说明该条目是旧的，否则说明该条目是新的。

步骤1216：判断该条目的起始时隙是否大于等于0，如果是，则执行步骤1217，否则执行步骤1222；

其中，如果该条目的起始时隙小于0，则说明该HELLO包的发送方并没有请求一个有效的时隙，此时，直接更新本地请求表，例如，将该条目添加入本地请求表中即可。

步骤1217：判断该条目是否与本地请求表中1,2,…,（n-1）跳的邻居冲突，如果是，则执行步骤1218，否则执行步骤1219；

步骤1218：将该条目的确认信息设为反对，然后执行步骤1222更新本地请求表；

其中，因为发生了冲突，则该HELLO包的发送方不能使用其请求预约的时隙，因此对其请求预约的多个时隙给予反对的意见，并将其添加入本地请求表中。

步骤1219：将该条目的确认信息设为同意，然后执行步骤1220；

其中，因为没有发生冲突，则该HELLO包的发送方可以使用其请求预约的时隙，因此对其请求预约的多个时隙给予同意的意见。

步骤1220：判断该条目是否与本地REQ部分冲突，如果是则执行步骤1221，否则执行步骤1222；

步骤1221：确定本地的REQ部分为无效，执行步骤1222更新本地请求表；

其中，尽管该条目与本地请求表中的条目不冲突，但与本地的REQ部分冲突，则此时认为本地不能使用请求预约的时隙，将本地保存的预约历史信息中所请求预约的多个时隙的标志位修改为无效。另外，还需要将确认信息设置为有效的该条目添加入本地请求表中。

步骤1222：更新本地请求表或本地预约历史信息。

如前所述，基于不同的处理过程，更新本地请求表。

在图12的说明中，是以接收到的HELLO包包括REQ部分和RES部分为例，但本实施例并不以此作为限制。如前所述，在一个实施方式中，例如初次构建HELLO包的过程中，由于没有存储本地请求表，该构建的HELLO包只包括REQ部分，此时接收到这样的HELLO包的节点，只需要对该HELLO包的发送方所请求预约的多个时隙进行认证（给出同意或反对的意见），并依此更新本地请求表或本地预约历史信息即可，也即只需要执行步骤1214-1222的处理，在此不再说明。

通过本实施例的方法对接收到的HELLO进行相应处理，可以更为有效的预约时隙并构建HELLO包，提高了时隙利用率。

在本发明实施例中，当成功预约了多个时隙，获得了预约的多个时隙的时隙集合之后，还可以利用一些交织方法，将该时隙集合中的多个时隙映射到物理时隙上，以便在交织后的时隙上传输数据。如此进一步提高了时隙的分配效率。

其中，为了指示各节点的交织周期，HELLO包中要增加一个交织周期的字段，如图3B所示，其中，该交织周期指示了是否采用时隙交织，例如，如果周期为0，则不使用时隙交织，如果周期不为0，则采用时隙交织，并且其中，该数量等于交织的周期。

其中，交织后的时隙和交织前的时隙是一一对应的。可以通过Slot_interleaving[i]指示Slot[i]交织后的时隙。

其中，周期代表了交织的写入周期，S_total代表了在一个分配周期内可用时隙的数量。

图13给出了周期为3时一个交织分配的示例，如图13所述，经过本发明实施例的方法进行时隙分配，得到的结果是时隙1、2、3，而经过交织分配后，结果改为时隙1、3、6。

图13的交织方法只是举例说明，本发明实施例并不以此作为限制，现有技术中其他交织方法同样适用。

通过本实施例的时隙分配方法，可以提高时隙的利用率。

在本发明实施例中，当网络中的所有节点都预约完时隙后，每个节点的本地请求表不再变化。这时，每个节点可以利用相同的规则扩展所预约的时隙，由此，可进一步提高数据的发送效率。

图14为向左扩展的一个实施例，如图14所示，节点根据本地表，占用自己所预约时隙左边的空闲时隙，再通过hello包广播。其中，如果左边没有空闲时隙，则不扩展占用。

其中，向左扩展只是举例说明，本发明实施例并不以此作为限制，也可以依据其他规则进行扩展，例如向右扩展等。

本发明实施例还提供了一种节点，如下面的实施例2所述，由于该节点解决问题的原理与实施例1的方法类似，因此，其具体的实施可以参照实施例1的方法的实施，内容相同之处，不再重复说明。

实施例2

本发明实施例提供了一种多跳网络中的节点。图15是该节点的组成示意图，请参照图15，该节点包括：

构建单元151，其用于构建HELLO包，所述HELLO包包含所述节点请求预约的多个时隙的相关信息（REQ部分）或者包含所述节点请求预约的多个时隙的相关信息（REQ部分）和所述节点的至少一个邻居节点请求预约的多个时隙的相关信息（RES部分）；

发送单元152，其发送构建单元构建的所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO所包含的信息对所述节点请求预约的多个时隙进行认证。

其中，所述节点请求预约的多个时隙的相关信息包括：所述节点的地址、所述节点要发送的数据包的接收节点地址、所述节点请求预约多个时隙的起始时隙索引和时隙长度；所述节点的至少一个邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点的距离、以及邻居节点请求预约的多个时隙的确认信息。

在一个实施例中，所述本地节点请求预约的多个时隙的相关信息还可以包括：本地节点的交织周期；相应的，所述邻居节点请求预约的多个时隙的相关信息还可以包括：邻居节点的交织周期。

在一个实施例中，所述构建单元151包括：

第一取得模块1511，其从路由表中选择本地节点要发送的数据包的接收节点，得到所述本地节点要发送的数据包的接收节点地址；

第二取得模块1512，其根据本地预约历史信息和/或本地保存的本地请求表，确定请求预约的多个时隙，由此得到请求预约的多个时隙的起始时隙索引和时隙长度；

构建模块1513，其根据本地节点要发送的数据包的接收节点地址、请求预约的多个时隙的起始时隙索引和时隙长度以及本地节点的地址，得到所述本地节点请求预约的多个时隙的相关信息（REQ部分）。

其中，所述构建单元151还包括：

第三取得模块1514，其根据预定策略，从本地请求表中选择至少一个邻居节点的信息条目作为所述节点的至少一个邻居节点请求预约的多个时隙的相关信息（RES部分）。

在本实施例中，第二取得模块1512包括：计算模块15121，确定模块15122，第一选择模块15123，第二选择模块15124，以及第三选择模块15125。其中：

计算模块15121计算所需的时隙长度。该计算模块15121可以根据本地节点的所有子节点预约的时隙的长度之和计算所需的时隙长度，也可以根据本地节点的冲突域内的邻居节点的业务量计算所需的时隙长度。如前所述，在此不再赘述。

确定模块15122根据本地保存的预约历史信息确定所需的时隙长度是否发生变化。

第一选择模块15123在所需的时隙长度发生变化时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙。

第二选择模块15124在所需的时隙长度没有发生变化，并且根据所述预约历史信息确定之前请求预约的多个时隙有效时，根据所述预约历史信息确定请求预约的多个时隙。

第三选择模块15125在所需的时隙长度没有发生变化，但根据所述预约历史信息确定之前请求预约的多个时隙无效时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙。

其中，第一选择模块15123和第三选择模块15125在选择空闲时隙时，可以先确定起始时隙，并以所述起始时隙为起点，根据本地请求表的信息，选择连续M个未被占用的时隙作为所述空闲时隙，其中，M小于等于计算出的所需的时隙长度。

其中，确定起始时隙时，可以从预先配置的时隙集合中随机选择未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择第一个未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择具有最大未被使用的时隙间隔内中间位置的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择时隙索引为本地节点的地址的函数的时隙作为所述起始时隙；或者，根据本地节点的跳数，从该跳数对应的时隙集合中选择未被使用的时隙作为所述起始时隙。这里的预先配置的时隙集合可以是预先设定的HELLO包间隔中指定帧的数据部分，也可以是预先设定的HELLO包间隔中所有帧的数据部分。

其中，选择连续M个未被占用的时隙时，可以根据本地请求表的信息，确定从所述起始时隙开始到经过所述所需的时隙长度的结束时隙为止的范围内的所有时隙是否空闲，在所述范围内的所有时隙空闲时，确定包含所述起始时隙在内的连续M个时隙为所述空闲时隙，其中，M为所述所需的时隙长度。其中，在所述范围内有至少一个时隙被占用时，将所述范围内最后一个被占用的时隙之后的第一个空闲时隙作为所述起始时隙，重新选择空闲时隙。其中，在根据本地请求表的信息，确定没有M个连续的未被占用的空闲时隙时，减小M的数量，以减小后的M的数量作为所需的时隙长度重新选择空闲时隙。

其中，该第二取得模块1512的上述组成只是举例说明，在本地没有保存预约历史信息的实施例中，只需要根据本地请求表选择空闲时隙即可，而在本地没有保存本地请求表（本地请求表为空）的实施例中，可以随机选择或根据预定策略选择空闲时隙。

在本实施例中，第三取得模块1514可以从本地请求表中选择本地节点的n跳冲突域内的1～（n-1）跳邻居节点的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息；或者，可以从本地请求表中选择本地节点的n跳冲突域内的所有一跳邻居节点的条目以及2～（n-1）跳邻居节点的条目中确认信息为同意的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

在本实施例中，该节点还可以包括：处理单元153，以根据接收到的HELLO包对HELLO包的发送方请求预约的时隙进行认证，和/或确定本地请求预约的多个时隙是否有效，和/或更新本地请求表或本地预约历史信息。

其中，接收到的HELLO包仅包括该HELLO的发送节点请求预约的多个时隙的相关信息，或者，接收到的HELLO包包括该HELLO的发送节点请求预约的多个时隙的相关信息以及该HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息。

其中，该处理单元153可以包括：

第一遍历模块1531，其遍历所述HELLO包中所述HELLO包的发送节点请求预约的多个时隙的相关信息（HELLO包的REQ部分）；

第一处理模块1532，其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙冲突时，对所述HELLO包的发送节点请求预约的时隙赋予反对，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，对所述HELLO包的发送节点请求预约的时隙赋予同意，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目。

其中，所述第一处理模块1532在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，判断所述HELLO包的发送节点请求预约的多个时隙与本地请求预约的多个时隙是否冲突，如果冲突，则确认本地请求预约的多个时隙为无效，并修改本地预约历史信息；如果不冲突，则确认本地请求预约的多个时隙为有效，并保持本地预约历史信息不变。

其中，该处理单元153还可以包括：

第二遍历模块1533，其遍历接收到的HELLO包中所述HELLO包的发送节点的每一个邻居节点请求预约的多个时隙的相关信息（HELLO包的RES部分，包括至少一个RES条目）；

第二处理模块1534，其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID为本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效，并据此更新本地预约历史信息；其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID不是本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表。

其中，所述第二处理模块1534根据本地请求表中的各信息条目确认是否保存过所述邻居节点请求预约的多个时隙的相关信息，如果没有保存过，则将该邻居节点请求预约的多个时隙的相关信息添加入本地请求表，并将其对应的距离加1；如果保存过，则当该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，更新本地请求表中的该邻居节点的该相关信息，并将其对应的距离加1；在该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，判断该HELLO包中该邻居节点请求预约的多个时隙的确认信息是否是同意，如果是同意，则更新本地请求表中所有一跳邻居节点的确认信息。

通过本实施例的节点进行时隙预约，可以提高时隙分配的利用率。

以上参照附图描述了本发明的优选实施方式。这些实施方式的许多特征和优点根据该详细的说明书是清楚的，因此所附权利要求旨在覆盖这些实施方式的落入其真实精神和范围内的所有这些特征和优点。此外，由于本领域的技术人员容易想到很多修改和改变，因此不是要将本发明的实施方式限于所例示和描述的精确结构和操作，而是可以涵盖落入其范围内的所有合适修改和等同物。

流程图中或在此以其它方式描述的任何过程或方法描述或框可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程中的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中，可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或者按相反的顺序，来执行功能，这应被本发明所述技术领域的技术人员所理解。

关于包括以上多个实施例的实施方式，还公开下述的附记。

附记1.一种时隙分配方法，其中，所述方法包括：

构建HELLO包，所述HELLO包包含本地节点请求预约的多个时隙的相关信息或者包含本地节点请求预约的多个时隙的相关信息和本地节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO包中所包含的信息对所述本地节点请求预约的多个时隙进行认证。

附记2.根据附记1所述的方法，其中，

所述本地节点请求预约的多个时隙的相关信息包括：本地节点的地址、本地节点要发送的数据包的接收节点地址、本地节点请求预约多个时隙的起始时隙索引和时隙长度；

所述邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点的距离、以及邻居节点请求预约的多个时隙的确认信息。

附记3.根据附记2所述的方法，其中，

所述本地节点请求预约的多个时隙的相关信息还包括：本地节点的交织周期；

所述邻居节点请求预约的多个时隙的相关信息还包括：邻居节点的交织周期。

附记4.根据附记1所述的方法，其中，构建HELLO包的步骤包括：

从路由表中选择本地节点要发送的数据包的接收节点，得到所述本地节点要发送的数据包的接收节点地址；

根据本地预约历史信息和/或本地请求表确定请求预约的多个时隙，得到请求预约的多个时隙的起始时隙索引和时隙长度；

根据本地节点要发送的数据包的接收节点地址、请求预约的多个时隙的起始时隙索引和时隙长度以及本地节点的地址，得到所述本地节点请求预约的多个时隙的相关信息。

附记5.根据附记4所述的方法，其中，构建HELLO包的步骤还包括：

根据预定策略，从本地请求表中选择至少一个邻居节点的信息条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

附记6.根据附记4所述的方法，其中，确定请求预约的多个时隙的步骤包括：

计算所需的时隙长度；

根据本地预约历史信息确定所需的时隙长度是否发生变化；

如果所需的时隙长度发生变化，则根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙；

如果所需的时隙长度没有发生变化，并且根据所述预约历史信息确定之前请求预约的多个时隙有效，则根据所述预约历史信息确定请求预约的多个时隙；

如果所需的时隙长度没有发生变化，但根据所述预约历史信息确定之前请求预约的多个时隙无效，则根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙。

附记7.根据附记6所述的方法，其中，计算所需的时隙长度的步骤包括：

根据本地节点的所有子节点预约的时隙的长度之和计算所需的时隙长度；或者

根据本地节点的冲突域内的邻居节点的业务量计算所需的时隙长度。

附记8.根据附记6所述的方法，其中，根据计算出的所需的时隙长度选择空闲时隙的步骤包括：

S1：确定起始时隙；

S2：以所述起始时隙为起点，根据本地请求表的信息，选择连续M个未被占用的时隙作为所述空闲时隙，其中，M小于等于计算出的所需的时隙长度。

附记9.根据附记8所述的方法，其中，步骤S1包括：

从预先配置的时隙集合中随机选择未被使用的时隙作为所述起始时隙；或者

从预先配置的时隙集合中选择第一个未被使用的时隙作为所述起始时隙；或者

从预先配置的时隙集合中选择具有最大未被使用的时隙间隔内中间位置的时隙作为所述起始时隙；或者

从预先配置的时隙集合中选择时隙索引为本地节点的地址的函数的时隙作为所述起始时隙；或者

根据本地节点的跳数，从该跳数对应的时隙集合中选择未被使用的时隙作为所述起始时隙。

附记10.根据附记9所述的方法，其中，

所述预先配置的时隙集合为预先设定的HELLO包间隔中指定帧的数据部分；或者

所述预先设置的时隙集合为预先设定的HELLO包间隔中所有帧的数据部分。

附记11.根据附记8所述的方法，其中，步骤S2包括：

根据本地请求表的信息，确定从所述起始时隙开始到经过所述所需的时隙长度的结束时隙为止的范围内的所有时隙是否空闲；

如果所述范围内的所有时隙空闲，则确定包含所述起始时隙在内的连续M个时隙为所述空闲时隙，其中，M为所述所需的时隙长度。

附记12.根据附记11所述的方法，其中，

如果所述范围内有至少一个时隙被占用，则将所述范围内最后一个被占用的时隙之后的第一个空闲时隙作为所述起始时隙，回到步骤S2。

附记13.根据附记12所述的方法，其中，

如果根据本地请求表的信息，确定没有M个连续的未被占用的空闲时隙，则减小M的数量，回到步骤S1。

附记14.根据附记5所述的方法，其中，从本地请求表中选择至少一个邻居节点的信息条目的步骤包括：

从本地请求表中选择本地节点的n跳冲突域内的1～（n-1）跳邻居节点的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息；或者

从本地请求表中选择本地节点的n跳冲突域内的所有一跳邻居节点的条目以及2～（n-1）跳邻居节点的条目中确认信息为同意的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

附记15.根据附记1所述的方法，其中，所述方法还包括：

根据接收到的HELLO包对HELLO包的发送节点请求预约的多个时隙进行认证，和/或确定本地请求预约的多个时隙是否有效，和/或更新本地请求表或本地预约历史信息；

其中，接收到的HELLO包仅包括该HELLO的发送节点请求预约的多个时隙的相关信息，或者，接收到的HELLO包包括该HELLO的发送节点请求预约的多个时隙的相关信息以及该HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息。

附记16.根据附记15所述的方法，其中，如果接收到的HELLO包仅包括该HELLO的发送节点请求预约的多个时隙的相关信息，则在接收到HELLO包后，所述方法还包括：

遍历接收到的HELLO包中所述HELLO包的发送节点请求预约的多个时隙的相关信息；

在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙冲突时，对所述HELLO包的发送节点请求预约的时隙赋予反对，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；

在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，对所述HELLO包的发送节点请求预约的时隙赋予同意，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；

在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，判断所述HELLO包的发送节点请求预约的多个时隙与本地请求预约的多个时隙是否冲突，如果冲突，则确认本地请求预约的多个时隙为无效，并修改本地预约历史信息；如果不冲突，则确认本地请求预约的多个时隙为有效，并保持本地预约历史信息不变。

附记17.根据附记16所述的方法，其中，如果接收到的HELLO包还包括HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息，则在遍历HELLO包的发送节点请求预约的多个时隙的相关信息之前，所述方法还包括：

遍历接收到的HELLO包中所述HELLO包的发送节点的每一个邻居节点请求预约的多个时隙的相关信息；

在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID为本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效，并据此更新本地预约历史信息；

在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID不是本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表。

附记18，根据附记17所述的方法，其中，根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效的步骤包括：

如果该邻居节点请求预约的多个时隙的相关信息所指示的确认信息为同意，则确认本地请求预约的时隙有效，如果该邻居节点请求预约的多个时隙的相关信息所指示的确认信息为反对，则确认本地请求预约的时隙无效。

附记19，根据附记17所述的方法，其中，根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表的步骤包括：

根据本地请求表中的各信息条目确认是否保存过所述邻居节点请求预约的多个时隙的相关信息，如果没有保存过，则将该邻居节点请求预约的多个时隙的相关信息添加入本地请求表，并将其对应的距离加1；如果保存过，则当该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，更新本地请求表中的该邻居节点的该相关信息，并将其对应的距离加1。

附记20，根据附记19所述的方法，其中，在该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，所述方法还包括：

判断该HELLO包中该邻居节点请求预约的多个时隙的确认信息是否是同意，如果是同意，则更新本地请求表中所有一跳邻居节点的确认信息。

附记21.一种节点，其中，所述节点包括：

构建单元，其用于构建HELLO包，所述HELLO包包含所述节点请求预约的多个时隙的相关信息或者包含所述节点请求预约的多个时隙的相关信息和所述节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送单元，其发送构建单元构建的所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO所包含的信息对所述节点请求预约的时隙进行认证。

附记22.根据附记21所述的节点，其中，

所述节点请求预约的多个时隙的相关信息包括：所述节点的地址、所述节点要发送的数据包的接收节点地址、所述节点请求预约多个时隙的起始时隙索引和时隙长度；

所述邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点的距离、以及邻居节点请求预约的多个时隙的确认信息。

附记23.根据附记22所述的节点，其中，

所述本地节点请求预约的多个时隙的相关信息还包括：本地节点的交织周期；

所述邻居节点请求预约的多个时隙的相关信息还包括：邻居节点的交织周期。

附记24.根据附记21所述的节点，其中，所述构建单元包括：

第一取得模块，其从路由表中选择本地节点要发送的数据包的接收节点，得到所述本地节点要发送的数据包的接收节点地址；

第二取得模块，其根据本地预约历史信息和/或本地请求表确定请求预约的多个时隙，得到请求预约的多个时隙的起始时隙索引和时隙长度；

构建模块，其根据本地节点要发送的数据包的接收节点地址、请求预约的多个时隙的起始时隙索引和时隙长度以及本地节点的地址，得到所述本地节点请求预约的多个时隙的相关信息。

附记25.根据附记24所述的节点，其中，所述构建单元还包括：

第三取得模块，其根据预定策略，从本地请求表中选择至少一个邻居节点的信息条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

附记25.根据附记23所述的节点，其中，第二取得模块包括：

计算模块，其计算所需的时隙长度；

确定模块，根据所述预约历史信息确定所需的时隙长度是否发生变化；

第一选择模块，其在所需的时隙长度发生变化时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙；

第二选择模块，其在所需的时隙长度没有发生变化，并且根据所述预约历史信息确定之前请求预约的多个时隙有效时，根据所述预约历史信息确定请求预约的多个时隙；

第三选择模块，其在所需的时隙长度没有发生变化，但根据所述预约历史信息确定之前请求预约的多个时隙无效时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙。

附记27.根据附记26所述的节点，其中，所述计算模块根据本地节点的所有子节点预约的时隙的长度之和计算所需的时隙长度；或者，所述计算模块根据本地节点的冲突域内的邻居节点的业务量计算所需的时隙长度。

附记28.根据附记26所述的节点，其中，所述第一选择模块或所述第三选择模块在选择空闲时隙时，先确定起始时隙，并以所述起始时隙为起点，根据本地请求表的信息，选择连续M个未被占用的时隙作为所述空闲时隙，其中，M小于等于计算出的所需的时隙长度。

附记29.根据附记28所述的节点，其中，所述第一选择模块或所述第三选择模块从预先配置的时隙集合中随机选择未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择第一个未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择具有最大未被使用的时隙间隔内中间位置的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择时隙索引为本地节点的地址的函数的时隙作为所述起始时隙；或者，根据本地节点的跳数，从该跳数对应的时隙集合中选择未被使用的时隙作为所述起始时隙。

附记30.根据附记29所述的节点，其中，所述预先配置的时隙集合为预先设定的HELLO包间隔中指定帧的数据部分；或者，所述预先设置的时隙集合为预先设定的HELLO包间隔中所有帧的数据部分。

附记31.根据附记28所述的节点，其中，所述第一选择模块或所述第三选择模块根据本地请求表的信息，确定从所述起始时隙开始到经过所述所需的时隙长度的结束时隙为止的范围内的所有时隙是否空闲，在所述范围内的所有时隙空闲时，确定包含所述起始时隙在内的连续M个时隙为所述空闲时隙，其中，M为所述所需的时隙长度。

附记32.根据附记31所述的节点，其中，所述第一选择模块或所述第三选择模块在所述范围内有至少一个时隙被占用时，将所述范围内最后一个被占用的时隙之后的第一个空闲时隙作为所述起始时隙，重新选择空闲时隙。

附记33.根据附记32所述的节点，其中，所述第一选择模块或所述第三选择模块在根据本地请求表的信息，确定没有M个连续的未被占用的空闲时隙时，减小M的数量，以减小后的M的数量作为所需的时隙长度重新选择空闲时隙。

附记34.根据附记25所述的节点，其中，所述第三取得模块具体用于：从本地请求表中选择本地节点的n跳冲突域内的1～（n-1）跳邻居节点的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息；或者，从本地请求表中选择本地节点的n跳冲突域内的所有一跳邻居节点的条目以及2～（n-1）跳邻居节点的条目中确认信息为同意的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

附记35.根据附记21所述的节点，其中，所述节点还包括：

处理单元，其根据接收到的HELLO包对HELLO包的发送节点请求预约的时隙给予认证，和/或确定本地请求预约的时隙是否有效，和/或更新本地请求表或本地预约历史信息；

其中，接收到的HELLO包仅包括该HELLO的发送节点请求预约的多个时隙的相关信息，或者，接收到的HELLO包包括该HELLO的发送节点请求预约的多个时隙的相关信息以及该HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息。

附记36.根据附记35所述的节点，其中，所述处理单元包括：

第一遍历模块，其遍历接收到的HELLO包中所述HELLO包的发送节点请求预约的多个时隙的相关信息；

第一处理模块，其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙冲突时，对所述HELLO包的发送节点请求预约的时隙赋予反对，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，对所述HELLO包的发送节点请求预约的时隙赋予同意，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目。

附记37，根据附记36所述的节点，其中，所述第一处理模块在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，判断所述HELLO包的发送节点请求预约的多个时隙与本地请求预约的多个时隙是否冲突，如果冲突，则确认本地请求预约的多个时隙为无效，并修改本地预约历史信息；如果不冲突，则确认本地请求预约的多个时隙为有效，并保持本地预约历史信息不变。

附记38.根据附记36或37所述的节点，其中，所述处理单元还包括：

第二遍历模块，其遍历接收到的HELLO包中所述HELLO包的发送节点的每一个邻居节点请求预约的多个时隙的相关信息；

第二处理模块，其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID为本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效，并据此更新本地预约历史信息；其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID不是本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表。

附记39.根据附记38所述的节点，其中，所述第二处理模块根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效时，如果该邻居节点请求预约的多个时隙的相关信息所指示的确认信息为同意，则确认本地请求预约的时隙有效，如果该邻居节点请求预约的多个时隙的相关信息所指示的确认信息为反对，则确认本地请求预约的时隙无效。

附记40.根据附记38所述的节点，其中，所述第二处理模块在根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表时，根据本地请求表中的各信息条目确认是否保存过所述邻居节点请求预约的多个时隙的相关信息，如果没有保存过，则将该邻居节点请求预约的多个时隙的相关信息添加入本地请求表，并将其对应的距离加1；如果保存过，则当该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，更新本地请求表中的该邻居节点的该相关信息，并将其对应的距离加1；在该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，判断该HELLO包中该邻居节点请求预约的多个时隙的确认信息是否是同意，如果是同意，则更新本地请求表中所有一跳邻居节点的确认信息。

Claims (10)

1.一种节点，其中，所述节点包括：

构建单元，其用于构建HELLO包，所述HELLO包包含所述节点请求预约的多个时隙的相关信息或者包含所述节点请求预约的多个时隙的相关信息和所述节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送单元，其发送构建单元构建的所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO所包含的信息对所述节点请求预约的多个时隙进行认证；

其中，

所述节点请求预约的多个时隙的相关信息包括：所述节点的地址、所述节点要发送的数据包的接收节点地址、所述节点请求预约多个时隙的起始时隙索引和时隙长度；

所述邻居节点请求预约的多个时隙的相关信息包括：邻居节点的地址、邻居节点要发送的数据包的接收节点地址、邻居节点请求预约多个时隙的起始时隙索引和时隙长度、邻居节点到达本地节点的距离、以及邻居节点请求预约的多个时隙的确认信息。

2.根据权利要求1所述的节点，其中，所述构建单元包括：

第一取得模块，其从路由表中选择本地节点要发送的数据包的接收节点，得到所述本地节点要发送的数据包的接收节点地址；

第二取得模块，其根据本地预约历史信息和/或本地请求表确定请求预约的多个时隙，得到请求预约的多个时隙的起始时隙索引和时隙长度；

构建模块，其根据本地节点要发送的数据包的接收节点地址、请求预约的多个时隙的起始时隙索引和时隙长度以及本地节点的地址，得到所述本地节点请求预约的多个时隙的相关信息。

3.根据权利要求2所述的节点，其中，所述构建单元还包括：

第三取得模块，其根据预定策略，从本地请求表中选择至少一个邻居节点的信息条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

4.根据权利要求2所述的节点，其中，第二取得模块包括：

计算模块，其计算所需的时隙长度；

确定模块，其根据所述预约历史信息确定所需的时隙长度是否发生变化；

第一选择模块，其在所需的时隙长度发生变化时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙；

第二选择模块，其在所需的时隙长度没有发生变化，并且根据所述预约历史信息确定之前选择的时隙有效时，根据所述预约历史信息确定请求预约的多个时隙；

第三选择模块，其在所需的时隙长度没有发生变化，但根据所述预约历史信息确定之前选择的时隙无效时，根据计算出的所需的时隙长度选择空闲时隙，并根据选择出的空闲时隙确定请求预约的多个时隙。

5.根据权利要求4所述的节点，其中，所述第一选择模块或所述第三选择模块从预先配置的时隙集合中随机选择未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择第一个未被使用的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择具有最大未被使用的时隙间隔内中间位置的时隙作为所述起始时隙；或者，从预先配置的时隙集合中选择时隙索引为本地节点的地址的函数的时隙作为所述起始时隙；或者，根据本地节点的跳数，从该跳数对应的时隙集合中选择未被使用的时隙作为所述起始时隙，并以所述起始时隙为起点，根据本地请求表的信息，选择连续M个未被占用的时隙作为所述空闲时隙，其中，M小于等于计算出的所需的时隙长度。

6.根据权利要求3所述的节点，其中，所述第三取得模块具体用于：从本地请求表中选择本地节点的n跳冲突域内的1～（n-1）跳邻居节点的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息；或者，从本地请求表中选择本地节点的n跳冲突域内的所有一跳邻居节点的条目以及2～（n-1）跳邻居节点的条目中确认信息为同意的条目作为所述至少一个邻居节点请求预约的多个时隙的相关信息。

7.根据权利要求1所述的节点，其中，所述节点还包括：

处理单元，其根据接收到的HELLO包对HELLO包的发送节点请求预约的多个时隙进行认证，和/或确定本地请求预约的多个时隙是否有效，和/或更新本地请求表，和/或更新本地预约历史信息；

其中，接收到的HELLO包仅包括该HELLO的发送节点请求预约的多个时隙的相关信息，或者，接收到的HELLO包包括该HELLO的发送节点请求预约的多个时隙的相关信息以及该HELLO包的发送节点的至少一个邻居节点请求预约的多个时隙的相关信息。

8.根据权利要求7所述的节点，其中，所述处理单元包括：

第一遍历模块，其遍历接收到的HELLO包中所述HELLO包的发送节点请求预约的多个时隙的相关信息；

第一处理模块，其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙冲突时，对所述HELLO包的发送节点请求预约的时隙赋予反对，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；其在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，对所述HELLO包的发送节点请求预约的时隙赋予同意，并在本地请求表中添加对应该HELLO包的发送节点请求预约的多个时隙的相关信息的信息条目；

其中，所述第一处理模块在所述HELLO包的发送节点请求预约的多个时隙与本地请求表中确认信息为同意的1～（n-1）跳邻居节点请求预约的多个时隙不冲突时，判断所述HELLO包的发送节点请求预约的多个时隙与本地请求预约的多个时隙是否冲突，如果冲突，则确认本地请求预约的多个时隙为无效，并修改本地预约历史信息；如果不冲突，则确认本地请求预约的多个时隙为有效，并保持本地预约历史信息不变。

9.根据权利要求8所述的节点，其中，所述处理单元还包括：

第二遍历模块，其遍历接收到的HELLO包中所述HELLO包的发送节点的每一个邻居节点请求预约的多个时隙的相关信息；

第二处理模块，其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID为本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息所指示的确认信息确认本地请求预约的时隙是否有效，并据此更新本地预约历史信息；其在该邻居节点请求预约的多个时隙的相关信息所指示的本地源ID不是本地节点的ID时，根据该邻居节点请求预约的多个时隙的相关信息更新本地请求表；

其中，所述第二处理模块根据本地请求表中的各信息条目确认是否保存过所述邻居节点请求预约的多个时隙的相关信息，如果没有保存过，则将该邻居节点请求预约的多个时隙的相关信息添加入本地请求表，并将其对应的距离加1；如果保存过，则当该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，更新本地请求表中的该邻居节点的该相关信息，并将其对应的距离加1；在该HELLO包中该邻居节点的该相关信息对应的距离小于本地请求表中该邻居节点的该相关信息对应的距离时，判断该HELLO包中该邻居节点请求预约的多个时隙的确认信息是否是同意，如果是同意，则更新本地请求表中所有一跳邻居节点的确认信息。

10.一种时隙分配方法，其中，所述方法包括：

构建HELLO包，所述HELLO包包含本地节点请求预约的多个时隙的相关信息或者包含本地节点请求预约的多个时隙的相关信息和本地节点的至少一个邻居节点请求预约的多个时隙的相关信息；

发送所述HELLO包，以便接收到该HELLO包的节点根据所述HELLO包中所包含的信息对所述本地节点请求预约的时隙进行认证。