Re: short description of GeoNetworking

On Mon, Jul 20, 2026 at 08:36:13PM +0200, Simon Dietz wrote:

Hi Andrew,

quoted

Is there an architecture documentation somewhere?

No really available one, at least not public. The ETSI ITS standard is
public available and there are research papers, but that would be a lot
to read.

Sorry, i was meaning Linux architecture. Something is feeding in GPS
location information. I assume there is some daemon talking to gpsd on
one side, and the kernel and the other? What other user space pieces
are there?

quoted

One of my comments was about routing tables.

I agree that cosine calculations may not belong to the kernel space.
Before we continue talking about routing tables, let me give a short

Description of the GeoNetworking (gn) protocol

GeoNetworking is used in a vehicle2x context where vehicles exchange
position information (and other data in higher protocol layers like
BTP) for use cases like trafic jam notifications, or railroad crossing

BTP?

communication with cars or trains.

gn transmitts packets in various possible 'modes', including:
* broadcast (all recievers in range, like ip)

Hold on. IP broadcast, not L2 broadcast. So if you have a mash, this
broadcast is L2 multi hop, but stays within the same IP subnet.

* single hop broadcast (all recievers in direct range, like ip, if the
  reviever is in the same network and no default gateway is used)

Given the previous definition, this makes no sense. IP broadcast never
leaves the IP subnet. You need to use IP multicast, and an IP
multicast gateway for such packets to go into other subnets. And then
you need PIM or some other multicast routing protocol.

* unicast (one reciever out of range, packet is sent to the closest
  intermediary; only here a routing decision is involved)

Closest intermediary. So the idea is the maximise the number of L2
hops?  That can make sense, assuming the underlying WiFi network is
using different coding rates. A short hop can use a high coding rate,
making the use of air time shorter. If the furthest intermediary was
used, you need to use a lower coding rate, which takes up more air
time.

And only unicast needs routing? So broadcast is dumb flood everywhere,
and the receiver needs to remove duplicates, and not reflood
duplicates. And broadcast uses the lowest coding rate, so giving the
biggest coverage, but takes up the most air time.

gn packets contain a gps position and a geographic target scope, which
can be one of predefined shapes (rectangle, circle, ellipsis) and
dimensions of that shape (radius if circle, length and width if
rectangle). Hosts with a position outside the shape may recieve, e.g.
a broadcast, but drop the packet (because it's out of the target scope)

So the sender does not care about the shape, it is the receiver which
does the filtering. And there is no concept of a receiver which is
outside the shape being able to fill dead spots by transmitting back
towards the shape?

There are location service (ls) requests, which are used to query
nearby hosts for the location of a host out of the sender's own range,
which are answered with ls reply packets.

So this is a flood search? Is the outward path recorded in each LS
request packet as it hops away from the sender?  So when it reaches
the target, the reply can be hop-by-hop unicast back to the requester?

I would suggest to handle them in kernel space and only notify the user
space, if something happens (previously unknown beacon recieved, ls
reply recieved, ...) instead of passing all the beacon and ls packets
to user space.

We generally split policy from mechanical actions. Doing a routing
table lookup is mechanical, and goes in the kernel. The policy of what
to put in the routing table is generally in userspace. If you think
about IP routing, we have a couple of different OSPF versions, BGP,
IS-IS, RIP, EIGRP, etc. Each implement a different policy.

It also seems like there is some scope for experimentation here with
routing. A node at the edge of the shape receiving from a node in the
middle of the shape could consider where its neighbours are within the
same, and set the coding rate for the broadcast based on the unicast
coding rates to pick the highest rate which should work for all
neighbours, so saving air time? And rather than trying to maximise
hops, you could try to find an intermediary somewhere in the middle,
so you balance hops and coding rate/air time?

That sort of experimentation is a lot harder to do in the kernel, it
is more natural to do in userspace.

quoted

There also seems to be a need for location information. How does that
get into the kernel? Is there a daemon for that? Patches to gpsd?

In the first version /proc has been used, after that ioctl; today
netlink generic seems to be the most reasonable option. We used
standard u-blox gps recievers and wrote a little userspace tool to
inject the location information into the kernel space (via ioctl).

So it would be good to include a link to your git repo. We generally
want open user spaces tools. And i would expect a generic solution,
e.g. using gpsd, so any of the GPSes supported by gpds can be used.
However, given the simplicity of the API, this is not a GPU after all,
this is less important.

That brings me to the question, how the ideal interface between user
and kernel space should look like for this module/functionality.

For short term, it should be possible to strip the routing stuff incl.
the cos table from the module and return -EOPNOTSUPP and/or -EINVAL
when using advanced stuff like routing and only support recieving gn
packets and send broadcast and beacon packets. Routing could then be
added in a v2 patch series.

How useful is the stack without unicast?

    Andrew