Once we have a PAWS standard, the certification process should be greatly simplified, and it should be much easier to certify a device with multiple databases simultaneously.
-Pete Peter Stanforth wrote: > That is not a valid assumption. > The FCC did not consider how the DB and WSD communicate, it simply > treats the pair as a system. > Under the rules a TVWS radio get part 15 certification in two parts, > by passing the typical emissions tests and demonstrating correct > interworking with a database. The resulting FCC ID is based on the > combination. Note that a device can be certified with more than one DB > by repeating the second part of the test process. There is no ability > to say radio A, certified with DB X, can talk to DB Y because radio B > was certified with Y. > Peter S. > > On FriApr/20/12 Fri Apr 20, 10:03 AM, "Peter McCann" > <[email protected]> wrote: > >> I think at least part of the reason the WSD and WSDB have to be >> certified together today is that we have no standards for the interface >> between them. So, they have to be viewed together as a "black box". >> >> Once we have PAWS, it will be possible for a device owner to easily >> switch database providers, and to more easily support roaming to >> different jurisdictions. >> This is what imposes the requirement for a discovery protocol. >> >> -Pete >> >> Peter Stanforth wrote: >>> Just to clarify US implementation ALLOWS for operator to choose DB. It >>> does not require it. We have to support various schemes for how the DB >>> to use is determined. Peter S >>> >>> There are many more solutions and the choices have more bearing on >>> commercial and business issues than technical issues. Out of necessity >>> we built a discovery solution, because we have radios and databases >>> running in trials in several countries, that is very different from >>> both of those described. The solution we chose was as simple and >>> quick as possible because the goal was to try to get trials up and >>> running, so I would not offer it up as a direct solution but it does >>> have some interesting concepts I will outline below. However because >>> the scope of discovery keeps growing I still think it should be >>> outside the current scope of PAWS. Lets get a protocol completed and >>> decide if we need to come back and address this issue. >>> >>> First issue. For our US solution discovery is not allowed in the >>> context described below. The radio has to be certified along with the >>> DB(s) that it will operate with. In the UK they have proposed a >>> national discovery process that will be managed by the regulator. I >>> can't speak for Ofcom but I believe they chose this approach to have >>> some control of the databases that are actually providing access to >>> white space. Thus I don't believe they will be happy relinquishing >>> control to some UN of database discovery. >>> >>> Second issue. The radio vendors we are working with do not want to >>> have to go to different databases, though they would like the >>> option to choose. >>> In the US regulation they achieve this by certifying with multiple >>> databases. In the Uk they would use a business relationship related >>> to the list provided by Ofcom. >>> >>> Third issue is who is making the decision? There seems to be a >>> presumption that the radio is making the choice. I Strongly reject >>> that. Here in the US the implemented model allows the network >>> operator, who purchased the radio, to choose the database. I expect we >>> have to support both models and maybe others, which further >>> complicates discovery. >>> >>> Fourth issue is flexibility. One complaint on this forum was how to >>> add or delete from the possible list. Again the presumption was >>> that the lack of a discovery mechanism would prevent this. >>> >>> This is what we did. Step 1 the radios leave the manufacturer >>> preconfigured with the address(s) of the DB that it can talk to. So >>> today it is our US database as that is what the device is certified >>> for. Step 2. The radio always comes to the last known (initially >>> original) DB. The DB verifies the location and determines if it is >>> within scope. If not it returns a pointer/link to the device to direct >>> it to a DB that can support it based on the reported location. As I >>> said this was done as an expedient. However I could see a variation of >>> this appealing to a device manufacturer. Assume that every device is >>> preprogrammed to "phone home" the device manufacturer can then return >>> the pointer/link to the DB or DB discovery server the device is to use >>> based on the location provided. Several nice things about this >>> approach. One I don't need to create some UN of Database discovery >>> mechanisms and, two, the device manufacturer can add/delete support >>> for DB around the world when and how it sees fit. Such an >>> implementation would serve the US market (it would return a list of >>> certified DB) and Ofcom (it would retune a pointer to the Ofcom DB >>> manager process). Third this is a very simple, lightweight proposal >>> that does not need to carry the burden of a process designed for >>> Public Safety applications (LoST). >>> >>> So a long way of saying I don't buy the two options as I think >>> there are many more, much better, options. >>> >>> Peter S. >>> >>> On ThuApr/19/12 Thu Apr 19, 5:52 PM, "[email protected]" >>> <[email protected]> wrote: >>> >>>> ➢ it would be useful to actually have some I-Ds proposing a solution >>>> for discovery I guess Subir initiated this thread to find out which >>>> solutions might be acceptable for the group. >>>> >>>> So far we heard about two possible solutions: >>>> a) LoST (RFC5222), and >>>> b) (semi-)preconfiguration >>>> >>>> With LoST, the master device needs to first discover a LoST server >>>> (using either DNS, DHCP or it may be preconfigured), then do the >>>> query. This assumes there is a LoST server which is preconfigured >>>> with the boundaries the WSDBs can provide answer for. In roaming >>>> cases, the LoST server would need to be a local one (not just _the_ >>>> preconfigured one), as it is unlikely that a LoST server in one >>>> country would know the WSDBs in other countries. If the master device >>>> does not know what country it is in, it may find that out from the >>>> WSDB it is told to contact by the LoST server. The weak part of this >>>> solution I think is the roaming case, where the LoST server has to be >>>> discovered either by dhcp (we all know the limitations of this) or >>>> DNS. DNS also has its practical limitations, as zone admins may be >>>> reluctant to just add U-NAPTR records for a service with limited >>>> usage. If there could be assumed that the is a global LoST server >>>> able to answer queries from all over, then this could be a working >>>> solution. But can we make these assumptions? >>>> >>>> The preconfiguration could be as simple as provisioning the master >>>> devices with a URI, which would contain an up-to-date list of >>>> existing WSDBs. The device would need to find out which country it is >>>> in, then query the appropriate db. If there are multiple in that >>>> country and didn't pick the right one, it could either be redirected >>>> to the right one or could try itself the other one. The problematic >>>> part here is how to find out what country it is in. Again, if we >>>> assume non-roaming, then it is trivial, the problem here is also with >>>> the roaming case. If the device has map data available, that would >>>> help it map its location to a country/regulatory_domain. >>>> >>>> So, I think both solutions have their weak points, depending on >>>> how the assumptions we make will match with the global >>>> deployments. If we conclude that different discovery mechanisms >>>> would suit better the diversity of use cases, we may not need to >>>> pick one mechanism, but go with (eg) two. >>>> >>>> - Gabor >>>> >>>> >>>> From: [email protected] [mailto:[email protected]] On Behalf >>>> Of Patil Basavaraj (Nokia-CIC/Dallas) Sent: Thursday, April 19, 2012 >>>> 12:35 PM To: [email protected]; [email protected] Cc: >>>> [email protected] Subject: Re: [paws] Database Discovery Question >>>> >>>> >>>> I agree that we are jumping off to discuss the solution space. The >>>> requirement for PAWS is that we need a database discovery mechanism. >>>> There can be multiple approaches towards this requirement. LoST is >>>> one option. But there are others as well and it would be useful to >>>> actually have some I-Ds proposing a solution for discovery than >>>> fragmented pieces of information and ideas. >>>> >>>> -Raj >>>> >>>> From: "<ext Rosen>", "[email protected]" >>>> <[email protected]> >>>> Date: Thursday, April 19, 2012 1:40 PM >>>> To: "Das, Subir" <[email protected]> >>>> Cc: "[email protected]" <[email protected]> >>>> Subject: Re: [paws] Database Discovery Question >>>> >>>> We're getting solutions ahead of requirements. >>>> >>>> LoST is a solution to a requirement for discovery. >>>> >>>> However, the answer to your question is that either we use an >>>> existing LoST service and add service urns for our purpose, or all >>>> the database operators in an area cooperate to run one LoST service, >>>> or some single neutral entity runs it. >>>> >>>> Brian >>>> >>>> On Apr 19, 2012, at 2:33 PM, Das, Subir wrote: >>>> >>>> >>>> I think that database discovery should be left to each country to >>>> define based on their own requirements and Whitespace ecosystem. >>>> >>>> By that argument, we should close up shop and let each country >>>> define their own database query protocol. >>>> >>>> SD> I would not consider both of them at the same level. >>>> >>>> I do not understand how we will satisfy the following: >>>> >>>> If it is an operator managed LoST service (likely) how would it know >>>> what answer to provide for the other database assuming there is no >>>> roaming relationship. And why should the operator provide this, if >>>> he is not managing the whitespace service. >>>> >>>> >>>> >>>> >>>> From: Rosen, Brian [mailto:[email protected]] >>>> Sent: Thursday, April 19, 2012 2:01 PM >>>> To: Don Joslyn >>>> Cc: Das, Subir; [email protected] >>>> Subject: Re: [paws] Database Discovery Question >>>> >>>> <as individual> >>>> I disagree. >>>> >>>> While local regulation could limit capability for discovery, in >>>> general, I would like to be able to build devices that find >>>> databases based on location and type of device. >>>> >>>> It may be, as in say GSM cell phones, that discovery presents a list >>>> of possibilities, and specific choices get based on things like >>>> roaming relationships, but to make that work requires standardization. >>>> >>>> See inline for comments >>>> On Apr 19, 2012, at 1:30 PM, Don Joslyn wrote: >>>> >>>> >>>> >>>> I don't think PAWS should define discovery, I think the protocol >>>> should simply start after a device has "found" the correct database >>>> to use. >>>> >>>> I feel this way for many reasons: 1) In the US, a radio is certified >>>> to work with one or more specific databases. So the device will be >>>> pre-configured to contact specific databases, no need to implement a >>>> discovery service. If the device is programmed to work with more than >>>> one database provider, the device owner will configure which one to >>>> use based on the relationship that they have established with the >>>> database provider (for example, which one they are paying to use). >>>> Discovery would provide the list of (10) databases. Which one you >>>> use could be based on existing subscriptions, but could also be based >>>> on roaming agreements. Preconfiguration won't work: I build a device >>>> that is certified to work in the U.S. and the U.K. It's sold to a >>>> U.K. customer, who visits the U.S. The customer's U.K. provider has >>>> a roaming arrangement with one or more U.S. database operators. I >>>> want that to work, even if the device is certified to work in 25 >>>> countries. Preconfiguration rarely works well in global, mobile >>>> environments. You can do it, but I want a standardized discovery >>>> mechanism. >>>> >>>> >>>> >>>> >>>> 2) Discovery services like LoST are based on location, but the >>>> device's relationship with a database service is not known or >>>> considered. While it may seem simple to configure LoST or similar >>>> service to point to a database service based on location, how do you >>>> point to the one that the customer has a relationship with, for >>>> example, paid to use? I do realize that this may not be an issue in >>>> every country. See roaming above. You may have configuration for >>>> your home database, but not a roaming database. Also, I expect >>>> arrangements in some other countries will be simpler than the U.S. >>>> >>>> >>>> >>>> >>>> 3) If PAWS defines a globally applicable discovery process and either >>>> picks an existing protocol (like LoST) or designs one, most likely >>>> it would include a centrally based discovery service. What entity >>>> will be responsible for hosting and configuring the central >>>> discovery service? How will PAWS define this as a global solution, >>>> and deal with the politics between countries? LoST is designed to not >>>> require a central anything. It's distributed. It cleverly avoids the >>>> political mess. The designers were mindful of these issues. >>>> >>>> I'm waving my hands a bit, but it's a very good answer for discovery >>>> of location sensitive servers. >>>> >>>> 4) Some radio manufacturers do not have very much ROM to include even >>>> more code on their device. I'm concerned that discovery will consume >>>> even more space on the radio, space that they may not even have. Not >>>> an argument that gets you any traction in the IETF. ROM is cheap. >>>> Have more. All it takes is one service call to wipe out savings in >>>> ROM. >>>> >>>> >>>> >>>> 5) I believe that defining discovery will take more time than >>>> defining the protocol between the WSDB and WSD. >>>> Nah. We do this for lots of protocols. If we decide to use LoST, >>>> it will be very easy. >>>> >>>> >>>> >>>> >>>> I think that database discovery should be left to each country to >>>> define based on their own requirements and Whitespace ecosystem. >>>> By that argument, we should close up shop and let each country >>>> define their own database query protocol. >>>> >>>> >> >> >> > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
