Optical CDMA MAC Evaluation in Vehicle-to-Vehicle Visible Light Communications

Round 1

Reviewer 1 Report

• page 2 : writing that CSMA/CA is not for VLC has to be moderated as it depends of the scenario. 
• page 4 : why not taking directly into account the visibility parameter into account in the VLC channel model as it can be impacted by smoke, fog, snow or dust in the air?
• Page 4 : your optical source is lambertsian. Why not taking the radiation pattern of a real car lighting (symmetry generally is not present anymore)? Some papers are doing so in the litterature.
• Page 4 : why not using the OCC camera of the front/rear of the car in place of the photodiode?
• Figure 4 has no meaning as the number of VLC links is an entire value.
• Table 1 : what is the unit of the environmental noise? Why to write it in this table as it is not taken into account following the sentence in §3.3?
• Table 1 : what has guided the choice of OOC length and PN length?
• Page 6 : Is the scenario of 7 lanes credible with using a speed of 50 km/h?
• Figure 6 (a) : the blue car interfering with the others should not be drawn on the figure as it attract the attention to a unique location
• Figure 6 (b) : the vertical scale of all subfigures should be the same in order to compare correctly the PDR evolution at one glance. And I have the same remarks for all other figures showing PDR evolution.
• Why not using Hadamar-Walsh codes in place of Gold Code? They are known to be better in crosscorrelation.
• Figure 8 : Why choosing Manchester encode? 
• Figure 8 : Manchester coding is know to help clock recovery at the receiver side as it possesses a phase transition in the middle of the transmitted bit. So why to consider asynchronous synchronisation?
• Page 11 : Altough you work is preliminary, do you have an idea on how to organise in real life the association of tracks and codes families throughout the world and for all trade marks of cars?
• Figure 8 : when visible light is used and when the light source is LEDs, VLC acronym is used and not FSO (generally used for laser sources).
• Page 11 : the simulation details are not sufficiently explained to my point of vue
• Page 15 : why choosing a 32 bytes frame as it is writen 1000 bytes in the Table 1?
• Page 16 :  In place of expressing simulation time in terms of expected latency, just mention it in term of computation complexity. Memory requirements should also be adressed for both code types.
• Figure 17 : not relevant
• Refence 24 : missing 

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Reviewer 2 Report

This paper reveals an interesting result about the use of a certain Optical Code Division Multiple Access protocol for improving the medium access control performance in a vehicle-to-vehicle communication scenario. The result shows that optical orthogonal codes and pseudo-noise sequence codes can be a good approach, much better for its low interference performance if they act in an asynchronous way. Moreover, authors show that PN solution is faster, therefore suitable for more demanding scenarios.

The paper is well written, succint and clear, scientific sounding and with a very well designed graphic support, which eases its reading and understanding. It deserves to be published. I only have some minor issues with the humble aim to further improve what is really good: 

• I think that authors should stress not only the strengths but also the drawbakcs of their soultion. I would like to see a remark on two issues:
  • although mentioned, the fact that the car should have information about its position is a not light difficulty: inherently costly, technologty demanding, etc. Regarding this, I would like authors to clarify line 237 of their text: both lane and position is needed. It is not clear the needing for the position: respect to the receiver? In that case, how could it be known by the transmitter without using any other link? In case of being a position in the lane, again it seems a demanding hardware solution.
  • Fig. 17 is a good result but it is not so clear when thinking in the overall real time needed for establishing the right communication. I would like to see a discussion about the time needed to process the asynchronous solution, as it could be a drawback in a real scenario. At least, a tentative time based on authors simulations should be provided.
• Fig. 8: would not it be necessary to add in the flow chart the change in code X in case of not having a good decoding? (upper right branch)
• Figure 16: is it plotted for a lane or as an overall?

Some minor issues:

• Fig. 11: maybe it is just a convention, but I would have used L and R interchanged, as seen from the car's point of view.
• Line 162: "breaking" should be "braking"?
• Take care with references. There are some mistakes around ref. [24]

Author Response

Please see the attachment.

Author Response File: Author Response.pdf

Round 2

Reviewer 1 Report

Thank you for taking into account and/or providing answers to my questions and interrogations.

Points 1, 4, 6, 7, 8, 9, 10, 12, 13, 14, 15, 17, 18, 20 : ok --> closed points

Points 2, 3, 11 : I understand your point to chose the simplest model to go straight to the application. Those 3 points give you maybe some future improvement ideas --> ok --> closed points

Point 5 : I still believe that only an entire number number of VLC links is of interest in place of this figure. I suggest a compromise between your view and mine by adding dots (or steps) at distances where the entire number of VLC links is changing

Point 16 : I mean that there are not enough details on how your matlab simulations are done and so there is a lack of information if one researcher wants to reproduce your results. Please add some explanations

Point 19 : I meant that the content of figure 17 does not need a figure with only 2 points but a table presentation is better

Author Response

Please see the attachment.

Author Response File: Author Response.pdf