September 2007 doc.: IEEE 802.22-07/0460r0
IEEE P802.22
Wireless RANs
Date: 2007-09-17
Author(s):
Name / Company / Address / Phone / email
Chris Clanton / Shure Inc. / 5800 W. Touhy Ave
Niles, IL / 847-600-8990 /
1 Introduction
The 802.22.1 group has been tasked with the development of the protocols, data formats, and other technical details for communication devices used to protect low-power, licensed devices operating in the television broadcast bands from new license-exempt devices that would operate in the same bands. More specifically, the 802.22.1 standard under development would detail operations of a new class of wireless “beacon” devices aimed at providing protecting existing incumbent TV band users (such as licensed wireless microphone operators) from harmful interference that could be generated by the new license-exempt devices.
The 802.22.1 work includes specification of only the MAC and PHY operations of the wireless beacon device. However, with the ongoing development of the standard, it has become clear that beacon’s operation would be better understood if additional information regarding the functionality of the “upper” or “next higher” layer (NHL), which would interact/utilize services of the MAC layer, was provided. This contribution provides some options for how the NHL functionality might be implemented, e.g. possible approaches to populating the beacon frame, and how the various protecting devices (PPDs, SPDs, and NPDs) might logically behave under some likely operating scenarios.
Through further development and discussion of this text, a “NHL Informative Annex” could be developed and included with the eventual 802.22.1 standard, as possible guidance for implementers of the devices.
2 Suggested Approach
The following is suggested as an approach to proceeding with this work
1.) Review this document and ensure the list of issues is complete (it should at least include the list of items identified in the first set of letter ballot comments).
2.) Identify which issues need to be addressed.
3.) Review proposed resolutions to the issues which require it (where given); propose additional alternatives, as appropriate.
4.) Agree to a single or set of approaches to resolving the issue.
5.) Document the resolutions as text in e.g. an NHL Informative Annex that can be included with the main 802.22.1 draft spec as part of the Re-Ballot process.
Ideally, items 1-4 could be completed during the September meetings, to the extent that it would be possible to vote for a Re-Ballot of the 802.22.1 draft. If necessary, the changes could be documented by the editor off line prior to the actual Re-Ballot (i.e. item 5 could be done after the actual vote to Re-Ballot).
This document is arranged as an outline of issues/questions which should be addressed at the NHL in order to better understand how the TG1 beacon would function in practice. When available, possible resolutions to the issues are proposed for discussion.
3 Generic PD Issues
This section deals with those issues which are relevant to any type (PPD, SPD, or NPD) of beaconing device.
3.1 Channel Scanning
[1] specifies that the “MLME-SCAN.request primitive is generated by the next higher layer and issued to its MLME to initiate a listening period on a given TV channel or channels”. This primitive should be generated as part of the initialization procedure, and requires that the NHL have some idea of which channels to scan. An obvious choice would be the channel where the incumbent device to be protected would be operating.
Open Issue/Question: The spec allows scanning of any number of channels. Given that each scan is mandated to take 2 seconds or more, the time for this operation could be excessive (we must add that time also to the new “grace period” we are requiring, in order to prevent a new PD from attempting to communicate with a beacon that just came on the air) for multiple channels. The NHL should include a description of how to determine which channels to scan. Also, section 7.4.5 (Device Initialization Procedure) seems to imply that we will scan only one channel at initialization, “Upon initialization, a protecting device shall identify the TV channel it is to monitor, then monitor that channel for a period of 2 + 0.01m continuous second…”, so it is not really clear how/when multiple scans would be triggered?
3.2 Beacon Frame Construction
[1] specifies that the “MLME-START-BEACON.request primitive is generated by the next higher layer and issued to its MLME to initiate either a single beacon frame transmission or periodic beacon frame transmissions or to stop periodic beacon frame transmissions.” This means that each parameter in the MLME-START-BEACON.request primitive must be determined by the NHL. The parameters settings will significantly impact beacon operation, some possible approaches to determining the values is described in the below subsections. Note that some of the parameters are utilized differently depending on the PD type, so they will be described later.
Issue/Question: [1] specifies that MLME-START-BEACON.request is generated by the NHL, but subsequent sections in [1] indicate that fields within it “shall” be set to specific values. Is this an issue of work scope?
Issue/Question: [1] also specifies the format of the “MLME-INCOMING-BEACON.indication” primitive, but what should be the NHL’s response when it receives beacon information that is somehow incomplete (is this even possible)?
3.3 Parameter 1 – Priority Field
Priority Level field: This 3-bit parameter should be set by the NHL to ensure the best possible protection is afforded to any TG1 device.
Issue/Question: [1] section 7.2.1.1 is not really clear about how this field is used. It is not evident when there might be services that would be of different priority. We should clarify that this field is meant to be interpreted by another TG1 device, not by the device whose interference is being mitigated (e.g. 802.22 CPE or BS). Also, since we state rules for aggregation for other parameters (such as Antenna Height) should we do the same for this parameter setting?
3.4 Location Information
According to [1], “The Location field is 41 bits in length and specifies the location of the originator of the beacon frame.”
Open Question/Issue: The Location Field would ideally be populated using some form of satellite based geolocation data (GPS or Galileo). However, this information, may, in some instances, not be obtainable, due to the location of the beacon device (signals may not reach certain closed structures). In those cases, some alternative approaches to providing the data should be provided. What are those options and how does the NHL get the location data in those cases?
· Manual entry of latitude and longitude information via a keypad or PC interface to the beacon; this info would have to be in the format of the specification, which probably should not be expected to be known/understood by the beacon user.
· Others?
How does the system operate if this field is not populated?
Note, in section 7.4.1 of [1] it is stated that “The beacon frame itself contains information relevant to the device protected by the protecting device, including its physical location and estimated duration of TV channel occupancy.”. May want to clarify that location is of the beacon, not the receiver, “…including the beacon’s physical location …” to avoid ambiguity.
3.5 Parameter 2 – Time Parity Field
According to [1], this field indicates “the parity of the time subfield t used when generating the signature”. The field is also helpful in “synchronizing the received time with the transmitted time” between two devices.
Open Question/Issue: The Time Parity would ideally be populated using a source of UTC time. However, this information, may, in some instances, not be obtainable, due to the location of the beacon device (certain closed structures). In those cases, some alternative approaches to providing the data should be provided, what are those options and how does the NHL get the time data in those cases?
· Manual entry of information via a keypad or PC interface to the beacon could be considered. This puts some additional constraints on the beacon design and user interface.
· Others?
3.6 Channel/SubChannel Map
As described in [1], this field can be used to either
1.) indicate a list of TV channels that are being protected by the beaconing device
2.) indicate details of which 200 kHz “subchannels” within a TV channel are currently in use by incumbent devices.
Open Issue/Question: Regarding application 1.) above, the text in [1] states that “if the center frequency of one or more protected devices falls within a 200 kHz subchannel, the bit representing that subchannel is set to a 1.” Does the 200 kHz subchannel definition cause a problem, given that wireless microphones can operate on any 25 kHz raster, and would also typically be spaced by 400 MHz (carrier frequency separation). We should specify how this field would be mapped and utilized by the NHL.
Open Issue/Question: Is the meaning of the subchannel map unambiguous, e.g. if it follows transmission of a list (more than one) of TV channels to be protected? How does the NHL determine which channel the subchannel map applies to in that case?
3.7 NHL Reaction to SIGNATURE_INVALID
This value is reported to the NHL as part of the “MLME-BEACON-LOST.indication” when the signature of a received beacon is found to be invalid.
Open Issue/Question: What should be the action performed by the NHL when this value is received?
3.8 NHL Reaction to CERTIFICATE_INVALID
This value is reported to the NHL as part of the “MLME-BEACON-LOST.indication” when the certificate of a received beacon is found to be invalid.
Open Issue/Question: What should be the action performed by the NHL when this value is received?
3.9 Security-Specific Considerations
Open Issue/Question: Additional text describing how the security system would be implemented in practice should be included in an informative annex. There is already text that can be described as informative in the main draft, one approach could be to use that as a basis going forward. There are comments related to
1.) Ensuring that certificates be cryptographically bound to MAC addresses
2.) Specifying the operation of the trusted authority and the trusted MAC database
Where should we capture these descriptions? Should they be included in the NHL description or as a separate informative annex on security?
3.10 NHL Reaction to TX_FAILURE Indications
A retransmission mechanism has been incorporated to [1] to address potential issues with RTS transmission e.g., two or more SPD devices transmit the same RTS codeword during the PPD Rx Period. The new mechanism would allow some number of retransmissions, and, per [1] “If the retransmission procedure fails, the next higher layer of the SPD is notified of the inability to transmit its beacon frame via the MLME-STARTBEACON.
confirm primitive with the Status parameter set to TX_FAILURE.”
Open Issue/Question: What does the NHL do when it receives a TX_FAILURE indication? Should it “start over”? What action is taken?
4 PPD Specific Behaviors
This section identifies/addresses various issues related to the specific operation of PPD devices.
4.1 Deciding Whether to Become a PPD or Not
A PD decides to become a PPD based on information determined during the initialization phase described in section 7.4.5 of [1]. An SPD should have reasonable assurances that a selected PPD can adequately provide it with the protections it requires.
Open Issue/Question: Should we describe a basic set of criteria that should be met in order for a PD to become an SPD or PPD? Otherwise, poor selection criteria would in turn lead to poor protection performance, e.g., picking a device that cannot provide adequate protection could result in harmful interference levels at the protected device. Conversely, without a proper SPD/PPD decision, it could be possible for two PPDs to exist in close proximity on the same channel, such that their transmissions effectively interfere with each other.
Criteria which could be useful in the SPD’s decision would probably include at least (data obtained from the MLME-INCOMING-BEACON.indication)
1.) The location of the PPD; closer proximity could imply a better opportunity to provide protection
2.) The PPD’s current keep out zone setting; the PPD may already be providing protection over the area the SPD wants to protect
3.) The link quality of the PPD signal at the SPD’s location can provide some info related to the PPD’s capability to offer protection
4.2 NPD Selection
Open Issue/Question: Although the MLME-INCOMING-BEACON.indication primitive can request that the NHL select an NPD, NPD selection cannot be made to be mandatory in [1] . Should we describe a simple procedure at the NHL by which the PPD would always attempts to make at least one of the SPDs (if they are present) an NPD? There should be some basic criteria for NPD selection, what would those criteria be? The criteria could, e.g., be similar to those used by an SPD to determine if a given PD should be its PPD.
4.3 ANP Transmission
According to [1] “The PPD has ultimate control of the radio channel. Therefore, the PPD may send a NACK during the ANP of any superframe regardless of what was heard during the receive period.”.
Open Issue/Question: Since the ANP field content is completely controlled by the PPD, it effectively decides when an SPD will be able to transmit, and it could prevent certain operations from ever occurring. For example, there could be scenarios where data aggregation as described in section 7.4.6.3 never happens due to lack of SPD transmission opportunities. The operation of newly proposed ideas, such as an SPDs periodically notifying its PPD that it still requires protection (in order to avoid unnecessarily protecting resources), could also be impacted. How can we ensure that features like this will still work as planned? In the PPD, does the NHL, MAC, or PHY make the determination of what to ultimately send in the ANP and how?
Open Issue/Question: How does PPD indicate a particular response should be sent during the ANP? There does not appear to be a primitive to allow it to instruct the PHY layer on what would be an appropriate value to send?
Open Issue/Question: in 7.4.2 of [1], it states that “In the event that two SPDs transmit an RTS burst simultaneously, at least one should be successfully received by the PPD. If neither is received, the PPD will transmit a NACK during the ANP and then continue to transmit its own beacon frame. If one is received, both SPDs will hear an ACK from the PPD and proceed to transmit a beacon frame. These beacon frames are transmitted without first sampling the TV channel”. But this may or may not be true, since the choice is left to the PPD as to how the ANP field will be set.