[Tinyos-users] Successful in implementing static routes for Surge, but came accross some interesting scenarios

Yogesh Iyer Sat, 01 Jan 2005 17:30:52 -0800

Hi,

I was finally able to implement static routes for the Surge application. In yesterdays mail, I had mentioned that we need to hardwire the routes at getParent(). But even after I did that, the nodes were still sending packets directly to node 0 (Base station).

I realized that getParent() only changes the parent that is reported in the Surge packet. The actual parent is set in the chooseParent() function. So, I hardwired the parent address in chooseParent() as follows:

if (pNewParent) {
      atomic {
        gpCurrentParent = pNewParent;
        gbCurrentHopCount = bNewHopCount + 1;

        switch (TOS_LOCAL_ADDRESS) {
                case 0: // Parent of mote 0 is the UART
                        gpCurrentParent->id = TOS_UART_ADDR;
                        break;
                case 1: // Parent of mote 1 is mote 2
                        gpCurrentParent->id = 0x02;
                        break;
                case 2: // Parent of mote 2 is mote 0
                        gpCurrentParent->id = 0x00;
                        break;
                case 3: // Parent of mote 3 is mote 0
                        gpCurrentParent->id = 0x00;
                        break;
                case 4: // Parent of mote 4 is mote 1
                        gpCurrentParent->id = 0x01;
                        break;
                case 5: // Parent of mote 5 is mote 0
                        gpCurrentParent->id = 0x00;
                        break;
                case 6: // Parent of mote 6 is mote 2
                        gpCurrentParent->id = 0x02;
                        break;
                case 7: // Parent of mote 7 is mote 5
                        gpCurrentParent->id = 0x05;
                        break;
                case 8: // Parent of mote 8 is mote 0
                        gpCurrentParent->id = 0x00;
                        break;
                case 9: // Parent of mote 9 is mote 5
                        gpCurrentParent->id = 0x05;
                        break;
        }

        dbg(DBG_ROUTE,"The chosen Parent is: %x",gpCurrentParent->id);
      }

}

The nodes then sent packets to their respective parents but then I observed the following cases:

In a 7 node network (including the Base station), when node 1 sends a packet to node 2, node 2 does not forward it to node 0. Similarly, packets do not get forwarded on the path node 4 --> node 1 --> node 2 --> noe 0. The packet originated by node 4 does not get forwarded by node 1.
BUT, in a 10 node network, everything works perfectly. Node 1 and node 2 forward the packets that they get from other nodes to node 0.
Again with a 10 node network, I add a static route node 6 --> node 2 --> node 0; and observe that node 2 does not forward packets received from node 6, while still continuing to forward node 1's and node 4's packets.
This is similar to case 2. I had a static route initially as node 9 --> node 5 --> node 0. Node 5 forwarded packets received from node 9.
BUT, when I add the static route node 7 --> node 5 --> node 0, node 5 does not forward node 7's packets while still continuing to forward node 9's packets.

Can someone please explain why do we observe Case 1. How does different number of nodes in the network affect the forwarding of packets?

Also, in Case 2 & 3, why does node 2 and node 5 only forward packets coming from one route. Is this related to buffer overflow or something of that sort?

I'll be really obliged if you can explain whats going on. Thanks in advance and have a great new year.

Regards,
Yogesh.

[EMAIL PROTECTED] wrote:

Hi,

If the parent is in the neighbor table, meaning
you can assign a table entry pointer to gpCurrentParent, you can hardwire the parent
in chooseParent().

If you don't care about the neighbor table,
simply hardwire the route. Do it at RouteSelect.selectRoute. This is probably the easiest place to modify.

Something like:

pMHMsg->sourceaddr = TOS_LOCAL_ADDRESS;
pMHMsg->hopcount=gbCurrentHopCount;//hardwire
Msg->addr = gpCurrentParent->id; //hardwire

return SUCCESS;

should do. Hope this helps.

alec
Content-Type: multipart/alternative; boundary="0-2031195102-1104372015=:21939"

--0-2031195102-1104372015=:21939
Content-Type: text/plain; charset=us-ascii

Hi Philip,

Thanks for your help. I looked at app.c and saw that the Surge application is using the MultiHopEngineM.nc ! and MultiHopLEPSM.nc modules. I have made the following observation. Please correct me if I am wrong.

MultiHopEngineM has all the sending, forwarding and receiving functions & MultiHopLEPSM has all the neighbor table update & parent selection functions. Surge calls the RouteControl.getParent() function which is defined in MultiHopEngineM which in turn calls the RouteSelectCntl.getParent() function in MultiHopLEPSM, where we get the parent addr from gpCurrentParent.

My task is to implement static routes in Surge application. So, I am ONLY interested in the parent address. I have thought of 2 ways of implementing this:

Have a case statement which sets the parent address for all the nodes in MultiHopEngineM, and then return the parent address in MultiHopEngineM itself. We can then "unwire" the MultiHopLEPSM module because we are not interested in having a nighbor table.

Have a a new struct in MultiHopLEPSM which only declares the parent and point gpCurrentParent to this new struct. We then comment out everything except the StdControl functions in MultiHopLEPSM.

Can you please suggest which one of the two is a better way to implement static routes. Thanks a lot for your time and help.

Regards,
Yogesh.

Philip Levis <[EMAIL PROTECTED]>wrote:
On Dec 29, 2004, at 11:35 AM, Yogesh Iyer wrote:

> Hi,
>
> I am trying to understand the multihop routing implemented by Surge.
> Surge uses the MultiHopRoute.nc for routing.
>
> Now, In the implementation section of the MultiHopRoute.nc file, there
> are preprocessor directives defined on the OLD_ROUTING identifier. I
> wanted to know whether the Surge application executes the
> Old_routing (the MultiHopRouteM module) or the else part (the
> MultiHopLEPSM module).
>
> Can someone please help me understand how to figure that out?
>
> Thanks,
> Yogesh.
>

Three ways:

1) Make docs and look at the component graph
2) take a look at build/*/app.c (the generated C file) and see which is
there
3) Run it in TOSSIM and use gdb

Phil

---------------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot, 'Little Gidding'

---------------------------------
Do you Yahoo!?
Yahoo! Mail - now with 250MB free storage. Learn more.
--0-2031195102-1104372015=:21939
Content-Type: text/html; charset=us-ascii

Hi Philip,

Thanks for your help. I looked at app.c and saw that the Surge application is using the MultiHopEngineM.nc and MultiHopLEPSM.nc modules. I have made the following observation. Please correct me if I am wrong.

MultiHopEngineM has all the sending, forwarding and receiving functions & MultiHopLEPSM has all the neighbor table update & parent selection functions. Surge calls the RouteControl.getParent() function which is defined in MultiHopEngineM which in turn calls the RouteSelectCntl.getParent() function in MultiHopLEPSM, where we get the parent addr from gpCurrentParent.

My task is to implement static routes in Surge application. So, I am ONLY interested in the parent address. I have thought of 2 ways of implementing this:

Have a case statement which sets the parent address for all the nodes in MultiHopEngineM, and then return the parent address in MultiHopEngineM itself. We can then "unwire" the MultiHopLEPSM module because we are not interested in having a nighbor table.

Have a a new struct in MultiHopLEPSM which only declares the parent and point gpCurrentParent to this new struct. We then comment out everything except the StdControl functions in MultiHopLEPSM.

Can you please suggest which one of the two is a better way to implement static routes. Thanks a lot for your time and help.

Regards,
Yogesh.

Philip Levis <[EMAIL PROTECTED]> wrote:

On Dec 29, 2004, at 11:35 AM, Yogesh Iyer wrote:

> Hi,
>
> I am trying to understand the multihop routing implemented by Surge.
> Surge uses the MultiHopRoute.nc for routing.
>
> Now, In the implementation section of the MultiHopRoute.nc file, there
> are preprocessor directives defined on the OLD_ROUTING identifier. I
> wanted to know whether the Surge application executes the
> Old_routing (the MultiHopRouteM module) or the else part (the
> MultiHopLEPSM module).
>
> Can someone please help me understand how to figure that out?
>
> Thanks,
> Yogesh.
>

Three ways:

1) Make docs and look at the component graph
2) take a look at build/*/app.c (the generated C file) and see which is
there
3) Run it in T!
OSSIM and
use gdb

Phil

---------------

"We shall not cease from exploration
And the end of all our exploring
Will be to arrive where we started
And know the place for the first time."

- T. S. Eliot, 'Little Gidding'

Do you Yahoo!?

Yahoo! Mail - now with 250MB free storage. Learn more.
--0-2031195102-1104372015=:21939--
_______________________________________________
Tinyos-users mailing list
[email protected]
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users

Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search. Learn more.

_______________________________________________
Tinyos-users mailing list
[email protected]
http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users

[Tinyos-users] Successful in implementing static routes for Surge, but came accross some interesting scenarios

Reply via email to