In-band interference doesn't seem to affect SINR

[lemon-lyman]

Goal

Simple jamming demonstration with 3 nodes. Node 1 sends to Node 3 and a short while later Node 2 also starts sending to Node 3 (jamming).

Expected behavior

I would expect the SINR to drop to around 1 once Node 2 also starts sending since Node 2 and Node 1 have identical settings. The rxpower of Node 2 and Node 1 should be the same at Node 3 and Node 1 should be counted as noise in the calculation of SINR between 2 and 3 and vice versa with Node 2's signal in the calculation of SINR between 1 and 3.

Actual behavior

I've paired down our use-case as best I could into the script at the bottom. I realize it contains some non-EMANE code but I believe the central issue is EMANE. I hope the other stuff is clear enough.

Each node wrapper uses the control port and the method described in this question to keep a log of SINR_avg and the instantaneous SINR between itself and every other node. After running the script, here are those SINR logs:

Once Node 2 starts also sending to Node 3, the SINR betweeen 3->2 and 3->1 doesn't really change, as expected.

I've tried this on all three noisemode settings with the same results. I've verified that my instantaneous calculation of the SINR works in a separate example where nodes are moved around and the instantaneous SINR reflects the new positions.

Edit for clarification: The "sending" is done using the tx.py script which is triggered by CORE. It uses the Python socket library to send packets between nodes. I've verified that these packets use the OTA channel and that they are received on the other side.

Script:

import subprocess
import time
import logging
logging.basicConfig(level=logging.DEBUG)

from core.api.grpc import client
from core.api.grpc.core_pb2 import Node, NodeType, Position, SessionState
from core.emane.rfpipe import EmaneRfPipeModel

from wrappers import EST_Node

#################################################################################################
######################################### CORE setup ############################################
iface_helper = client.InterfaceHelper(ip4_prefix="10.0.0.0/24", ip6_prefix="2001::/64")
core = client.CoreGrpcClient()
core.connect()
response = core.create_session()
session_id = response.session_id
core.set_session_state(session_id, SessionState.CONFIGURATION)
#################################################################################################

#################################################################################################
##################################### configure CORE nodes ######################################
emane_id = core.add_node(session_id,
                         Node(type=NodeType.EMANE, position=Position(x=0, y=0), emane=EmaneRfPipeModel.name)).node_id

node_ids = []
est_nodes = []
positions = [Position(x=0, y=0),
             Position(x=0, y=0),
             Position(x=100, y=0)]
for pos in positions:
    n = Node(type=NodeType.DEFAULT, position=pos)
    n_id = core.add_node(session_id, n).node_id
    node_ids.append(n_id)
    logging.debug(f"Created node {n_id}")
    est_nodes.append(EST_Node(n_id, n_id))

for n_id in node_ids:
    iface = iface_helper.create_iface(n_id, 0)
    core.add_link(session_id, n_id, emane_id, iface)
#################################################################################################

#################################################################################################
##################################### configure EMANE nodes #####################################
# core.set_emane_config(session_id, {"eventservicettl": "2",
#                                    "otamanagerloopback": "True"
#                                    })

emane_config = {"datarate": "18446744073709551614",
                "noisemode": "all",
                "propagationmodel": "freespace",
                "txpower": "100"}
[core.set_emane_model_config(session_id, n, EmaneRfPipeModel.name, emane_config) for n in node_ids]

core.set_emane_model_config(session_id, emane_id, EmaneRfPipeModel.name, emane_config)
#################################################################################################

core.set_session_state(session_id, SessionState.INSTANTIATION)
logging.debug(f"Instantiated")

# Transfer node_scripts and open EMANE control port
for n in est_nodes:
    n.open_control_port()
    subprocess.run(f"cp -R ../node_scripts /tmp/pycore.{session_id}/CoreNode{n.core_id}.conf/", shell=True, stdout=subprocess.PIPE)

#################################################################################################
##################################### begin sending process #####################################
for _ in range(5):
    [[n1.get_SINR(n2.emane_id) for n2 in est_nodes if n1 != n2] for n1 in est_nodes]
    time.sleep(1)

print(f"Started sending {est_nodes[0].core_id} -> {est_nodes[2].core_id}")
core.node_command(session_id, est_nodes[0].core_id, f"python3 node_scripts/tx.py 10.0.0.4 0.001 10000", wait=False)
for _ in range(5):
    [[n1.get_SINR(n2.emane_id) for n2 in est_nodes if n1 != n2] for n1 in est_nodes]
    time.sleep(1)

print(f"started sending {est_nodes[1].core_id} -> {est_nodes[2].core_id}")
core.node_command(session_id, est_nodes[1].core_id, f"python3 node_scripts/tx.py 10.0.0.4 0 100000", wait=False)
for _ in range(5):
    [[n1.get_SINR(n2.emane_id) for n2 in est_nodes if n1 != n2] for n1 in est_nodes]
    time.sleep(1)
#################################################################################################

[n.close_control_port() for n in est_nodes]

[sgalgano]

RF Pipe is very simple. It does not handle in-band (same waveform) interference and does not implement a channel access protocol. Only the outofband noise mode is valid for this model. If you want to use RF Pipe and see jammer impact, introduce jamming from another waveform or another RF Pipe network with a different subid, or use emane-jammer-simple.

[lemon-lyman]

Hey, thanks so much for the response!

So from your comment I tried two things:

1. Giving the sending nodes (nodes 1 & 2) different frequencies. One matched that receiving node (node 3) and one didn't. This just resulted in the outofband node not getting any messages through to the receiving node, but it didn't have the desired effect of decreasing the SINR.
2. I tried a similar thing with setting different subid's on nodes 1 & 2 and it had the same effect. One node didn't get any messages through, but still the same SINR.

noisemode=outofband for these new trials

Do I need to change any settings on the receiving node for this interference to show up?

[patelkb]

Try this:

1. Assign the same frequency to all 3 nodes.
2. Set the subid for nodes 1 and 3 to be the same and for node 2 to something else.
3. Have node-2 blast traffic at node-3 at a rate that is inline with the datarate setting so node-2's is on the channel all of the time or close to it. This will make Node-2 seem like a continuous tone jammer, which is what the simple jammer actually allows you to do.

Observations:

1. If the RxPower from Node-1 is higher at Node-3 than from Node-2, you should see positive SNR values and packets will get through based on the PCR curve you are using for the RF-Pipe model.
2. If the other way, you will see a negative SNR and won't see any packets from Node-1 make it through at Node-3 if you didn't update the default PCR curve to support negative SNRs.
3. Packets from Node-2 are just for noise/interference so those should not make it through at Node-3. This is what the different subid is for.

regards

kb

Kaushik B. Patel Adjacent Link LLC

On 5/6/21 11:55 AM, Nick West wrote:

Hey, thanks so much for the response!

So from your comment I tried two things:

1. Giving the sending nodes (nodes 1 & 2) different frequencies. One matched that receiving node (node 3) and one didn't. This just resulted in the outofband node not getting any messages through to the receiving node, but it didn't have the desired effect of decreasing the SINR.
2. I tried a similar thing with setting different subid's on nodes 1 & 2 and it had the same effect. One node didn't get any messages through, but still the same SINR.

noisemode=outofband for these new trials

Do I need to change any settings on the receiving node for this interference to show up?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/adjacentlink/emane/issues/196#issuecomment-833635262, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPLXM25VDJ4AOGJN5I7VPLTMK3XBANCNFSM44HHD3IA.

[lemon-lyman]

Thanks for the suggestion.

After setting up as you describe, I ran the script again with the same unexpected result: No effect on SINR. However, if I tcpdump the traffic I notice that the packets from node 1 (different subid) aren't being sent to the OTA channel. Normally, when all subid's are the same, tcpdump shows thousands of messages from nodes 1 & 2 being uploaded to the OTA channel (labeled as 172.16.0.2 and 172.16.0.3 here due to CORE's different indexing system) However, when I change the subid of node 1 to something different, almost no traffic gets uploaded to the OTA channel from node 1. Node 1 still thinks its correctly sending the packets. I checked the logs on node 1 and the python socket library is throwing no errors.

[sgalgano]

It is probably ARP. If you don't have a node to respond, you should disable ARP or statically populate your ARP cache.