Wireless-Innovation-Forum / 6-GHz-AFC

This repository contains code and data for testing the compliance of Automated Frequency Coordinator (AFC) software. The AFC is defined by the FCC in proceeding 18-295 on Unlicensed Use of the 6 GHz Band. This repository contains procedures, documentation, and tests for such software, and for the devices authorized by it. To contribute, please first read the CONTRIBUTING file in the repository for instructions.
14 stars 3 forks source link

NLCD code difference from WINNF data and latest US Govt data FSP.23 #63

Open alexcpn opened 1 month ago

alexcpn commented 1 month ago

While checking the discrepancy between calculated and expected values of FSP.23 came across a point (among so many uncertainty points) where on debugging found a difference between the WINNF provided data and the latest US Govt data ( NLCD_2021_Land_Cover data)

This is similar to issue #62

If I use the NLCD tiles from WINNF https://github.com/Wireless-Innovation-Forum/Common-Data/tree/master/data/nlcd nlcd_n34w119_ref.zip

I get NLCD code =22 for the uncertainty point and PSD does not match the test vector.

When I downloaded the Tiles from the US Govt https://www.mrlc.gov/viewer/ for 2021 land cover NLCD_x3tyHGqm37Jn4p5rSP6_LA7.zip and loaded this in QGIS and checked via the value tool it shows the difference between the WINNF data as can be seen below

image

More details

Using the downloaded 2021 land cover data

Name | NLCD_2021_Land_Cover_L48_20230630_x3tyHGqm37Jn4p5rSP67 Path | /ssd/qgis/NLCD_x3tyHGqm37Jn4p5rSP6_LA7/NLCD_2021_Land_Cover_L48_20230630_x3tyHGqm37Jn4p5rSP67.tiff

NLCD code  =23 for (33.7721928444125, -118.37560733754981)
NLCD code  =23 for (33.773091155587494, -118.3745266624502)

This causes FSP.23 test case to fail for 6640.0-6650.0 frequency range

Calculated Frequency
[INFO] 6640.0-6650.0  psd: -15.163155932231206
Expected Frequency
[INFO] 6640-6650,upperBound:-5.6 nominalValue:-7.6
[INFO] Max PSD =-15.163155932231206 dBm/MHz [PSD Receiver=-14.557765500572557 PSD Diversity=-15.163155932231206 PSD Passive=None]
[INFO] Loss Receivers=115.94223449942744 Mode=winner at AP Loc=(33.7721928444125, -118.37560733754981) accesspoint_ht_m=90.0
[INFO] Diversity PSD =-15.163155932231206 Diversity Loss=118.63684406776879 @(33.7721928444125, -118.37560733754981)
[INFO] receiver_clutterloss=0 ap_nlcd_code=22  ap_clutterloss=0
[INFO] uuid: 962266

INFO] Winner:URBAN L_LOS=108.65778149546409 L_NLOS=142.68679313737698 loss=133.4075090200557 ap_nlcd_code=23 @ (33.773091155587494, -118.3745266624502) distance_m=383.81878473815686 d_BP=83313.53333333333
[INFO] Winner:SUBURBAN L_LOS=101.20171089404549 L_NLOS=129.548840773724 loss=115.94223449942744 ap_nlcd_code=22 @ (33.7721928444125, -118.37560733754981) distance_m=261.38326869293627 d_BP=207589.8

NLCD Code selected is Suburban among the uncertainty points as it has the lowest loss; and since loss is less, PSD also less

However, if we set this as URBAN we get the proper values

[INFO] Calculated Frequency
[INFO] 6640.0-6650.0  psd: -7.649093991777136
Expected Frequency
[INFO] 6640-6650,upperBound:-5.6 nominalValue:-7.6
[INFO] Max PSD =-7.649093991777136 dBm/MHz [PSD Receiver=-7.649093991777136 PSD Diversity=-7.563253505581983 PSD Passive=None]
[INFO] Loss Receivers=122.85090600822286 Mode=winner at AP Loc=(33.7721928444125, -118.37560733754981) accesspoint_ht_m=90.0
[INFO] Diversity PSD =-7.563253505581983 Diversity Loss=126.23674649441801 winner @(33.7721928444125, -118.37560733754981)
[INFO] receiver_clutterloss=0 ap_nlcd_code=23  ap_clutterloss=0
[INFO] uuid: 962266

[INFO] Winner:URBAN L_LOS=108.65778149546409 L_NLOS=142.68679313737698 loss=133.4075090200557 distance_m=383.81878473815686 d_BP=83313.53333333333
[INFO] Winner:URBAN L_LOS=104.31972202032362 L_NLOS=132.54884077372398 loss=122.85090600822286 distance_m=261.38326869293627 d_BP=207589.8
sergebdt commented 1 month ago

The NLCD common data is based on a retiling operation of the original NLCD data snapshot of 2011 (re-released in 2014), using a set of provided scripts found in https://github.com/Wireless-Innovation-Forum/Common-Data/tree/master/scripts

Obviously if you compare the data with latest data from 2020+, then you will have differences here and there.

alexcpn commented 1 month ago

@sergebdt is the expected results calculated using the NLCD common data by WINNF or by third party using the latest ones. Wanted to confirm if this was indeed the reason for the differences with my calculated value and test output

sergebdt commented 1 month ago

I guess that any reference test output should use a common database that everyone can agree on - ie. the NLCD common data. Check with the AFC people for confirmation.

In SAS, that was the case and every production system out there reproduces internally that common NLCD database in their live system (and also using similar data read routines) so as to avoid small discrepancies (such as reading at the border, etc..). If someone use another database, there is strong risk of failing the compliance tests.

Remember also that in the common NLCD database, the format used after retiling is regular grids in degrees space (1 arcsec separation), which is different from the original NLCD source file used to construct this database.

alexcpn commented 1 week ago

I am seeing here also similar problem for FSP.71. I was comparing this with results shared by Tom for AT&T and putting the uncertainty corodinates from him I got the NLCD code exact as 52. But all surrowinding pixels are 42 and in AT&T computation it is 42 making a huge change in clutter loss calculation.

It is not specified anywhere but I am planning on taking the surrounding pixels and voting for the majority so that one off cases like this do not cause problems especially for use cases like this when uncertainty point is near the edge.

https://docs.google.com/presentation/d/1f655lJkrhLSxkTe5t4MBdH77AWJtHXnj8q4FOZtq0so/edit?usp=sharing

Screenshot from 2024-09-02 17-35-25

alexcpn commented 1 week ago
sergebdt commented 1 week ago

As I said previously, the SAS project normalized on the 2011 NLCD (released in 2014). If the AFC project is using another reference, then the source data will obviously be different -- and any results you expect will be different than one obtained with SAS NLCD database. You should make sure that the AFC project has correctly and clearly normalized on one set of data, and use that. Has the AFC project clearly defined in its specification which data to use for the compliance tests ?

alexcpn commented 1 week ago

No, in the WINF-TS-1014 v4 it is mentioned to use https://www.mrlc.gov/data, but not which date.It should mean then to use the latest always for production I guess. But the question is now only with regard to matching the test vector output where as you mentioned this should be clearly mentioned

image

[n.18] National Land Cover Database (NLCD) data for CONUS, Alaska, Hawaii and Puerto Rico, available at https://www.mrlc.gov/data

In https://github.com/Wireless-Innovation-Forum/Common-Data/ it is mentioned that it holds the Common Data for the SAS and AFC project as well.

@AEgbert could you please clarify if the test vector results were calculated from NED form the WINNF repository or is it from US Govt 2020 land cover ?