Zigbee 和 Thread

Zigbee 和 Thread 论坛

状态 TI Thinks Resolved
已锁定已锁定
回复 31 回复
答案 1 答案
订户 17 订户
视图 12853 视图
用户 0 会员在此处

选项

选项

相关

关于MTO网络中普通Route Request转发的问题

user4658901

Intellectual 281 points

Other Parts Discussed in Thread: Z-STACK

各位大神：

好！~~

有个疑问请教一下各位大神。在MTO的网络中，设备端发出Route Request，如果此RRQ的目的地址是0x0000，则其他路由设备（之前收到过协调器发出的MTO的RRQ）不会帮忙转发RRQ；如果目的地址不是0x0000，则其他路由设备可以帮忙转发RRQ。请问这是某个地方配置造成的还是zigbee本身的机制？如果如果是自带的机制，请问为什么会有这种机制？

使用的是Z-Stack Home 1.2.2a。

先谢谢各位大神赐教！~~

0 Alvin Chen 7 年多前

TI__Guru 56646 points

你的这个设备如果父设备为ZC应该不会转发，父设备为其他路由则会转发。

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

谢谢Alvin Chen的解答！~~
设备的父节点是ZC或ZR的情况，我都试过，还是没有转发。抓包看两种情况的RRQ都是一样。而且其他路由曾经断过电，应该不会保存其他设备的父节点信息吧。

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

如果你设置了NV restore 则会保存。我晚些试一下会给更新到这个帖子上。

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

好的，谢谢您！~~

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

你方便上传的你的抓包文件以及Route Request 部分的code吗？

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

The following figure shows an example of the Many-to-One route discovery procedure. To initiate Many-to-One route discovery, the concentrator broadcast a Many-to-One route request to the entire network. Upon receipt of the route request, every device adds a route table entry for the concentrator and stores the one hop neighbor that relays the request as the next hop address. No route reply will be generated.

这个可能和你的neighbor table和route table 有关，我认为你应该设置为0xFFFC，更多细节可以在下面查看，此外关于发送给ZC（0X0000）的问题可能晚些回复你，我和同事讨论一下这个问题是否合理。

dev.ti.com/.../z-stack-overview.html

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

附件是抓包数据。PANID是0xDDED，52~57行是协调器发出MTO的RRQ，其他路由设备（E2CE）转发并回复路径，69行是设备（EAAE）上电发送数据失败然后发出RRQ，并没有其他路由帮忙转发。期间一直通信不上，然后188行协调器发出MTO的RRQ后，设备（EAAE）收到后开始建立路径，并且通信成功。设备（EAAE）和其他路由设备（E2CE）是直接入到协调器的。通过路由入网的情况跟这个一样，就没有额外附上抓包数据。RRQ是程序自动发送的，我这没有修改，所以也没附上RRQ的Code。麻烦帮忙分析一下，谢谢！~~MTO.zip

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

好的，等待您的回复，谢谢！~~

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

你好，是可以转发的，我无法复现你的问题，你是不是环境干扰或者距离过远造成的。

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

https://e2echina.ti.com/cfs-file/__key/communityserver-discussions-components-files/104/TEST.7z

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

TEST里面没有文件，麻烦重新发一下，谢谢

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

应该不是距离的原因，其他路由设备（E2CE）和设备（EAAE）是放在一起的，只是把设备（EAAE）的天线拔掉了，模拟需要路由转发的情况。我先看一下您测试的抓包数据

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

谢谢您的解答，我看了一下，唯一的区别就是我这边是0XFFFC，您的是0xFFFD，我这边先试一下看看能不能改成0xFFFD，然后试一下能不能帮忙转发，再次感谢！~~

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

我的也是0xFFFC。。。。你说0XFFFD在哪。。。

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

不好意思，看错了，RRQ都是0xFFFD，没有0xFFFC。我再对比一下

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

我对比了一下RRQ，发现除了Number以外只有一个地方不一样，请问这个地方会影响其他路由帮忙转发吗？

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

Many-to-One route request command is similar to unicast route request command with same command ID and payload frame format. The option field in route request is Many-to-One and the destination address is 0xFFFC.

你注意看：

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

会的，你需要更改 CONCENTRATOR_DISCOVERY_TIME 和 SRC_RTG_EXPIRY_TIME

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

谢谢您的回复，我可能没说清楚，我上面说的是DST Add 为0x0000普通RRQ里面的NWK DST是0xFFFD，不好意思让您误解了。我这边再试一下，谢谢!~~

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

请问RRQ中Destination IEEE Address Include标志位在哪使能，设置成YES？

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

你先去改一下试试，参考这个：
e2e.ti.com/.../2903648

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

谢谢您的分享！~~那个帖子最后的原因是NLME_RouteDiscoveryRequest 中Options参数设置错误，可是NLME_RouteDiscoveryRequest 是底层调用的，我在代码中搜索不到其调用的地方，请问我需要怎么操作才能修改NLME_RouteDiscoveryRequest 中的Options或者可以在哪找到底层调用NLME_RouteDiscoveryRequest 的地方？

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

你先微调那个 CONCENTRATOR_DISCOVERY_TIME 和 SRC_RTG_EXPIRY_TIME，不行的话就是强制自己发送NLME_RouteDiscoveryRequest 。

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

刚刚试过了，强制发送NLME_RouteDiscoveryRequest 的话建立起来路由时好时坏，只有当协调器发出MTO的RRQ时，通信才正常。然后我们又拿Z3.0试了一下，发现普通的RRQ其他路由会帮忙转发，跟我们现在用Z-Stack Home 1.2.2a设备发出的RRQ唯一的区别就是Destination IEEE Address Include为YES。请问Z-Stack Home 1.2.2a协议栈里面可以修改Destination IEEE Address Include？另外请问一下，您刚才测试是用Z-Stack Home 1.2.2a进行测试的吗？

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

我用的3.0测试的，那个参数应该没有影响，你有调整那两个参数，不行的话就升级3.0吧。我明天会再看一下。

0 Alvin Chen 7 年多前回复 Alvin Chen

TI__Guru 56646 points

你好，

昨天晚上我和同事又在1.22A上面测试了一下，没有复现，我们再次查看了你的sniffer files ,我们发现0xEAAE RSSI不是很好，似乎和ZC (0X0000)失去了连接。

总结你设备之前的RF 信号不是很好，造成了这一现象。

我给出的最终建议：

1. 把你网络中其他PANID的设备移除掉（备选）

2. 拉近你的设备之间的距离

3.或者加个PA试试。

0 user4658901 7 年多前回复 Alvin Chen

Intellectual 281 points

谢谢您的解答，以及十分感谢您那么晚还在帮忙测试！~~我在问题的沟通上可能存在描述不清，能否私信留个电话或者联系方式，我把我们的现场环境以及产品需求跟您沟通下。

0 Alvin Chen 7 年多前回复 user4658901

TI__Guru 56646 points

你可以在私信我。我们测试的环境比较好，你可以先去试试看。