Subject: [paws] Clarification of M2M use case

From: <[email-masked]>
Date: Fri, 20 Jan 2012 14:01:32 +0000

All

There was a request for clarification on the M2M use case presented at the Taipei F2F, in particular with regard to slave-to-slave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to the M2M slide to make this clearer. We have added two arrows so that it is clear that each of the slaves is in communication over TVWS with the master, as well as the slaves being in communication with each other. The "Note" on the slide now has two bullets and reads:

*         Note: Further signalling can take place (outside the scope of PAWS) to establish direct links among those slave devices that have associated with the master device.

*         Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of the master device, and would cease if so requested by the master, or if connection to the master is lost

I have also copied the revised slide here:

The sequence of events is as follows (note that steps 1-5 are the same as in the use case description in the current working group draft, but we have removed the last sentence in step 6 (previously the final step) so that this can be expanded in the new step 7):

   1.  The master device powers up with its whitespace radio in idle or
       listen mode only (no active transmission on the whitespace
       frequency band).

   2.  The master device has internet connectivity and establishes a
       connection to a trusted white space database (see Section 3.1<http://trac.tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-01#section-3.1>
       above).

   3.  The master device sends its geolocation and location uncertainty
       information, and optionally additional information which may
       include (1) device ID and (2) antenna characteristics, to a
       trusted database, requesting a list of available whitespace
       channels based upon this information.

   4.  The database responds with a list of available white space
       channels that the master device may use, and optional information
       which may include inter alia (1) a duration of time for the use
       of each channel (channel validity time) (2) a maximum radiated
       power for each channel, (3) an indication of the quality of the
       spectrum for each channel and (4) directivity and other antenna
       information.

   5.  Once the master device authenticates the whitespace channel list
       response message from the database, the master device selects one
       or more available whitespace channels from the list.

   6.  The slave devices fitted to the machines scan the TV bands to
       locate the master transmissions, and associate with the master
       device.

   7.  Further signaling can take place outside scope of PAWS
       to establish direct links among those slave devices that have
       associated with the same master device. At all times these direct
       links are under the control of the master device. For example,
       common to all use cases, there may be a regulatory requirement
       for transmissions from slave to master to cease immediately if so
       requested by the master, or if connection to the master is lost
       for more than a specified period of time. When one of these
       conditions occurs, transmissions from slave to slave would also
       cease. Direct slave to slave transmissions could only restart if
       each slave subsequently restores its connection to the same
       master, or each slave joins the network of another master.

- end of event sequence description -

I hope this is now clearer. Please let me have any further queries on the reflector.

To deflect one set of questions before they start, please note that we have removed any inference in this use case that slaves may talk directly with other slaves when one or other of them is out of range of the master (i.e. a type of relay or proxy function). This is not a requirement that is particular to M2M, and will be dealt with in a separate thread.

Regards

Andy

---

From: "Malyar, John P" <[email-masked]>
Date: Fri, 20 Jan 2012 09:10:20 -0500

Andy,

I believe that Step 7 addresses and clarifies the issues raised at the F2F (at least the ones that I had raised). Thank you.

Regards,

John Malyar

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 20, 2012 9:02 AM
To: [email-masked]
Subject: [paws] Clarification of M2M use case

All

Regards

Andy

---

From: <[email-masked]>
Date: Tue, 24 Jan 2012 17:49:54 +0000

Hi Andy,

Question about the following statement:
"
Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of the master device, and would cease if so requested by the master, or if connection to the master is lost
"

How does the master know that slaves are communicating with each other directly using TVWS channels? Do you assume that communication between slaves is routed through the master?

-Raj

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Fri, 20 Jan 2012 14:01:32 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [paws] Clarification of M2M use case

All

There was a request for clarification on the M2M use case presented at the Taipei F2F, in particular with regard to slave-to-slave communication. Juan Carlos Zuniga, Mike Fitch and myself have agreed a couple of changes to the M2M slide to make this clearer. We have added two arrows so that it is clear that each of the slaves is in communication over TVWS with the master, as well as the slaves being in communication with each other. The “Note” on the slide now has two bullets and reads:

·         Note: Further signalling can take place (outside the scope of PAWS) to establish direct links among those slave devices that have associated with the master device.

·         Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of the master device, and would cease if so requested by the master, or if connection to the master is lost

- end of event sequence description –

Regards

Andy

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

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 15:06:52 +0000

Hi Raj

The master doesn't need to know that slaves are talking direct, and traffic is not routed through the master. Each slave is within range of the master, and associated to it. A command from the master to tell slaves stop TVWS communications on the current channel (if such a protocol is developed) would be received by all slaves and acted upon. This would apply to slave-slave transmissions as well as slave-master transmissions since they are both using TVWS. Alternatively if the master dropped comms (stopped beaconing or whatever) then both slaves could detect that, and the default action then would be to cease all transmissions over the air, to the master or to other slaves. Thus, the direct slave-slave transmissions are under control of the master in so far as the master decides whether all slaves can transmit or not, based on information from the database. I don't think there is anything extra needed wrt PAWS protocols to enable this.

The scenario is similar if the master is allocated a choice of channels by the database, and the list is passed to the slave. I suppose the master could make itself known on channel A, and slaves associate on channel A and are told that channels B and C are also available (at particular powers etc). They then use B and C for direct slave-slave comms. If the database indicates (by push or pull) a revised list of channels to the master, with channel A still usable but B or C not, then the changed list of frequencies should be signalled to the slave. This could result in a change of frequency by the slave, rather than a ceasing of all transmissions, and the existing network on channel A would be unaffected.

The previous paragraph is just a theoretical exercise, I don't see any reason why slave-slave comms would use a different channel  to slave-master comms in the M2M use case, but don't see any reason to prevent it.

Regards

Andy

From: [email-masked] [mailto:[email-masked]]
Sent: 24 January 2012 17:50
To: Sago,AJ,Andy,COD R; [email-masked]
Subject: Re: [paws] Clarification of M2M use case

Hi Andy,

-Raj

All

Regards

Andy

---

From: <[email-masked]>
Date: Wed, 25 Jan 2012 21:11:51 +0000

Thanks for the clarification.
I guess it is important to point out in the use case that the slave devices are listening to a beacon from a master device (as an example at least) and the loss of such a beacon would result in communications that may be directly between slaves ceasing immediately.

-Raj

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 25 Jan 2012 15:06:52 +0000
To: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Clarification of M2M use case

Hi Raj

The master doesn’t need to know that slaves are talking direct, and traffic is not routed through the master. Each slave is within range of the master, and associated to it. A command from the master to tell slaves stop TVWS communications on the current channel (if such a protocol is developed) would be received by all slaves and acted upon. This would apply to slave-slave transmissions as well as slave-master transmissions since they are both using TVWS. Alternatively if the master dropped comms (stopped beaconing or whatever) then both slaves could detect that, and the default action then would be to cease all transmissions over the air, to the master or to other slaves. Thus, the direct slave-slave transmissions are under control of the master in so far as the master decides whether all slaves can transmit or not, based on information from the database. I don’t think there is anything extra needed wrt PAWS protocols to enable this.

The previous paragraph is just a theoretical exercise, I don’t see any reason why slave-slave comms would use a different channel  to slave-master comms in the M2M use case, but don’t see any reason to prevent it.

Regards

Andy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 24 January 2012 17:50
To: Sago,AJ,Andy,COD R; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Clarification of M2M use case

Hi Andy,

-Raj

All

Regards

Andy

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 14:06:56 +0000

Raj

Firstly just to reiterate that this is out of scope for PAWS - action to be taken if slaves lose communication with a master must be out of scope (clearly we can't define a message exchange if the underlying transport has disappeared). But I have included it in the use case to address concerns raised in Taipei. I would be OK to add an additional sentence into my new point 7 in the M2M use case, after the sentence "When one of these conditions occurs, transmissions from slave to slave would also cease." This extra sentence would say "Various mechanisms could be used to detect loss of signal from the master, for example by requiring masters to transmit regular beacons if they allow slave to slave communications".  In the UK, when Ofcom writes the statutory legislation that licence exempts slave devices, they will need to specify the rules for controlling slave to slave communication.

Regards

Andy

From: [email-masked] [mailto:[email-masked]]
Sent: 25 January 2012 21:12
To: Sago,AJ,Andy,COD R; [email-masked]
Subject: Re: [paws] Clarification of M2M use case

-Raj

Hi Raj

Regards

Andy

Hi Andy,

-Raj

All

Regards

Andy

---

From: <[email-masked]>
Date: Thu, 26 Jan 2012 23:30:11 +0000

Hi Andy,

Agree with your comment below. I am in favor of including the additional sentence that you proposed in your email to this use-case.

-Raj

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 26 Jan 2012 14:06:56 +0000
To: Basavaraj Patil <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Clarification of M2M use case

Raj

Firstly just to reiterate that this is out of scope for PAWS - action to be taken if slaves lose communication with a master must be out of scope (clearly we can’t define a message exchange if the underlying transport has disappeared). But I have included it in the use case to address concerns raised in Taipei. I would be OK to add an additional sentence into my new point 7 in the M2M use case, after the sentence “When one of these conditions occurs, transmissions from slave to slave would also cease.” This extra sentence would say “Various mechanisms could be used to detect loss of signal from the master, for example by requiring masters to transmit regular beacons if they allow slave to slave communications”.  In the UK, when Ofcom writes the statutory legislation that licence exempts slave devices, they will need to specify the rules for controlling slave to slave communication.

Regards

Andy

-Raj

Hi Raj

Regards

Andy

Hi Andy,

-Raj

All

Regards

Andy