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
