Hello All,
As editors of the problem statement, use cases & requirements draft we are
attempting to prepare a completed draft which could be ready for working
group last call before IETF83. In the coming days we will post the
sections of the draft to the mailing list. Our request is that you review
these sections and reply to the email with any comments.
Below is the text for section on the machine to machine use case (new
section numbering is NOT shown, all use cases will be moved to section 4.2
Use cases in the next version). This text has been marked up from
version-02 as uploaded January 26, 2012 as follows:
* comments from this mail reflector beginning January 20 topic
"Clarification of M2M use case"
* removed "indication of channel quality" and "antenna directivity" from
the channel response message. If there is a regulatory requirement for
these, they should not be deleted.
* added relevant comments from the Hotspot use case.
Our goal is that any discussion on this text will conclude by February 15.
To be clear, approval of the document will go through the normal process
of last calls etc.. We are simply asking for your assistance in preparing
a complete & accurate document that could progress the work. So please
review the text and send your comments either directly to the editor or to
the mailing list.
Kind Regards,
Raj & Scott
4.10. Machine to Machine (M2M)
In this use case, each "machine" includes a white space slave device
and can be located anywhere, fixed or on the move. Each machine
needs to have connectivity to the internet and or to other machines
in the vicinity. Machine communication over a TVWS channel, whether
to a master device or to another machine (slave device), is under the
control of a master device. This deployment scenario is typically
characterized by a master device with internet connectivity by some
connection that does not utilize TV white space.
The figure below shows an example deployment of this scenario.
\|/
|
|
+-|---------+
| TVWS |\
/|Master Dev | \
/ +-----------+ \
WS AirIF \ +----------+
+-------+ / \ (----) | Database |
|Machine| \ ( ) /----------+
+-------+ \ / \
| X( Internet )
WS AirIF \ /
| ( )
+-------+ (----)
|Machine|
+-------+ \ +-------+
WS AirIF-- |Machine|
+-------+
Figure 10: Example illustration of M2M TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
machine to machine connectivity consists of the following steps:
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 <Insert>, determines its
location (either from location determination capability or from saved
value that was set during installation), </Insert> and establishes a
connection to a trusted white space database (see Section 3.1
above<Ed. Note>reference is to database discovery, will be updated
in next
version</Ed. Note>).
<Insert>
3. The master/AP registers with the trusted database according to
regulatory domain requirements (see Section 4.1.2).
</Insert>
4. <Insert>Following successful registration,</Insert>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.
5. <Insert>If the master has met all regulatory domain requirements,
</Insert>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, <Delete>(3) an indication of the quality of
the
spectrum for each channel and (4) directivity and other antenna
information</Delete><Insert>or a notification of any additional
requirements for sensing</Insert>.
6. 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.
7. The slave devices fitted to the machines scan the TV bands to
locate the master transmissions, and associate with the master
device. <Delete>Further signaling can take place outside scope of
PAWS
to establish direct links among those slave devices that have
associated with the master device.</Delete>
<Insert>
8. 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.
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. 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.
</Insert>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
