Multiple locations in single JSON query

[Przemysław Pawełczak]

Dear Forum (Dear Mike),

My group is still working on the spectrum database profiling and I have some questions for which we cannot find an answer. Hope you will be able to help.

We are experimenting with asking for spectrum information for multiple locations in one JSON request. Questions:

-> We have observed a severe jump in query reply delay (more than 2 second query reply delay) when comparing delay if one location in JSON query with a delay when sending JSON request containing two locations (see attached figure). Such jump is not existent when querying N and N+1, for N>1 (delay difference is linear). We see this jump consistently throughout querying from different devices in our lab. Unfortunately we cannot explain where does this behavior come from in Google database implementation.

-> Can you confirm that general the delay in white space database spectrum reply comes from the implementation of spectrum rules search tree in the database? For example - querying locations in Alaska (from coast of the state to Canadian border) and querying US mainland (coast to coast) we see that delay for database reply delay is always lower than for US - consistently?

-> Is there any physical limit in your database how many simultaneous locations in one JSON query can the Google White Space Database accept?

Thank you for your help and I look forward to your feedback.

With best regards,

Przemek Pawelczak, TU Delft

[Michael Head]

Hi Przemek,

With respect to the performance problem you noticed, would you mind providing a couple samples of the fast and slow queries? I can't offer any hypotheses about the multi-location query issue (I don't think we've explicitly tested that case ourselves, and I'm personally a little surprised it even works at all!)

With respect to the higher performance of queries targetting Alaska: it's possible the queries are faster because (a) there are so many fewer transmitters / entities to consider up there and/or (b) for fixed device queries, we might read terrain data which is at a coarse resolution (leading to a smaller collection of data to load/scan for a given query).

With respect to the number of locations in general: I don't believe we have any policy about it today, but we might consider applying some kind of quota limit for this in the future.

-- mike

[Przemysław Pawełczak]

Hey Mike,

Thanks for the reply.

We included in the attachment: (i) the group query function (from Matlab) that we use to generate a multi-location query and (ii) the "request sample" of multi-location (sent you your personal email).

In the attached figure you will see the results of our extra experiment: 30 different locations were queried with a different number of antennas around it (this data was acquired from the FCC server) in a circle of 60 miles. The figure indicates that there is not relation between the number of antennas and the delay. 

Therefore: 

-> We are very interested to know why do you think there could be a relation between the number of antennas and a delay?

-> Further, if you can elaborate a bit more on the relation between the physical world and database system. Our hypotheses about the difference between the Alaska and the mainland US is due to separation in the databases, and the database related to Alaska is smaller in size. The time the system takes to search for the results is therefore less.

-> About the maximum number of locations that can be queried in one request: our answer is that there is actually a limit of 3000. Simply put, for for more than 3000 locations in one request your database response will be "Too many elements".

-> Finally, when we send a request to the database, how is the answer being generated? Is it only performed by checking the validation of the parameters and search for the results of that locations (since the data is ready) or there will be a some calculation performed to generate the response? If so - can you elaborate what is happening during this calculation?

Thanks again for your feedback.

Best regards,
Amjad and Przemek

[Michael Head]

Ah, I understand better what you're doing.

You're using JSON-RPC batch mode to issue multiple queries in a single request. This isn't a supported mode of operation, though it's nice to find out that it does appear to work.

From what I can tell, our calculations take the same amount of time independent of the number of batched queries, so my best guess is that there's some overhead in the common JSON-RPC-handling code when dealing with N>1 queries in a batch request.

This is definitely an interesting performance issue, and so I thank you and your team for reporting it.

The bad news (I suppose) is that since we don't explicitly support this mode of operation, it's unlikely we'll address it in the foreseeable future.

For posterity, I did note significantly increased query time when issuing requests like this ( ~ 1.5s response time):

curl -X POST https://www.googleapis.com/rpc -v -H "Content-Type: application/json;charset=utf-8" -d '

[

{"jsonrpc": "2.0","method": "spectrum.paws.getSpectrum","apiVersion": "v1explorer","params": {"type": "AVAIL_SPECTRUM_REQ", "version": "1.0", "deviceDesc": { "serialNumber": "mrhead-sn1", "fccId": "TEST", "fccTvbdDeviceType": "MODE_2" }, "location": { "point": { "center": {"latitude": 28.5666, "longitude": -81.3094} } },"antenna": { "height": 30, "heightType": "AMSL" },"owner": { "owner": { } }, "capabilities": { "frequencyRanges": [{ "startHz":800000000, "stopHz": 850000000 }, { "startHz": 900000000, "stopHz": 950000000 }] }, "key": "<scrubbed>"},"id": "rq1"},

{"jsonrpc": "2.0","method": "spectrum.paws.getSpectrum","apiVersion": "v1explorer","params": {"type": "AVAIL_SPECTRUM_REQ", "version": "1.0", "deviceDesc": { "serialNumber": "mrhead-sn2", "fccId": "TEST", "fccTvbdDeviceType": "MODE_2" }, "location": { "point": { "center": {"latitude": 28.5666, "longitude": -81.3086} } },"antenna": { "height": 30, "heightType": "AMSL" },"owner": { "owner": { } }, "capabilities": { "frequencyRanges": [{ "startHz":800000000, "stopHz": 850000000 }, { "startHz": 900000000, "stopHz": 950000000 }] }, "key": "<scrubbed>"},"id": "rq2"}

]'

over requests like this ( ~-.5s response time):

curl -X POST https://www.googleapis.com/rpc -v -H "Content-Type: application/json;charset=utf-8" -d '

[

{"jsonrpc": "2.0","method": "spectrum.paws.getSpectrum","apiVersion": "v1explorer","params": {"type": "AVAIL_SPECTRUM_REQ", "version": "1.0", "deviceDesc": { "serialNumber": "mrhead-sn1", "fccId": "TEST", "fccTvbdDeviceType": "MODE_2" }, "location": { "point": { "center": {"latitude": 28.5666, "longitude": -81.3094} } },"antenna": { "height": 30, "heightType": "AMSL" },"owner": { "owner": { } }, "capabilities": { "frequencyRanges": [{ "startHz":800000000, "stopHz": 850000000 }, { "startHz": 900000000, "stopHz": 950000000 }] }, "key": "<scrubbed>"},"id": "rq1"}]'