Clarification regarding Frequency Range AvailableSpectrumInquiryRequests and Response framing

[alexcpn]

In the request_sample.json the frequency range is given as 5925-6425, the U-NNNI-5 range. This is the same given in the sample request at AFC System to AFC Device Interface Specification Version 1.4.1 document by WifiAlliance

    "inquiredFrequencyRange": [
        {
          "lowFrequency": 5925,
          "highFrequency": 6425
        }

However, in the response_sample.json the response is given as the following frequency range. This is similar to the sample response at AFC System to AFC Device Interface Specification Version 1.4.1 document

      "availableFrequencyInfo": [
                {
                    "frequencyRange": {
                        "lowFrequency": 5925,
                        "highFrequency": 6020
                    },
                    "maxPsd": 23.0
                },
                {
                    "frequencyRange": {
                        "lowFrequency": 6020,
                        "highFrequency": 6050
                    },
                    "maxPsd": 1.0
                },
                {
                    "frequencyRange": {
                        "lowFrequency": 6050,
                        "highFrequency": 6360
                    },
                    "maxPsd": 23.0
                },
                {
                    "frequencyRange": {
                        "lowFrequency": 6360,
                        "highFrequency": 6390
                    },
                    "maxPsd": -24.0
                },
                {
                    "frequencyRange": {
                        "lowFrequency": 6390,
                        "highFrequency": 6425
                    },
                    "maxPsd": 23.0
                }
            ],

It is not clear how these frequency ranges are derived. I have calculated the frequency range and channels according to the 80211.ax 2021 specification see wifi6GHz channels.pdf and I cannot find these valid ranges ex 5925-6020 (95 MHz Bandwidth ??). The closest valid range is the (5945, 6025) for 80 MHz. What am I missing?

[AEgbert]

Hi Alex, thanks for the question.

My understanding is that the frequency-based availability info is not made with any consideration for WiFi channels. Rather, it is a more "raw" look at the available spectrum, which could be used by e.g., non-WiFi devices. The ranges are determined by the frequency bands of the incumbent users corresponding to each power limit.

For instance, looking at the 5925-6020 range you mentioned, the 23.0 dBm/MHz limit implies that no incumbents in that frequency range require a more limited power level. However, an incumbent does exist between 6020-6050 MHz that is resulting in a 1 dBm/MHz limit.

If this doesn't fully answer your question, let me know and I'll try to track down someone else who can provide a more detailed answer.

[alexcpn]

Thanks @AEgbert for the clarification. Sorry I have some follow-up clarification still.

So can this response

   {
                    "frequencyRange": {
                        "lowFrequency": 5925,
                        "highFrequency": 6020
                    },
                    "maxPsd": 23.0
                },

be interpreted as that the Wifi device, or any device using frequency between 5925 to 6020 in any of the 20 MHz, 40 MHz, 80 MHz or 160 MHz band, need to limit max PSD to 23.0 dBm/MHz limit.

I am not a radio engineer, but what I found is that PSD is related to bandwidth via

Max PSD (dBm/MHz) = Max EIRP (dBm) - 10 * log10(Bandwidth)

If that is right, then between these two frequencies (5925-6020), for all the different BW (20,40,80,160 MHz) one need to calculate the Max EIRP and Max PSD and take the lowest possible of these as the resultant maxPsd ??

[AEgbert]

Apologies for the delay in my response.

I believe your final note is correct (one should use the most restrictive of the EIRP and PSD limits). The FCC's max EIRP and max PSD limits are equivalent for a 20 MHz channel (see FCC 6GHz Report and Order, note 55). For bandwidths greater than 20 MHz, the realized PSD would be less than the AFC's provided PSD limit for the emission to remain below the FCC's EIRP limit. For bandwidths less than 20 MHz, the realized EIRP would be less than the FCC's EIRP limit for the emission to remain below the PSD limit.

In your example, a device operating with a 40 MHz channel within the 5925-6020 MHz range would need to maintain a PSD less than 23 dBm/MHz to comply with the overall 36 dBm EIRP limit. A device would not be permitted to use 23 dBm/MHz over a 40 MHz channel, as this would exceed the 36 dBm EIRP limit.

I hope this helps answer your question. Let me know if you have any more follow-up questions.

[alexcpn]

Thanks for the clarification @AEgbert . I am working on a slightly different part and it is taking time; I will come back to this and close in a short time. thanks again

[alexcpn]

Sorry for the delay in responding here. I was trying to check how to verify this.

However, an incumbent does exist between 6020-6050 MHz that is resulting in a 1 dBm/MHz limit.

From ULS data ( wget https://media.githubusercontent.com/media/Wi-FiTestSuite/6GHz-AFC/17656cc709795a704bbbd7eeda5bfbb67b2560ef/ULS_database/FCC/weekly/l_micro_211024_modified_PA.zip) I am able to find the call sign and ULS id and other details of the MW towers but not the location

But to get the location of all MW towers near this Access Point given in the example request (request_sample.json using the ULS license search API seems not possible directly?

It just provides some high-level information

'https://data.fcc.gov/api/license-view/basicSearch/getLicenses?format=json&searchValue={uls_id}&api_key={api_key}'

Ouput

 #{'status': 'OK', 'Licenses': {'page': '1', 'rowPerPage': '100', 'totalRows': '1', 'lastUpdate': 'Jun 21, 2023', 'License': [{'licName': 'GRAHAM MEDIA GROUP, MICHIGAN, INC.', 'frn': '0002161123', 'callsign': 'KC26392', 'categoryDesc': 'Broadcast Support', 'serviceDesc': 'TV Pickup', 'statusDesc': 'Active', 'expiredDate': '10/01/2029', 'licenseID': '957264', 'licDetailURL': 'http://wireless2.fcc.gov/UlsApp/UlsSearch/license.jsp?__newWindow=false&licKey=957264'}]}

It seems then that to get the location of the incumbents near the AP and the frequency at which they operate I need to go to the ULS license webpage and get the details via web-search.

Unfortunately, this webpage seems to be not that stable and is down for maintenance. Is there any other API other than crawling through the web interface to get this info?

[AEgbert]

Hi Alex,

The sample request and response files come from the Wi-Fi Alliance interface specification (available here, AFC System to AFC Device Interface Specification v1.5.pdf). How exactly those sample files were developed is outside of my expertise, and beyond the scope of the test harness itself, unfortunately. My earlier statement about an incumbent existing in that band was an inference from the example response (that is, the response can be read as saying that some incumbent exists that requires a 1 dBm/MHz limit for that frequency range). While I believe the example files are based on actual data (and thus it should be possible to reverse engineer the response and find that incumbent), I do not know that for certain.

I'll bring your question to the attention of the broader test and cert group within WInnForum, asking them to provide their input as well. My hope is someone may be able to answer your questions with more certainty.

[w4je]

The examples in the Wi-Fi Alliance interface specification are purely imaginary examples. They do not represent any real device and the response does not represent any real consideration for incumbents. It is an interface example, not an example AFC system calculation. The request and response examples were originally created before the rules and standards for doing AFC system calculations existed. To be clear, they only demonstrate the interface format, nothing else.

[alexcpn]

Thanks, @AEgbert @w4je for the response. This is clear in the examples of sample requests and responses in the interface document.

However, I was mentioning, in the context of this test repo document the request and response and its values

https://github.com/Wireless-Innovation-Forum/6-GHz-AFC/blob/main/src/harness/request_sample.json and the response sample

https://github.com/Wireless-Innovation-Forum/6-GHz-AFC/blob/5b7234c10417fd668e233f44a2bc3d0d9d25520b/src/harness/response_sample.json

1. Are these just initial files to test the harness itself and will then the official files be having proper requests and responses?
2. To test the official request and response (assuming that it will come in future) how is one to find the location of the incumbent from the ULS data? From exploring the ULS API, there seems to be no way to get location information other than through ULS webpage access. The difficulty also is mentioned in this paper where the authors have scraped the web pages for it https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3897187. The access is slow and frequently times out.
3. Can this location data for the incumbents also be stored in https://github.com/Wireless-Innovation-Forum/6-GHz-AFC/tree/main/data/uls-snapshot

[AEgbert]

Hi Alex,

Per @w4je’s response, the *_sample.json files in the harness repository are merely example files that show the expected JSON format of any requests, responses, and expected response masks.

The actual requests for use in testing are included in src/harness/inquiries, and the expected response masks (generated using the linked ULS snapshot) are in src/harness/masks. These are available in this repository and are sourced from the Wi-Fi Alliance: https://www.wi-fi.org/file/afc-specification-and-test-plans

Location data for the incumbents should be available in the snapshot that you linked. Documentation for the format of ULS snapshots is provided by the FCC here: https://www.fcc.gov/wireless/data/public-access-files-database-downloads. Based on my understanding, the location data should be available in the LO.dat file. If you have additional questions about the ULS data, you may wish to get in touch with the FCC via the “Questions and Support” link provided on the documentation page I linked above.

[alexcpn]

@AEgbert thanks for the clarification. This clears a lot of doubts. Thank you very much. I see that the harness files are added here https://github.com/Wireless-Innovation-Forum/6-GHz-AFC/tree/main/src/harness about two weeks back. Is the test harness ready for use or still under development? Thanks once again

[AEgbert]

The test harness is ready for use. We may have some additional, minor edits as people begin to use the harness and report any issues or feedback, but the core functionality should be ready. I'm not anticipating any significant breaking changes to the harness functionality or configuration at this time.

EDIT: We also may add some separate utility scripts at a later date, but these will not be used by or impact the main test_harness script.

[alexcpn]

Thanks for the clarification. I have doubt regarding the response value and what is mentioned in the interface sepc

In the interface specification (AFC System to AFC Device Interface Specification v1.5), it is mentioned in the availableSpectrumInquiryResponses (Appendix A) the maxEIRP as

"availableChannelInfo" :
[
{
"globalOperatingClass" : 133,
"channelCfi" : [7, 39, 55, 71, 135, 151, 167],
"maxEirp" : [27.8, 36, 36, 36, 36, 33.0, 36]
},

However, in the response mask, it is given as

        "maxEirp": [
                        {
                            "nominalValue": 27.8,
                            "upperBound": 30,
                            "lowerBound": 22
                        },

mask_sample.json

There is no mention in the JSON spec in the interface document of nominalValue, upperBound and lowerBound.

Since the messages are in JSON, the JSON schema with and without these are different. Should we follow the JSON spec or the response mask format. Or will the interface spec be updated with these later ?

Also, for a channel, does nominalValue correspond to the EIRP calculated for the centre channel frequency, and the upperBound for the lower frequency and lowerBound for the EIRP for upper frequency of the channel

[AEgbert]

Since the messages are in JSON, the JSON schema with and without these are different. Should we follow the JSON spec or the response mask format. Or will the interface spec be updated with these later ?

As you've noticed, an AFC system's response and the SUT test harness response mask have different formats. The AFC system response follows the format of the System to Device Interface Specification. Meanwhile, the SUT test harness response mask dictates the values expected to be included in an AFC's response, and its format is documented as part of its implementation in src/harness/expected_inquiry_response.py.

The response mask format differs from the response format, as the mask must include information beyond what the base response definition permits (for example: multiple possible response codes for various error responses). The response mask format also excludes information that cannot be sensibly included in a response mask, but would be required in a valid response (for example: availabilityExpireTime).

There is no mention in the JSON spec in the interface document of nominalValue, upperBound and lowerBound.

Regarding nominalValue, upperBound, and lowerBound: these are fields of the ExpectedPowerRange class in src/harness/expected_inquiry_response.py. Each channel or frequency range in the response mask will have an ExpectedPowerRange instance defining the expected range of powers (either EIRP or PSD) associated with a given channel or frequency range. nominalValue does not impact the outcome of a test, but is an optional field providing documentation of the "canonical" expected value. As AFC systems may return different, acceptable values for the same request, upperBound and lowerBound are included to define the acceptable range of responses for test purposes. When applied to an AFC System's response, the test harness will ensure that any frequency range's PSD or channel's EIRP value in the response will fall within the upperBound and lowerBound for that frequency or channel.

For the test vectors included with the harness (src/harness/masks), lowerBound is excluded, which defaults to a value of -Infinity. In other words, any response below upperBound is accepted by the test harness. The nominalValue is the average value agreed upon by Wi-Fi Alliance, to which a 2dB margin is permitted (limited to the maximum value permitted by regulation), resulting in the value for upperBound.

Also, for a channel, does nominalValue correspond to the EIRP calculated for the centre channel frequency, and the upperBound for the lower frequency and lowerBound for the EIRP for upper frequency of the channel

The ExpectedPowerRange's upperBound and lowerBound (if present/not -Infinity) for each frequency range and channel are applied uniformly over the entire channel or frequency range. For channels, the max EIRP applies to the entire channel as a whole (as EIRP references the integrated power of the transmitter).