Towards Personal Virtual Traffic Lights
, Luis Silva 1, João Almeida 1, Bruno Miguel Fernandes Silva 1, Joaquim Ferreira 1,2 and José Fonseca 1Round 1
Reviewer 1 Report
Personal Virtual Traffic Lights
The paper describes a system that uses common devices as sensors for localization and triggering of users in the traffic scene.
It describes some first experiments that show the feasibility of implementing such a system with BLE.
Although I strongly have no background in this domain, I would expect such a paper to be submitted to a related conference. Personally, I think the paper does not cover sufficient aspects to validate a journal submission.
Moreover, the paper is a bit too generic for the presented work (in my limited view).
The idea of using personal bluetooth devices with a display to signal traffic states is good, the total system is only partly validated in this work. For a journal submission I would expect a more broad and more detailed evaluation.
But again, that is my view (which is based on the computer vision domain).
The paper starts with a well readable and extensive introduction
Although the results show that the proposed soluton can be implemented in a real-life case, it lacks very many important aspects. For example, it is nice to get the state of the upcoming traffic light, but a route planner is required to filter out which exact traffic light the user is interested in. Of course this is not the focus of the paper. Also the usability aspects are completely ignored in this paper. What is people don't view the messages on their phone? OF course this is not the focus of the paper, but I would really like a summary of all such aspects in the paper, which would make it more relevant work.
Before the physical traffic lights can be removed, many more steps need to be taken. At least listing all these steps should be done in this work to validate the title of the paper.
I would name it "Towards Personal Virtual Traffic Lights" as we are quite far away still.
Line 171: the figure does not show an overview of the architecture, it show an example situation with all sensors and participants. Lateron you call it 'scenario' (189). There is no achitecture figure in the paper.
I actually really miss the total actual architecture.
The paper shows first results on a small part of the impleemntation, but the larger picture is not validated. That is no problem, but the paper and introduction suggest more than the paper brings.
Author Response
Point 1 - Also the usability aspects are completely ignored in this paper. What is people dont view the messages on their phone? OF course this is not the focus of the paper, but I would really like a summary of all such aspects in the paper,which would make it more relevant work.
Response - Although an interesting topic for discussion, the focus of this work is to kick off the development of a comprehensive system that aims to leverage commonly available communication technologies and wearables in order to address the targeted application. One could ask the same question regarding current traffic light systems: If someone doesn’t look at a physical traffic light, what should/can be done? Actually, nowadays people spend more time looking at the smartphone while walking than checking its surroundings :) Still, an interesting challenge to address. Thank you for raising it.
Point 2 - Before the physical traffic lights can be removed, many more steps need to be taken. At least listing all these steps should be done in this work to validate the title of the paper.I would name it ”Towards Personal Virtual Traffic Lights” as we are quite far away still..
Response - We changed the title following your suggestion and to better reflect the nature of the contribution.
Point 3 - There is no achitecture figure in the paper. I actually really miss the total actual architecture..
Response- Figure 2 was updated in order to provide a more detailed overview of the global system architecture.
Reviewer 2 Report
The paper proposes a for centralized virtual traffic light systems, based on Bluetooth Low Energy (BLE)
Although the proposed solution requires further development and testing, it is nevertheless very interesting and potentially useful for practioners. The paper is adequately written and organized. Its aim is well described. The idea is original and convincing. More complete and all-encompassing field tests would have been welcome. Discussion is lacking but the contribution of paper to literature research is evident.
· Perhaps the title is too demanding compared to what is reported in the paper: this is just “a proof of concept for the proposed system”.
· A discussion section should be added, before conclusions section, to address a general and critical evaluation of the new solution proposed, stressing on its advantages and limitations, with a comparison with the other methods reported in literature. Such evaluation could be useful to individuate and justify the future steps.
· Section 6. Experimental Evaluation: which is the speed the moving vehicle in the second sets of experiments? Please reported it in the text.
· Please, check the format of references, especially from line 375 to line 379.
Author Response
Point 1 - Perhaps the title is too demanding compared to what is reported in the paper: this is just a proof of concept for the proposed system..
Response - The title of the paper was changed to better reflect its contribution. Thank you.
Point 2 - Section 6. Experimental Evaluation: which is the speed the moving vehicle in the second sets of experiments? Please reported it in the text.
Response - The document now includes the (average) speed of the moving vehicle.(”The vehicle’s speed, constrained by the traffic congestion at the time, averaged close to 30 km\h.”)
Point 3 - Please, check the format of references, especially from line 375 to line 379.
Response - Fixed. Thank you
Reviewer 3 Report
The paper proposes and evaluates a control system for traffic lights based on Bluetooth Low Energy. The topic is interesting, and contributes to the important aim of using communication systems to improve the safety and efficiency of traffic.
The paper is very well written. The proposal can be a good approach to implement cooperative traffic lights systems. Nevertheless, some issues must be considered:
- The evaluation is limited in scope. It uses a real-world implementation, but the most complex scenario uses just one car, one controller, and one retransmitter. The effect of multiple retransmitters, for example, could be important.
- BLE uses an overcrowded band of spectrum. The paper is proposing, unlike the typical BLE use case, to use BLE with an extended range using maximum power. Are the authors envisioning a dedicated range for an adoption of your solution in the real world? Interference seems to be a danger for the proposed system. Some discussion about this in the paper could be valuable for readers.
- The evaluation does not say at which rate controller/retransmitter messages are sent, which is a critical information to understand most of the provided performance metrics values. The information about throughput in equation (2) seems to imply that a message is sent as soon as possible after the previous one. This would mean that you are sending more than 2 messages per ms, is this the case?
- It is not clear how long the retransmitter spends in update and transmit states (what is "controller_period"?), and how consistency with the information sent by the controller is ensured. For example, if the controller changes the information and the retransmitter is in the transmit state, does this mean that the retransmitter is sending wrong information until its next change to update state? or am I missing something?
- Some references have missing information (e.g., 1, 2, 3, 4, 5, 15, 16 and 17). A title and authors are not enough. If they are web references, provide a URL.
- Minor detail, page 6: "an user" -> "a user"
Author Response
Point 1- The evaluation is limited in scope. It uses a real-world implementation, but the most complex scenario uses just one car, one controller, and one retransmitter. The effect of multiple retransmitters, for example, could be important. The presented scenario and evaluation is intended as initial proof-of-concept for the proposed system.
Response - Thank you so much for your opinion, we do intend to address complex scenarios in the near future.
Point 2 - BLE uses an overcrowded band of spectrum. The paper is proposing, unlike the typical BLE use case, to use BLE with an extended range using maximum power. Are the authors envisioning a dedicated range for an adoption of your solution in the real world? Interference seems to be a danger for the proposed system. Some discussion about this in the paper could be valuable for readers..
Response - We are aware of the possible interference issue, however, we believe that this is greatly mitigated in our proposal since it only utilises BLE’s advertisement channels (which minimize interference from 2.4GHz Wi-Fi channels). Nonetheless, this aspect was absent in the paper; section 5.1 was updated with this information. Thank you for bringing the issue to our attention.
Point 3 - The evaluation does not say at which rate controller/retransmitter messages are sent, which is a critical information to understand most of the provided performance metrics values. The information about throughput in equation (2) seems to imply that a message is sent as soon as possible after the previous one. This would mean that you are sending more than 2 messages per ms, is this the case?. It is not clear how long the retransmitter spends in update and transmit states (what is controller-period),and how consistency with the information sent by the controller is ensured. For example, if the controller changes the information and the retransmitter is in the transmit state, does this mean that the retransmitter is sending wrong information until its next change to update state? or am I missing something?
Response - Section 5.1 and 5.2 were updated in order to clarify the procedure for the dissimination of messages (lines 272-289 and 294-300).
Point 4 - Some references have missing information (e.g., 1, 2, 3, 4, 5, 15, 16 and 17). A title and authors are not enough. If they are web references, provide a URL..
Response - It has been fixed, thank you so much.
Point 5 - Minor detail, page 6: ”an user” - ”a user”.
Response - Also fixed. Thank you.
