Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(163)

Issue 11480044: implement WAVE 1609.4 without some important features

Can't Edit
Can't Publish+Mail
Start Review
Created:
8 years, 2 months ago by Tom Henderson
Modified:
8 years, 1 month ago
Reviewers:
Nicola Baldo, Junling Bu, ns-3-reviews
Visibility:
Public.

Description

This code is part of Junling Bu's GSoC midterm review. http://www.nsnam.org/wiki/index.php/GSOC2013WAVE_MAC This patch is to complete 1609.4-2010 standard based on 802.11p to deal with multiple channels operation for vehicular environment. It would build on the previous patch shown here: https://codereview.appspot.com/11685043/ The implemented features are 1) provide a NetDevice with special APIs, 2) allow users to route different packets by different ways, 3) define standard channel coordination mechanism, user can inherit to overwrite for optimization research, 4) provide two simple channel access assignment mechanisms. Because of time limit of this midterm review, some important features are not finished, including 1) the support of VSAs frame in multiple channels environment, 2) the most important channel access assignment named AlternatingAccess. Besides that, some details not defined in the standard will need more consideration and tests. Further study is to 1) verify the correctness of the implementation, 2) implement some examples to study performance and impact of multiple channels operation. Some high standards like 1609.3 and mobility model for vehicular environment are out of scope.

Patch Set 1 #

Total comments: 5

Patch Set 2 : updates after midterm review #

Unified diffs Side-by-side diffs Delta from patch set Stats (+3796 lines, -8 lines) Patch
M doc/models/Makefile View 1 chunk +1 line, -0 lines 0 comments Download
M doc/models/source/index.rst View 1 chunk +1 line, -0 lines 0 comments Download
A src/wave/doc/wave.rst View 1 chunk +369 lines, -0 lines 0 comments Download
A src/wave/examples/wave-simple-device.cc View 1 chunk +215 lines, -0 lines 0 comments Download
A src/wave/helper/wave-helper.h View 1 chunk +69 lines, -0 lines 0 comments Download
A src/wave/helper/wave-helper.cc View 1 chunk +195 lines, -0 lines 0 comments Download
A src/wave/model/channel-coordinator.h View 1 1 chunk +235 lines, -0 lines 0 comments Download
A src/wave/model/channel-coordinator.cc View 1 1 chunk +309 lines, -0 lines 0 comments Download
A src/wave/model/channel-manager.h View 1 1 chunk +169 lines, -0 lines 0 comments Download
A src/wave/model/channel-manager.cc View 1 1 chunk +161 lines, -0 lines 0 comments Download
A src/wave/model/channel-scheduler.h View 1 1 chunk +134 lines, -0 lines 0 comments Download
A src/wave/model/channel-scheduler.cc View 1 1 chunk +304 lines, -0 lines 0 comments Download
A src/wave/model/wave-net-device.h View 1 1 chunk +432 lines, -0 lines 0 comments Download
A src/wave/model/wave-net-device.cc View 1 1 chunk +597 lines, -0 lines 0 comments Download
A src/wave/test/wave-test-suite.cc View 1 chunk +579 lines, -0 lines 0 comments Download
M src/wifi/helper/wifi-helper.h View 1 chunk +1 line, -1 line 0 comments Download
M src/wifi/helper/yans-wifi-helper.h View 1 chunk +1 line, -1 line 0 comments Download
M src/wifi/helper/yans-wifi-helper.cc View 1 chunk +1 line, -1 line 0 comments Download
M src/wifi/model/edca-txop-n.h View 1 chunk +2 lines, -1 line 0 comments Download
M src/wifi/model/edca-txop-n.cc View 2 chunks +2 lines, -2 lines 0 comments Download
M src/wifi/model/wifi-mac-queue.cc View 1 2 chunks +17 lines, -2 lines 0 comments Download
M src/wifi/wscript View 1 2 chunks +2 lines, -0 lines 0 comments Download

Messages

Total messages: 3
Nicola Baldo
A few more comments on this other patchset. https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst File src/wave/doc/wave.rst (right): https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode282 src/wave/doc/wave.rst:282: NqosWave80211pMacHelper ...
8 years, 2 months ago (2013-07-29 10:50:04 UTC) #1
Tom Henderson
On 2013/07/29 10:50:04, Nicola Baldo wrote: > A few more comments on this other patchset. ...
8 years, 2 months ago (2013-07-29 13:06:42 UTC) #2
Junling Bu
8 years, 2 months ago (2013-07-30 16:49:10 UTC) #3
https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst
File src/wave/doc/wave.rst (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/doc/wave.rst#newcode290
src/wave/doc/wave.rst:290: do not support NqosWaveMacHelper because of 1609.4's
requirement for Qos.
On 2013/07/29 10:50:04, Nicola Baldo wrote:
> so, if WAVE does not support NqosWaveMacHelper, then NqosWaveMacHelper is
> clearly misnamed 
Yes, I want to provide two types of NetDevice, one is only WifiNetDevice object
that support 802.11p, and another is WaveNetDevice object that will support WAVE
architecture. The first can use either qos or nqos, but the second should be qos
because of IEEE 1609.4 needs priority. I know NqosWaveMacHelper is not a
suitable name, but the question is I don't know how to use a better
implementation to meet the requirement. I think changing the name of
NqosWaveMacHelper is still not good. My implementation now is WaveMacHelper base
class, QosWaveMacHelper and NqosWaveMacHelper inherit from the base class, a
802.11p device can use either QosWaveMacHelper or NqosWifiMacHelper because the
parameter of 802.11p device helper is WaveMacHelper, a wave device can only set
QosWaveMacHelper because the parameter of wave device helper is QosWaveMacHelper
and I add comments to remind users that we shall support qos here. So Nicola,
how can I reflector my implementation? 

Another issue you talked in ns-3-reviews is about wave-helper.
Actually I know here are many duplicate codes. The reason is : 1) SetType
(std::string type,...) of WifiMac helpers allow users to set high mac class like
adhoc, but for 802.11p I think we should not allow users to do this, he should
use OcbWifiMac only, 2) still considering flexibility, I am afraid that if we
inherit from wifi helper class, when people use helper, he can easily make
mistake that use WifiMacHelper create a AP mac and add it into WaveHelper, the
only way to prevent is to use RTTI of c++ to check class type. Since as you
suggested, my thought is  1)add virtual to the method of wifi helpers, 2)
refactor the QosWaveMac, NqosWaveMac and WaveMac to inherit from wifi helper
classes, 3) add check in the method to protect user not make mistake. How do you
think?

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device.h
File src/wave/model/wave-net-device.h (right):

https://codereview.appspot.com/11480044/diff/1/src/wave/model/wave-net-device...
src/wave/model/wave-net-device.h:190: * However WaveNetDevice inherits from
NetDevice instead of  WifiNetDevice
On 2013/07/29 10:50:04, Nicola Baldo wrote:
> I think no one expected that WaveNetDevice inherited from WifiNetDevice, so it
> is ok just to mention that WaveNetDevice and WifiNetDevice are different with
> the differences that you mentioned.
> 
> I mean, you don't have to excuse yourself for not inheriting from
WifiNetDevice
> :-)
I have asked myself many times which is better to inherit from WifiNetDevice or
not. But the answer is hard for me. If inherit from WifiNetDevice, we could
avoid replicating a lot of code, then we should add some method to support
multiple channel operation, overwrite some method that is not suitable, and we
need to overwrite WifiNetDevice::SetMac method to construct some MAC objects (I
don't know how to achieve that, maybe add operate= in WifiMac, but it seems not
a good way), and since people uses this device for WAVE architecture, a device
type that is a NetDevice rather than WifiNetDevice could be more understandable.
So now I prefer to inheriting from NetDevice, off course, maybe I will change to
inherit from WifiNetDevice if it seems more reasonable.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b