AFCS.SIP.1 ULS data version related doubt

alexcpn commented 6 months ago

For AFCS.SIP.1 I am getting one incumbent with a 6 db lower PSD at the band (6862.5-6875.0) which is not expected.

I am using the ULS Snapshot 'l_micro_211024_modified_PA.zip' at https://github.com/Wireless-Innovation-Forum/6-GHz-AFC/tree/main/data/uls-snapshot

In this, I noticed that this particular incumbent license state is Active (which is the field we check as per WF-TR-1008 but license expiration data is in the past.

However the latest weekly download (3/3/2024) at https://www.fcc.gov/uls/transactions/daily-weekly has the updated expiry date.

Is it that the test-case results are looking at the expiry data from the older ULS snapshot and removing these from the test vectors ? As then this would explain this discrepency

More details

[INFO] Calculated Frequency
[INFO] 5925.0-6425.0  psd: 23.0
[INFO] 6525.0-6650  psd: 23.0
[INFO] 6650-6675.2  psd: 0
[INFO] 6675.2-6862.5  psd: 23.0
[INFO] 6862.5-6875.0  psd: 16.04420146953538

********************************************************************************
[INFO] Going to process UUID = 2795557 call_sign = 'WQEQ218
[INFO] accesspoint_loc =(18.16277, -66.722083) receiver_loc=(18.233055555555556, -66.75972222222222)
[INFO] Processing UUID = 2795557 call_sign = 'WQEQ218' R to AP Dist =8739.162352855034 m, CF =6875.0 Mhz r_antenna_make= ANDREW CORP r_antenna_model=PAR10-65 RF
[INFO] uuid: 2795557
[INFO] call_sign: WQEQ218
[INFO] frequency_assigned: 6875.0
[INFO] receiver_loc: (18.233055555555556, -66.75972222222222)
[INFO] t_loc_num: 1
[INFO] t_path_num: 1
[INFO] t_ant_num: 1
[INFO] receiver_to_ap_dist_m: 8739.162352855034
[INFO] r_height_to_center_raat: 106.7
[INFO] r_gain: 43.6
[INFO] r_diversity_gain: 41.3
[INFO] r_azimuth: None
[INFO] r_antenna_make: ANDREW CORP
[INFO] r_antenna_model: PAR10-65 RF
[INFO] r_loc_num: 2
[INFO] r_path_num: 1
[INFO] r_ant_num: 1
[INFO] polarization_code: None
[INFO] line_loss: None
[INFO] r_diameter_ft: 10.006561999999999
[INFO] r_diameter_m: 3.05
[INFO] ant_category: B2
[INFO] transmitter_loc: (18.42216666666667, -66.06905555555555)
[INFO] t_height_to_center_raat: 20.1
[INFO] t_gain: 43.9
[INFO] t_diversity_gain: None
[INFO] t_azimuth: 254.1
[INFO] t_antenna_make: ANDREW CORP
[INFO] t_antenna_model: HP10-65G
[INFO] bandwidth: 25.0
[INFO] frequency_range: (6862.5, 6887.5)
[INFO] accesspoint_loc: (18.16277, -66.722083)
[INFO] accesspoint_ht_m: 10.0
[INFO] accesspoint_vtunc_m: 2
[INFO] accesspoint_hzunc_x: 150
[INFO] accesspoint_hzunc_y: 150
[INFO] Free Space Path Loss =128.03240057486568
[INFO] receiver_elev=926.0 transmitter_elev=3.0
[INFO] Near field adjustments do not have to be done
[INFO] Uncertanity Points Length=330
[INFO] accesspoint_elev=501.75
[INFO] GRx = 43.6  GDRx= 41.3 dB
[INFO] centerFreq of Receiver =6875.0 Mhz
[INFO] ant_category = B2 
[INFO] Angle 1: Azimuthal discrimination angle:R-AP The azimuthal discrimination angle,  θAZ_Disc= 79.2282694625921 degress
[INFO] Angle 2: Elevation angle: R-T The receive antenna boresight elevation angle (from transmmitter) θEL_Disc= -1.0175006586649242 degrees
[INFO] Angle 3:elevation angle: R-AP The elevation angle from the  receive antenna to the evaluation phi= -3.4407691419700717 degrees
[INFO] --------------------------------------------------------------------------------
[INFO] Overall discrimination angle, 𝛾 =79.18747279001671 degress
[INFO] --------------------------------------------------------------------------------
[INFO] 2.d GRx=43.6 >= 38:/A  rpe=-42 from Radiation Supression Table 
[INFO] 2.d GRx=41.3 >= 38:/A  rpe=-42 from Radiation Supression Table 
[INFO] getRPE Diversity Antenna GDAZ_Disc=-42 GDEL_Disc=-42 
[INFO] getRPE gamma=79.2282694625921 ant_category=B2 rpe=-42 rpe_d=-42 
[INFO] The azimuthal discrimination= GAZ-Disc =-42 This should be negative
[INFO] The elevation discrimination  GEL-Disc in dB = -42 contribution This should be Negative!)
[INFO] --------------------------------------------------------------------------------
[INFO] Taking Max of GRx_Effectivein dB = 1.600000000000004 GDRx_Effective=-0.7000000000000002
[INFO] GRx_Effectivein dB = -3.7 polarization mismatch=3
[INFO] ----GRx_Effective in dB = -3.7-----------
[INFO] **Minimum transmit_power PSD = 16.04420146953538 dBm/MHz at (18.164117466762484, -66.723501125128) for loss 127.84420146953539
[INFO] --------------------------------------------------------------------------------

WF-TR-1008 for License data

AEgbert commented 6 months ago

I believe the license in question actually occupies the frequency range 6875-6900 MHz, as the "Frequency Upper Band" field is set to 6900, and the range 6875-6900 MHz matches the 25 MHz bandwidth specified in the emission code. This is also how the frequency is recorded if I lookup this license via the FCC ULS website.

alexcpn commented 6 months ago

frequency upper band is null for most entries (1774661 of 1899312) and is not mentioned also in WF TR-1008. So we use _frequencyassigned as the center frequency and use frequency_assinged $\pm$ bandwidth/2 to get the range

I will do this additional logic wherever this upper band is non null and check

alexcpn commented 6 months ago

With this logic this is exlcuded. Thanks @AEgbert . It would be well to document this in WF-TR-1008

[INFO] Expected Frequency
[INFO] 5925-6300,upperBound:23.0 nominalValue:23.0
[INFO] 6300-6361,upperBound:-1.1 nominalValue:-3.1
[INFO] 6361-6425,upperBound:23.0 nominalValue:23.0
[INFO] 6525-6650,upperBound:23.0 nominalValue:23.0
[INFO] 6676-6875,upperBound:23.0 nominalValue:23.0
[INFO] Calculated Frequency
[INFO] 5925.0-5930.025  psd: 23.0
[INFO] 5930.025-6167.925  psd: 23.0
[INFO] 6167.925-6182.065  psd: 23.0
[INFO] 6182.065-6300.665  psd: 23.0
[INFO] 6300.665-6360.665  psd: -5.073971845592894
[INFO] 6360.665-6419.965  psd: 23.0
[INFO] 6419.965-6425.0  psd: 23.0
[INFO] 6525.0-6540.0  psd: 23.0
[INFO] 6540.0-6575.0  psd: 23.0
[INFO] 6575.0-6580.0  psd: 23.0
[INFO] 6580.0-6650.0  psd: 23.0
[INFO] 6650.0-6675.2  psd: 0
[INFO] 6675.2-6702.5  psd: 23.0
[INFO] 6702.5-6702.53  psd: 23.0
[INFO] 6702.53-6707.47  psd: 23.0
[INFO] 6707.47-6710.0  psd: 23.0
[INFO] 6710.0-6870.0  psd: 23.0
[INFO] 6870.0-6875.0  psd: 23.0
[WARNING] gc=131 cn=85,freq_range=(6365.0, 6385.0),expected_eirp={'nominalValue': 32.5, 'upperBound': 34.5} calc_eirp=30.2 diff=4.30
[INFO] Time in Milliseconds 0:05:32.124538, processed_count=224070

alexcpn commented 6 months ago

It would be well to document this in WF-TR-1008

keeping this open to update this in document.

AEgbert commented 5 months ago

Thanks--I've brought the topic up for inclusion. My understanding is the (as-yet unofficially documented) recommendation for handling this case is that an AFC system should consider incumbents that satisfy the following conditions:

Frequency Assigned is greater than or equal to 5925 and less than 6425 OR Frequency Assigned is greater than or equal to 6525 and less than 6875 OR Frequency Assigned is equal to 6875 and Frequency Upper Band is null.

In other words, if Frequency Assigned is 6875 but Frequency Upper Band is not null, then the AFC system would not need to analyze it.

I'll provide an update here if anything changes regarding this recommendation.

alexcpn commented 5 months ago

@AEgbert , Thanks, this is now more clear and I have changed to handle this

That is treat _frequencyassigned as the centre frequency and do the handling for below to exclude possible outliers

if  (5925 <= frequency_assigned < 6425) or  (6525 <= frequency_assigned < 6875) or \
    (frequency_assigned == 6875 and frequency_upper_band is None):
     consider for processing
else
     ignore processing

I hope this is fine and is what is intended.

One worry I have is that, if frequency_assigned is equal to 6425, we may miss some bands (frequency_assigned- bw/2) if we exclude this. Is this case considered?

Secondly -do we still need to do something like the below assuming that the frequency upper band is capped for some receivers to < (center_frequency + bandwidth/2 ) if the frequency_upper_band is present with some value in ULS; and it has passed the above filter and is considered for processing

 if not frequency_upper_band:
      center_freq = frequency_assigned
  else:
      lower_band = frequency_assigned - bandwidth_Mhz/2 #assuming frequency_assiged is center frequency
      # but upper frequency may be capped; so adjusting center_freq to correct one
      center_freq= (lower_band + frequency_upper_band)/2
      log.info(f"Handling UUID {receiver.uuid} upper_band {frequency_upper_band} frequency_assigned {frequency_assigned}  bandwidth {bandwidth_Mhz} center_freq={center_freq}")
      assert frequency_upper_band <=center_freq + bandwidth_Mhz/2

Entries I found in ULS possibly for above

 SELECT unique_system_identifier, frequency_assigned,frequency_upper_band
        FROM frequency
        WHERE frequency_assigned >= 5925  AND frequency_assigned <6425 
        AND frequency_upper_band is not null and frequency_upper_band <> 6425

967060     5925.00000000    6525.00000000
1014394    5945.20000000    6123.10000000
1004982    5925.00000000    6424.00000000

    SELECT unique_system_identifier, frequency_assigned,frequency_upper_band
        FROM frequency
        WHERE frequency_assigned >= 6525  AND frequency_assigned <6875 
        AND frequency_upper_band is not null and frequency_upper_band <> 6875

2426010 6815.00000000   6827.50000000
2342105 6585.00000000   6745.00000000
2342106 6585.00000000   6745.00000000
2360998 6565.00000000   6645.00000000

AEgbert commented 5 months ago

In response to your question about entries with an assigned frequency of 6425:

One worry I have is that, if frequency_assigned is equal to 6425, we may miss some bands (frequency_assigned- bw/2) if we exclude this. Is this case considered?

I'll raise this question during any discussions around documenting this recommendation (i.e., does 6425 with null-valued upper frequency need a special case like with 6875).

In response to the ULS entries you found:

967060 5925.00000000 6525.00000000

This license appears to be expired.

1014394 5945.20000000 6123.10000000

This license appears to have three frequencies filed for the location in question. All three have an emission code of 30M0D7W, and frequencies of 5945.2, 6123.1, and also 5945.2-6123.1. If I had to guess (i.e., this is not official guidance), the entry spanning 5945.2-6123.1 is an error.

1004982 5925.00000000 6424.00000000

This license appears to be expired.

2426010 6815.00000000 6827.50000000

This entry appears to satisfy the emission code (25M0D7W) with a frequency span centered at 6815 and an upper frequency of 6827.5.

2342105 6585.00000000 6745.00000000

This license appears to be expired.

2342106 6585.00000000 6745.00000000

This license appears to be expired.

2360998 6565.00000000 6645.00000000

This license appears to be expired.

AEgbert commented 4 months ago

@alexcpn, I’ve been advised that 6425 should be handled in a similar manner to 6875 (i.e., should be included when upper frequency band is null). Thank you for noticing this!

Wireless-Innovation-Forum / 6-GHz-AFC

AFCS.SIP.1 ULS data version related doubt #52

More details