Subject: [paws] Device update function - ETSI/UK regulatory requirement

From: Cesar Gutierrez <[email-masked]>
Date: Tue, 16 Apr 2013 13:20:14 +0000

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.
******************************************************************************************************************

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Apr 2013 14:18:28 +0000

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-masked]> wrote:

> <EN301598v0018_MasterWSDupdate.docx>_______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws

---

From: Cesar Gutierrez <[email-masked]>
Date: Tue, 16 Apr 2013 14:55:16 +0000

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-masked]]
Sent: 16 April 2013 15:18
To: Cesar Gutierrez
Cc: [email-masked]; Reza Karimi; [email-masked]
Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement

Brian
On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <[email-masked]> wrote:

> 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 cease transmission, and shall instruct the slaves
> attached to it to cease transmission, if it loses connection with the
> WSDB
> ++++++++++
>
> **********************************************************************
> ********************************************
> **********************************************************************
> ********************************************

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 16 Apr 2013 11:25:10 -0400

Brian
Big difference between a simple "Am I ok?" and a reauthentication and channel request.
The former could be very light weight and make DB processing a lot simpler

On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <[email-masked]> wrote:

> _______________________________________________
> paws mailing list
> [email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 16 Apr 2013 15:28:55 +0000

Not really.  Use a cache.  If nothing changed, reply so and move on.

If it's really 60 seconds, then you are maintaining the SSL connection, so you don't need a complete reauth.
OTOH, if you are maintaining an SSL connection, then a push is pretty easy.

Brian

---

From: Vincent Chen <[email-masked]>
Date: Wed, 17 Apr 2013 15:36:35 -0700

All,

For scalability and redundancy reasons, a "stateless" system is much
preferred. That means not having answers depend on priory history of
queries.
This allows running many server instances to service requests. It also
means that each request can go to any serving machine.

There also may be reasons why caching might not work:

 - The answer is not totally dependent on only the device characteristics.
In the US, for example, there are dynamic registrations,
   so the Database might have to run through most of the computation
anyways to determine whether anything has changed.

 - For devices that use GPS, the location might jitter just a bit from time
to time, so the difference might cause cache misses

To keep the API simple, I wouldn't recommend adding another call when the
existing one already works.

----------------------
Query Volume
----------------------
As for the polling period. I think we should look at what this actually
means:

  - At 60-seconds polling period for only 1 million devices.....that's
almost 1.5 Billion queries per day!

Note that a large search engine like Baidu only handles 5B queries per day.

So....I would be very cautious about trying to set the polling period too
low. It would be requiring a significant amount of resources to provide
a capability that would be used rarely, perhaps 0.001% of the time (once a
month)?

At the F2F, there was a suggestion that actual management could be a staged
process, e.g.,
  - By default the required update period is 1 or 2 hours
  - When needed, the update period for devices within a specified
geographic region could be lowered to 60 seconds,
    allowing investigation
  - When investigation is complete (and/or after a timeout), update period
is reset to default

This seems more reasonable to me (IMHO), and the current proposed protocol
with expiry will handle this just fine, I think.

-vince

On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <[email-masked]>wrote:

> >> 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
> >>> 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
> master WSD that its operational parameters, and those of the slave WSDs
> attached it, are still valid or are no longer valid
> >>> REQUIREMENTS
> attached to it to cease transmission, if it receives update from the WSDB
> that the operational parameters are no longer valid.
> 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
> >>>
> >>>
> >>>
> >>> If you have received this email in error please notify the originator
> of the message and delete it from your system.
> >>>
> >>> 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.
> >>>

-- 
-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 18 Apr 2013 12:51:32 +0000

But you can't really do "stateless" and have registration.  That's state.  You can't serve an unregistered device.  Slowly changing state, but then again, most location is slowly changing (mobile devices on the move excepted).

I agree that maintaining 60 second polling is very challenging, and I agree the mechanism we discussed of having a much longer period and temporarily lowering the period when needed is an appropriate mechanism.   I will remind everyone that if a device is moving, a faster poll is needed due to the motion (every hour, or when you move more than x meters).

This affects the proposed rules.

Brian

On Apr 17, 2013, at 6:36 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>>
 wrote:

All,

For scalability and redundancy reasons, a "stateless" system is much preferred. That means not having answers depend on priory history of queries.
This allows running many server instances to service requests. It also means that each request can go to any serving machine.

 - The answer is not totally dependent on only the device characteristics. In the US, for example, there are dynamic registrations,
   so the Database might have to run through most of the computation anyways to determine whether anything has changed.

 - For devices that use GPS, the location might jitter just a bit from time to time, so the difference might cause cache misses

To keep the API simple, I wouldn't recommend adding another call when the existing one already works.

----------------------
Query Volume
----------------------
As for the polling period. I think we should look at what this actually means:

  - At 60-seconds polling period for only 1 million devices.....that's almost 1.5 Billion queries per day!

So....I would be very cautious about trying to set the polling period too low. It would be requiring a significant amount of resources to provide
a capability that would be used rarely, perhaps 0.001% of the time (once a month)?

At the F2F, there was a suggestion that actual management could be a staged process, e.g.,
  - By default the required update period is 1 or 2 hours
  - When needed, the update period for devices within a specified geographic region could be lowered to 60 seconds,
    allowing investigation
  - When investigation is complete (and/or after a timeout), update period is reset to default

This seems more reasonable to me (IMHO), and the current proposed protocol with expiry will handle this just fine, I think.

-vince

On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
Not really.  Use a cache.  If nothing changed, reply so and move on.

Brian

On Apr 16, 2013, at 11:25 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>>
 wrote:

> On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> All,
>>>
>>> For more information visit www.ofcom.org.uk<http://www.ofcom.org.uk/>
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 18 Apr 2013 07:12:01 -0700

Brian,

On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian <[email-masked]>wrote:

>  But you can't really do "stateless" and have registration.  That's state.
>  You can't serve an unregistered device.  Slowly changing state, but then
> again, most location is slowly changing (mobile devices on the move
> excepted).
>

 Yes, you're right. I'll just note that there is still a difference between
read (of a registration record) vs read-modify-write to update some
information associated with the registration with each query.

>  I agree that maintaining 60 second polling is very challenging, and I
> agree the mechanism we discussed of having a much longer period and
> temporarily lowering the period when needed is an appropriate mechanism.
> I will remind everyone that if a device is moving, a faster poll is needed
> due to the motion (every hour, or when you move more than x meters).
>
>  On Apr 17, 2013, at 6:36 PM, Vincent Chen <[email-masked]>
>  wrote:
>
>  All,
>
>   - The answer is not totally dependent on only the device
> characteristics. In the US, for example, there are dynamic registrations,
>   - For devices that use GPS, the location might jitter just a bit from
> time to time, so the difference might cause cache misses
>
>  So....I would be very cautious about trying to set the polling period
> too low. It would be requiring a significant amount of resources to provide
>  This seems more reasonable to me (IMHO), and the current proposed
> protocol with expiry will handle this just fine, I think.
>
>  -vince
>
>
>> >>> - 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
>> >>> ++++++++++
>> >>>
>> >>> 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.
>> >>>

-- 
-vince

---

From: Cesar Gutierrez <[email-masked]>
Date: Mon, 22 Apr 2013 16:23:33 +0000

Vince and all,

A couple of comments on the update requirement in the ETSI standard:

*        Its purpose is to inform the device that there have been changes in its environment and, as a result, in the available spectrum. The device itself has not changed or moved, so it does not have to communicate parameters to the database (except its ID). The scenario of a moving device is different and there is another requirement for it: as soon as the device moves beyond a threshold distance, it must request new spectrum availability (for which it must provide its new location).

*        I agree that  a 60 secs. period for millions of devices will generate an unmanageable volume of queries. I also think that the interference management process is likely to be similar to what Vincent outlined below. However, I would be wary of making assumptions about the default update period. My personal bet is 15 minutes, but even here in Ofcom everybody in the team has different views. Eventually, in the UK it will be Ofcom interference enforcement team who decides on the default value and on the management process. It is for this reason that the requirement is that devices (and databases) are capable of supporting 60 secs. or higher.

Regards,
Cesar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Vincent Chen
Sent: 18 April 2013 15:12
To: Rosen, Brian
Cc: [email-masked]; [email-masked]; Reza Karimi
Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement

Brian,

On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian <[email-masked]<mailto:[email-masked]>> wrote:
But you can't really do "stateless" and have registration.  That's state.  You can't serve an unregistered device.  Slowly changing state, but then again, most location is slowly changing (mobile devices on the move excepted).

 Yes, you're right. I'll just note that there is still a difference between read (of a registration record) vs read-modify-write to update some information associated with the registration with each query.

Brian

All,

----------------------
Query Volume
----------------------

-vince

Brian

--
-vince

--
-vince