TVWS Enablement after New FCC Rules

Slides:



Advertisements
Similar presentations
tv Mi-Kyung Oh etc., ETRI Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs) Submission Title: TV White Space.
Advertisements

Doc.: IEEE /0544r0 May 2010 Padam Kafle, Nokia Submission Slide 1 Some Comments on White Space Map IE Authors: Date: May 14, 2010 NameCompanyAddressPhone .
Doc.: IEEE /151r0 Submission Oct Jesse Caulfield, Key Bridge Global LLCSlide 1 Interfacing the White Space Database Notice: This document.
Doc.: IEEE /0262r1 Submission March 2010 Ha-Nguyen Tran et al., NICTSlide 1 Requirements and Amendment Regarding TVWS Database Access Notice:
Doc.: IEEE /0175r2 Submission June 2011 Slide 1 FCC TVWS Terminology Date: Authors: Peter Ecclesine, Cisco.
Doc.: IEEE /1274r1 November 2011 Padam Kafle, Nokia Submission Neighboring Network Information Sharing through RLSS Authors: Date: Nov 7, 2011.
Doc.: IEEE /1393r1 Submission November 2011 Slide 1 OFCOM ECC TR 159 TVWS Terminology Date: Authors: Peter Ecclesine, Cisco.
Doc.: IEEE /0261r0 SubmissionSlide 1 Enabling Procedure of Communication in TVWS under FCC rules Notice: This document has been prepared to assist.
Submission November 2010 doc.: IEEE /1236r0 Enhancements to Enablement Procedure Slide 1 Santosh Abraham, Qualcomm Incorporated Date:
Doc.: IEEE /xxxxr0 July 2011 Padam Kafle, Nokia Submission Simplification of Enablement Procedure for TVWS Authors: Date: July 18, 2011 NameCompanyAddressPhone .
Doc.: IEEE /0352r1 March 2011 Padam Kafle, Nokia Submission Simplification of Enablement Procedure for TVWS band Authors: Date: March 11, 2011.
Submission November 2010 doc.: IEEE /1237r0 Over the Air Database Access for Mode 2 Capable Devices Slide 1 Santosh Abraham, Qualcomm Incorporated.
Doc.: IEEE /0019r0 Submission February 2010 Mika Kasslin, NokiaSlide 1 High Level Architecture View Notice: This document has been prepared to.
Amendment Proposal for TV White Spaces Operation
Requirements and Amendments Regarding TVWS Database Access
Submission Title: Proposed Approach for MAC changes for TVWS
FCC TVWS Terminology Date: Authors: Month Year Month Year
White Space Map Notification
Follow-Up on WUR Discovery Frame and Discovery Channel
Proposal on system description, reference model and draft outline
FCC TVWS Terminology Date: Authors: Month Year Month Year
Channel list request/response for multiple geo-locations
Follow-Up on WUR Discovery Frame and Discovery Channel
Enabling signal and enablement
Consideration on WUR frame for Fast Scanning
Consideration on WUR frame for Fast Scanning
Multiple Locations Channel Availability Query
P System Architecture Date: Authors: March 2010
Multiple Locations Channel Availability Query
Multiple Locations Channel Availability Query
Low Rate Enabler Date: Authors: March 2011 Month Year
Follow-Up on WUR Discovery Frame and Discovery Channel
Interference Management for TVWS Networks
Secure Enablement and CVS without Persistent Association
Channel list request/response for multiple geo-locations
FCC rules and design Date: Authors: October 2010
Follow-Up on WUR Discovery Frame and Discovery Channel
Enabling Procedure of Communication in TVWS under FCC rules
Low Rate Enabler Date: Authors: March 2011 Month Year
P System Architecture Date: Authors: March 2010
Channel list request/response for multiple geo-locations
Follow-Up on WUR Discovery Frame and Discovery Channel
Interference Management for TVWS Networks
TVWS WLAN Enablement- Review and Open Issues
TGaq Mini Tutorial Date: Authors: November 2013
Enabling signal and enablement
TVWS WLAN Enablement- Review and Open Issues
Identification Signal for Fixed devices
EHT Feature Discussion
October 2010 On the new FCC second order memorandum opinion and order with regard to TVWS Date: Authors: Notice: This document has been prepared.
Fast Session Transfer Session Setup in TVWS
TVWS WLAN Enablement- Discussions and Open Issues
Examples of deployment scenarios
Simplification of Enablement Procedure for TVWS band
Multiple Locations Channel Availability Query
11af architecture Date: Authors: May 2011 Month Year
TVWS WLAN Enablement- Discussions and Open Issues
Synchronization of Quiet Periods for Incumbent User Detection
Simplification of Enablement Procedure for TVWS band
Neighboring Network Information Sharing through RLSS
Notification of available channel list in TVWS
Fast Session Transfer Session Setup in TVWS
P System Architecture Date: Authors: March 2010
P System Architecture Date: Authors: March 2010
TVWS WLAN Enablement- Discussions and Open Issues
Discussion on 6 GHz Band Support
Format for Device Location Information in .11af
Enabling Procedure of Communication in TVWS under FCC rules
EHT Multi-AP Feature Discussion
Date: Authors: February 2010 Month Year
Presentation transcript:

TVWS Enablement after New FCC Rules Month Year doc.: IEEE 802.11-yy/xxxxr0 TVWS Enablement after New FCC Rules Date: November 02, 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 Prabodh Varshney +1 469 9512745 Prabodh.varshney@nokia.com Zexian Li +358 50 4869272 Zexian.li@nokia.com John Doe, Some Company

Contents Introduction FCC’s Final Rules and Implications Summary of FCC Rules Network Architecture and Interfaces Mapping of FCC Terms to 802.11 Spec What are the Next Steps?

doc.: IEEE 802.15-<doc#> <month year> Introduction The Dynamic Station Enablement (DSE) was first introduced by 802.11y as a means to control the unlicensed devices from a licensed operator running the network in 3650-3700 MHz licensed band. 802.11af specification has adopted 802.11y DSE procedure as its basis for enablement and has started modifying it for TVWS operation. Some major recent changes (in D0.06) have been: A separate server entity (e.g., a server in IT department, registered location server) was introduced (Doc: 238r3, 737r3) Enabling signal definition was changed (beacon frames with an advertising Protocol element with an Advertising Protocol tuple whose Advertisement Protocol ID is set to the value of Registered Location Query Protocol) (Doc: 737r3) GAS protocol from .11u was added as a means for enablement, channel power control etc. (Doc: 737r3, 767r1) Our proposal (11-10-0813r5) has added terms and definitions as a basis for architecture, and also expanded the enablement procedure to be fully specified that include all parameters necessary for the enablement decision (to the extent that allows third party Enabler implementations) The TVWS enablement procedure has to be revisited to address the new regulatory requirements coming from the recent FCC ruling > Page 3

FCC’s Final Rules and Implications doc.: IEEE 802.15-<doc#> <month year> FCC’s Final Rules and Implications We need to clearly understand the deployment possibilities based on the final FCC rules (10-174), agree on a generic architecture as a basis for different entities and define the required procedures There is a room for simplifications and clarity: Agree on the required entities, interfaces and level of message flows Take out what is not needed Only specify what is necessary as per the regulations > Page 4

Summary of FCC Rules (for network initiation and operation) doc.: IEEE 802.15-<doc#> <month year> Summary of FCC Rules (for network initiation and operation) Fixed Device operation: Network Initiation: can initiate and operate network (can send enabling signal to other Fixed and PP TVBDs), but only after getting the channel list (for its own location) Geo-location capability: requires latitude, longitude coordinates (accuracy +/- 50 m) plus antenna height obtained by, Own geo-location capability Professional installation service Need to determine at the time of installation and first activation from power-off, then re-establish each time if its location has been changed Registration to FCC DB: Required to register: first time after installation, then each time if its location has been changed Detailed location and identifying information are required: Geo-location coordinates plus antenna height above ground level FCC ID, serial number by manufacturer, details of owner and responsible contact person > Page 5

Summary of FCC Rules .. Database access for channel query: doc.: IEEE 802.15-<doc#> <month year> Summary of FCC Rules .. Database access for channel query: Access by connecting to the internet: either directly or through another fixed TVBD that has a direct connection to the Internet Provides: location and identifying information (same as for registration OR up to DB provider?) Receives: available channel list, may also receive channel availability schedule info, separate available channel list for Mode I. At least once a day Other functions during operation: Must adjust the channel usage to comply with the channel availability schedule info obtained by the database for the 48 hour period since the time of last DB access Must transmit identification signal (device identity and geo-location) May accept contact initiation request from Mode I devices, and provide list of available channels (list valid for its own location or a separate list for Mode I obtained from DB) Requires to first provide FCC ID of Mode I device and receive successful verification back Must broadcast contact verification signal if it had provided a list of available channels for operation to a Mode I device must have the capability to display the lists of available channels and operating channels Discussion: We believe 802.11af specification should include Fixed devices > Page 6

Summary of FCC Rules .. Personal/Portable Mode II Device: doc.: IEEE 802.15-<doc#> <month year> Summary of FCC Rules .. Personal/Portable Mode II Device: Network Initiation: can initiate and operate network (can send enabling signal to other Fixed and PP TVBDs), but only after getting the channel list (for its own location) Geo-location capability: requires latitude, longitude coordinates (accuracy +/- 50 m) by its own geo-location capability Need to determine its geographic position: each time after activation from power-off re-establish at least once every 60 s during operation (except while in sleep mode) Registration to FCC DB: not required Database access for channel query: Access by connecting to the internet: either directly or through another fixed or Mode II TVBD that has a direct connection to the Internet Provides: location (geographic latitude, longitude coordinates, accuracy +/- 50 m) and identifying information (FCC ID & Serial number by manufacturer) Receives: available channel list, may also receive channel availability schedule info for 48 hr May request and receive channel availability information for multiple locations > Page 7

Summary of FCC Rules .. Other functions during operation: > doc.: IEEE 802.15-<doc#> <month year> Summary of FCC Rules .. How often: At least once a day, each time after activation from power-off Once it moves by > 100 m distance since the location of last DB access, OR when moves outside from its currently valid channel availability zone for multiple locations Other functions during operation: Must adjust the channel usage to comply with the channel availability schedule information May accept contact initiation request from Mode I devices, and provide list of available channels Requires to first provide FCC ID of Mode I device and receive successful verification back from database Must broadcast contact verification signal if it had provided list of available channels for operation to a Mode I device Must signal Mode I devices to acquire new channel list if it looses power and obtains new channel list (or whenever it gets new channel list?) must have the capability to display the lists of available channels and operating channels > Page 8

Summary of FCC Rules .. Personal/Portable Mode I Device: doc.: IEEE 802.15-<doc#> <month year> Summary of FCC Rules .. Personal/Portable Mode I Device: Network Initiation: not allowed to initiate a network of other Fixed or PP TVBDs Geo-location capability: not required Registration to FCC DB: not required Database access for channel query: Not required, but must be in contact with a fixed/Mode II device to get available channel list Contact establishment with a Fixed or Mode II device for channel query: To initiate contact, it can transmit in an available channel used by Fixed or Mode II device, or on a channel indicated to be available for Mode I device on a signal seeking such contacts Provides: identifying information (FCC identifier) Receives: available channel list and info to decode the contact verification signal Contact verification process: Must re-check/re-establish contact with a Fixed or Mode II device if activated from power-off Must either receive and decode contact verification signal, at least once every 60 s (except while in sleep mode) originated from the same Fixed or Mode II device that had provided the current available channel list , OR contact a Mode II or fixed device to re-check/re-establish channel availability Must seize operation immediately if it can not perform the procedure above Other functions during operation: must have the capability to display the lists of available channels and operating channels > Page 9

Network Architectures and Interfaces doc.: IEEE 802.15-<doc#> <month year> Network Architectures and Interfaces Signaling Interfaces and Open Issues: DB Access: could be for Registration for Fixed Devices Channel query for its location (Fixed and Mode II) FCC ID validation of Mode I device Qn: Is it beyond scope of 802.11 ? OR, need to specify message content/format at least? Initial wireless signal before Mode I can attempt contact: Simple beacon frame reception can be sufficient Any need to define signal seeking contact (FCC term) ? Shall we call it Enabling signal? Enablement (contact establishment for channel query): 1. Is enablement term fine (contact establishment in FCC) ? 2. Request contains FCC ID, Response: channel list + Info to decode contact verification signal 3. Enabler is a functional unit to serve its Mode I contacts WLAN Operational control (contact verification): Must hear contact verification signal at least once every 60 s (from same Enabling STA providing channel list) Shall we still call it Enabling Signal? Scenario 1: AP has direct connection to Internet for DB access > Page 10

Network Architectures and Interfaces .. doc.: IEEE 802.15-<doc#> <month year> Network Architectures and Interfaces .. Scenario 2: AP does not have direct connection to Internet, access is via another TVBD > Page 11

Network Architectures and Interfaces .. doc.: IEEE 802.15-<doc#> <month year> Network Architectures and Interfaces .. Some Implications: Enabling signal: the enabling signal definition may require re-thinking: The signal should be encrypted to ensure unique mapping to its source Must be over the air signal in a TVWS channel Simple implementation of Enabling STA may only require an Enabler functionality to serve Mode I devices. Keeping RLQP support as a requirement for Mode II or Fixed devices can support Scenario 2, but we need to be clear if it is a mandatory requirement or not. Qn: Do we need to mandate RLQP support as a mandatory feature for Mode II/Fixed ? Enablement procedure, Enabling STA and dependent STA relationship looks good to have for defining the exchanges between a non-beaconing STA (Mode I in FCC term) to a beaconing STA (Fixed or Mode II in FCC term). However, the need for enablement procedure between two beaconing STAs, or between RLS and a beaconing STA may require re-thinking: The access from a beaconing STA to RLS directly, or via another beaconing STA may only be required for: obtaining available channel list for its location, OR for FCC ID validation of Mode I devices, OR Registration for Fixed devices 802.11af needs to mainly define the procedure for the above messages for beaconing STAs The internet access from a beaconing STA via another beaconing STA can be done in pre-association state, not required to have enablement or follow dependent STA state machine > Page 12

Mapping of FCC Terms to 802.11 Spec doc.: IEEE 802.15-<doc#> <month year> Mapping of FCC Terms to 802.11 Spec Device Types: Fixed TVBD PP Mode II PP Mode I Messages: Geo-location format: For Fixed TVBD For Mode II Available Channel List Channel Availability Schedule Mode I FCC ID Validation Signals: Identification signal (for fixed) Contact verification signal Enabling Signal/control signal (for network initiation) Signal seeking contact STA Types: Fixed Beaconing STA => Enabling/Dependent AP PP Beaconing STA => Enabling/Dependent AP Non-beaconing STA => Dependent STA Messages: Geo-location format: Antenna height included Geographic coordinates (NAD 83) only White space MAP (is power info needed?) Channel Availability Schedule (new info) Include FCC ID validation in enablement Signals: Need location and ID broadcasting Enabling signal Enabling signal or only beacons ? Beacons/ Enabling signal > Page 13

What are the next steps ? Changes necessary due to new FCC rules: doc.: IEEE 802.15-<doc#> <month year> What are the next steps ? Changes necessary due to new FCC rules: Impact to RLS based architecture (as a separate entity or an entity within a Fixed/Mode II TVBD) FCC rule mentions that a Mode II device can access database either directly by its own internet access or via other Fixed or Mode II TVBD that has direct connection to Internet. However, the direct Internet connectivity is a vague requirement. Can the RLS entity be considered as a part of the Internet connection? Mode II operation requires some additional functions to support limited mobility: possibility of multiple location channel map, DB access once it moves by 100 m distance Assertion of geo-location position once every 60s (except while in sleep mode). This is an internal procedure within a STA. Mode I device need to provide FCC ID to a Mode II/Fixed TVBD, which needs to validate it with FCC DB before it can send available channel list Mode I device need to either receive a “contact verification signal” from a Fixed/Mode II TVBD once every 60 s or contact a Fixed/Mode II TVBD to re-verify/re-establish channel availability to continue its operation Accommodating new requirements into our text proposal (Doc: 813r6): We view the enablement procedure to be suitable mainly between the non-beaconing STA and an Enabling STA/dependent AP The RLQP protocol should include the signaling exchanges for channel list query between the beaconing STA (Fixed/Mode II) to RLS, and to another beaconing STA for an indirect access to RLS. > Page 14