PAWS 0900 Tuesday 1. Administrivia (5 min) Blue sheets, minutes taker, jabber proxy, jabber scribe? 2. WG doc status (5 min) One WG document which captures problem statement, use cases, requirements 2 individual submissions on Use cases One from Zhu Lei - still have some comments that need to be addressed Take it to the mailing list Juan Carlos Zuniga - most of the items were discussed 1 on data model, Jesse Caulfield will be discussed today 1 on protocol - going to be presented today We need to decide which use cases to keep Milestones have been revised: Use cases now April 2012, instead of Oct 2011 Accessing Database now Decemper 2012 instead of April 2012 3. PAWS Use Cases presentation (Raj, JC, 20 min) draft-ietf-paws-problem-stmt-usecases-rqmts Incorporates ideas from Juan-Carlos Since last meeting, has been adopted as WG draft, rev 0 to rev 1 Several new use cases: Mobility Indoor networking Machine-2-machine Deleted the location based service use case Wasn't contributing to requirements We will now go through each use case in the document Database discovery Need to discover appropriate database for region/country/regulatory domain, so it needs to be based on location Various mechanisms for discovery Pre-programmed/configured list of databases Query a well-known website operated by the regulator etc. Brian Rosen (individual): we have a solution in the IETF, we should just use it. But, we are not ready for solution space yet. Steps for discovery: Master device connects to Internet by some other means than WS Device constructs and broadcasts/multicasts a database discovery message Receives a response(s) from available databases or a list of databases from a website Device chooses a database from a list Registration with the DB After discovering a trusted database, device may need to register with it (regulatory domain specific), e.g., FCC requires this Conditions requiring registration: Powerup Change of location by a certain distance Periodically based on a time interval Registration information includes Device ID, Serial Number, etc. Schematic diagram of registration process Master device with connectivity other than WS radio Secondary master device with no direct connectivity to the WS DB can query using another master as a relay Use cases Hotspot: urban Internet connectivity Like a WiFi hotspot Transmit power needs to be very low Operation Master/AP powers up (WS radio in idle mode) Discover database & registers Query for channels Database responds Master/AP selects a channel(s) and activates the WS radio interface Slave devices scan the WS band and detects the Master/AP and attaches to it Slave devices have Internet connectivity over WS radio channels Gabor: missing one step: after step 2, device has to ask the database what regulatory domain it is in. Needs this to determine what parameters it needs to send to the DB. Raj: right, that could be considered part of the discovery. Will need to know some schema to use depending on location. SubirDas: idle mode different from powerup? Idle mode does device always need to discover and register? Raj: if you have already registered, you may not need to do it again. The point was just that you are not able to transmit or use. EllisMaher: is it in scope that device registers with database or is the database strictly read-only? BrianRosen: no, scope of group is to determine what channels are free. Putting state in the database is out of scope Rural Internet broadband access Internet access is provided as a WAN or Wireless Regional Area Network (WRAN) Transmit power is significantly higher than the hotspot case Cell sites are fairly large: several kilometers wide ZhuLei: What about the relay case of a master device? Raj: you have to have some sort of internet connectivity? BrianRosen: document is about use cases, some use cases might lead to the same requirements. We are talking about a case where a device queries on behalf of another device. Need to differentiate whether relay is sending its own location or the location of the other device. In some regulatory domains, we assume client has same location as base stations, in other domains it needs more fine-grained location. Typical case: ad-hoc mesh network, only one device has an Internet connection, you've got to loop queries through that one. Different scenario, but protocol may be the same. Raj: differences are transmit power levels, antenna height, etc. At the end of the day, the objective looks similar. Gabor: in this case, seeing the base station doesn't mean you are located nearby. In the hotspot case, you are definitely within 50m or so. Offloading: Moving traffic to a WS network Mobile devices using 3G/4G cellular networks for data can offload the session to a WS network if a network is available Example session: video streaming Device has a policy to decide when to move the stream Scenario diagram: cellular/WS device Backhaul: WS spectrum can be used as backhaul for WiFi Rapid deployment network for emergency scenario Even spectrum that has been reserved for other uses could be made available Mobility in whitespace Master/AP can give a list of locations (current and future) Database responds with a list of available channels that are available at all locations identified in the request. Master device may use the channels while moving without the requirement to re-query due to mobility (time-based restrictions still apply) Gabor: general comment: don't know if WG agrees with these use cases, nobody took the effort to derive requirements from the use cases. You need to do this as well. Juan-Carlos: we did, Scott took a shot at merging requirements with document. Switching to Juan Carlos Indoor Networking Co-authored with BT, out of discussions with OFCOM Very similar to hotspot case Geolocation is not enough because depending on radio characteristics you might be using a completely different database Machine-to-machine Machines communicate among themselves without necessarily going through the master, could be similar to the relay case raised by Zhu Lei. Master will do the request, machines can connect to the master for Internet/database connectivity. Master device still has full control BrianRosen: looks like an ad-hoc mesh network. Is that the case? A device sends a query toward the master, may take multiple hops J-C: multihop connectivity to the master? BR: yes, but every node knows what is going on. J-C: don't want to put that intelligence into PAWS BR: distinguish the transport from the PAWS query, then there could be another case where the intermediate devices interpret the protocol Raj: not necessarily mesh networking, it is p2p connections between machines. You are obtaining the available channels, then not necessarily going through the TVWS device for subsequent connectivity. BR: What's the difference? Do I have to contribute a use case for the mesh network? Raj: would be useful to have a separate use case BR: ok, I'll contribute one. JohnMalliard: with direct links, does that mean they can operate without the master device once the channel is established? J-C: we did include a requirement for some time/period of validity. From time to time the master has to come back in and re-authorize. The machines shouldn't go off and do nasty things, but it is out of scope. Gabor: hearing different opinions, might be helpful to add clarifications to this use case. ZhuLei: M2M may be very cheap, WSDB may have different channels available to such devices. mic: Can any machine talk to the master device? When channels are assigned, is assignment coming from machine above or from the master device? From machine above. Need to describe the peering or hierarchical approach in the use case. Hannes: don't understand this at all. Terminology is confusing. The requirement is that instead of direct Internet connectivity, you query some local intermediary to see if they have cached some information? E.g., your laptop previously requested information. Instead of my machine going to the Internet, I would get the cached data from your local machine? J-C: not what we had in mind. Master is still the master. He asks for permission and somehow delegates to take care of the mesh. It's a mesh where the master belongs. Gabor: seems we need clarifications to this use case. Can you address these comments and send a new description to the list? Subir: is it the intention that all machines are WS devices and they can query the master device? Or is it only one machine? J-C: master is the one that queries. Any machine can talk to the master, but it might not be a single hop. May need to relay. Gabor: let's take it offline JohnM: clarification, please describe peer/non-peer relationship Back to Raj Next Steps Request further review and comments Would like to progress the I-D to WGLC in April Gabor: are there any problems with these use cases? PeteMcCann: what about the registration use case? Is it keeping state? also heard that keeping state is out of scope. Conflicts. BR: regulations require registration, there is no good reason to do it but we are required to do it. Register, creates state, deregister, release state. Have to be registered to query. HannesTschofenig: is it a publish/subscribe type of registration? BR: there are different requirements ZhuLei: Mobility of 100m might be too burdensome on the database BR: send text, the number doesn't matter to the protocol. mic: no cases where the client device needs to do any querying? JohnM: back to offloading, raises a question similar to m2m. If use cases for devices to access the database, cellular device has 2 different connectivities, cellular leg doesn't seem relevant to the protocol. BR: it's ok that two use cases don't have any requirements differences. Raj: Most of these use cases talk about masters sending queries, slave devices can do it too, but it's not required. Gabor: even if use cases look the same, there might be a different requirement to use the WS. In offloading case it is offloading. Any additional requirements? Pete: multicast case might be covered by multiple location query JohnM: any requirement to validate the slave devices? 4. PAWS Requirements presentation (Gabor, 30 min) Now moving on to the requirements Gabor to present Requirements Grouping Data model Protocol Operational Data model: 4 requirements about location D3: location of the subject and uncertainty if location uncertainty exceeds regulatory requirements, don't make a query Pete & BR: device needs to know the rules for uncertainty vs. ability to query Alex: unhappy with the consequence Gabor: not in the draft currently, just that you get an error if uncertainty is too high D4: (copy-paste error? replace with): data model MUST support specifying multiple (independent) locations Apurva: we have a requirement Alex: concerned about "multiple". Could mean I put 1M and get info about the whole world. Multiple sounds like a potential d-dos. Gabor: put an upper limit on the number? Alex: yes, maybe 2 or 3. Gabor: 2 use cases, 1 start/stop, 1 while moving 2nd case might be a query with a big radius JohnM: some of these are functional requirements not data model requirements. Idea that you can query multiple locations seems reasonable. The idea of computing multiple locations requires more study remote: normally device is at one location, need dummy device ids. Does db do the intersection or device? We will delete D.7 D8: Data model MUST support specifying channel availability information for an area around a specified location Raj: is this a contour that you are specifying? So like, 50km around my current location? Gabor: for example. Raj: contours have been discussed Gabor: interested in the available channel list in this area Raj: response could be very wide, area Gabor: response could be "no channel" and that might be a risk Raj: Requirement seems weak JesseCaulfield: This scenario was debated heavily during development of FCC whitespace rules. FCC changed their minds and allowed mobility within a predefined contour. This should be a requirement. JuanCarlos: seems like you guys had different views about whether this was in the request or response. Jesse: use case FCC wanted to enable was mobility within a predefined area. Andrew,BBN: Is it possible to specify a direction for transmission in addition to location? Gabor: suggest new requirement on the list Radiation Parameters D1, D6, D9: combine these, have one requirement antenna height maximum output power etc. Transmitter ID requirements D.2: ID of a transmitter device used to be certified by a regulatory body for a regulatory domain D.2.1: contact or a list of contacts of this transmitter. D.5: List of available channel list and time constraints for the channel list Gabor suggests augmenting with lower/upper frequencies and time of availability Protocol Requirements P.1: protocol MUST provide a mechanism for the subject to discover the WS database it has to use at a given location P.2: MUST support regulatory domain discovery Implies transmitter first queries the DB to find out the regulatory domain before it queries for the available channel list Raj: when you discover the database, you probably know the regulatory domain BR: need to spend time figuring out an implementable requirement. Related to sending "rules" for a domain Jesse: don't take it off yet, put it as a suggestion rather than requirement. Current regulations envision tight coupling between certified devices and owners. Don't know how to do global international roaming. Gabor: we will take this to the list. Subir: Note may not be applicable JoelHalpern: implication in an earlier comment that BR made in passing, we need to document the coupling between regulatory domain, database, requirements. Need to be clear about what coupling we are willing to assume for the first version. J-C: document about UK requirements, we knew some things did not apply to FCC. Feedback channel may or may not be applicable to certain regulatory domains. Security-specific Protocol Requirements P.4, P.5, P.6, P12, P13: we will take these to the list, they may not be controversial P.3: Pushing updates in channel availability changes to subjects. Alex: adding quite a lot of complexity to the protocol. This is a different story between a simple query protocol and one that keeps state about each of its clients. Need to keep a connection open to the server? BR: always a tradeoff. Most of the environments require a way to get a change in channel availability in a short period of time. Can be done with push or pull (polling). In the US, wireless MICs often have fast time to clear the channel. Raj: OFCOM also has requirements for a "kill switch" Gabor: so this is a valid requirement BR: would like to make the requirement "quick way to change availability" rather than imply a mechanism. Operational Requirements 01 through 011 They are not needed for Data Model or Protocol Design But without them the usage of the protocol is not clear no objection to leaving them in the document. 5. Input on Requirements from 802.22 (Apurva, 15 min) 802.22 Database interface model BS acts as proxy to all the CPEs, queries the DB with 802.22 Additional Requirements from 802.22: D.1: transmitter parameters height parameter must be AGL in meters Gain parameters: antenna directionality information in dB every 5 degrees RF Mask Parameters: specify regulatory domain, regulatory class, device type Not all RF masks would be acceptable. Unless you meet some basic mask, you will not be able to avoid interference Gabor: good input, we will try to capture input from .11 and .22 and put it in the protocol design section D.2: ID of the subject should include certification number as well as technology D.3: location, uncertainty in meters and confidence in percentage 802.22 would like the info to be in NMEA format Gabor: this might be controversial, we will take it to the list D.4: should not be power, should be EIRP D.6: single and multiple locations Need not do the intersection in the WSDB D.7: channel availability in an area Could be done using dummy device IDs D.8 (NEW): reporting to the database the selected channel Agree with P1-P6 P.7 (NEW): protocol MUST require the master to maintain contact with database as specified by local regulator as well as to specify and re-register its operating and backup channels with at least the same periodicity We will skip the operational requirements and talk about them on the list. 5.1 Coexistence In-scope / out of scope discussion We will defer this to later 6. PAWS Data Model presentation (Jesse, 30 min) Message data structure in a UML-like format mic: copyright on the slides, remove the copyright before uploading the presentation to the datatracker. 2 equipment classes, 3 modes of operation Classes: Those that create a network, those that consume a network Operation: fixed, Mode2 (transportable, limited mobile), WSIF data model hierarchy Supports FCC baseline Supports all use cases we've come across Anticipates international requirements A commercial spec contributed to IETF 4 objects of interest to this group: Antenna & Radiation pattern Regulatory domain Channel (band start/stop, list of rules) Licenses Transmitter Location descriptions Gabor: we lost Jesse. Who has read the document? A couple of hands, good sign. People realize that you are referencing existing IETF specifications (civic and geo locations, icalendar, vCard, etc) Jesse's back Gabor: raise your hand if this is a good starting point? No hands. Not enough data. Hannes: More important to discuss the ideas behind the data model BR: not ready to make a decision like that. Need to get a draft out. We ought to wait before deciding whether to start with this or not. Jesse: that's a fair response OritLevin: Announcement about these documents, missed them. This is the 2nd version, 1st version submitted in October was empty document. Not the way things should be done. 2nd document, the protocol was submitted just today. I read both documents this morning, great start, but we shouldn't continue like that. BR: fair comment we'll try not to do that again. Russ: strongly encourage, if it's not by the deadline, don't put it on the agenda. Gabor: this document was there before the deadline Need more discussion on mailing list and then take it from there. 7. PAWS protocol framework (30 min) JohnMalyar Doc was uploaded today WS Application, HTTPS, Reliable Transport, IP Gabor: is this agreeable to the wg? BR: not prepared to do anything yet, haven't seen the document, not ready for protocol design JM: basic functionality bootstrapping registration querying the database device validation Hannes: what does device bootstrapping mean? What does identity/validation mean? JM: bootstrapping means device initializing itself with the database, authenticating, etc. Establish initial connection Hannes: some of those statements are very vague. It's not so clear what that means. If you want to say the device has to authenticate itself to the database server, that's specific. There is no device identity as such, what would it be? What would you authenticate? JM: I can give some examples, this was just a framework. Regulatory authority's ID, serial number, a way to authenticate the device. Hannes: do people really want a shared secret with the database? What serial number for my laptop? How does the whole thing work? JM: In the US, there is the need to authenticate the device. One way is to use its ID and serial number. Could be a shared secret. Message format: version, authority, device type, device identity comment: this looks like a protocol. JM: just an example Device Registration Message format, with MAC Querying the database Message format, with MAC Response message format: list of channels, duration of availability, max power Device validation request/response Message format, identity, location Encoding considerations Here were bit-oriented descriptions May want to include XML, JSON Security Considerations Mutual Authentication Message Integrity Confidentiality Replay protection Hannes: Good idea to talk about framework/architecture in addition to requirements. That document is not a framework/architecture, it talks about irrelevant details such as bit encoding. Interested in security requirements, some of the regulatory requirements don't make sense we have to translate them into something that works. Gabor: questions you may want to answer in the next version of the document. BR: We need better security requirements, better architecture framework, we need some suggestions. 8. Next steps discussion (10 min) Co-existence in scope/out of scope discussion 802.19 will provide co-existence requirements to PAWS in January/February Question to the WG: should the scope be extended to cover co-existence or not? Rationale: if adding co-existence is easy later, it should remain out of scope. If it is hard, we should extend the charter sooner rather than later. Suggestion: we wait for 802.19 requirements and then make an educated guess ZhuLei: it will be a real impact to the PAWS architecture to add co-existence later. Framework should be extensible to adopt co-existence. We should add and think about impact now. Peter St. Andre (AD hat on): do people really want to work on this? We tightly scoped the charter originally, would like to hear from more than one person that this is needed. BR: ok, let's take a hum. How many people think it's important to expand the charter now? Consensus is we'll wait.