Issues with Protocol Documentation Sec. 3.2.1 New Location Computation

[zkhalapyan]

Hi Eric,

I believe t0 in the calculation is supposed to be change in time as opposed to the timestamp the neighbor's location was calculated. Otherwise the new location will be very very far.

Could you also specify what equation is the calculation based on and also clarify about the units of the variables - speed in m/s, Earth's radius in meters, time in seconds, and bearing in degrees. Also is Earth's radius the median radius ~ 6,371,000m or are you using another value? It would be nice if it was specified.

[ebollens]

I'm not sure I understand your first comment. The t0 value should be the time when the location was reported. This is because the calculation isn't computing distance change from the ROUTING-TABLE-1 value but instead from the ROUTING-TABLE-2 value. Therefore, if a new report hasn't come in that updated ROUTING-TABLE-2 since last computation, then the location it calculated will again be derived from ROUTING-TABLE-2, not from the current location. I will add a clarifying statement though changing "and the location (longitude,latitude)=(ψ_0,ϕ_0 ) of the node" to "and the location (longitude,latitude)=(ψ_0,ϕ_0 ) of the node as defined in ROUTING-TABLE-2".

As for the second comment, let me address these individually:

• Radius is up to the implementation. Consider two nodes with different values for radius: they will make their ROUTING-TABLE-1 computations slightly differently, but these values don't really require synchronization. It just means that one node might be more accurate in computation than another if they use different radius values. Since we're running uniform software between all, this isn't even a concern, but from the protocol perspective, that's where this comes from. In a production implementation, there might be a more accurate way of describing this, since Earth is an ellipsoid and not a sphere, but let's consider that outside scope.
• Speed needs to be in the same units as the radius and time, but again this is implementation-specific. I will make a note in the protocol of the fact it needs to be in the same units, while leaving the specifics up to the implementation.
• The formula is just a orthodomic calculation of movement in spherical coordinates. I'm not exactly sure what it's called, but here's a source that confirms the formula I used: http://www.movable-type.co.uk/scripts/latlong.html

Honestly, we're providing a bit more than most protocols by giving equations even. I am actually going to add a note to the protocol that another formula could be used to make these calculations, depending on the use case, and that these are just recommended formulas. The reason I say that these computations are not actually part of the "protocol" par se is because they're not about intercommunication, but rather just how you make calculations for forwarding and routing table updates.

[ebollens]

I've added the following section to the preface for section 3:

This section describes two different sets of algorithms required for the protocol:

  • Greedy Perimeter Selection Routing (§3.1) - A functional implementation of the protocol 
     initially presented by Karp and Kung.
  • Predictive Velocity Neighbor Maintenance (§3.2) - A method for maintaining knowledge
     of immediate neighbors using information from neighbor beacons about two-hop neighbors.

While this protocol makes recommendations concerning the algorithms, other methods may be 
used that achieve the same effect, taking into account design decisions about computational 
complexity, communication range and location/velocity accuracy. Generally, a deployment of 
this protocol should seek uniformity in implementation throughout, but this is not necessary in 
the event that factors such as heterogeneous hardware make it unviable.

[zkhalapyan]

Assuming that s is speed and t0 is the timestamp when the location was reported, than distance doesn't equal s_t0. I think it's supposed to be s_dt, where dt equals t_current - t_reported. Doesn't this make more sense?

[ebollens]

Oh, by the way, all the angles are in radians.

[ebollens]

Oh, yeah, you're right. I'll fix that.

[ebollens]

Fixed in 92ba81d.

[zkhalapyan]

The rest looks good!