Add support for wireless regulatory provisioning
jaylogue opened this issue · 10 comments
PROPOSED: Extend the Weave Network Provisioning profile with features to support runtime provisioning of wireless regulatory configuration on devices.
To support wireless regulatory provisioning, it is proposed to extend the Network Provisioning profile with three new message types, comprising two new protocol patterns.
SetWirelessRegulatoryConfig (msg type 15)
The SetWirelessRegulatoryConfig message updates a device with new wireless regulatory configuration information. Information conveyed with the message describes the operating location of the device with respect to regulations governing wireless radio transmissions. The payload of a SetWirelessRegulatoryConfig message consists of the following TLV structure:
SetWirelessRegulatoryConfigArguments [anon] => STRUCTURE
{
/** ISO 3166-1 country code, or “00” for world-wide.
*/
regulatoryDomain [1, optional] : STRING [len 2],
/** Operating location relevant to wireless regulatory rules.
*/
operatingLocation [2, optional] : UNSIGNED INTEGER [range 0..255]
{
reserved = 0, /* may not be sent. */
unknown = 1,
indoors = 2,
outdoors = 3
}
}
The regulatoryDomain argument must identify the country in which the device is or will be operated, OR another country that is subject to the same or compatible regulatory rules as the operating country. Additionally, the special value “00” may be supplied to indicate the device should operate in a mode which is compatible with all regulatory rules world-wide.
The operatingLocation argument identifies a logical location in which the device is or will be operated that may be relevant to the regulatory rules of the operating country. This value is an integer enumeration that may be extended over time. The unknown operating location signifies that the device's specific operating location is not known, or that it may change over time. (Note that the reserved value may not be sent in any message).
The values specified for regulatoryDomain and operatingLocation govern the transmission behavior of all radios built-in to the device. This includes WiFi and 802.15.4 radios, if so provisioned. The effects of setting wireless regulatory configuration should be persistent on the device at least until the device is factory reset.
Either or both the regulatoryDomain or operationLocation arguments may be absent in a SetWirelessRegulatoryConfig message. If an argument is not present, then its corresponding current value on the target device is not changed.
The response to a SetWirelessRegulatoryConfig message is always a Common:StatusReport message containing the status of the request. Devices that do not support the SetWirelessRegulatoryConfig message must return the Common:UnsupportedMessage status. If a device supports the SetWirelessRegulatoryConfig message but does not support the specified regulatoryDomain, it must return the status code NetworkProvisioning:UnsupportedRegulatoryDomain (12). If a device does not support the specified operatingMode, it must return the new status code NetworkProvisioning:UnsupportedOperatingLocation (13).
Devices must implement suitable access controls for SetWirelessRegulatoryConfig requests. In general, requests should be subject to the same access control rules as NetworkProvisioning:AddNetwork requests.
A SetWirelessRegulatoryConfig message must always be the first message in a Weave exchange, and the Common:StatusReport response to the message always marks the end of the exchange.
GetWirelessRegulatoryConfig (msg type 16)
The GetWirelessRegulatoryConfig message fetches the wireless regulatory configuration information from a device. The GetWirelessRegulatoryConfig message has no payload.
The response to a GetWirelessRegulatoryConfig message is either a GetWirelessRegulatoryConfigComplete message if the request was successful, or a Common:StatusReport message containing an error status. Devices that do not support the GetWirelessRegulatoryConfig request must return the Common:UnsupportedMessage status.
Devices must implement suitable access controls for GetWirelessRegulatoryConfig requests. In general, requests should be subject to the same access control rules as NetworkProvisioning:GetNetwork requests where network passwords are not being requested.
A GetWirelessRegulatoryConfig message must always be the first message in a Weave exchange. The response to the GetWirelessRegulatoryConfig message (either a GetWirelessRegulatoryConfigComplete or a Common:StatusReport) always marks the end of the exchange.
GetWirelessRegulatoryConfigComplete (msg type 17)
The GetWirelessRegulatoryConfigComplete message conveys wireless regulatory configuration information from a device in response to a GetWirelessRegulatoryConfig message. The payload of a GetWirelessRegulatoryConfigComplete message consists of the following TLV structure:
GetWirelessRegulatoryConfigResults [anon] => STRUCTURE
{
/** ISO 3166-1 country code, or “00” for world-wide, or
* null if unknown.
*/
regulatoryDomain [1] : STRING [len 2, nullable],
/** Operating location relevant to wireless regulatory rules,
* or null if unknown.
*/
operatingLocation [2] : UNSIGNED INTEGER [range 0..255, nullable]
{
reserved = 0, /* may not be sent. */
unknown = 1,
indoors = 2,
outdoors = 3
},
/** List of support regulatory domains.
*/
supportedRegulatoryDomains [3] : ARRAY OF STRING [len 2]
}
The regulatoryDomain result identifies the country whose regulatory rules the device is operating under, or “00” if the device is operating in a mode which is compatible with all regulatory rules world-wide.
The operatingLocation result identifies the regulatory-specific logical location in which the device has been configured to operate.
The supportedRegulatoryDomains result contains a list of all country codes that the device is capable of accepting in the regulatoryDomain argument of a SetWirelessRegulatoryConfig message. The list must NOT include the “00” special value.
A device implementation may opt to not persist either or both of the regulatoryDomain and operatingLocation values, choosing instead to persist internal radio settings corresponding to effective regulations implied by those values. In this case, a device can return null for the regulatoryDomain and operatingLocation values. Note that the unknown operatingLocation value should not be returned in this case.
The GetWirelessRegulatoryConfigComplete message must only be sent in response to a GetWirelessRegulatoryConfig message, and therefore can never be the first message in an exchange.
@gerickson, @robszewczyk, @mrjerryjohns : Based on recent discussions, it has been suggested that the Network Provisioning profile be extended to support wireless regulatory configuration during OOB, as needed by some products. Here is a proposal for how I see that working. Let me know what you think.
We've had a body of historical and currently-active work on this front in Nest and Google Nest products to date. I've shared an internal document that memorializes that work.
It mostly harmonizes with the Linux Wireless Regulatory Database and CRDA where the Indoor / Outdoor notion here is represented there as FLAGS:
| Flag | Description |
|---|---|
| NO-OFDM | OFDM modulation not allowed. |
| NO-CCK | CCK modulation not allowed. |
| NO-INDOOR | Indoor operation not allowed. |
| NO-OUTDOOR | Outdoor operation not allowed. |
| DFS | Dynamic Frequency Selection (DFS) is required. |
| PTP-ONLY | May only be used for point-to-point links. |
| PTMP-ONLY | May only be used for point-to-multipoint links. |
| PASSIVE-SCAN | Passive scanning is required (no active (probe) scans are allowed). |
| NO-IBSS | Independent Basic Service Set (IBSS) (ad-hoc) networks are not allowed. |
If we can see a path to only doing here what's necessary for use cases in front of us while extending to incorporate the fullness of "Linux Wireless Regulatory Database and CRDA" in the future, if needed, then I think we're good.
That document also describes values for operatingCountry as:
| Mnemonic | Code | Description |
|---|---|---|
| kRegulatoryDomainUnknown | ?? | Unknown or unspecified domain. |
| kRegulatoryDomainWorldwide | 00 | World-wide, restrictive domain. |
Table 1. Other Regulatory Domain Codes
| Mnemonic | Code | Description |
|---|---|---|
| kRegulatoryDomainAgencyDOC | A0 | Canadian Department of Communications |
| kRegulatoryDomainAgencyIC | A0 | Industry Canada |
| kRegulatoryDomainAgencyETSI | A1 | European Telecommunications Standards Institute |
| kRegulatoryDomainAgencyFCC | A2 | United States Federal Communications Commission |
| kRegulatoryDomainAgencyARIB | A3 | Japanese Association of Radio Industries and Businesses |
| kRegulatoryDomainAgencyMIC | A3 | Japanese Ministry of Internal Affairs and Communications |
| kRegulatoryDomainAgencyMKK | A3 | Japanese Ministry of Telecommunications |
| kRegulatoryDomainAgencyTELEC | A3 | Japanese Telecommunications Engineering Center |
| kRegulatoryDomainAgencyKC | A4 | Korean Certification |
| kRegulatoryDomainAgencyNCC | A5 | Taiwanese National Communications Commission |
Table 2. Agency-specific Regulatory Domain Codes
| Mnemonic | Code | Description |
|---|---|---|
| kRegulatoryDomainCountryAD | AD | Andorra |
| kRegulatoryDomainCountryAE | AE | United Arab Emirates |
| kRegulatoryDomainCountryAF | AF | Afghanistan |
| kRegulatoryDomainCountryAG | AG | Antigua and Barbuda |
| kRegulatoryDomainCountryAI | AI | Anguilla |
| kRegulatoryDomainCountryAL | AL | Albania |
| kRegulatoryDomainCountryAM | AM | Armenia |
| kRegulatoryDomainCountryAO | AO | Angola |
| kRegulatoryDomainCountryAQ | AQ | Antarctica |
| kRegulatoryDomainCountryAR | AR | Argentina |
| kRegulatoryDomainCountryAS | AS | American Samoa |
| kRegulatoryDomainCountryAT | AT | Austria |
| kRegulatoryDomainCountryAU | AU | Australia |
| kRegulatoryDomainCountryAW | AW | Aruba |
| kRegulatoryDomainCountryAX | AX | Åland Islands |
| kRegulatoryDomainCountryAZ | AZ | Azerbaijan |
| kRegulatoryDomainCountryBA | BA | Bosnia and Herzegovina |
| kRegulatoryDomainCountryBB | BB | Barbados |
| kRegulatoryDomainCountryBD | BD | Bangladesh |
| kRegulatoryDomainCountryBE | BE | Belgium |
| kRegulatoryDomainCountryBF | BF | Burkina Faso |
| kRegulatoryDomainCountryBG | BG | Bulgaria |
| kRegulatoryDomainCountryBH | BH | Bahrain |
| kRegulatoryDomainCountryBI | BI | Burundi |
| kRegulatoryDomainCountryBJ | BJ | Benin |
| kRegulatoryDomainCountryBL | BL | Saint Barthélemy |
| kRegulatoryDomainCountryBM | BM | Bermuda |
| kRegulatoryDomainCountryBN | BN | Brunei Darussalam |
| kRegulatoryDomainCountryBO | BO | Bolivia |
| kRegulatoryDomainCountryBQ | BQ | Bonaire, Sint Eustatius and Saba |
| kRegulatoryDomainCountryBR | BR | Brazil |
| kRegulatoryDomainCountryBS | BS | Bahamas |
| kRegulatoryDomainCountryBT | BT | Bhutan |
| kRegulatoryDomainCountryBV | BV | Bouvet Island |
| kRegulatoryDomainCountryBW | BW | Botswana |
| kRegulatoryDomainCountryBY | BY | Belarus |
| kRegulatoryDomainCountryBZ | BZ | Belize |
| kRegulatoryDomainCountryCA | CA | Canada |
| kRegulatoryDomainCountryCC | CC | Cocos Islands |
| kRegulatoryDomainCountryCD | CD | Congo Democratic Republic |
| kRegulatoryDomainCountryCF | CF | Central African Republic |
| kRegulatoryDomainCountryCG | CG | Congo |
| kRegulatoryDomainCountryCH | CH | Switzerland |
| kRegulatoryDomainCountryCI | CI | Côte d'Ivoire |
| kRegulatoryDomainCountryCK | CK | Cook Islands |
| kRegulatoryDomainCountryCL | CL | Chile |
| kRegulatoryDomainCountryCM | CM | Cameroon |
| kRegulatoryDomainCountryCN | CN | China |
| kRegulatoryDomainCountryCO | CO | Colombia |
| kRegulatoryDomainCountryCR | CR | Costa Rica |
| kRegulatoryDomainCountryCU | CU | Cuba |
| kRegulatoryDomainCountryCV | CV | Cape Verde |
| kRegulatoryDomainCountryCW | CW | Curaçao |
| kRegulatoryDomainCountryCX | CY | Cyprus |
| kRegulatoryDomainCountryCY | CX | Christmas Island |
| kRegulatoryDomainCountryCZ | CZ | Czech Republic |
| kRegulatoryDomainCountryDE | DE | Germany |
| kRegulatoryDomainCountryDJ | DJ | Djibouti |
| kRegulatoryDomainCountryDK | DK | Denmark |
| kRegulatoryDomainCountryDM | DM | Dominica |
| kRegulatoryDomainCountryDO | DO | Dominican Republic |
| kRegulatoryDomainCountryDZ | DZ | Algeria |
| kRegulatoryDomainCountryEC | EC | Ecuador |
| kRegulatoryDomainCountryEE | EE | Estonia |
| kRegulatoryDomainCountryEG | EG | Egypt |
| kRegulatoryDomainCountryEH | EH | Western Sahara |
| kRegulatoryDomainCountryER | ER | Eritrea |
| kRegulatoryDomainCountryES | ES | Spain |
| kRegulatoryDomainCountryET | ET | Ethiopia |
| kRegulatoryDomainCountryFI | FI | Finland |
| kRegulatoryDomainCountryFJ | FJ | Fiji |
| kRegulatoryDomainCountryFK | FK | Falkland Islands |
| kRegulatoryDomainCountryFM | FM | Micronesia |
| kRegulatoryDomainCountryFO | FO | Faroe Islands |
| kRegulatoryDomainCountryFR | FR | France |
| kRegulatoryDomainCountryGA | GA | Gabon |
| kRegulatoryDomainCountryGB | GB | United Kingdom |
| kRegulatoryDomainCountryGD | GD | Grenada |
| kRegulatoryDomainCountryGE | GE | Georgia |
| kRegulatoryDomainCountryGF | GF | French Guiana |
| kRegulatoryDomainCountryGG | GG | Guernsey |
| kRegulatoryDomainCountryGH | GH | Ghana |
| kRegulatoryDomainCountryGI | GI | Gibraltar |
| kRegulatoryDomainCountryGL | GL | Greenland |
| kRegulatoryDomainCountryGM | GM | Gambia |
| kRegulatoryDomainCountryGN | GN | Guinea |
| kRegulatoryDomainCountryGP | GP | Guadeloupe |
| kRegulatoryDomainCountryGQ | GQ | Equatorial Guinea |
| kRegulatoryDomainCountryGR | GR | Greece |
| kRegulatoryDomainCountryGS | GS | South Georgia |
| kRegulatoryDomainCountryGT | GT | Guatemala |
| kRegulatoryDomainCountryGU | GU | Guam |
| kRegulatoryDomainCountryGW | GW | Guinea Bissau |
| kRegulatoryDomainCountryGY | GY | Guyana |
| kRegulatoryDomainCountryHK | HK | Hong Kong |
| kRegulatoryDomainCountryHM | HM | Heard and McDonald Islands |
| kRegulatoryDomainCountryHN | HN | Honduras |
| kRegulatoryDomainCountryHR | HR | Croatia |
| kRegulatoryDomainCountryHT | HT | Haiti |
| kRegulatoryDomainCountryHU | HU | Hungary |
| kRegulatoryDomainCountryID | ID | Indonesia |
| kRegulatoryDomainCountryIE | IE | Ireland |
| kRegulatoryDomainCountryIL | IL | Israel |
| kRegulatoryDomainCountryIM | IM | Isle of Man |
| kRegulatoryDomainCountryIN | IN | India |
| kRegulatoryDomainCountryIO | IO | British Indian Ocean Territory |
| kRegulatoryDomainCountryIQ | IQ | Iraq |
| kRegulatoryDomainCountryIR | IR | Iran |
| kRegulatoryDomainCountryIS | IS | Iceland |
| kRegulatoryDomainCountryIT | IT | Italy |
| kRegulatoryDomainCountryJE | JE | Jersey |
| kRegulatoryDomainCountryJM | JM | Jamaica |
| kRegulatoryDomainCountryJO | JO | Jordan |
| kRegulatoryDomainCountryJP | JP | Japan |
| kRegulatoryDomainCountryKE | KE | Kenya |
| kRegulatoryDomainCountryKG | KG | Kyrgyzstan |
| kRegulatoryDomainCountryKH | KH | Cambodia |
| kRegulatoryDomainCountryKI | KI | Kiribati |
| kRegulatoryDomainCountryKM | KM | Comoros |
| kRegulatoryDomainCountryKN | KN | Saint Kitts and Nevis |
| kRegulatoryDomainCountryKP | KP | North Korea |
| kRegulatoryDomainCountryKR | KR | South Korea |
| kRegulatoryDomainCountryKW | KW | Kuwait |
| kRegulatoryDomainCountryKY | KY | Cayman Islands |
| kRegulatoryDomainCountryKZ | KZ | Kazakhstan |
| kRegulatoryDomainCountryLA | LA | Lao |
| kRegulatoryDomainCountryLB | LB | Lebanon |
| kRegulatoryDomainCountryLC | LC | Saint Lucia |
| kRegulatoryDomainCountryLI | LI | Liechtenstein |
| kRegulatoryDomainCountryLK | LK | Sri Lanka |
| kRegulatoryDomainCountryLR | LR | Liberia |
| kRegulatoryDomainCountryLS | LS | Lesotho |
| kRegulatoryDomainCountryLT | LT | Lithuania |
| kRegulatoryDomainCountryLU | LU | Luxembourg |
| kRegulatoryDomainCountryLV | LV | Latvia |
| kRegulatoryDomainCountryLY | LY | Libya |
| kRegulatoryDomainCountryMA | MA | Morocco |
| kRegulatoryDomainCountryMC | MC | Monaco |
| kRegulatoryDomainCountryMD | MD | Moldova |
| kRegulatoryDomainCountryME | ME | Montenegro |
| kRegulatoryDomainCountryMF | MF | Saint Martin |
| kRegulatoryDomainCountryMG | MG | Madagascar |
| kRegulatoryDomainCountryMH | MH | Marshall Islands |
| kRegulatoryDomainCountryMK | MK | Macedonia |
| kRegulatoryDomainCountryML | ML | Mali |
| kRegulatoryDomainCountryMM | MM | Myanmar |
| kRegulatoryDomainCountryMN | MN | Mongolia |
| kRegulatoryDomainCountryMO | MO | Macao |
| kRegulatoryDomainCountryMP | MP | Northern Mariana Islands |
| kRegulatoryDomainCountryMQ | MQ | Martinique |
| kRegulatoryDomainCountryMR | MR | Mauritania |
| kRegulatoryDomainCountryMS | MS | Montserrat |
| kRegulatoryDomainCountryMT | MT | Malta |
| kRegulatoryDomainCountryMU | MU | Mauritius |
| kRegulatoryDomainCountryMV | MV | Maldives |
| kRegulatoryDomainCountryMW | MW | Malawi |
| kRegulatoryDomainCountryMX | MX | Mexico |
| kRegulatoryDomainCountryMY | MY | Malaysia |
| kRegulatoryDomainCountryMZ | MZ | Mozambique |
| kRegulatoryDomainCountryNA | NA | Namibia |
| kRegulatoryDomainCountryNC | NC | New Caledonia |
| kRegulatoryDomainCountryNE | NE | Niger |
| kRegulatoryDomainCountryNF | NF | Norfolk Island |
| kRegulatoryDomainCountryNG | NG | Nigeria |
| kRegulatoryDomainCountryNI | NI | Nicaragua |
| kRegulatoryDomainCountryNL | NL | Netherlands |
| kRegulatoryDomainCountryNO | NO | Norway |
| kRegulatoryDomainCountryNP | NP | Nepal |
| kRegulatoryDomainCountryNR | NR | Nauru |
| kRegulatoryDomainCountryNU | NU | Niue |
| kRegulatoryDomainCountryNZ | NZ | New Zealand |
| kRegulatoryDomainCountryOM | OM | Oman |
| kRegulatoryDomainCountryPA | PA | Panama |
| kRegulatoryDomainCountryPE | PE | Peru |
| kRegulatoryDomainCountryPF | PF | French Polynesia |
| kRegulatoryDomainCountryPG | PG | Papua New Guinea |
| kRegulatoryDomainCountryPH | PH | Philippines |
| kRegulatoryDomainCountryPK | PK | Pakistan |
| kRegulatoryDomainCountryPL | PL | Poland |
| kRegulatoryDomainCountryPM | PM | Saint Pierre and Miquelon |
| kRegulatoryDomainCountryPN | PN | Pitcairn |
| kRegulatoryDomainCountryPR | PR | Puerto Rico |
| kRegulatoryDomainCountryPS | PS | Palestine |
| kRegulatoryDomainCountryPT | PT | Portugal |
| kRegulatoryDomainCountryPW | PW | Palau |
| kRegulatoryDomainCountryPY | PY | Paraguay |
| kRegulatoryDomainCountryQA | QA | Qatar |
| kRegulatoryDomainCountryRE | RE | Reunion |
| kRegulatoryDomainCountryRO | RO | Romania |
| kRegulatoryDomainCountryRS | RS | Serbia |
| kRegulatoryDomainCountryRU | RU | Russia |
| kRegulatoryDomainCountryRW | RW | Rwanda |
| kRegulatoryDomainCountrySA | SA | Saudi Arabia |
| kRegulatoryDomainCountrySB | SB | Solomon Islands |
| kRegulatoryDomainCountrySC | SC | Seychelles |
| kRegulatoryDomainCountrySD | SD | Sudan |
| kRegulatoryDomainCountrySE | SE | Sweden |
| kRegulatoryDomainCountrySG | SG | Singapore |
| kRegulatoryDomainCountrySH | SH | Saint Helena, Ascension and Tristan da Cunha |
| kRegulatoryDomainCountrySI | SI | Slovenia |
| kRegulatoryDomainCountrySJ | SJ | Svalbard and Jan Mayen |
| kRegulatoryDomainCountrySK | SK | Slovakia |
| kRegulatoryDomainCountrySL | SL | Sierra Leone |
| kRegulatoryDomainCountrySM | SM | San Marino |
| kRegulatoryDomainCountrySN | SN | Senegal |
| kRegulatoryDomainCountrySO | SO | Somalia |
| kRegulatoryDomainCountrySR | SR | Suriname |
| kRegulatoryDomainCountrySS | SS | South Sudan |
| kRegulatoryDomainCountryST | ST | Sao Tome and Principe |
| kRegulatoryDomainCountrySV | SV | El Salvador |
| kRegulatoryDomainCountrySX | SX | Sint Maarten |
| kRegulatoryDomainCountrySY | SY | Syria |
| kRegulatoryDomainCountrySZ | SZ | Swaziland |
| kRegulatoryDomainCountryTC | TC | Turks and Caicos Islands |
| kRegulatoryDomainCountryTD | TD | Chad |
| kRegulatoryDomainCountryTF | TF | French Southern Territories |
| kRegulatoryDomainCountryTG | TG | Togo |
| kRegulatoryDomainCountryTH | TH | Thailand |
| kRegulatoryDomainCountryTJ | TJ | Tajikistan |
| kRegulatoryDomainCountryTK | TK | Tokelau |
| kRegulatoryDomainCountryTL | TL | Timor-Leste |
| kRegulatoryDomainCountryTM | TM | Turkmenistan |
| kRegulatoryDomainCountryTN | TN | Tunisia |
| kRegulatoryDomainCountryTO | TO | Tonga |
| kRegulatoryDomainCountryTR | TR | Turkey |
| kRegulatoryDomainCountryTT | TT | Trinidad and Tobago |
| kRegulatoryDomainCountryTV | TV | Tuvalu |
| kRegulatoryDomainCountryTW | TW | Taiwan |
| kRegulatoryDomainCountryTZ | TZ | Tanzania |
| kRegulatoryDomainCountryUA | UA | Ukraine |
| kRegulatoryDomainCountryUG | UG | Uganda |
| kRegulatoryDomainCountryUM | UM | United States Minor Outlying Islands |
| kRegulatoryDomainCountryUS | US | United States |
| kRegulatoryDomainCountryUY | UY | Uruguay |
| kRegulatoryDomainCountryUZ | UZ | Uzbekistan |
| kRegulatoryDomainCountryVA | VA | Holy See (Vatican City State) |
| kRegulatoryDomainCountryVC | VC | Saint Vincent and the Grenadines |
| kRegulatoryDomainCountryVE | VE | Venezuela |
| kRegulatoryDomainCountryVG | VG | BritishVirginIslands |
| kRegulatoryDomainCountryVI | VI | USVirginIslands |
| kRegulatoryDomainCountryVN | VN | Vietnam |
| kRegulatoryDomainCountryVU | VU | Vanuatu |
| kRegulatoryDomainCountryWF | WF | Wallis and Futuna |
| kRegulatoryDomainCountryWS | WS | Samoa |
| kRegulatoryDomainCountryYE | YE | Yemen |
| kRegulatoryDomainCountryYT | YT | Mayotte |
| kRegulatoryDomainCountryZA | ZA | South Africa |
| kRegulatoryDomainCountryZM | ZM | Zambia |
| kRegulatoryDomainCountryZW | ZW | Zimbabwe |
Table 3. Country-specific Regulatory Domain Codes
A little more background on this: Initially I was in favor of using a trait to control wireless regulatory configuration. However I was recently convinced that this was a more natural fit for the existing Network Provisioning profile, seeing as it has a strong effect on the process of finding and joining a network.
Another minor benefit to this approach is it possible to implement code-constrained devices that have limited or no support for WDM. An example of this might be a temp sensor device that only emits temp samples as multicast-only subscriptionless notifies. Requiring support for WDM view/update for wireless reg control would add a lot of code.
@jaylogue fully agreed on that sentiment. I believe so long as we have a TLV description that reasonably mirrors, or that can be extended to mirror, what I described above, that should work.
If necessary, this could be surfaced in device-published capability WDM schema in the future; however, I don't see a near-term use case for that.
@gerickson : The document you cite largely described how the rule sets are codified, whereas the configuration data specified here is meant as input to the process of selecting among those rule sets. It is not my belief that we need the ability to dynamically configure arbitrary new rule sets on a device. Thus I believe the input data form is correct. But please correct me if I've missed something.
Regarding the use of country codes, versus or in addition to designators for regulatory domains (e.g. A2 for "FCC"), my impression is that there is no standardization for such regulatory domain designators. Because of this, I expect clients to operate in terms of country codes only--e.g. a mobile commissioning device will first determine the country in which it is operating (via geolocation) and then use that to configure the device. I can see how it would be prudent to broaden the input field to allow for designators other than just country codes. But is there a specific case where this is needed?
I agree with using "00" for world-wide, and will update the proposal. I would prefer to continue to use null instead of "??" for unknown.
I don't disagree with any of the above. The key for me is that whatever the form of the input 'selector', that there be as minimal, mechanistic, and, ideally, 1:1 a mapping or translation as is possible from that input to the rule sets in devices deployed in the field. It seems like we're aligning with that goal.
As for NULL vs "??", NULL is more TLVish and the mapping from NULL to "??" is 1:1, so I'm fine with that.
Proposal updated:
- Use "00" for world-wide designation
- Generalized "operatingCountry" to "regulatoryDomain" to allow for the possibility that the values could, in the future, include designators that aren't countries (e.g. the proposed A2 for FCC). Such values are not allowed now, however.
- Eliminated use of abbreviations in protocol definition. (The diagrams still contain them for space reasons).
Proposal updated:
- Defined numerical values for new status codes.
- Clarified use of "unknown" operatingLocation.
Proposal updated: Updated TLV definitions for SetWirelessRegulatoryConfigArguments and GetWirelessRegulatoryConfigResults to match the latest Weave TLV schema language syntax.