Brian, A "pull" update function should be light and simple in my view. No need to provide location or device characteristics to the database, this procedure assumes that none of this has changed. This is how I think it could work: 1) The master device sends its DeviceID - and nothing else - to the database 2) The database looks up the IDs and finds out whether WS availability for this master and its slaves has changed since the last update 3) If no change, the database replies an ACK. If change, the database replies a NACK (this could be enhanced to take individual slaves into account)
I am fine if database operators prefer to implement this via expiry timer + full geospatial query, but it looks burdensome to me. The refresh time will be set by the database and communicated to the master. The requirement in ETSI is that devices should be able to support the functionality with a refresh time of 60 seconds or higher. In practice, it is unlikely to be that low under normal operating conditions. Thanks, Cesar -----Original Message----- From: Rosen, Brian [mailto:[email protected]] Sent: 16 April 2013 15:18 To: Cesar Gutierrez Cc: [email protected]; Reza Karimi; [email protected] Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement We already have the notion of an expiry time on the spectrum allocation. If you make that short (60 seconds), then the client has to come back to the database to get a refresh. No further pull mechanism is needed. Its not clear that doing something better helps a lot. The server has to get the location of the client and determine if any changes in spectrum have occurred. That's a full geospatial query, with some possibilities of maintaining caches of recently changed curves. A push is hard in many environments because NATs, firewalls and other middle boxes make it difficult to establish a connection from outside to inside. We could maintain a very simple ping from client to server that just kept the path open, and then use that to send the push notification. Maintaining pull mechanisms with circa 60 second timeouts is fine as long as the number of clients is small. A million clients on one server might work without this level of interactivity, with it and we're as much as two orders of magnitude less capacity. There are always problems like avalanche restart due to power failures, so it's probably not really this bad, but it's a pretty big problem. Brian On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <[email protected]> wrote: > All, > > At the meeting in Orlando we discussed a device update function (or kill > switch, or PUSH). This arises from the UK regulatory requirement that a > database should be able to contact any device within a short time. After > review of PAWS use case document with regards to this, I think our UK > requirement is neatly captured in requirement P.16 "The protocol MUST support > the capability for the database to inform master devices of changes to > spectrum availability information" > > This requirement is already part of the current draft of the ETSI Harmonised > Standard. Its main elements are summarised below, and the full text is > attached: > > +++++++++++ > DEFINITION > The master WSD update is the process by which a database informs a > master WSD that its operational parameters, and those of the slave > WSDs attached it, are still valid or are no longer valid REQUIREMENTS > - A master WSD shall support WSD update function. For this, a master WSD > shall either > *be able to receive an update from the Controller Database WSDB within > Tping seconds (push update), or > *send an update request to the Controller Database WSDB every Tping > seconds (pull update). > - A master WSD shall support a Tping value of [60] seconds or higher. > - A master WSD shall cease transmission, and shall instruct the slaves > attached to it to cease transmission, if it receives update from the WSDB > that the operational parameters are no longer valid. > - A master WSD shall cease transmission, and shall instruct the slaves > attached to it to cease transmission, if it loses connection with the > WSDB > ++++++++++ > > It is worth signalling that, at least among UK stakeholders, there is wide > support for the pull method and little support for the push method. This is > consistent with the view that it will be very difficult to implement the push > functionality over the internet. > > As a first step, I would like to ask the PAWS WG to consider support for this > functionality in the specification. Secondly, it would be good to have views > of how a pull mechanism could be implemented in the PAWS protocol. We have > had early discussions about this off-line, and I think the alternatives are > 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY and "Device > Validation" are possible candidates), and 2) create a new, dedicated > procedure. > > Thanks and regards, > Cesar > > > > ________________________________ > > ********************************************************************** > ******************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use of > the addressee only. > > If you have received this email in error please notify the originator of the > message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachments at > your own risk. > > Any views expressed in this message are those of the individual sender and do > not represent the views or opinions of Ofcom unless expressly stated > otherwise. > ********************************************************************** > ******************************************** > <EN301598v0018_MasterWSDupdate.docx>__________________________________ > _____________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws ________________________________ ****************************************************************************************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use of the addressee only. If you have received this email in error please notify the originator of the message and delete it from your system. This email has been scanned for viruses. However, you open any attachments at your own risk. Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise. ****************************************************************************************************************** _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
