-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: Add multichannel operation with explicit channel selection #60
base: master
Are you sure you want to change the base?
Conversation
I am a little bit worried about the backward compatibility of these changes. By default, Vanetza shall comply to the latest published standards. Does |
@riebl Those worries kept me up at night ;) I've tried hard to keep as much as possible to the latest standard, except:
I'm not aware of any other deviation from the standard. I had tought about using one
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. |
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)? 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. |
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 Looking at |
@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 |
@hagau Yes, I have just labelled this PR accordingly and keep it open. |
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: