WIP: Add multichannel operation with explicit channel selection

[hagau]

This adds multichannel operation with explicit channel selection, needed for riebl/artery#20.

This adds a LinkTable integrated into LocationTable for tracking link layer addresses associated with a GeoNetworking address.
LocationTableEntry has been extended with a LinkInfoTable to support tracking information pertinent to a link, such as packet data rate.
As the title suggests, this does not support channel offloading.

Missing:

• tests
• proper error handling
• callbacks upon GeoNetworking/link layer address change due to address collision

[riebl]

I am a little bit worried about the backward compatibility of these changes. By default, Vanetza shall comply to the latest published standards. Does geonet::Router behave any different now when we assume CCH wherever a channel needs to be given?
What is the advantage of modifying geonet::Router heavily over having one router per channel?
Do we have to detect duplicate packets across channels?

[hagau]

@riebl Those worries kept me up at night ;)

I've tried hard to keep as much as possible to the latest standard, except:

• a GeoNetworking address' MID is no longer necessarily bound to the link layer address of the NIC, but since they are handled independently, they can be. (The implementation in WIP: Add multichannel support artery#20 uses the link layer address of the NIC that's tuned to CCH as MID)

I'm not aware of any other deviation from the standard.
Of course, that needs to be thoroughly tested before merging to assure this is actually true.

I had tought about using one geonet::Router per channel, which I initially tought to only require adding a switch to disable beaconing for non-CCH channels. But then the strict dependency of the GeoNetworking address (GNA) on the link layer address necessitates multiple GNAs per station. (Decoupling the MID from the link layer might be a less invasive change than this PR.)
A few more arguments against multiple geonet::Router I noticed while implementing the approach in this PR:

• The LocTe would have a lot of redundant LocTEs, each channel would have a different LPV for a given station.
• For channel offloading the information in the LocTEs is neccessary, so either that needs to be available one layer above geonet::Router or offloading needs to be implemented in the geonet::Router.

I've not thought about duplicate packet detection across channels, so this needs some work. Right now it deduplicates across channels. I'm not sure whether we want this; probably not without offloading.

[riebl]

Regarding MID, possibly it is favourable to have the same MID/GNA on each channel even in a multi-transceiver configuration when we think of one pseudonym (identity) per station. I cannot give an authoritative answer on this, however.

Of course, with distinct Location Tables per channel there will be some redundancy of LocTEs. But even when we track only the most recent LPV of each station in one shared Location Table, how do we know that this station is still reachable on a particular channel? Maybe it is switching periodically between service channels? Maybe it is beneficial to keep beaconing enabled on all channels (some stations may be operate only on a single channel)?
Is the channel <-> transceiver mapping fixed in your system concept?

I haven't fully thought about it yet, but one idea for channel offloading is a cross-router entity which would allow to shift packets between routers. There are two interfacing points: 1) Data requests from upper layers need to be dispatched to the matching router (by ITS AID?) 2) If packet forwarding shall be shifted to another sibling router, there needs to be an "forwarding dispatcher". Such an entity would stick to the current router by default (just as the current behaviour) but may do something more advanced in your system.

[hagau]

One single MID/GNA also simplifies the design a lot, which might be worth the small discomfort of setting all links to the same address :).

Regarding reachability via a specific channel, the LinkInfoTable is a SoftStateMap, so a link that has not been seen recently is dropped, same as in the LocationTable. This of course ignores channel switching.

Looking at itsGnBeaconServiceRetransmitTimer (= 3s), beaconing will in most cases only occur on startup & in low density areas where channel contention is less of a problem. I was thinking since every station has to listen on CCH anyway, there's no point in beaconing on all channels.

[hagau]

@riebl Thanks for your comments! In light of the still open questions, I think it might be beneficial to leave this PR open for future reference and use vanetza as-is for now in riebl/artery#20 with multiple geonet::Router

[riebl]

@hagau Yes, I have just labelled this PR accordingly and keep it open.
At the first glimpse, MCO seems to be almost trivial but there are many pitfalls. Still, thanks for your contribution on the way to MCO in Vanetza :-)