1. TVWS WLAN Enablement- Discussions and Open Issues
Month Year
doc.: IEEE yy/xxxxr0
TVWS WLAN Enablement- Discussions and Open Issues
Date: September 10, 2010
Authors:
Name
Company
Address
Phone
Padam Kafle
Nokia
6021 Connection Drive, Irving, TX, 75039
Mika Kasslin
Itämerenkatu 11-13, Helsinki, Finland
Naveen Kakani
John Doe, Some Company

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

3. 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 by y amendment (2008) to satisfy the US 3650 MHz band requirements
The af has adopted the y 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 y?
What is needed from enablement procedure for TVWS operation ?
What should be the enablement procedure specified in af?
Additionally, the slide set provides possible solutions to cover some important scenarios in TVWS operation

4. Enablement in 802.11y in short
Dynamic STA enablement (DSE) is a mechanism that was introduced to in y 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 to enable 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

5. 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 (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 (b-3-iv) & (g))
TV channel availability check (applies to all TVBDs) (FCC (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 (c-4)). In addition,
client devices must notify the channels detected with primary signal during its sensing to its master device (FCC (c-6))
Transmissions of client devices (Mode I) must be under control of a master device during operation (FCC (c) ). But what control mechanisms are specified in rules?
Only those listed above
Note: More on this topic in the Annex B

6. The Route from y to TVWS
The concept of enabling signal and DSE enablement procedure in y 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 af 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 af are discussed next.

7. 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

8. 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

9. 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 y 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 y 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

10. 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 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”.

11. 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 the control of an Enabler. Can be a beaconing STA or a non-beaconing STA.
Beaconing dependent STAs are master mode devices and non-beaconing STAs are client mode devices as per the FCC’s part 15 rules
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 af
New STA types
Same as in af
Detailed protocol

12. 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) Detailed open protocol, b) Vendor specific protocol
DSE Enablement frame has a field that is used to indicate the protocol sub-type
If the detailed open protocol is used, the Enablement Request frame contains following additional information
STA type: a) Beaconing dependent (BD) STA b) Non-beaconing dependent (NBD) STA
STA location
Needed if the STA type is a beaconing STA
Not needed when the STA type is non-beaconing STA
STA identity:
MAC address of enablement requesting STA (required for all STA types)
Additional Device ID as required by country-specific regulations such as FCC ID and device serial number (required for BD STA)
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.

13. Enablement in TVWS – Configurations for STAs
Device Type
Enablement Request Type and Content
Enabling Signal (ES) Eligibility and Content
Detailed Open Protocol
Vendor Specific Protocol
Enabler
N/A
BD (Beaconing dependent) STA
STA Type – BD
Location – own location
STA Id – own MAC Address and Device ID (country specific)
Location – optional
STA Id – own MAC Address, additional Device ID optional
ES allowed
STA Type = BD
Advertisement Protocol element with Advertisement Protocol ID value for RLQP
NBD (Non-beaconing dependent) STA (Simple Client)
STA Type – NBD
Location – none
ES not allowed

14. 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 as a 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 enabling signal with a) Dependent STA Type = BD, b) its Enablement Identifier
The Enabler AP may 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

15. 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 as a beaconing dependent (BD) 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 it from the Enabler device by 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 enabling signal with a) Dependent STA Type = BD, b) its Enablement Identifier
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

16. 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

17. 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 BD STA.
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 from the Enabler by 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 enabling signal with a) Dependent STA Type = BD, b) its Enablement Identifier
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

18. 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

19. 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 format of the message is known however)
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

20. Enablement using 802.11u GAS .. . Multiple Infra-BSS STA (NB)
RLQP
Advertisement
Server
Dep. AP (BD STA with Enabling Signal) .
Multiple Infra-BSS
GAS Query Request/ Responses
Query Request/ Query Responses (outside WLAN BSS)
Dep. AP (BD STA with Enabling Signal)
Dep. AP -N (BD STA with Enabling Signal)
STA (NB)

21. 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 (beaconing dependent STA) and Enablement Identifier are required.
The use of GAS public action frames for enablement provides an alternative to DSE public action frames due to y. Some open issues are:
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?

22. Operational Control after the Enablement
All beaconing dependent STAs are required to be approved as Master device (as per FCC) as they will be initiating a network after enablement. Non-beaconing dependent STAs can be client mode devices (as per FCC rules).
All beaconing dependent STAs must receive list of permissible channels from Enabler when they are granted enablement, as they will be beginning beacon transmission after enablement. Such information is not required for non-beaconing STAs.
Some open issues:
Enabler
What is the role of Enabler during operation? Can we consider it as a controller for operational parameters like channel and power limit changes?
BD STA:
Any rules related to reception of enabling signal from Enabler?
Any rules related to refreshing enablement with the Enabler?
Any rules related to receiving commands from the Enabler?
NBD STA:
Any rules related to reception of enabling signal?
Can a NBD STA enabled by some other Enabler join a BSS run by a BD STA (under the control of different Enabler) ? If it is allowed, which enabling signal it needs to continue hearing?
Any rules related to refreshing enablement with the enabler?
Any rules related to receiving commands from the enabler?

23. 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 better 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.

24. 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 af 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 u for enablement process is complementary to already existing methods based on y. The af standard should at least facilitate implementation of RLQP Advertisement Server and AP from different vendors
Page 24
LG Electronics, Inc.

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

26. 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.” 26

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

28. A: Some Remarks on 802.11y Operation
In 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) 28

29. 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 (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 29

30. 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 y 30