首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

ZigBee协议请教?

我再把我的问题重新叙述一遍,现在我以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编辑过]

jimmytan,能不能你也抓一下包,看看是不是我这样的,现在我理解的很乱,为什么明明要求ACK的帧(如frametype=61),却没有得到ACK.
你是用什么工具抓得啊?
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.
我是用我们实验室做的sniffer抓的,谢谢提醒,我差点忘了看这些文档!
(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编辑过]

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

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编辑过]

jimmytan,如果你能用你的抓包工具证明我抓下的包漏掉了ACK(如assocaite.request对应的ACK)的话,那我的问题就迎刃而解了.期盼!!!
这是我用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

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
0x0050c237b0000f52是RFD的MAC地址.
非常感谢!很清楚
返回列表