Underwater Networks Handbook

Imagine a network with gateway node A (a standalone buoy), surface node B (deployed from a boat), and an underwater node C (diver). Nodes A and B have underwater acoustic modems and in-air WiFi connectivity. Node C is fully submerged, and only has acoustic connectivity to nodes A and B. An diver tracking script on node B wishes to track the location of diver node C. This requires the script on node B to make range measurements btween node B and node C (easy to do!), but also between node A and node C (not so easy!). The traditional approach to this problem would be to deploy a helper agent on node A to make the range measurement, and have the script communicate with the agent using a custom protocol over a UDP link over WiFi. Another approach would be to enable remote access ( Chapter 24 ) on node A, and use rsh to execute the ranging commands on node A, and send back the results using tell . While this would work, it would be quite fragile. Wormholes provide a much simpler and robust way to do this.

We’ll use the Netiquette 3-node network to demonstrate how to do this:

Nodes A and B are assumed to be connected over an in-air WiFi network, and so we can enable UdpLink on both nodes and establish connectivity over it:

Next, we enable the Wormhole agent on both nodes, and set it up to use the udplink for connectivity:

That’s it for the setup! We’re now ready to prototype out our application over the wormhole.

The functionality we needed was to make range measurements between nodes B and C, and nodes A and C, from a script on node B. Let’s start off measuring range to node C from node B and call it r1 :

In a script, you’d probably want to use ntf = receive(RangeNtf, 5000) to access the RangeNtf that comes back, but we’ll stick to doing this just in the shell for the demonstration. Now comes the magic . From the shell on node B, we want to ask the ranging agent on node A (address 232) to make a range measurement to node C for us:

Now that we have r1 and r2 , we can use it to compute the location of the diver in our script.

In the diver tracking application above, we performed two-way travel-time (TWTT) ranging from nodes A and B to node C. While this works well, each diver location measurement required transmission of 4 frames. With one-way travel-time (OWTT) ranging (see Chapter 17 ), we could make each measurement in just one transmission from diver node C, as long as we had accurate clocks at all nodes.

First, let us enable OWTT ranging by synchronizing clocks between nodes A and C, and nodes B and C (see Section 17.3.2 for details):

OWTT is now enabled. To send out a beacon on node C, we use the beacon command (or equivalently send a BeaconReq message):

On nodes A and B, you’ll see the RangeNtf notifications:

Diver node C can now send out a beacon transmission regularly, and ranging agents on node A and node B will publish RangeNtf notifications on their respective agent topics. On node B, we would then want to subscribe to the ranging agent topics on both nodes. We are already subscribed to node B’s ranging agent, and connected over the wormhole (established in the previous section) to node A. Since we can refer to the ranging agent on node A as agent('ranging@232') , we should be able to subscribe to it:

Now, try sending a beacon again from node C, and see what we get at node B:

We got the notification from node B’s agent, but nothing from node A! 😕

By default, wormholes do not publish messages on topics. However, it is easy to enable certain topics to be published. To enable this, we set the wh.publish parameter on node A:

Now, try sending a beacon again from node C, and see what we get at node B:

Cool! We got both ranges on node B now. 🙂

We can now write our application script to call receive(RangeNtf) to get the ranges, and computes the position of the diver everytime the diver node transmits a beacon.