Underwater Networks Handbook

All agents supporting the PHYSICAL service must also support the DATAGRAM service ( Chapter 14 ).

The physical layer in UnetStack typically supports 2 logical channels (3 if JANUS is supported). The CONTROL channel provides low-rate, robust communication that allows exchange of small amounts of control information in the network. The DATA channel is a usually a higher rate communication link, but may require tuning to operate well in various environmental conditions.

Fire up the 2-node network simulation and connect to node A’s shell. If you simply type phy , you can explore the physical layer parameters for the node:

The phy.MTU and phy.RTU parameters tells us the maximum and recommended amount of user data that can be transmitted in a single frame (56 bytes in this case) respectively. This is based on the DATA channel, as we will see shortly, since DatagramReq are fulfilled using the DATA channel. The PhysicalParam parameters provide us information on whether the channel is busy, transmission power levels supported, receiver sensitivity, and propagation speed of the signal (e.g. speed of sound for underwater modems). The phy.time parameter is a microsecond resolution clock that is used to timestamp all physical layer events such as frame transmission, reception, etc.

We can dig deeper into the parameters for the CONTROL and DATA channel separately:

Here are a few important parameters to take note of:

In the previous section, we explored several parameters from a simplified simulated physical layer. Next let’s look at a real modem. If you are lucky enough to own one with UnetStack on it, you can connect to it’s shell now. Otherwise, we can use Unet audio SDOAM as our test modem:

On the web shell for the modem:

For brevity, we have omitted the baseband service and scheduler service parameters in the listing above. Even then, there are many parameters that allow you to configure the SDOAM. We cannot cover each parameter in detail here, but we encourage you to explore the help pages for the parameters by simply typing help phy. followed by the parameter name.

Further, let’s look at the indexed parameters for the CONTROL channel:

Again, we cannot cover all the parameters in detail here, but will draw your attention to a few important ones. You see that the modulation for the CONTROL channel is set to 'fhbfsk' (frequency-hopping binary frequency shift keying). Depending on your modem, different modulations may be supported. Once a modulation scheme is chosen, you see additional modulation-dependent parameters. In this case, these are the org.arl.yoda.FhbfskParam parameters such as fmin , fstep , hops , chiplen , tukey , etc. These parameters allow you to control the modulation’s frequency band, number of hops, chip duration, windowing, etc.

The preamble parameter determines a detection preamble that is transmitted before each frame. This is used by the receiving modem to determine the start of a frame. The threshold parameter controls the detection probability and false alarm rate for frame detection. A lower threshold will improve detection probability, but increase false alarm rate.

If the test flag is set on the transmission and reception modems, each transmit frame is filled with known test data. This allows the receiving modem to compute the bit error rate (BER), even when the frame has too many errors for FEC to be able to correct.

If you have two computers with speakers and microphones, you could run Unet audio on both, and communicate between the two. If you happen to have only one computer handy, do not worry — we can get one Unet audio instance to transmit and receive at the same time. This is full-duplex communication!

On Unet audio shell, enable full-duplex operation and try a transmission (you should be able to hear it from your computer speaker!). Your output might not look exactly the same, but let’s go over all the notifications we got and see if we can understand all of them:

To get rid of the false alarm on the DATA channel, we could either increase the detection threshold or turn off the detector completely ( phy[DATA].threshold = 0 ). For now, we’ll do the latter. Let’s also turn on the phy[CONTROL].test flag so that we can measure communication performance in terms of BER. To measure BER before error correction, we also need to turn off phy[CONTROL].fec :

Now we can make 10 transmissions, 2 seconds apart, and watch the BER of the received frames:

For brevity, we have omitted the TxFrameStartNtf and RxFrameStartNtf messages. We see that no bits were in error, out of 144 transmitted bits. We had perfect communication, even without FEC! This is not surprising since the speaker and microphone are very close (and hence good signal-to-noise ratio), but real channels are rarely so forgiving. You can try this between 2 computers, and things may not be as rosy.

Feel free to play around with the parameters of the modulation scheme and try transmissions to get a feel for how the parameters affect communication performance. Since your transmission and reception modems are the same, you only need to set the parameters once! In real life, you’ll need to set the same parameters on all modems in your network.

To explore timed and timestamped transmissions, let’s go back to our 2-node network simulation. On the shell for node A:

We see that the phy agent supports the TIMESTAMPED_TX and TIMED_TX optional capabilities. Let us try them out. On node B:

Going back to node A, send a timestamped frame:

We see that the frame was transmitted at time 2489196375 (when you try this, the time will of course be different). You should see the RxFrameNtf for this frame on node B:

Note that the RxFrameNtf now has an additional txTime field that’s populated, and the timestamp in there is the same as the txTime on node A’s TxFrameNtf . The frame was timestamped before transmission, and transmitted at exactly the intended time.

Sometimes you may not need to transmit a timestamped frame, but you do want the frame to be transmitted at a specified time. On node A:

If you check node B’s shell, you’ll find the corresponding RxFrameNtf , but it will not have a txTime field, as the frame transmitted was not timestamped.

If you’re familiar with Ethernet network interface cards, you may have come across promiscuous mode . In this mode, the network card receives all packets that it hears, not just the ones that are addressed to the node. Agents providing the PHYSICAL service essentially do this continuously, but they send the notifications for frames intended for other nodes on a special sub-topic called SNOOP.

With the 2-node network simulation, let’s first only subscribe to the phy agent’s topic on node B:

From node A, transmit a frame to node B and to node C (node C does not exist in this network):

On node B, you’ll find that it receives the RxFrameStartNtf for both transmissions, but only the RxFrameNtf for the transmission addressed to node B:

The RxFrameStartNtf is sent when a frame is detected. At that point in time, the agent has no idea whom the frame is intended for, because the frame contents have not yet arrived. Only when the frame is received and decoded does the agent know the destination address. Seeing that the second frame was intended for node C, node B does not report a RxFrameNtf for it.

If you were interested in snooping conversations between other nodes, you could subscribe to the SNOOP topic on node B:

Now try transmitting another frame from node A to node C. On node A:

Now you’ll see on node B that the corresponding RxFrameNtf is received:

The to address of 74 corresponds to host('C') , but the frame is available for agents on node B through the SNOOP topic.