TVWS WLAN Enablement- Review and Open Issues Month Year doc.: IEEE 802.11-yy/xxxxr0 TVWS WLAN Enablement- Review and Open Issues Date: August 10, 2010 Authors: Name Company Address Phone email Padam Kafle Nokia 6021 Connection Drive, Irving, TX, 75039 +1 214 673 6232 Padam.kafle@nokia.com Mika Kasslin Itämerenkatu 11-13, 00180 Helsinki, Finland +358-50-4836294 Mika.kasslin@nokia.com Naveen Kakani +1 214 763 1041 Naveen.Kakani@nokia.com John Doe, Some Company

Contents Introduction Enablement in 802.11y in short Basic Regulatory Requirements for TVWS Operation (FCC) The route from 802.11y to TVWS Enablement in TVWS Terms Current Methods Specified in 802.11af Open Issues Our proposal Proposed Terms and Concepts Details on Enablement for Beaconing Dependent Stations Deployment examples Summary Annexes A: Enablement Procedure as per 802.11y B: FCC Requirements

Introduction This slide set deals with one specific mechanism of WLAN that will most likely be applied in TVWS: Enablement Enablement (or DSE: dynamic station enablement) is a mechanism that was introduced to 802.11 by 802.11y amendment (2008) to satisfy the US 3650 MHz band requirements The 802.11af has adopted the 802.11y enablement procedure as the basis and has started modifying it for TVWS operation We believe that the enablement procedure needs to be analyzed in detail with main objective to find out whether the existing methods are suitable for TVWS and what kind of changes would be needed to support the important use cases We provide our views on the current status and open issues: What does enablement mean as in 802.11y? What is needed from enablement procedure for TVWS operation ? What should be the enablement procedure specified in 802.11af? Additionally, the slide set provides possible solutions to cover some important scenarios in TVWS operation

Enablement in 802.11y in short Dynamic STA enablement (DSE) is a mechanism that was introduced to 802.11 in 802.11y amendment to satisfy the US 3650 MHz band requirements Enablement can be provided only by a registered STA. If a registered STA provides enablement services, it is referred as an enabling STA every registered STA doesn’t have to provide enablement services fixed stations are not allowed enabling other stations An unregistered STA is a dependent STA that needs to be enabled by an enabling STA Enablement process uses public action frames (DSE Enablement frames for request/grant exchange) that can be transmitted in pre-associated state Enabling signal An unregistered STA needs to receive an enabling signal before attempting enablement with an enabling STA Once enabled by the enablement process, a dependent STA’s operation is contingent upon being able to receive enabling signals over air directly from the enabling STA Enabling signal is an information element (DSE Reg. Loc. IE with RegLoc DSE bit set to 1) transmitted in specific frames, e.g. Beacon, Probe response frames Note: More on this topic in the Annex A

Basic Regulatory Requirements (FCC in USA) We believe the main regulatory requirements for operation in TVWS band for a client device are: needs to receive a transmission on a TVWS channel from a fixed or mode II device before it may transmit in a TVWS channel (FCC 15.711 (g)) A client can transmit on any TVWS channel indicated to be available from the Fixed or Mode II device from which it received the list of available TV channels (FCC 15.711(b-3-iv) & 15.711 (g)) TV channel availability check (applies to all TVBDs) (FCC 15.711(c-7)) 30 s spectrum sensing before transmitting any energy into air in any channel FCC mandates in-service monitoring for all TVBDs by spectrum sensing once every 60 s (FCC 15.711 (c-4)). In addition, client devices must notify the channels detected with primary signal during its sensing to its master device (FCC 15.711 (c-6)) Transmissions of client devices (Mode I) must be under control of a master device during operation (FCC 15.703(c) ). But what control mechanisms are specified in rules? Only those listed above Note: More on this topic in the Annex B

The Route from 802.11y to TVWS The concept of enabling signal and DSE enablement procedure in 802.11y can be used as means to satisfy some of the regulatory requirements in TVWS, even though some of the steps seems non-essential, or could have been simplified, e.g. an AP needs to only obtain a list of available channels from the primary database or through its enabler before starting beaconing, i.e. to initiate a BSS. Client stations just need to hear beacons and know the channels available On the other hand, some procedures to accommodate important specific use cases are missing. The current 802.11af draft has already made some changes or added some methods, e.g: Enabling signal do not have to be received over the air the “dependent AP” type stations can also transmit enabling signal (to allow control from an enablement server type master entity of an enterprise IT network) Some other open issues and changes important for 802.11af are discussed next.

Terms for TVWS Enablement Enabler Acts as an enabling entity as per the dynamic station enablement (DSE) procedures Acts as a master as per the FCC terms and accesses the primary data base Doesn’t have to be a STA but can be anything anywhere. Enabler is a logical entity, not a device. Dependent STA A WLAN STA that operates under control of an Enabler. Operational parameters of a dependent STA are determined by the Enabler. Dependent STA can be any type of STA as per the WLAN standards (802.11): a) non-beaconing client STA, b) beaconing AP STA, c) beaconing IBSS STA. Enablement A DSE process between an Enabler and a Dependent STA in which the Dependent STA issues an Enablement Request frame to an Enabler and the Enabler replies with an Enablement Response frame. Enabling signal A DSE related signal that a dependent STA needs to receive in order to start enablement, i.e. to issue an Enablement Request frame to an Enabler. Dependent STA

Terms for TVWS Enablement .. Following device types (can be dynamic) can be imagined Enabler device Enabler that has no WLAN capability, e.g. a server in a company network Enabler AP A device with an infra-beaconing STA and Enabler functionality Dependent AP A device with an infra-beaconing STA but no Enabler functionality Client device A device with a non-beaconing STA and that relies on an external Enabler Enabler Enabler AP Enabler Dependent STA Dependent AP Dependent STA Dependent STA

Enablement in TVWS – Introduction The very basic idea of the enablement and enabling signal can be applied also in TVWS A Dependent STA needs to be enabled by an Enabler in order to operate in TVWS Once the Dependent STA has been enabled, it needs to frequently enough receive enabling signal to continue operating in TVWS The main difference to 802.11y enablement is that the Enabler doesn’t have to be a STA. Enabler is a functional/logical element that provides DSE services for Dependent STAs in TVWS. Additionally, the 802.11y process has some strict limitations that are expected to be relaxed Enablement frames can be transmitted over any media Enabling signal can transmitted over any media, not only over the air Enabling signal can be relayed

Enablement in TVWS – As in 802.11af today Enabler A logical entity that provides enablement services. Doesn’t need to be a WLAN STA a but can be e.g. a network management server. Problems and concerns: None Dependent STA A WLAN STA that operates under control of an Enabler. Can be an AP STA or a non-AP STA. Enabling signal An enablement related signal that a dependent STA needs to receive before initiating enablement process. Can be transmitted over any media, wireless and wireline. WLAN enabling signal is an information element that can be included e.g. in a Beacon and a Probe Response frame. Problems and concerns: a) Where to specify enabling signal that is transmitted over non-802.11 media? Enablement Process in which a Dependent STA asks for permission to operate in TVWS. Builds upon WLAN public action frames (DSE Enablement frames for Request/Grant) that can be transmitted over any band. As an example, a dependent client STA can perform enablement in 2.4 GHz through a multi-band AP before starting operation in TVWS. Problems and concerns: a) Enablement Request frame is loosely defined and it doesn’t contain information the Enabler needs to enable a Dependent STA. All the required information is assumed to be delivered to the Enabler in “higher layers”.

Enablement in TVWS – proposed terms & concept Enabler A logical entity that provides enablement services. Doesn’t need to be a WLAN STA a but can be e.g. a network management server. Dependent STA A WLAN STA that operates under control of an Enabler. Can be a first tier beaconing STA, a second tier beaconing STA or a non-beaconing STA. The two tiers are defined to facilitate initiation of local small scale networks e.g. for D2D purposes. More on the details in the next slide. Enabling signal An enablement related signal that a dependent STA needs to receive before initiating enablement process. Can be transmitted over any media, wireless and wireline. WLAN enabling signal is an information element that can be included e.g. in a Beacon and a Probe Response frame. Enablement Process in which a Dependent STA asks for permission to operate in TVWS. Builds upon WLAN public action frames (DSE Enablement frames for Request/Grant) that can be transmitted over any band. As an example, a dependent client STA can perform enablement in 2.4 GHz through a multi-band AP before starting operation in TVWS. Well defined enablement protocol with DSE Enablement exchange for Requests and Responses that are specified to the extent that allows third party Enabler implementations More on the details in the next slide Same as in 802..11af New STA types Same as in 802..11af Detailed protocol

Enablement in TVWS – proposed concept details Enablement with detailed protocol description: A dependent STA has two sub-types of the enablement protocol from which to select: a) Open protocol, b) Vendor specific protocol DSE Enablement frame has a field that is used to indicate the protocol sub-type If the open protocol is used, the Enablement Request frame contains following additional information STA identity STA type: a) First tier beaconing (FTB) STA b) Second tier beaconing (STB) STA c) Non-beaconing (NB) STA STA location Needed if the STA type is first tier beaconing STA Needed if the STA type is second tier beaconing STA and no reference to first tier beaconing STA is given Not needed when the STA type is non-beaconing STA First tier beaconing STA reference Some form of identification of a first tier beaconing STA from which one receives enabling signals If a vendor specific protocol is used, the DSE Enablement frame’s content for Request beyond the protocol sub-type indicator depends on the protocol Also in this case the Enabler needs to have means to verify that the dependent STA that requests for enablement can operate in TVWS. If the requesting dependent STA is to become a beaconing STA, the Enabler needs to know the location of the STA. The Enabler may have acquired that information in an Enablement Request frame or in a higher layer protocol frame. Alternatively the Enabler has a pre-established relationship with the dependent STA e.g. through means of network management system. In that case the Enabler can determine the dependent STA’s location e.g. based on the STA’s identity.

Enablement in TVWS – proposed concept details Dependent STA and two tiers of beaconing STAs Tier of the beaconing STA is indicated in the enabling signal. Alternatively, enabling signal transmissions can be limited to the 1st tier beaconing STAs. With this limitation one will limit further the coverage area of all the dependent STAs. If a dependent STA receives an enabling signal from a first tier beaconing STA, the dependent STA can request becoming enabled as a second tier beaconing STA without providing one’s location in an DSE Enablement frame for enablement request. An enabling signal from the first tier beaconing STA can be used as a reference in an Enablement Request; one is within an area where the available channels are still available. Second tier beaconing STA can’t be used as a reference in enablement More details on the two tiers in the following slide

Enablement in TVWS – More on the two tiers The two tiers builds upon an assumption that a channel is available within an area which can be split into sub-areas that determine where 1st and 2nd tier beaconing STAs are allowed Area boarders are to ensure that dependent non-beaconing STAs that are served by 1st or 2nd tier beaconing STA networks do not interfere with the world outside the white space area Transmit power limitations can be used to limit coverage areas, suitable especially for 2nd tier beaconing STAs if we consider D2D cases One method for the 2nd tier beaconing STA to refer to the 1st tier beaconing STA in its enablement request is to always transmit the request to the 1st tier beaconing STA that attaches a form of fingerprint to the request that it forwards to the enabler White space area 2nd tier area 1st tier beaconer 2nd tier beaconer

Enablement in TVWS – Configurations for STAs Device Type Enablement Request Type and Content Enabling Signal (ES) Eligibility and Content Open Protocol Vendor Specific Protocol Enabler N/A ES allowed RegLoc DSE = 1, Dep STA = 0, LCI = own location, Channel/power Map FTB (First Tier Beaconing) Dependent STA STA Id – own Address STA Type – FTB Location – own location FTB Reference- None Location – optional RegLoc DSE = 1, Dep STA = FT B, LCI = LCI of enabler FTB Identifier, Enabler’s Address, Channel/power Map STB (Second Tier Beaconing) Dependent STA STA Type – STB Location – own location if no FTB reference / location of FTB if FTB reference FTB Reference- Id of FTB or none ES optional RegLoc DSE = 1, Dep STA = STB, LCI = LCI of enabler NB (Non-beaconing) Dependent STA (Simple Client) STA Type – NB Location – none ES not allowed

Enablement in TVWS – Home AP example Simple case in which an Enabler AP enables clients and acts as an AP to them Typical home AP case in which the AP is independently operated standalone AP The AP’s dependent STA can operate either as a 1st tier or as a 2nd tier beaconing STA. Client device is associated to the Enabler AP and all the traffic goes through the Enabler AP The client device operates only as a client (i.e. as a non-beaconing dependent STA) in the infra BSS determined by the Enabler AP (no D2D network needed) From DSE perspective, the enablement process related to enablement of the dependent STA from the enabler within the Enabler AP is run internally The dependent STA within the Enabler AP needs to, however, enable itself with means of either open protocol or vendor specific protocol The Enabler AP is visible over air to Client devices in the following manner The Enabler AP transmits DSE Reg Loc IE with a) RegLoc DSE = 1, b) Dependent STA = 0, c) its own location The Enabler AP can transmit a list of available channels Client device communicates with the Enabler AP over air in TVWS band Enablement with the Enabler AP over any media but typically over air with WLAN Criteria to initiate a network Enabler AP: The Enabler in the Enabler AP enables the collocated Dependent STA that can start beaconing Criteria to transmit in a TVWS channel Client device: a) Enabling signal, b) Enabled by the Enabler AP, Criteria to operate in a TVWS band Enabler AP: DB Client device: Enabled by the Enabler AP Enabler AP Client device FCC DB Enablement WLAN operations DB access Enabler Dependent STA

Enablement in TVWS – Office AP/network example Typical office network case with a network server acting as an Enabler device Dependent AP has a wired connection to the Enabler device The AP’s dependent STA can operate either as a FTB or STB beaconing STA. Client device is associated to the Dependent AP and all the traffic goes through it The client device doesn’t want to establish a network of its own for D2D purposes but operates only as a client (i.e. as a non-beaconing dependent STA) in the infra BSS From DSE perspective, the enablement process for enablement of the dependent STA within the Dependent AP is run between the Dependent AP’s dependent STA and the Enabler The dependent STA within the Dependent AP needs to enable itself with means of either open protocol or vendor specific protocol. Enablement protocol messages are typically carried in the wired office network. The Dependent AP has initiated an infra network upon being enabled by the Enabler device and receiving a list of available channels from it The Dependent AP transmits DSE Reg Loc IE with a) RegLoc DSE = 1, b) Dependent STA = 1, c) Enabler device’s location The Dependent AP may transmit a list of available channels (all or subset) Client device communicates with the Dependent AP over air in TVWS band and performs enablement with the server over any media Criteria to initiate a network Dependent AP: Enabled by the Enabler device, available channels from the Enabler Criteria to transmit in a TVWS channel Client device: a) Enabled by the Enabler device, b) List of available channels from Enabler/Dependent AP, c) Sensing requirements as per FCC Criteria to operate in a TVWS band Dependent AP: Enabler device Client device: a) Enabled by the Enabler device, b) Sensing requirement as per FCC Enabler device Dependent AP Client device FCC DB Enablement WLAN operations DB access Dependent AP Dependent STA

Enablement in TVWS – Office AP/network example .. Steps taken by the Dependent AP Enabling signal received from an Enabler device Enablement over a wired connection with the Enabler Enablement Request to the Enabler device If the open protocol is used, the request contains at least all the following information STA identity STA type STA location Receive Enablement Response from the Enabler device Enabler device Dependent AP Client device FCC DB Enablement WLAN operations DB access Dependent AP Dependent STA

Enablement in TVWS – D2D network in office example Typical office network case with a network server acting as an Enabler device A mobile device wants to establish a network of its own for D2D purposes. In other words, the mobile device wants to become a Dependent AP. The mobile requests becoming enabled as a STB STA (2nd tier). A mobile should not be allowed to operate as a FTB STA (1st tier). The mobile may also be acting as a client in the office infra network. If that is the case, the mobile needs to be able operate in two WLAN modes concurrently, i.e. client and D2D AP. These two operation modes are, however, independent from each other and the mobile needs to e.g. enable for each mode separately. Additionally there are other WLAN devices with which the mobile will communicate with in the D2D network. Those devices act as client devices in the D2D network established by the mobile serving as a Dependent AP. From DSE perspective the enablement process for enablement of the dependent STAs within the Dependent AP is run between the Dependent AP’s dependent STA and the Enabler The dependent STA within the Dependent AP needs to enable itself with means of either open protocol or vendor specific protocol. Since the Dependent AP is a mobile/portable device whose location is not obvious for the Enabler device unlike in the previous example of office network, the mobile typically needs to provide its location to the Enabler. In this case the enablement protocol messages are typically carried over air. One can use e.g. cellular or WLAN to conduct enablement with the Enabler. The Dependent AP has initiated an infra network upon being enabled by the Enabler device and receiving a list of available channels from it The Dependent AP transmits DSE reg loc IE with a) RegLoc DSE = 1, b) Dependent STA = 1, c) Enabler device’s location The Dependent AP may transmit a list of available channels (all or subset) Mobile initiated D2D network Enabler device Dependent AP Client device FCC DB Enablement WLAN operations DB access Dependent AP Dependent STA

Enablement in TVWS – D2D network in office example .. Mobile initiated D2D network Enabler device Dependent AP Client device FCC DB Enablement WLAN operations DB access Client device communicates with the Dependent AP over air in TVWS band and performs enablement with the server over any media Criteria to initiate a network Dependent AP: Enabled by the Enabler device, available channels from the Enabler device Criteria to transmit in a TVWS channel Client device: a) Enabled by the Enabler device, b) List of available channels from Enabler/Dependent AP, c) Sensing requirements as per FCC Criteria to operate in a TVWS band Dependent AP: Enabler device Client device: a) Enabled by the Enabler device, b) Sensing requirement as per FCC Dependent AP Dependent STA

D2D network in office example with two tiers of beaconing Same case as in the previous example except that the mobile uses the office AP as a reference in its own enablement request to the Enabler device The office AP is a dependent AP (dependent AP1) that has a 1st tier beaconing dependent STA The dependent AP1 transmits enabling signal and indicates that it is a 1st tier beaconing STA The mobile receives enabling signal from the office AP and recognizes that the AP is a 1st tier beaconing STA that it can use as the reference in enablement request to become a 2nd tier beaconing STA The mobile can issue an enablement request to the Dependent AP1 that labels the request with its own identity (or alike) and forwards it to the Enabler device The mobile doesn’t have to provide its location to the Enabler device but if one is able to receive enabling signal from the Dependent AP1 is enough for enablement request For the client device the case is same as in the previous example except that the Dependent AP2 may be configured not to transmit enabling signal. If that is the case, the client needs to receive enabling signal e.g. from the Dependent AP1

Changes in Enablement from Adoption of 802.11u GAS A new Advertisement Protocol element- Registered Location Query Protocol (RLQP) dedicated for enablement related content has been created. The support for such protocol is advertised by including the protocol ID for RLQP in the Advertisement Protocol element in beacons or probe response frames All DSE message content can have similar format with unique Info ID for each message to be transported by GAS public action frames over the air The advertisement of GAS transport for enablement has following advantages: adds clarity to message exchange between WLAN STAs, basically the AP’s role is clearer that it can receive enablement related messages from other STAs and forward it to the corresponding server (or enabler), and vice versa Only the enabled STA capable to talk to an enabler should advertise such service The advertisement of GAS transport for enablement has some unclear issues: The way the messages are transmitted or received between the GAS service provider (i.e., the AP) to the Enabler remains unspecified The enablement procedure for the AP (GAS service provider) with the enabler is not clear Can we conclude that enabling signal is only required to be transmitted by the GAS service provider who knows how to send Query Request and receive Query Response from the enabler (or the RLQPAS (registered location query protocol advertisement server))? YES

Changes in Enablement from Adoption of 802.11u GAS ..

Changes in Enablement from Adoption of 802.11u GAS .. More on Enabling signal: Before transmitting enabling signal, the dependent STA must have been first enabled from an enabler. What information should be provided in an enabling signal ? At least the capability to provide access to an enabler (RLQPAS), type of STA (STA with enabler function, Tier 1 or Tier 2 dependent STA), Enablement Identifier are required. The use of GAS public action frames for enablement provides an alternative to DSE public action frames due to 802.11y. Some open issues: Do we need both types of frame exchanges for enablement in TVWS? Shall we only limit use of GAS public action frames until an STA has attained enablement, and then only reuse public action frames?

Some Open Questions on TV White Space MAP The use of White Space MAP should be very clear: Does it need to contain information of TV channel list and power limit that has been received directly from database after database query ? Can an Enabler change the power limit and list of channels available for its service area before it sends such information to its dependent STAs ? The differences between the application of the white space MAP received during enablement and the one received during operation under control of a local AP should be clear (e.g., TV channel vs RLAN channels, power constraint by database vs power limit assigned by local control point) ? Do we need more information like radius of validity (area boundary for each channel), time of validity etc on top of the current information (channel list and power limit)? It may be good to separate the WSM to provide different contents: One for the purpose of enablement only (TV channel list only for beaconing devices) One for operation of BSS/IBSS after the enablement. During operation, only the beaconing device talks to the enabler, the beaconing device can change channel and power based on local decision or as per the command received from enabler.

November 2009 Accelerate Contribution Summary We need more clear understanding on the requirements of enablement procedure that can support various deployment scenarios of TVWS operation The proposed classification of dependent stations, and some changes to enablement protocol allows more flexible enablement options for various device needs. The proposed enhancements is built upon the current 802.11af specification, in order to additionally provide means to utilize open signaling exchange for enablement (to allow third party enablement services) and also to provide more clarity to the boundary of white space service area for dependent stations Adoption of GAS protocol from 802.11u for enablement process is complementary to already existing methods based on 802.11y. The 802.11af standard should at least facilitate implementation of RLQP Advertisement Server and AP from different vendors Page 26 LG Electronics, Inc.

Annexes A: Enablement as per IEEE 802 Annexes A: Enablement as per IEEE 802.11y B: FCC requirements and their mapping to 802.11 27

A: 802.11y device and network types 802.11y has the following types of STA Registered STA “A STA for which information must be submitted to an appropriate regulatory or coordination authority before it is allowed to transmit.” Can be either a Fixed STA or an Enabling STA Fixed STA “A STA that is physically attached to a specific location.” Enabling STA “A registered STA that has the authority to control when and how a dependent STA can operate. An enabling STA communicates an enabling signal to its dependants over the air. An enabling STA may choose for other dynamic STA enablement (DSE) messages to be exchanged over the air, over the DS, or by mechanisms that rely on transport via higher layers.” Dependent STA “A STA that is not registered and whose operational parameters are dictated by messages it receives from an enabling STA. Once enabled by the DSE process, a dependent STA’s continued operation becomes contingent upon being able to receive messages from its enabling STA over the air.” 28

A: 802.11y device and network types (cont.) Dependent STA state machine as per the 802.11y 29

A: Some Remarks on 802.11y Operation In 3650-3700 MHz band, the operation requires licensing: Licensing fee to each operator for nationwide permission to operate Additional fee for each high powered base station to be installed The enabling STA is a licensed base station that can transmit enabling signals to dependent STA or dependent AP over 3650 MHz or any other band The enablement requests and grants can also be exchanged through Internet or any other connectivity No concept of a dependent AP transmitting enabling signal (can not be relayed) Interference resolution is possible by means of unique identifiers assigned to each dependent STA and location of the enabling STA. Dependent STA only broadcast the location of the station that enabled it, plus the unique id they obtain from the enabling STA DSE service area boundary is controlled to the area where enabling signal can be received (initially, as well as, during operation) 30

B: FCC requirements and their mapping to 802.11 Note: FCC terms are used here to determine basic requirements What’s required from a client device before it can transmit anything in a TVWS channel? “A personal/portable TVBD operating in Mode I may only transmit upon receiving the transmissions of fixed or Mode II TVBD. A personal/portable device operating in Mode I may transmit on either an operating channel of the fixed or Mode II TVBD or on a channel the fixed or Mode II TVBD indicates is available for use.” (FCC 47CFR 15.711 (g)) In which TVWS channel a client device can transmit once it has been allowed ? “A personal/portable TVBD operating in Mode I may only transmit upon receiving the transmissions of fixed or Mode II TVBD. A personal/portable device operating in Mode I may transmit on either an operating channel of the fixed or Mode II TVBD or on a channel the fixed or Mode II TVBD indicates is available for use.” Is there some other level of enablement that a client device needs to fulfill before it can operate in a TVWS channel? NO 31

B: FCC requirements and their mapping to 802.11 .. In other words, A client needs to receive a transmission on a TVWS channel, i.e. an enabling signal, before it may transmit in a TVWS channel A client can transmit on any TVWS channel indicated to be available by the device from which it received the enabling signal No requirements on Order of enabling signal reception and reception of available channels list Enablement In WLAN words, A client STA needs to receive an enabling signal (e.g. Beacon frame) from a master STA on a TVWS channel before it may transmit in a TVWS channel If the enabling signal is a Beacon frame, it may need to contain some specific information in order to become an enabling frame A client STA can transmit on any TVWS channel indicated to be available by the master STA from which it received an enabling frame List of available channels don’t have to be in the enabling frame, but some other frames, protocol and non-WLAN transport can be used List of available channels can be acquired before or after reception of an enabling signal in a TVWS channel There is no regulatory requirement for enablement like one defined in 802.11y 32