You are here

NPR (New Packet Radio) Available`

31 posts / 0 new
Last post
K6AH
K6AH's picture
NPR (New Packet Radio) Available`

Just ordered a pair of F4HDK's NPR-70 70cm TCP/IP Data Modems (fully assembled for $80 ea) and DMR amplifiers ($140 ea) which I intend to use to gain access to the SoCal AREDN network from my house (it's in a bit of an RF hole). They come from China, so I expect 2-3 weeks delivery.  

https://www.elekitsorparts.com/product/npr-70-modem-by-f4hdk-new-packet-radio-over-70cm-band-amateur-radio-packet-radio 

Andre, K6AH
 

N3WTT
Will be following

I find this interesting let us know how it works?

F4HDK
New Packet Radio

Thank you Andre!
I'm the inventor of New Packet Radio (NPR).

There are lots of news about my project.
Reminder, all info is here: https://hackaday.io/project/164092

A Chinese partner is now selling modems, assembled or kits, world-wide.
Price is low : 80$ fully assembled, with aluminum enclosure.
https://www.elekitsorparts.com/product/npr-70

I have improved the firmware, it's more stable, and it now allows the optional "FDD mode" (Frequency Division Duplex).
With this feature, you can use the Master (=repeater) in duplex mode, with 2 modems (TX/RX) and a RF duplexer. The frequencies are different between uplink (from Clients to Master) and downlink (from Master to Clients). Clients are half duplex, with one single modem, switching very fast (300us) between uplink and downlink frequencies. The main goal is to put NPR master on tower where there is already a duplex repeater (FM or DMR or D-Star...), without interference between the 2 repeaters.
Check all the documentation on hackaday for more details : "Introduction", and "Advanced user guide".
The new firmware is also on hackaday of course.

Finally, I have written an article for "IEEE spectrum"; It's currently on the web, and it will be on the paper version in a few days. I hope it will bring some advertisement to my project, and to the modern amateur radio movement.
https://spectrum.ieee.org/geek-life/hands-on/build-a-longdistance-data-network-using-ham-radio

If you have any question, just ask me.

73,
Guillaume F4HDK

K6CCC
K6CCC's picture
Where will you be pointing?

Andre, just wondering where you will be pointing your NPR link?  One of my concerns (in general) is that 434 MHz (the frequency referenced in the ieee article) is heavily used for ATV in many areas.  Here in southern California, that frequency is used as an input for several ATV repeaters.
 

F4HDK
Frequency :

@K6CCC
Have you read the documentation on my hackaday page?  https://hackaday.io/project/164092
You should read at least the "Introduction" document, and then if you have enough time the "advanced user guide".

Of course, the frequency can be tuned in the whole range 420-450MHz.

Maybe the IEEE article is not clear, sorry. 434MHz is only the frequency for the ISM band.

73,
Guillaume F4HDK

K6CCC
K6CCC's picture
No, I had only read the ieee

No, I had only read the ieee article.  My concern is that a lot of the ISM devices are not at all frequency agile.  They are 434 or nothing.  One other question about these.  What is the bandwidth?  That is not mentioned in the ieee article.
 

F4HDK
please read the documentation

Once again, please read the documentation on the hackaday site.
There is lot of information there

https://hackaday.io/project/164092


You should read at least the "Introduction" document, and then if you have enough time the "advanced user guide".

If you don't find information you request, just ask me.

73,
Guillaume F4HDK

K9CQB
K9CQB's picture
We're doing it here as well in Northern Virginia

Andre, 
K-Jam (KE2N) and I each built 3 of these the hard way. Thank you for sending out the link for the new website that is selling both the kit ($69ea ) and the fully assembled version ($79ea), but the fully assembled version was bought out immediately. It will be in stock again in 2 weeks. 

I found a cheaper source for the TDMA amplifiers for only $90 on eBay:
AMP‑U25D - UHF (+DMR) Amplifier 400-480MHz, 20-40W Output 2-6W BTECH AMP T2 ($90)
https://www.ebay.com/itm/AMP-U25D-UHF-DMR-Amplifier-400-480MHz-20-40W-Ou...

I have not gotten my nodes installed yet. I am going to pair a Raspberry Pi with each of these modems to manage services. One of the slave models will also have a LoRa-mesh hat on it for future LoRa management connectivity. This node will also be connected to an AREDN 5GHz node. Here is a photo:

-Damon K9CQB

Image Attachments: 
K3PGM
K3PGM's picture
Ditto in Delaware

Andre:

Here in Delaware (AKA the Second Flattest State in the Union) we're very interested in doing something similar. I managed to order three of the NPR-70 modems to experiment with connecting two sites (one of them my house) to our mesh infrastructure. With flat terrain and 80-foot trees everywhere, practically everyone in Delaware is "in a bit of an RF hole" at SHF. In fact, to date our backbone sites outnumber our end users because making connections on any of the AREDN-supported bands has proven very difficult. If we could make some of those connections with NPR, I predict very rapid uptake of that technology here.

Unfortunately, I'm not sure how best to match the NPR networking model to the application. Implementing the "LAN" and "WAN" use cases described a few months ago by Joe AE6XE in another thread is straightforward, but it seems to me that some variant of his "DtdLINK" use case is what we really want, and I haven't quite worked out how to do that. The difficulties I see include the fact that the DtD interface has a statically assigned /8 address, which doesn't fit the NPR addressing model, and that any site with more than one node is going to have lots of redundant OLSR broadcasts that really shouldn't be flooding the NPR link.

You could, of course, just set up the NPR modems as WAN connections and open a tunnel across them, assuming you don't mind the extra overhead and can disable encryption, but there should be a better solution.

One approach might be to add, on just one node at each site, an additional virtual interface just for DtD over NPR, with its address assigned by DHCP from the NPR pool. Put that interface and the NPR modem on their own VLAN, and set a high link cost on that interface so it's only used if no better route is available. But that's just my first thought; perhaps there's a simpler way?

Thanks and 73,
Paul, K3PGM

F4HDK
NPR and AREDN

Hello Paul,

Unfortunately, I'm not sure how best to match the NPR networking model to the application. Implementing the "LAN" and "WAN" use cases described a few months ago by Joe AE6XE in another thread is straightforward, but it seems to me that some variant of his "DtdLINK" use case is what we really want, and I haven't quite worked out how to do that. The difficulties I see include the fact that the DtD interface has a statically assigned /8 address, which doesn't fit the NPR addressing model, and that any site with more than one node is going to have lots of redundant OLSR broadcasts that really shouldn't be flooding the NPR link.

I've not understood what DtdLink is, sorry.
Could you please discribe more precisely where do you think that there will be problems about NPR links inside an AREDN network?
My knowledge about AREDN is almost zero... I don't know the technical constraints of the AREDN.
Do you have a concise documentation?
There seems to be VLANS, OLSR, but I don't find a clear overview. Only user guides, which do not talk about the underlying details...

You could, of course, just set up the NPR modems as WAN connections and open
a tunnel across them, assuming you don't mind the extra overhead and can
disable encryption, but there should be a better solution.

In my opinion, NPR is mainly designed for "access" network, "last mile" (could be dozens of miles of course). Connexion from Client to Backbone.  What you call "endpoints" here :  https://arednmesh.readthedocs.io/en/latest/arednNetworkDesign/network_topology.html
Due to very limited datarate of NPR, you should be very careful about chatty protocols. Avoid usage of NPR in backbone. Avoid usage of VPN over NPR, etc...

Once again, if many people request it, I could develop a "full ethernet" mode, it would probably take a few months. But I do want to understand why you would need it.

About the ideas of Joe AE6XE (which I've not understood), I forgot to answer that currently, NPR does not provide "IPv4 broadcast", nor "multicast". Currently, it only carries IPv4 unicast trafic.

73,
Guillaume F4HDK
 

K9CQB
K9CQB's picture
"Full Ethernet" mode, please. It would bring more use cases.

Guillaume,
I would love to have a "full Ethernet" mode. There are several applications we would like to try that would require a bit more that just unicast traffic. We have a lot of highly capable network engineers involved in AREDN and many of them will think of all sorts of cool applications for you NPR if you have a "full Etherent" mode.
I have 3 of your modems and I haven't installed them yet, but I'm testing a lot of data stuff. I will absolutely buy 4-5 more NPR modems (the Funtronics version) once they are back in stock. I'll be buying the fully assembled version as I've already assembled 3 of these things and I think I'm well practiced in it. Here's the website I'm referring to where they are out of stock:
https://www.elekitsorparts.com/product/npr-70-modem-by-f4hdk-new-packet-radio-over-70cm-band-amateur-radio-packet-radio

-Damon K9CQB

K3PGM
K3PGM's picture
Guillaume:

Guillaume:

Thank you very much for your reply, and for your huge contribution to the community!

I don't know the technical constraints of the AREDN. Do you have a concise documentation? There seems to be VLANS, OLSR, but I don't find a clear overview. Only user guides, which do not talk about the underlying details...

One of the AREDN developers could do a better job of answering your question; I'm just a user. But I'll give it a try (and welcome corrections)...

AREDN is focused on emergency communications, with an emphasis on easy, rapid deployment in the field (at a disaster site, say, or an outdoor event such as a race). It is designed to be usable by people who know next to nothing about IP networking, and as such, must be almost entirely self-configuring. In theory, you just flash the firmware, put in your callsign, center frequency, and bandwidth, and you're on the air. The node itself does everything else, including assigning itself a few pieces of the 10.0.0.0/8 address space all AREDN nodes share.

Every AREDN node is a router with four logical interfaces:

  • The radio interface (usually 802.11n)
  • The LAN interface, to which the user connects local resources such as laptops, IP cameras, and VoIP phones
  • The Device-to-Device (DtD) interface, a wired link to other AREDN nodes that do not share a radio frequency
  • The WAN interface, which allows the node to act as a gateway from the mesh to the Internet when a local Internet connection is available

Most node hardware has only two physical interfaces (WiFi and Ethernet), so the LAN, DtD, and WAN logical interfaces appear as separate VLANs on the single Ethernet port. Which of these logical interfaces is in use on any particular node will depend upon the circumstances of its deployment.

If the WAN interface is connected, the node uses DHCP to get an address from the upstream gateway and then acts as a NAT gateway to the 10.0.0.0/8 address space that represents the entire mesh. The other three interfaces all have static addresses automatically derived from one of the node's MAC addresses, without reference to any external entity, since none is known to be available. Again, all these addresses are in the 10.0.0.0/8 space.

When Joe AE6XE described his "WAN use case", what he meant was using an NPR client as the upstream gateway for the WAN interface, with the NPR master somehow connected to the larger Internet.

On the LAN interface, the mesh node acts as a DHCP and dynamic-DNS server, handing out addresses from the small pool it reserved for itself out of the 10.0.0.0/8 mesh address space. In the normal configuration it does not provide NAT, so all LAN resources are visible from anywhere on the mesh. For example, a PC on one node's LAN can directly connect to an IP camera on another node;s LAN.

When Joe AE6XE described his "LAN use case", what he meant was placing an NPR master on the LAN of one AREDN node, and connecting one or more LAN resources (such as a PC or IP camera) to one or more remote NPR clients.

Finally, the radio and DtD interfaces both serve to connect nodes to one another. The nodes broadcast OLSR traffic on both interfaces, and olsrd organizes all the nodes that hear one another into a single mesh island. It is common, particularly at backbone sites, to have a number of AREDN nodes operating on different frequencies, all connected together on a common LAN via their DtD interfaces.

When Joe AE6XE described his "Dtdlink use case", what he meant was replacing a subset of those DtD connections with an NPR master and clients, so as to coalesce two or more mesh islands that would otherwise be out of range of one another. Now, I understand that this use case is emphatically not the one for which NPR was designed, but if it could somehow be shoehorned in, it would be of great interest to the AREDN community.

Again, the primary intent of AREDN is emergency communications. Sometimes, deployiing a mesh island in a small area (say, a race course) is enough, but in many cases, enabling meaningful emergency response means erecting a permanent mesh backbone over a large area and training and equipping volunteers to deploy to a field location, set up a local mesh, and connect that local mesh to the backbone for communications to emergency operations centers, hospitals, race organizers, etc.

It's the last part that's the problem: reaching the backbone from the field site. In an actual emergency one might have enough ham volunteers to station a whole chain of relay nodes between the site of the emergency and the nearest backbone site, but real emergencies, thankfully, are rare. In the meantime, it is crucial to motivate those volunteers to equip themselves and train with that equipment sufficiently frequently to maintain readiness. The best way to do that is to make it easy to connect mesh nodes from their own homes where they can integrate them into their normal amateur-radio activities.

In mountainous areas, that's easy: just put a node on your roof and point it at whichever peak has the local mesh relay. But the highest "peak" in Delaware is 134m above sea level, and yes, we do have a tower at that location, but the only ham who can see it directly lives 60m from the tower. Everyone else has at least 20 trees, or an office building, or a low hill in the way.

It is possible to connect two mesh islands via an encrypted tunnel over the Internet; that's how my house is connected. But that doesn't excite very many hams because there's no radio involved. We really need to be able to offer radio-based connections, even if they're slow.

Could you please describe more precisely where do you think that there will be problems about NPR links inside an AREDN network?

The natural way to connect small AREDN mesh islands would be by extending DtD links over some other transport such as NPR. The traffic on DtD links is essentially identical to that over the radio links: a combination of IPv4 unicast datagrams carrying user data between LAN resources and IPv4 broadcast datagrams carrying OLSR updates from the directly connected nodes. The problems I see are:

  • NPR doesn't currently handle IPv4 broadcasts, although I see that there is provision for them in the protocol. All the OLSR traffic is addressed to 10.255.255.255, and that is the single biggest difficulty.
  • All the DtD interfaces have statically assigned IPv4 addresses widely distributed throughout the 10.0.0.0/8 address space.
  • You only want to transport OLSR broadcasts from a single node at each site; the others are redundant.

So, putting an NPR master on the DtD network on the tower isn't going to work. As I suggested in my previous message, you could solve the address-space and redundant-broadcast problems by setting up a fifth logical interface on one of the mesh nodes at each site, making it a DtD-like interface with DHCP-assigned addresses and a high link cost to avoid unnecessary transits of the NPR network.

I'm not sure how we deal with the lack of support for IPv4 broadcasts.

Thanks and 73,
- Paul, K3PGM

F4HDK
Thank you Paul.

Thank you Paul.
I understand much better now.

Have you thought at which modulation/datarate you plan to use NPR? If you plan for example modulation 21, then you will have only 130kbps (sum of both uplink and downlink). That's very little compared to "several Mbps" provided by WiFi-like equipments.
In these conditions, do you really think that it is realistic to use NPR for WAN or DtD links?

I think that you should first give a try with NPR for "LAN access", and only after consider it for other types of links (WAN or DtD).

Other concerns:
 - the OLSR protocol can be quite chatty, if you plan to use NPR for DtD. Have you measured the overhead datarate of OLSR in a point to point DtD link? Such measurement are really necessary before considering DtD over (slow) NPR links.
 - DtD links are pure Ethernet links? Or do they carry VLANs?

If you are really interested about putting NPR links for DtD or WAN, then I could rapidly implement Ethernet, in a quick-and-dirty way, just for point to point topology. If you test it, and if you think that it's useful, then I could code a full Ethernet behavior with "point to multipoint" NPR networks, but it will take more time.

Finally, one question : how many Ethernet addresses would you like one "NPR network" to manage? 50 or 100 could be enough?

73,
Guillaume F4HDK

K3PGM
K3PGM's picture
Guillaume:

Guillaume:

If you plan for example modulation 21, then you will have only 130kbps (sum of both uplink and downlink). That's very little compared to "several Mbps" provided by WiFi-like equipments.
In these conditions, do you really think that it is realistic to use NPR for WAN or DtD links?

Yes, but in an emergency situation you can do a lot with that bandwidth. It's enough to, say, support a few simultaneous G.729 VoIP calls while other users update web forms and send the occasional still image. It's slow compared to WiFi, but not compared to Winlink over 1200 bit/second packet, or worse yet, spelling words one letter at a time over FM phone.

I think that you should first give a try with NPR for "LAN access", and only after consider it for other types of links (WAN or DtD).

We certainly will try that, and there are practical use cases for which that approach would excel, but it doesn't help the specific and important goal of motivating ham volunteers to acquire the hardware and skills needed to set up and maintain mesh networks for emergency communications. For that, they need to be able to connect to other hams as a matter of routine.

A tabletop exercise (such as connecting two 5.8 GHz nodes from one end of your basement to another) is a great way to get started, but if your interest is radio communications and the only way to connect from those nodes to another ham is through tunnel over the Internet, a sense of defeat quickly sets in. And so we have a lot of dejected would-be participants sitting around in this topographically challenging part of the country.

the OLSR protocol can be quite chatty, if you plan to use NPR for DtD. Have you measured the overhead datarate of OLSR in a point to point DtD link?

At this moment, there are 21 AREDN nodes online, with a total of 69 OLSR entries, on the mesh to which I am connected (through the aforementioned depressing Internet tunnel). The unidirectional data rate for OLSR traffic on one point-to-point link, including IPv4 overhead but not Ethernet overhead, is currently 5390 bits/sec. That's not bad by itself, but if we had several clients simultaneously connected via NPR, and the master node were rebroadcasting each client's OLSR packets to all the other clients, we'd have a problem. So perhaps it shouldn't do those rebroadcasts.

If the master did not rebroadcast the clients' OLSR packets, the resulting mesh routing tables would show the master-connected AREDN node as an intermediate hop between each pair of client-connected AREDN nodes. This routing is technically incorrect because traffic between two client-connected AREDN nodes would not actually transit the master-connected node, but it perhaps better represents the reality of the point-to-multipoint topology.

If the master were to transmit a frame to Client ID 0x7F (I know that's not yet implemented), would all the connected clients receive it simultaneously? If so, perhaps the only change necessary to NPR would be to recognize limited (255.255.255.255) or directed (e.g. 10.255.255.255) IP broadcast datagrams coming in on the Ethernet interface, and forward them to Client ID 0x7F on the radio interface.

Finally, we could further reduce the OLSR overhead simply by increasing the interface-specific intervals for OLSR messages.

DtD links are pure Ethernet links? Or do they carry VLANs?

DtD does not carry VLANs. AREDN nodes are pure IPv4 routers, and DtD links are simply IPv4 over Ethernet, with ARP. The only use AREDN makes of VLANs is to separate the LAN, WAN, and DtD traffic that must be stuffed into the single Ethernet port on the mesh device.

If you are really interested about putting NPR links for DtD or WAN, then I could rapidly implement Ethernet, in a quick-and-dirty way, just for point to point topology.

I do not believe raw Ethernet support is required for connecting AREDN via DtD or WAN:

  • The WAN use can be done today; the AREDN node would appear as a single device behind an NPR client, and everything else would happen via NAT. The use case for this configuration would be providing Internet connectivity to a single mesh island at a remote location.
  • For a real deployment, the DtD use case would require the limited implementation of IP broadcast described above.
  • For initial testing, we could work around the lack of broadcasts in NPR by configuring the NPR-connected AREDN nodes to use hardcoded unicast addresses for outgoing OLSR traffic. That approach doesn't work in the general case, but it's a quick way to test feasibility.
  • Increasing the interval between OLSR transmissions on NPR links would allow larger networks. Because NPR-connected mesh islands are unlikely to hop rapidly between different NPR networks, a slower update rate should not impact mesh stability.
  • I'd rather not pay for the overhead of Ethernet framing on the air.

So, my vote for the next NPR feature would be limited IP broadcast support, assuming the approach I outlined above is feasible. I can think of a number of fun things to do with Ethernet-over-NPR, but I currently see it as a lower priority.

Thanks and 73,
- Paul, K3PGM

AE6XE
AE6XE's picture
"my vote for the next NPR


"my vote for the next NPR feature would be limited IP broadcast support, assuming the approach I outlined above is feasible.".

Ditto.

This would support the AREDN dtdlink scenario  on limited size mesh networks.   At some point, with too many nodes on the AREDN network, the OLSR traffic would not leave enough bandwidth for applications to work (mesh chat, etc.).

Joe AE6XE

F4HDK
AREDN : automatic IP assignment inside DtD?

Before trying to implement Ethernet or IPv4 Broadcast, I need to understand the DtD more in details.
How are IP "automatically assigned" in DtD link? (You tell me that the network auto configures itself).
Does it matches the very-specific NPR behavior?

I really insist : the "LAN" usage of NPR is probably the most promising. 2.4GHz or 5.6GHz for backbone (with dozens of Mbps), and 430MHz for "users access". That's what we are doing here in Europe.
The "NPR-client" are already almost auto configurable regarding IP address aspects. If the AREDN router to which an NPR-Master is attached could automatically configure (via scripts) the NPR-Master, then it would probably match your request of using it (the Master) by low-skilled OMs.

73,
Guillaume F4HDK

K3PGM
K3PGM's picture
Re: AREDN : automatic IP assignment inside DtD?

Guillaume:

Again, thank you for taking the time to consider our application and and understand the requirements.
 

How are IP "automatically assigned" in DtD link? (You tell me that the network auto configures itself). Does it matches the very-specific NPR behavior?

Currently, DtD interface addresses are derived by a mathematical transformation on one of the AREDN node's MAC addresses. The resulting IP address can be anywhere in the 10.0.0.0/8 space. Clearly, this addressing scheme is not compatible with NPR. But that's OK, because that's not the DtD interface I propose we use with NPR.

Instead, we would create a second DtD interface on one AREDN node at each site; that interface would be dedicated to connecting to the NPR modem. The first DtD interface would retain its existing function of linking to other AREDN nodes at the site, and would not connect to the NPR modem.

The IP address of the second DtD interface would be assigned via DHCP, for compatibility with NPR:

  • At a client site, the client NPR modem would be configured with client_req_size=1, and the modem would hand out its one address to the second DtD interface of the directly attached AREDN node.
  • At the master site, the second DtD interface would again be directly connected to the master NPR modem. Because the master modem is not a DHCP server, the DtD interface address would be either statically configured or assigned by another DHCP server at the site.

 

I really insist : the "LAN" usage of NPR is probably the most promising.

You're right. I agree that the LAN-over-NPR configuration would yield the best performance for the end user. We will certainly experiment with this configuration,and happily deploy it wherever it fits.

Nevertheless, we also need the DtD-over-NPR configuration, even if it performs substantially worse, for two specific use cases:

  1. Training and experimentation: a ham's QTH hosts a multi-node mesh island so that ham can experiment with mesh configurations, test new hardware, develop a mesh go-kit, etc. That island also needs access to servers on the larger mesh, which is not within line of sight.

    • Real-world example: I currently have three AREDN nodes on line at my QTH, and half a dozen more on the shelf waiting for other experiments. Currently, I use an Internet tunnel to connect to the rest of the mesh.
    • How NPR would help: I would no longer be dependent upon my Internet connection, and that of the ham at the other end of the tunnel, both being up in order for me to run my own experiments as well as administer the rest of the mesh. Also, Internet tunnels are not ham radio.
  2. Backup connectivity: a mesh island in the field can lose its high-speed connection to the backbone, and thus needs a backup, even if it's slow.
    • Real-world example: At our Field Day site this year, we used a 3G cellular modem to maintain mesh connectivity when the 900 MHz mesh link went offline because of high background noise at the other end.
    • How NPR would help: We wouldn't have had to pay $60 in data charges, or explain to visitors why we were using a cellular modem as part of a ham-radio readiness exercise.

Again, I know that this isn't the use case for which NPR was designed, and performance issues are likely. But I'm convinced a lot of hams in this area, at least, will want to try it. Being able to have your own nodes on the mesh network is fundamentally different, and for many hams more exciting, than connecting their laptops to someone else's network.
 

The "NPR-client" are already almost auto configurable regarding IP address aspects. If the AREDN router to which an NPR-Master is attached could automatically configure (via scripts) the NPR-Master, then it would probably match your request of using it (the Master) by low-skilled OMs.

I really like this idea, and it works for both configurations:

  • For the LAN use case, the AREDN node could emit commands that would configure the NPR master modem to use a portion of that node's LAN address space.
  • For the DtD use case, the AREDN node at the master end could emit commands that would configure the NPR master modem to use a range of addresses adjacent to the statically configured address of the second DtD interface.


73 and thanks again,
- Paul, K3PGM

K9CQB
K9CQB's picture
Great use cases. We are in the same situation.

Paul,
I concur with the requirement of your 2 use cases. A lot of my buddies here in Northern Virginia and I are in the same situation. Where we would use the NPR to connect a 'small-ish' mesh island to the rest of the network.

-Damon K9CQB

KE2N
KE2N's picture
DtD traffic

I have a hunch that the OLSR traffic across the DtD link will be enough to totally swamp a 56 k link.  Does anybody have a measure of what typically flows across a DtD connection between two mesh-lets ?

K6AH
K6AH's picture
Only for small networks

Ken, the proposed use case is only for small networks.  It's usefulness will diminish as the network grows.

Andre

AE6XE
AE6XE's picture
On the southern CA network

On the southern CA network with typically 400+ mesh nodes, I receive about 9 OLSR packets per second at ~1500 byte packet size.   Thus about  13,500 bytes per second or 108kbps.   on a 10MHz channel under 802.11n at slowest possible rate of 3Mbps, this is only 3.6% of the time OLSR is consuming the channel (then my node is transmitting back another ~2 packets a second, so < 5% total channel time).    For running applications on the AREDN network, this OLSR time is not consequential.    An NPR link would be saturated and not able to do any usefull applications.   However, if the mesh size was  somewhere < 100,  an NPR link would start getting in the ballpark of functional (to use meshchat and other low volume traffic apps).

Joe AE6XE

F4HDK
ARP-proxy and routing are not compatible

Hello,

I think we were totally wrong focusing on the problem of broadcasting routing packets within a DtD link over NPR.
The main problem is not "routing OLSR packets"; the main problem is about forwarding "traffic packets". I will explain.

L3 IPv4 routing cannot work at all with ARP-Proxy in the middle. You cannot put routers at both ends of an ARP-Proxy, it will never work.
An ARP proxy totally puts to trash the destination Ethernet address of an incoming ethernet frame. The NPR client (which is ARP-Proxy) can only forward IP packet to its ethernet interface if it founds the destination MAC address (from the destination IP) via ARP, therefore only if the destination IP is "seen" directly by the ethernet interface (no router in the middle).

You just cannot put a router at the "client" side of an NPR network! (of course, you could put a NAT router, but that's not how AREDN works, and what AREDN needs). The "client NPR modem" (which is ARP proxy) will try to find MAC address of the destination IP address (via ARP), but it is not on the same ethernet-network/segment so nobody will answer! The "client NPR modem" will also never find the MAC address of the "next router", because it just doesn't know the IP of the next router. It only knows the destination IP address of a "traffic" IPv4 packet.
And at Master side, you can only put a single router which carries the "default route".

The only way to handle traffic between 2 standard routers (wired via Ethernet) is to handle Ethernet. Doing something else would be, in my opinion, very messy, and very difficult to debug for users/sysadmin.

At "short term", I can propose a very simple implementation: An NPR network will only forward all Ethernet traffic, from clients to Master and vice versa. Ignoring the destination and source MAC addresses. In this way, you will only handle traffic between Master and Clients; you will not be able to handle direct traffic between 2 NPR-clients. Maybe the AREDN router at the Master side can do it, I don't know. This is a "quick and dirty" solution, but I think it's enough for starting to work/test.
Are you OK with that?

For "long term", I will implement Ethernet-MAC address routing (like a switch). But I need to know how many MAC addresses max you plan to have in an ethernet segment (with NPR network in the middle). 30? 60? 100?

K3PGM
K3PGM's picture
Re: ARP-proxy and routing are not compatible

Guillaume:

Yes, you're right. Another way to say it is: because NPR uses a point-to-multipoint architecture, but has no routing information, it must depend upon the next-hop routing decisions made by the directly connected routers. The Ethernet destination address is, indeed, the most natural way to convey those decisions on an Ethernet link. Alternative pure-IP solutions include IP source routing (LSRR) or IP-IP encapsulation (tunneling), but those approaches are awkward and would require additional support in the AREDN nodes.
 

At "short term", I can propose a very simple implementation: An NPR network will only forward all Ethernet traffic, from clients to Master and vice versa. Ignoring the destination and source MAC addresses. In this way, you will only handle traffic between Master and Clients; you will not be able to handle direct traffic between 2 NPR-clients. Maybe the AREDN router at the Master side can do it, I don't know.

Well, the client-to-master traffic would work, and yes, the AREDN router at the master end would correctly route the traffic between client nodes. But if "ignoring the destination and source MAC addresses" means you would effectively treat all master transmissions as broadcasts, I think we would get broadcast amplification (self-inflicted Smurf attack) if we have more than one client.

Through OLSR, the node at the master end would learn all of the client routes, and the nodes at the client ends would learn that the node at the master end is the next-hop route for everything not behind that client node. One of the characteristics that distinguishes mesh routing from normal IP routing is that routing a packet out the same interface on which it came in is not considered an error. Thus, any client node that receives a datagram that should have gone to a different client node will dutifully forward that datagram back to the master node, which would then broadcast it again.
 

This is a "quick and dirty" solution, but I think it's enough for starting to work/test. Are you OK with that?

Yes, it's certainly good enough to test with a single client.

I would also prefer that you not strip the VLAN tag. Even though only traffic from a single VLAN would be present, retaining the tag means we need not un-tag and then re-tag the traffic at each end to get it into the AREDN node.
 

For "long term", I will implement Ethernet-MAC address routing (like a switch). But I need to know how many MAC addresses max you plan to have in an ethernet segment (with NPR network in the middle). 30? 60? 100?

For the AREDN DtD use case we only need 9 MAC addresses (master + 7 clients + broadcast) because we would arrange for the NPR-specific DtD VLAN to be isolated from other traffic at each site. And like WiFi, you could treat all multicasts as broadcasts.

One nice feature would be a configuration option that allows you to specify a single VLAN tag to forward; all traffic not having that specific VLAN tag would be dropped. That way, installations with just one AREDN node could put the node, NPR modem, and local resources all on an unmanaged switch. You could also construct a relay station consisting of one AREDN node, one NPR modem, a power supply, some cables, and an antenna.

Thanks and 73,
- Paul, K3PGM

K9CQB
K9CQB's picture
Shall I send you a few AREDN nodes?

F4HDK,
Do you need a couple AREDN nodes? If you had 2 nodes of one band, 2.4GHZ for example, that were linked via RF with one of them connected to a NPR-Master running 400MHz RF to an NPR-Client, then a 5GHz node connected to that client NPR, and a second 5GHz node across the room linked via 5GHz RF, you could experiment a lot with AREDN interconnectivity. 
Just let me know how I can help.

-Damon K9CQB

F4HDK
Thanks, but not enough free time

Thanks Damon for the proposal.
I won't have time to test NPR in all possible use cases. I let you (the AREDN community) test that, and give me feedback.
If I implement the "raw Ethernet over NPR" feature, then it will very probably work with AREDN DtD, with the mentioned limitations (datarate).

I don't know when I will code this feature. I will let you know.

73,
Guillaume F4HDK

K6AH
K6AH's picture
CBP Delay...

Argh!  It appears Customs has my shipment of NPR radios.  The amplifiers I ordered sailed right through.  I've been told by Customs that holds can take up to 90 business days to inspect and clear.  Not a lot I can do in the mean time.  I'd be interested in hearing comments from others who have ordered these from www.elekitsorparts in China.

Andre, K6AH
 

K3PGM
K3PGM's picture
Probably the same state...

The 4PX tracking information for mine has read, "Shipment arrived at airport of destination country" for almost a week. It's possible that they just stopped tracking it at that point, or it might be the same situation as yours. Sigh...

- Paul, K3PGM

K6AH
K6AH's picture
I'm beginning to wonder if...

ours might be the first NPR-70 devices to cross customs.  They could be checking everything from contraband to FCC type-approvals... the latter strikes me as a potentially major problem.  They call it a "modem" but it's really a transceiver.

Andre

K6AH
K6AH's picture
Just released by CBP

The shipment status now indicates the package has been released to DHL.  So fears appear to be unfounded.  Should be here in 2-3 days.
 

K3PGM
K3PGM's picture
Re: Just released by CBP

Mine, too. As of this morning, it's in transit from DHL to USPS, so I might even see it this weekend. Yay!

KE2N
KE2N's picture
NPR on the bench

>> Maybe the moderator could start  a new thread for discussion of NPR usage with AREDN ?

anyway - mine arrived and, after a little head scratching, (rats I had to read some of the instructions) I have the pair talking to each other on the bench.  Setting up a meaningful data link test will require a little more head scratching.

basics (get the Assembly and Programming Guide and the Advanced User Guide)
1) download and install the required USB/serial driver on your PC
2) plug in the NPR USB connection - at appears as a removable drive (like an OpenSpot) 
3) download and install the required firmware update for the microcontroller
4) download the application .bin file and drop it into the removable drive mentioned above

Then you need to edit the configuration to put in your call sign, select a FCC-legal modulation and turn on the transmitter.
>> putty.exe works very well for a serial connection (which you will need at some point)

Note -> do not plug the unit into your home LAN.  It has a DHCP server that will start stealing all your devices and putting them on 192.168.0.x.

Attached PNG shows the close-in spectrum of the un-amplified signal running modulation 20. Looks fine to me. You will have to stay 100 kHz away from any FM activity and probably 200 kHz away from weak signal activity. Maybe more when an amplifier is added. (I note that the Spectrum Occupancy document on the web page is for modulation scheme 21 which has a 100 k symbol rate - this is in excess of present FCC regulations for data) and twice the width of what is shown below.

Image Attachments: 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer