7. Wired and over-the-air links

The networks we explored in the last few chapters were completely underwater. All links were underwater acoustic links. If we wanted to replace some of the acoustic links with underwater optical or RF links, or even through-the-air cellular, WiFi or RF links, that could easily be done, as long as you had a modem driver (a specific type of agent) that supported the device that provided the link. Cellular, WiFi and other devices often already have TCP/IP network stacks running on them, to provide seamless connectivity to the Internet. UnetStack can leverage the existing network stack in these devices without having to develop new modem drivers, by translating Unet datagrams to UDP/IP datagrams, tunneling them through the IP network, and translating them back to Unet datagrams at the other end.

7.1. The UdpLink agent

The UdpLink agent offers the LINK service ( Chapter 21 ) over an IP network.

To see how this works, let us revisit the MISSION 2013 network from Figure 5 . Recall that node 21 was a gateway node with surface expression, and was connected to the Internet via a 3G cellular IP connection. During the experiment, we had no direct acoustic connectivity between nodes 21 and 31, and hence we routed all communication to node 31 via node 28.

Let us consider a scenario where node 31 also has a surface expression and 3G cellular IP connectivity. In this case, it would be nice to have a direct link from node 21 to node 31 via UDP/IP. Let’s see how to set that up.

Fire up the mission2013-network.groovy network simulation (or if you already have it running from the last chapter, terminate and restart it, so that we have no routes in our routing tables). Connect to node 21’s shell and add the UdpLink agent, and setup a route to node 31 via the UDP link:

Node 21: 
> container.add 'udplink', new UdpLink();
> udplink
« UDP/IP Link »

Link protocol over UDP/IP for use over wired/wireless IP networks.

[org.arl.unet.DatagramParam]
  MTU ⤇ 65535
  RTU ⤇ 1450

[org.arl.unet.link.LinkParam]
  dataRate = 0.0

[org.arl.unet.link.UdpLinkParam]
  advertise = 30
  broadcastAddress = 192.168.1.255
  monitorTimeout = 200
  port = 5100
  retries = 2
  timeout = 0.5

> addroute 31, 31, udplink
OK
> routes
    uuid      to nextHop         link reliability hops metric enabled
---------------------------------------------------------------------
  dhlx8t      31      31      udplink        true    1    0.0    true

Similarly, connect to node 31’s shell and add the UdpLink agent as well as a route to node 21 via the UDP link:

Node 31: 
> container.add 'udplink', new UdpLink();
> addroute 21, 21, udplink
OK
> routes
    uuid      to nextHop         link reliability hops metric enabled
---------------------------------------------------------------------
  lbouxd      21      21      udplink        true    1    0.0    true

Go back to node 21’s shell and see if you can communicate to node 31 via the UDP link:

Node 21: 
> ping 31
PING 31
Response from 31: seq=0 rthops=2 time=27 ms
Response from 31: seq=1 rthops=2 time=5 ms
Response from 31: seq=2 rthops=2 time=4 ms
3 packets transmitted, 3 packets received, 0% packet loss

> ack on
> tell 31, 'hello'
AGREE
remote >> RemoteSuccessNtf:INFORM[RemoteTextReq:REQUEST[to:31 text:hello ack:true]]

and on node 31, you’ll see:

Node 31: 
[21]: hello

You’ll also notice that the communication is much faster, since the UDP/IP latency is low and data rate is much higher.

7.2. Multilink routing

When we added the UdpLink agent in the last section, we set up static routes manually on both nodes. Let’s delete these routes on both nodes:

Node 21, 31: 
> delroutes

Now, let’s see what the route discovery agent does when we ask it to discover routes for us:

Node 21 
> rreq 31
OK
> routes      (1)
    uuid      to nextHop         link reliability hops metric enabled
---------------------------------------------------------------------
  w7iayp      31      31      udplink        true    1    0.0    true

> routes      (2)
    uuid      to nextHop         link reliability hops metric enabled
---------------------------------------------------------------------
  w7iayp      31      31      udplink        true    1    0.0    true
  6gji1z      22      22       uwlink        true    1    0.0    true
  8zhn5v      28      28       uwlink        true    1    0.0    true
  mjhfaw      31      28       uwlink        true    2   -1.0    true
  fj4g2j      34      34       uwlink        true    1    0.0    true
  2r1ymj      28      22       uwlink        true    2   -1.0    true
  ii73zj      31      22       uwlink        true    3   -2.0    true

> trace 31    (3)
[21, 31, 21]
1 Checking routes within a few seconds after the rreq , we see that the route via the udplink is discovered very quickly.
2 After a few minutes, we see that additional acoustic routes are also discovered (your routes may vary, as the route discovery is a probabilistic process).
3 The route used for data transfer is the single-hop udplink route to node 31 and back.

Note that the route discovery resulted in 3 routes to node 31 in this case. The first one is a single-hop UDP ( udplink ) route. The second one is an acoustic route (using uwlink ) via node 28, and the third one is a 3-hop acoustic route via node 22. We can see that the metric for the 2-hop and 3-hop acoustic routes is lower than that of the UDP route, and so the UDP route is used for data transfer. The metric is computed based on a combination of number of hops and the packet loss on a route.

You can check the routing table on node 31:

Node 31 
> routes
    uuid      to nextHop         link reliability hops metric enabled
---------------------------------------------------------------------
   v5lej      21      21      udplink        true    1    0.0    true
  uxl8yr      28      28       uwlink        true    1    0.0    true
  bvsu21      21      28       uwlink        true    2   -1.0    true
  9q9x91      34      34       uwlink        true    1    0.0    true
  vvzke2      21      34       uwlink        true    3   -2.0    true

We see 3 routes (direct/ udplink , via node 28/ uwlink and via node 34/ uwlink ), and the route with the largest metric is still the udplink direct route.

<<< [Routing in larger networks] [Interfacing with UnetStack] >>>