• 状态 Resolved
  • 已锁定 已锁定
  • 回复 5 回复
  • 订户 18 订户
  • 视图 3278 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

这段话真的很南理解啊，拜托TI的大神解答一下

user4958201
Intellectual 772 points

Other Parts Discussed in Thread: CC2530, Z-STACK, CC2538

TI官方400+节点实验中有这样一段话：

If the concentrator is memory constraint, it is very important to note the source route expiry timeout (SRC_RTG_EXPIRY_TIME) value should be such that no more than (MAX_RTC_SRC_ENTRIES) devices reporting within this interval. In this case concentrator should be able to store the paths back to all the nodes as they report data (even if the concentrator does not have memory to store path to all devices) as expired routes will be replaced with new routes and the network should not see broadcast route request storms originating from the concentrator which can cause the network throughput and reliability to go down significantly.

这段话没有理解透彻，到底SRC_RTG_EXPIRY_TIME这个源路由表超时时间宏定义应该怎么设置，特别是标注红色字体这句，真心没有翻译明白，希望大神解答下；

MAX_RTC_SRC_ENTRIES这个宏中标注红色的C应该是G，即源路由表的最大个数。

  • 0
    Genius 5959 points
    首先SRC_RTG_EXPIRY_TIME这个宏是设置路由表超时时间，具体底层怎么做的，这个是封装起来的没法看到。

    我也测试过SRC_RTG_EXPIRY_TIME=0的情况，似乎没太大变化，理论上有多少个节点，就记录多少个路由路径，这样会占用ZNP端的RAM资源，这篇文章当时测试的时候，ZNP使用的是CC2530，RAM只有几个KB，且是通过UART和电脑端连接之后来分析网络数据的。

    目前我把SRC_RTG_EXPIRY_TIME设置的比MAX_RTC_SRC_ENTRIES还要大，因为RAM是足够用的，就大点呗，这样省的后面老是发送route request广播
  • 0 回复 behold
    Intellectual 772 points
    谢谢您的解答，我是不是可以这么理解：
    根据400+节点实验，分为需要APS 的ACK和不需要两种，其中需要APS ACK的平均1秒ZC就会收到一个节点的数据（不需要APS ACK的平均0.4秒），我们设置源路由超时时间SRC_RTG_EXPIRY_TIME的值比节点个数MAX_RTG_SRC_ENTRIES还要大是为了（假如我们应用也是400秒内400个节点全部上送一次数据，即平均每秒ZC收到一包数据，需要APS ACK回复）在ZC收到节点发来的数据后可以直接在源路由表中找到APS ACK的回复路径，而不会因为路由表中数据存活时间短导致ZC找不到APS ACK的回复路径，继而需要发起route request广播寻找。
    不知道我这么理解对不对？
  • 0 回复 user4958201
    Genius 5959 points
    对于MTO(many to one)路由机制，我是这样理解的，只要协调器上保存了到达所有节点的路由路径，那么给这些节点发送消息的时候，就不需要再次发送route request广播，另外，AN123这个文档当时测试的并不很严谨，里面提及的宏参数优化，有局限于他们在圣地亚哥办公室的环境，网络密度较大，对于那些分散式的400+节点布局，不具有代表性。

    另外他们协调器的确是CC2530，受限于RAM大小只有8KB，所以无法保存更多的路由表，故他们设置SRC_RTG_EXPIRY_TIME=2，这样会导致协调器上的路由表很小，如果协调器要给这些节点发信息，就不得不再次发起route request广播以请求报告路由路径。
  • 0 回复 behold
    Intellectual 772 points
    恩 确实是 400+节点的宏不能全部照搬 需要根据自身的情况进行调整 就像我们现在用的2538 而且协议栈版本也是z-stack3.0 加密机制都是必须的了，我想按照这上面说的使用预配置密钥，但是修改uint8 zgPreConfigKeys = TRUE以及f8wConfig中配置没有成功，还没有查到原因； 主要是现在集群组网没有一个正确的标准，或者是不知道好的应该是什么样子，所以探索着比较困难。
  • 0 回复 user4958201
    Genius 5959 points
    首先，Z-Stack 3.0的确默认使能了加密机制，所以sniffer等抓包工具就歇菜了，只能依赖ubiqua抓包。

    其次，zgPreConfigKeys=TRUE的确能打开预置密钥，所有编译好的router/coordinator/end-device固件，就内置了network key和tc link key这两种key，以便于作为入网认证使用，我们这边全部都修改了协议栈默认的这两个key，测试过，如果任何一个key不同，是无法真正加入网络的(被leave掉)。

    另外，我的理解是协调器应该有两张路由表，一张叫做route table，就是真正的路由表，过期时间应该由RTG_EXPIRY_TIME指定，
    协议栈自带文档Z-Stack 3.0 Developer's Guide.pdf里面5.2.3 Route expiry的确阐述了ROUTE_EXPIRY_TIME这个宏的具体作用，以及设置为0时候的作用。

    还有一张表叫做source route table，存储在协调器上，并在收到route record时候进行更新，是专门用于MTO(是many to one，就是协调器，俗称的网关到其他节点，不是otm，其他节点到网关)这种路由机制的一张表，过期时间由SRC_RTG_EXPIRY_TIME指定，为什么有这张表，原因在AN123的2.2 Message Reporting 里面Case 2有提及[To avoid the network overhead of concentrator discovering paths to all the nodes in the network
    using the AODV routing, ZigBee-Pro-2007 also defines Source Routing. ]，说白了实际就是一种补救措施，因为传统的AODV会导致网络拥塞，就是美国人说的overhead---过头了，可以理解为额外负担、开销，因为建立mesh网络的初衷是为了传输数据，AODV显然不是为用户传输数据，而是为了维护网络，所以就叫overhead。

    遗憾的是，除了AN123文档短短几行文字，协议栈其他文档并没有提及宏SRC_RTG_EXPIRY_TIME的详细细节。

    我认为，像CC2538这种内存基本不受限制的设备，在router/end-device节点物理位置固定不变的环境下，完全可以不考虑SRC_RTG_EXPIRY_TIME过期的问题，应该可以设置为0，反正内存很大，再浪费也无所谓。