电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: ZigBee协议请教? [打印本页]

作者: soundsilly 时间: 2006-4-10 19:41 标题: ZigBee协议请教?

1、隔壁两户人家同时使用自己的一套基于zigbee的灯光系统，则各自建立了不同的网络，由不同的PANID来区分？现有一新的结点要加入到某户人家的网络里，那该结点是如何避免不加入另外一户人家的呢？

2、zigbee协议是如何实现低功耗的，即其结点的睡眠和唤醒机制怎么实现？是通过定时的广播becon唤醒帧实现的吗？

作者: seuafu2005 时间: 2006-4-11 10:56

1。通过应用层选择PANID来加入；
2。结点的睡眠和唤醒都是通过MCU来实现的。目前zigbee不支持网络唤醒的功能。

作者: soundsilly 时间: 2006-4-11 16:34

关于z-stack的应用实例有哪些文档呢?我只看到AN2994.pdf.

作者: seuafu2005 时间: 2006-4-11 16:41

可以查看z－stack中的一些文档。
另外，主要是查看z－stack给出的一些实例程序，通过程序了解应用

作者: soundsilly 时间: 2006-4-12 15:37

请问Z-STACK的OSAL是哪一种OS的API? 我初看提供的OSAL源码,这不是一个简单的OS的源码吗?为什么说它仅是API?

[此贴子已经被作者于2006-4-12 15:37:39编辑过]

作者: seuafu2005 时间: 2006-4-12 16:33

这里面的OS应该是自己编写的一个简单的OS，用于调度而已。

作者: soundsilly 时间: 2006-6-7 20:40

对Beacon帧中,如
FFD发出的00 80 0f ef be fe ca 11 ef 80 00
通过分析,该帧类型为BEACON,11 ef为super frame specification
80为GTS
00为pending
但我对这几个表示的是什么意思,有啥作用,还没领会出来也?请指教!

作者: seuafu2005 时间: 2006-6-8 10:05

具体数字的含义还是要查看IEEE802.15.4的spec

作者: soundsilly 时间: 2006-6-8 12:39

我在对freescale针对802.15.4 MAC PHY Software所提供的例子MyWirelessApp中的应用例程,如My_Wireless_App_Ex05a及My_Wireless_App_Ex05b,所抓下来的over the air的帧,
RFD:23 c8 20 ef be fe ca ff ff ff ff ff ff ff ff ff ff 01 80(associate.request)
RFD:63 c8 29 ef be fe ca ff ff ff ff ff ff ff ff 04(poll-data.request)
FFD:12 00 29(ack)
FFD:62 cc 3b ef be ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 01 00 00(associate.response)

以上RFD完成了接入FFD所建成的PAN.
不明白的地方是,按照IEEE 802.15.4 specification所提供的接入过程,FFD应该对RFD的associate.request给一个ACK,然后RFD才向FFD发送poll-data.request的帧,为什么这里不是呢?freescale的MAC PHY库也有不符合标准的吗?
[upload=image/pjpeg]uploadImages/association.jpg[/upload]

作者: soundsilly 时间: 2006-6-13 11:09

第一种情况：
RFD1：63 88 d2 30 34 0 0 6f 79 4 (MLME_POLL_request)
Coordinator：12 0 d2(ACK)
Coordinator：41 88 4a 30 34 6f 79 0 0 (MLME_POLL_response)

第二种情况：
RFD1：63 88 cf 30 34 0 0 6f 79 4(MLME_POLL_request)
Coordinator：2 0 cf(ACK)
第一种和第二种效果不是一样吗？为啥要区分出来呢？是怎么样的情况下才需要第一种的应答形式呢？

作者: soundsilly 时间: 2006-6-14 10:18

为什么没人回复我呢?

作者: seuafu2005 时间: 2006-6-14 10:55

你用的802154软件是哪个版本的？

两种情况是什么意思？具体你指的是哪两种情况？

前一个帖子FFD得到的ACK会不会是data request的ack？

作者: jimmytan 时间: 2006-6-14 14:02

没有抓过802.15.4 MAC over the air的帧，不知道会不会出现你所说的那种情况。加入网络的过程，应该是要符合IEEE802.15.4的规范的。但这个功能是在MAC层中完成的，所以对你来说，最重要的是能实现这个网络的加入功能。可以通过API来知道这个网络的加入状况。

作者: soundsilly 时间: 2006-6-14 14:46

该网络内有三个结点，即coordinator,RFD1,RFD2,现在是由RFD1与coordinator绑定后，向coordinator发送数据(64 65 66 )，

RFD1(short address:6F 79)向coordinator发送数据64 65 66
RFD1： 61 88 bc 30 34 0 0 6f 79 4 0 0 0 6f 79 7 1 54 1 5 f b 21 0 3 64 65 66
RFD2：63 88 3d 30 34 0 0 70 79 4 (poll data)
Coordinator：12 0 3d(ack)
Coordinator：41 88 43 30 34 70 79 0 0 （data send(NO_DATA),need not ack）

RFD1：63 88 bd 30 34 0 0 6f 79 4 （poll data）
Coordinator ：12 0 bd（ack）
Coordinator ：61 88 42 30 34 6f 79 0 0 44 0 6f 79 0 0 7 1 6 b 1 5 f

疑问如下：可以看到，当RFD2向coordinator 进行poll_data_request时，coordinator做出的反馈如下：
Coordinator：12 0 3d(ack，frame pending=1)
Coordinator：41 88 43 30 34 70 79 0 0 （data send(NO_DATA),need not ack）
也就是说此时，coordinator有RFD1的indirect data frame，而没有RFD2的indirect data frame，但对RFD2的poll data request回复为什么带frame pending=1,并紧跟一个data_length=0的数据帧，何不更省略一点，就回复一个frame pending=0的ACK呢？

[此贴子已经被作者于2006-6-14 14:46:33编辑过]

作者: soundsilly 时间: 2006-6-14 14:54

我现在是以freescale所提供的协议库功能为参照物，我当然期望它能和协议specification里的一样，不然我理解起来会非常费劲。

作者: soundsilly 时间: 2006-6-14 15:35

我再把我的问题重新叙述一遍,现在我以Fingure 8 Wireless->FS-1.0-1.2.0->Zstack->SerialApp为例,该实例利用Zstack的库,实现了网络结点间通过串口互发消息.下面是其RFD接入网络的通信过程:
RFD1(MAC add: 5d 79 22 23 24 25 26 27)加入PAN 30 34，分配的短地址为6F 79:
RFD1: 3 8 a7 ff ff ff ff 7(active scan)
coordinator: 0 80 c0 30 34 0 0 ff cf 0 0 0 11 84(beacon frame,PANID=34 30,SRC Add=00 00)

RFD1: 23 c8 aa 30 34 0 0 ff ff 5d 79 22 23 24 25 26 27 1 80(associate.request)
RFD1: 63 c8 ab 30 34 0 0 5d 79 22 23 24 25 26 27 4(poll-data.request)
coordinator: 12 0 ab(ack，FD=1,for poll_data.request)

coordinator ： 63 cc 40 30 34 5d 79 22 23 24 25 26 27 30 34 12 13 14 15 16 17 2 6f 79 0 (associate.response)

RFD1： 63 88 ac 30 34 0 0 6f 79 4 （poll_data.request）
coordinator：2 0 ac（ACK,FD=0,for poll_data.request）
问题如下:
coordinator的应答机制似乎只针对POLL_DATA_request的帧?而按照IEEE802.15.4标准,针对其他的所有命令数据消息,似乎都应该有应答,具体见楼9的图，即coordinator应该对RFD1的associate.request应答，RFD1应该对associate.response应答.

[此贴子已经被作者于2006-6-14 15:35:29编辑过]

作者: soundsilly 时间: 2006-6-15 10:03

jimmytan,能不能你也抓一下包,看看是不是我这样的,现在我理解的很乱,为什么明明要求ACK的帧(如frametype=61),却没有得到ACK.

作者: jimmytan 时间: 2006-6-15 14:22

你是用什么工具抓得啊？

作者: jimmytan 时间: 2006-6-15 16:59

Association is implemented according to the IEEE 802.15.4 standard but the standard is not explicit on
how and when various MAC PIB attributes are updated. Issuing the MLME-ASSOCIATE.request primitive
actually results in two MAC command frames being sent to the coordinator. The first is the association
request itself. The second is the data request that is sent after aResponseWaitTime symbols. Refer to
the IEEE 802.15.4 standard for a description of the association procedure. The following attributes are
updated when MLME-ASSOCIATE.request is called.

作者: soundsilly 时间: 2006-6-15 22:24

我是用我们实验室做的sniffer抓的,谢谢提醒,我差点忘了看这些文档!

作者: soundsilly 时间: 2006-6-16 15:09

(802.15.4 MAC PHY Software Reference Manual,3.5 Association Feature)
a MAC command frame containing the association request is
then sent to the coordinator. ......A timer is started upon successful reception.The timer expires after aResponseWaitTime symbols.......

"A timer is started upon successful reception.",请问RFD怎么确定自己的associate.request帧被coordinator成功接收呢,因为RFD并没有得到coordinator的ACK呀?
下面是我做的一个实验,RFD(基于freescale zigbee库)欲接入一PAN(coordinator是本人的试验代码)中,但未成功.RFD根本就不向coordinator发送data_request.
RFD:03 08 0B FF FF FF FF 07(active scan)
coordinator:00 80 12 12 2F 00 00 FF CF 00 00 00 11 84(beacon frame)
RFD:23 C8 0C 12 2F 00 00 FF FF 2E E1 22 23 24 25 26 27 01 80(assocaite.request)
RFD:23 C8 0C 12 2F 00 00 FF FF 2E E1 22 23 24 25 26 27 01 80
RFD:23 C8 0C 12 2F 00 00 FF FF 2E E1 22 23 24 25 26 27 01 80
RFD:23 C8 0C 12 2F 00 00 FF FF 2E E1 22 23 24 25 26 27 01 80
RFD:03 08 0D FF FF FF FF 07(active scan)
coordinator:00 80 15 12 2F 00 00 FF CF 00 00 00 11 84(beacon frame)

[此贴子已经被作者于2006-6-16 15:09:57编辑过]

作者: jimmytan 时间: 2006-6-20 18:02

从你抓的数据来看，不能判断coordinator到底有没有收到associate.request,有可能coordinator根本没有收到这个request，所以没有反应.因为你是beacon网络，所以我想你要发MLME-SYNC.request，让这个device先去同步这个beacon，然后再发associate.request。

作者: soundsilly 时间: 2006-6-23 11:19

jimmytan,上面的例子,网络均为NONE_BEACON,NONE_SECURITY网络.

原Freescale网络RFD1接入PAN过程中的帧：RFD1(MAC add: 5d 79 22 23 24 25 26 27)加入PAN 30 34，分配的短地址为6F 79:
RFD1: 3 8 a7 ff ff ff ff 7(active scan)
coordinator: 0 80 c0 30 34 0 0 ff cf 0 0 0 11 84(beacon frame,PANID=34 30,SRC Add=00 00)
RFD1: 23 c8 aa 30 34 0 0 ff ff 5d 79 22 23 24 25 26 27 1 80(associate.request)
RFD1: 63 c8 ab 30 34 0 0 5d 79 22 23 24 25 26 27 4(poll-data.request)
coordinator: 12 0 ab(ack)
coordinator ： 63 cc 40 30 34 5d 79 22 23 24 25 26 27 30 34 12 13 14 15 16 17 2 6f 79 0 (associate.response)
我不晓得为什么这能成功,而我上面的例子就不成功!

[此贴子已经被作者于2006-6-23 11:19:57编辑过]

作者: soundsilly 时间: 2006-6-23 15:34

jimmytan,如果你能用你的抓包工具证明我抓下的包漏掉了ACK(如assocaite.request对应的ACK)的话,那我的问题就迎刃而解了.期盼!!!

作者: jimmytan 时间: 2006-6-26 13:49

这是我用sniffer抓下来的一个组网的过程．首先是coordinator先起来，然后是一个RFD加入这个网络的过程．应该很清楚了．

Seq No Time Time Delta MAC Src MAC Dest NWK Src NWK Dest Protocol Packet Type
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
8 13:37:32.283 +00:00:00.137 0x0050c237b0000f52 0x0000 IEEE 802.15.4 Command: Association Request
9 13:37:32.284 +00:00:00.001 IEEE 802.15.4 Acknowledgment
10 13:37:32.780 +00:00:00.495 0x0050c237b0000f52 0x0000 IEEE 802.15.4 Command: Data Request
11 13:37:32.781 +00:00:00.001 IEEE 802.15.4 Acknowledgment
12 13:37:32.784 +00:00:00.003 0x0050c237b0003162 0x0050c237b0000f52 IEEE 802.15.4 Command: Association Response
13 13:37:32.785 +00:00:00.001 IEEE 802.15.4 Acknowledgment
7 13:37:32.146 +00:00:00.004 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
6 13:37:32.142 +00:00:01.139 0xffff IEEE 802.15.4 Command: Beacon Request
5 13:37:31.003 +00:00:00.002 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
4 13:37:31.000 +00:00:01.139 0xffff IEEE 802.15.4 Command: Beacon Request
2 13:37:29.859 +00:00:12.859 0xffff IEEE 802.15.4 Command: Beacon Request
3 13:37:29.861 +00:00:00.002 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
1 13:37:17.000 0xffff IEEE 802.15.4 Command: Beacon Request

作者: jimmytan 时间: 2006-6-26 13:51

Seq No Time Time Delta MAC Src MAC Dest NWK Src NWK Dest Protocol Packet Type
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1 13:46:03.000 0xffff IEEE 802.15.4 Command: Beacon Request
2 13:46:08.733 +00:00:05.733 0xffff IEEE 802.15.4 Command: Beacon Request
3 13:46:08.736 +00:00:00.003 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
4 13:46:09.875 +00:00:01.138 0xffff IEEE 802.15.4 Command: Beacon Request
5 13:46:09.880 +00:00:00.005 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
6 13:46:11.016 +00:00:01.137 0xffff IEEE 802.15.4 Command: Beacon Request
7 13:46:11.019 +00:00:00.003 0x0000 IEEE 802.15.4 Beacon: BO: 15, SO: 15, PC: 1, AP: 1, Nwk RC: 1, Nwk EDC: 0
8 13:46:11.158 +00:00:00.139 0x0050c237b0000f52 0x0000 IEEE 802.15.4 Command: Association Request
9 13:46:11.159 +00:00:00.001 IEEE 802.15.4 Acknowledgment
10 13:46:11.653 +00:00:00.494 0x0050c237b0000f52 0x0000 IEEE 802.15.4 Command: Data Request
11 13:46:11.654 +00:00:00.001 IEEE 802.15.4 Acknowledgment
12 13:46:11.656 +00:00:00.002 0x0050c237b0003162 0x0050c237b0000f52 IEEE 802.15.4 Command: Association Response
13 13:46:11.657 +00:00:00.001 IEEE 802.15.4 Acknowledgment

作者: jimmytan 时间: 2006-6-26 13:56

0x0050c237b0000f52是RFD的MAC地址．

作者: soundsilly 时间: 2006-6-27 15:51

非常感谢!很清楚

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)