PAWS WG session, 13:00 Tuesday, July 26th, 2011 Thanks to Pete McCann for taking minutes 1. Administrivia (chairs, 10 min) 2. Approved charter review (chairs, 10 min) Standardize mechanism for discovering whitespace database Standardize method for accessing a white space database. Standardize query and response formats Ensure that the discovery, access, and query/response formats have appropriate security Brian Rosen: lots of list discussion about what is or isn't in scope. This is the scope. Geoff Thompson: in item 4 (security) should there be something about the channel over which you do discovery, avoid misappropriation? Brian: we're not going to edit the charter. I think we have it covered. Deliverables: 1. Description of use cases/requirements (informational) 2. spec of the mechanism for discovering, accessing, query/response (standards track) Milestones: Oct 2011, Use case requirements as Info Apr 2012, Submit access mechanisms as PS BrianR: we need to discuss the requirements, if you have some that aren't covered please speak up. Gabor: People offline are preparing some solutions documents 3. FCC TV Band WS status update (Subir, 15 min) John Malyar & Subir Das Some perspective on what is going on with US and FCC US Regulatory Time Line Started 2004, in Jan 2011 order to conditionally designate nine database management entities Nov 2008, FCC adopts rules: second report and order and memorandum opinion and order (08-260) Sep 2010: database is mandatory, sensing is optional FCC Rules high level summary TVWS devices required to use geo-location to obtain channel list Devices have to provide geo-location and database returns available channel list Spectrum sensing can be performed but is not required Devices cannot radiate in "protection zones" of "protected entities" Three types of devices designated Fixed: professionally installed, no need for GPS, location entered by installer, 30m height restriction, 76m height above average terrain (HAAT) restriction Personal/Portable Mode II: access point, 100mW EIRP, must have GPS, consumer grade, operation on TV channels 21-51 Personal/Portable Mode I: Client-type operation, attaches to Mode II device by scanning channels for a MOde II, 100mW EIRP limit, does not need to report location Communication with the database Devices must contact db at least once every 24 hours All devices must report location, type of device, FCC ID, and so on Fixed device must report height to verify <30m P/P Mode II must get new channel list if it moves more than 100m or loses power P/P Mode II must signal attached Mode I devices when channel list changes Gabor: we are only concerned with Mode II devices, right? What does the "and so on..." refer to? Subir: FCC ID Gabor: we are going to define the data model, so we must know all the requirements Brian: we know exactly what that is, I can give you a precise list of what is required in the query and what is required in the response Subir: IETF needs to cover all the other rules as well, this is an example for the US. Protocol needs to be flexible so that all parameters can be included. CharlesPerkins: Mode II devices are not in cars? Would be silly to report their location every 100m? Brian/Subir: you would think so, but FCC requires it. Geo-location database Data is obtained from FCC CDBS (Consolidated Database System) ULS (Universal Licensing System) EAS (Equipment Authorization System) "white" list "black" list? TBD Registrations Fixed TVBD LP Auxiliary (Wireless mics) MVPD (Cable Head-ends) TV Receive sites / TV Translators Temporary BAS (Broadcast Auxiliary Service) links Interference Protection Contour types, examples TV stations: variable blob, depends on terrain Directional Antennae Omni circle (Radio astronomy, PLMRS/CMRS, wireless mics) Offshore radio telephone service determined by ORTS service areas on channels 15-18 in Gulf of Mexico Border areas near Canada and Mexico Database administrators group Purpose establish and maintain a database interoperability spec support development of a device to database API spec address technical and operation issues that affect the operation of database administrators Secretary: Neeraj Srivastava (Spectrum Bridge) StuartBryant: sharing/consistency, these are the DB owners problem, nothing to do with what we do here? Subir: right, but device interface is what we are concerned with Two technical subteams: database interop channel calculation Database Interop subgroup DB to DB, they will define Chair: John Malyar (Telcordia) Vice-Chair: Alan Norman (Google) Editor: Brian Rosen (Neustar) Channel Calc Subgroup covers precise calc Chair: Peter Moncure (Radiosoft) VC: Peter Stanforth (Spectrum Bridge) Ed: Voy Grohman (Arity) Gabor: channel calc is done apriori, right? DB already knows the channels? Subir: based on the location. If it specifies the location, then it can calculate BrianR: in practice, the database maintains a list of protected entities. For each one, it calculates a protected contour according to rules defined by the FCC and implemented by the calculation group. Generate a polygon, inside the polygon a certain channel is not available. Take location of device, intersect with all polygons, remaining channels are available. This is all inside the database, nothing to do with devices, not subject to standardization by the IETF. We are talking about the format of the message. In another country or band, there could be totally different calculation rules. Gabor: just clarify this is totally out of our scope Subir: right this is just to give information about what other groups are doing. Raj Patil: Brian, question, how dynamic is that information wrt contours? BrianR: theoretically, anytime a new e.g. wireless mic at a big event, they would like to be able to say that in this particular area, these two channels are unused. So on the order of minutes updates should work. Doing point/polygon for lots of queries, could be a lot of computation. For things that aren't changing very often, you can pre-calculate on a grid of 3 arc-seconds. Subir: question, when a device queries, within what timeframe must the response be there? BrianR: no FCC requirement. At some point we have to answer that question, but the update schedule may impact our requirements. Protocol may have to deal with schedules. Subir: OFCOM rules overview In the UK, channel width is 8MHz Several other differences StewartBryant: I was at a seminar where person from OFCOM was talking about this. Their view is you need to do a mixture of cognitive + database, inputs from Cept Subir: yes, we may have some requirements from rest-of-world. Definitely supporting this work getting done in IETF BrianR: Subir's presentation leads to requirements. We need to be flexible in how we represent data. May not be a list of channels, may be list of frequency ranges StewartBryant: could be a whole list plus a schedule BrianR: could be schedule or could be validity time StewartBryant: whose job is it to define that? BrianR: have to know what the regulators are thinking, there is some wording we need to conform to, US is a little ahead of rest of world, but there is some wiggle room in the wording. This is an example where we need to think hard about whether we have the right extension points. Schedule area has to be expandable. IEEE 802.22 WRAN standard and its interface to the WSD Gerald Chouinard Going back to where Subir started: 2004, Notice of Inquiry. IEEE reacted by asking 802.18 (regulatory group) to respond to the NOI. Feasible for fixed devices, formed a new WG 802.22 to develop standard that would do this job. Was issued 1st of July this year. Needed to propose an interface/primitives that contains information that the database would need. Back in 2004, we thought sensing was important (802.22.1: enhanced Part 74 protection (wireless microphone beacons) 802.22.2: Recommended practice Sensing team to sense all kinds of signals Geolocation team: diff means of geoloc, thinking that geo device would be expensive for consumer devices, we specified device for geolocation with OFDM timing (avoid use of GPS) 802.22 define RAN (Regional Area Network) 54 - 862 MHz 23, 27, 31, Mbps, BW=6, 7, 8, MHz Scheduled transmission not Aloha Range: 30 km Multipath absorption window: 37 usecs StewartBryant: below VHF, do you have to factor in anonymous propagation into the database? Gerald: probably so, but that's a database question not a device question Key features WRAN: Wireless Regional Area network designed to bring broadband to underserved low population areas Operate on vacant channels, license-exempt BS and possibly CPE may need to be professionally installed P2MP technology BS controls up to 512 CPEs and their RF characteristics Portable: nomadic, not mobile GeoffThompson: about the 512 limit, is that at any moment on the acces, subscribers over time? Gerald: simultaneous CPE GT: what happens for 513th person? Gerald: doesn't get access, or trade the number of level of services vs. number of clients. Use cognitive radio capabilities to avoid interference to broadcast incumbents Sensing, database Typical CPE installation: sensing antenna looks imposing 802.22 database interface model Takes place entirely between the DB service and the BS rather than with individual CPEs (BS has to find the channel that is common to all its CPEs rather than the CPEs doing it individually) GeoffThompson: model is CPE is not an independent entity who gets to choose from BS, it is a slave to a particular service? Gerald: yes, at any given moment. But, CPE can looks at multiple BS, but when it picks one, BS is the master Antenna is directional, professional installation is desirable TecoBoot: CPE sends position to BS? Gerald: at registration, CPE declares ID, FCC number, location, BS does the rest TB: BS then decides which channels to use, what about the initial location reporting channel? Gerald: CPE knows which channel the BS is operating on. If a new CPE comes online, BS may need to cancel the registration or change the channels TB: is this allowed by FCC? Gerald: yes, initial burst is allowed by FCC StewartBryant: alternative is BS tells CPEs on a broadcast whether they are allowed to send the first burst, which could interfere DB interface procedure BS will register as a fixed device, will enlist all of its CPEs on a real-time basis BS queries DB at least once every 24 hours using M-DB-AVAILABLE-CHANNEL_REQUEST message Database service could also push updates Security of the database interface Decided on some things based on a best guess: SSL will be supported on link between DB and BS, authenticating both WRAN system and DB EAP-TLS or EAP-TTLS for authentication Database service primitives exchanged 8 primitives M-DB-AVAILABLE-REQUEST M-DB-AVAILABLE-CONFIRM M-DEVICE-ENLISTMENT-REQUEST M-DEVICE-ENLISTMENT-CONFIRM M-DB-AVAILABLE-CHANNEL-REQUEST M-DB-AVAILABLE-CHANNEL-INDICATION M-DB-DELIST-REQUEST CONFIRM List of attributes inside each message BrianR: this is an IEEE standard, published, you have to pay? GT: 6 months after publication it becomes free BrianR: so right now people would have to pay. At various times, IEEE and IETF have negotiated that away StewartBryant: in tictoc Gabor: there is a procedure, chairs will try to work through it. GT: there is no way to make the charge go away during the 6 months Gabor: no, there was a procedure for 802.11 GT: that is for drafts, not for published standards through liaison Subir: last draft version can be served, right? BrianR: can you coneive of a future version of 802.22 using another protocol, can you imagine doing liaison work Gerald: there will be amendments, but what I described was the primitives, your protocol may not align 100% with what we did, but yes, we are open to amendments BrianR: can you coneive of a circumstance in which we converge? Or will the two protocols always be different? Gerald: it would be great to converge, we are offering what we've done as input, if there is reaction, bring it back to us and we will consider. mic: didn't see slides on meeting materials BrianR: we will have them up soon. PAWS: Problem Statement Basavaraj Patil draft-patil-paws Made a few edits for this IETF Key terms: Definition of whitespace: part of spectrum not used by primary user Ex: TV channels Figure showing whitespace Problem Statement Sensing or Database Sensing is difficult Nutshell: problem is to allow spectrum use by secondary users by going through a process to verify non-use of certain spectrum Problems related to querying a database Device needs to discovery relevant database to query Query protocol that is understood by multiple databases and devices needs to exist Data model needs to accommodate specific aspects of the spectrum, region, and regulation The device needs to be aware of its location where it seeks to find available spectrum Other issues Spectrum availability can vary across regions and countries Regulations depend on regional and national regulatory bodies The devices which intend to use the spectrum can vary in terms of their capabilities Next steps Problem statement for PAWS should be progressed toward publication as Informational Alternatively: PS can be included with the requirements and use cases I-D Gabor: how many people read this? (many hands) How many people think this is a good starting point: (5-6 hands) Do we want to consider adopting or adding into requirements? BrianR: I believe all the Informational stuff should be in one document. It is helpful for a reader to understand the context. Also works for process. The fewer of these documents the better. I would prefer there should be one document with all background information. RichardShockey: agree, should be its own document, let's hum. BrianR: Do people in the room believe this should be included in some document as a statement of the problem we are trying to solve? (unanimous hum) Scott Probasco White Space Use cases & Requirements (co-authors Gabor & ) Concepts: we all know them Use case: database discovery Scenarios: 1. Master is "pre-programmed" with address(es) 2. Master does not have an address 3. DB at that address is not suitable (e.g., doesn't cover current location) Use case: hot-spot, urban internet connectivity service 1. Multiple master devices 2. Small cells 3. Few available channels 4. Masters are un-coordinated Use case: wide-area or rural internet broadband access 1. Multiple masters 2. Large cells 3. many available channels 4. Masters are coordinated Use case: offloading, moving traffic to a white space network 1. Multimode device (cellular, white space) 2. Cellular is not preferred (cost, RF coverage, data caps, etc) 3. Move of 'offload' data traffic from cellular connection to whitespace connection Use case: TVWS for backhaul 1. Master establishes white space network 2. Bridge-slave joins the master's network 3. Bridge wiFi provides internet access to WiFi devices Use case: location based service usage scenario 1. Master registers with WS DB, including location 2. Smart phone (slave) connects to master 3. Smart phone app provides details of master to location service 4. Location service contacts WS DB for location Requirements for the Master: (list of 9 requirements, many of which come from FCC requirements) BrianR: accuracy of location doesn't impact the protocol It might be required to send uncertainty, but it isn't a requirement of the protocol itself Gabor: reformulate requirements to apply to protocol & data model, rather than master TecoBoot: as an overview, we have 200 countries in this world? Imagine each hands over a document full of requirements. Is this a first step? These are FCC requirements, not really requirements for protocol? Do we need issue tracking for requirements? BrianR: that's an impossible task, not every country has promulgated regulations. We believe we can reasonably anticipate the range of information that needs to be sent. Think hard about the data structures so they can be extended if we guess wrong. TB: so process wise, how can we make sure we meet all the requirements of all regulation bodies? BrianR: there are only a small number of regulators who have promulgated regulations. We can make sure we cover those. We can't anticipate what the next guy will do. That we have to predict. TB: so how does process work? BrianR; we have people who are in touch with regulators TB: so let's define the process RichardShockey: extensibility is the one-word answer to the question. There will be requirements that we cannot anticipate. RajPatil: re 200 countries, most of these will end up following what the FCC has done (lots of grumbling in the room) TB: In Europe, we want to have a common approach, but it is so hard. GeoffThompson: would it be reasonable for us to do basic info, then make available to regulators a format for their own requirements? BrianR: regulators do read the documents, understand the value of international markets, sometimes do a little bit of tweaking, GT: so we can have a standard container for country-specific stuff BrianR: point about process was good, we need to define what that is. Chairs will undertake to start e-mail on the list on that subject Requirements for Database Requirements for Gabor: how many people read the document? (5-8 people) Hum we took was to combine Raj's document with this one? (have one document) BrianR: hum was to take the PS as part of a WG document. We could have a hum on this document and then discuss how many documents Hannes: with the caveat that requirements will be re-worked to be requirements on the protocol not specific to the FCC BrianR: we could adopt the document now or wait for one more rev Subir: support last possibility, take things to start with, then build on top of it. If intention is to make one document, then WG can work BrianR: hum for whether to incorporate this work into a WG item? (strong support to adopt the work) BrianR: now how many documents? These are two, charter says one. (strong support for one document, bunch of don't cares, consensus is single document) All three of these must be confirmed on the list.