Wireless-Innovation-Forum / Citizens-Broadband-Radio-Service-Device

Apache License 2.0
32 stars 19 forks source link

<Branch:bug fixes>Mock SAS calculation of time interval between two heartbeat request messages is #88

Closed pawan25062 closed 6 years ago

pawan25062 commented 6 years ago

Hi,

It seems MOCK SAS is not calculating time interval correctly.

2017-12-21T09:23:46.565Z - INFO - heartbeat request from CBRS : { "heartbeatRequest": [ { "cbsdId": "S9GQ710US01Mock-SAS401629000040", "grantId": "35181109", "operationState": "AUTHORIZED" } ] } 2017-12-21T09:23:46.565Z - INFO - The time interval between two heartbeat request messages is 59.998 2017-12-21T09:23:46.582Z - INFO - engine sent successfully, the response to CBRS : { "heartbeatResponse": [ { "cbsdId": "S9GQ710US01Mock-SAS401629000040", "grantId": "35181109", "response": { "responseCode": 0 }, "transmitExpireTime": "2017-12-21T09:27:06Z" } ] } 2017-12-21T09:24:46.563Z - INFO - heartbeat request from CBRS : { "heartbeatRequest": [ { "cbsdId": "S9GQ710US01Mock-SAS401629000040", "grantId": "35181109", "operationState": "AUTHORIZED" } ] } 2017-12-21T09:24:46.578Z - INFO - The time interval between two heartbeat request messages is 60.013

Time interval between these above HB requests should be, time difference between "09:23:46.565" and "09:24:46.563". which should be 59.998.

But MOCK SAS is taking difference of "09:23:46.565" and "09:24:46.578" which is 60.013.

log file is also attached here for more reference. WINNF.FT.C.HBT.1_2017-12-21T09.20.30Z.zip

cwilliams-ericsson commented 6 years ago

As you have found, the timestamps used in calculating the heartbeatInterval are not exactly the same timestamp used for logging the request message. It may be possible to move the timestamps used for calculation closer to the time at which the request was received, but it will not be the exact time the request message is received, either. In fact, the timestamp printed for the heartbeat request message reception is not strictly correct, either, but happens somewhat after the actual message reception.

I am thinking that to take into account possible delays in request message processing in a test server, it may be a better solution to provide a margin on the heartbeatInterval calculation in order to avoid failing CBSD which may be under the heartbeatInterval (but the test harness calculates is over). I am thinking of a margin in the 100msec to 500msec range.

Anyone have any thoughts?

cwilliams-ericsson commented 6 years ago

I would caution though: even if we alter the timestamps used for calculating, your log shows margin on heartbeatInterval of 2 milliseconds. If that is truly the CBSD behaviour, you're implementation is on the edge and will potentially fail any test which has multiple heartbeats...

cwilliams-ericsson commented 6 years ago

Addressed in Pull Request #77 and #71

cwilliams-ericsson commented 6 years ago

Found one more issue: for a DP with 2 CBSD, communicating with an array, the heartbeat interval is not the same for two subsequent HBT messages that arrive in an array.

So it turns out I can't use timestamp from CBRSRequestHandler, but need to pass the msg timestamp from Engine.py to CBRSRequestHandler.

Stand by for one more small fix for DP case.

cwilliams-ericsson commented 6 years ago

Added fix for DP heartbeatInterval calculation in Pull-Request #77 and #71

pawan25062 commented 6 years ago

Hi,

Is 5msec proposed margin included in latest fix or something else? Because in logs we can see the limit is: "60.005". And in your comments we can see that proposed margin was 100 to 500 msec.