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 Mobility 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:
* change the scenario from peer-to-peer to simple master & slave.
Motivation is to separate this mobility case from the case of peer-to-peer
communications without a master involved (a separate topic)
* include most of the applicable comments from the Hotspot use case
(comments leading global clarifications or new text will be added in next
version, v-03).
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.8. Mobility
In this use case, the user has a non-fixed (portable or mobile)
device and is riding in a vehicle. The user wants to have
connectivity to another device which is also moving. Typical
deployment scenarios include urban areas and rural areas where the
user may connect to other users <Insert>while moving</Insert><Delete>in
peer-to-peer or ad-hoc networks</Delete>.
This deployment scenario is typically characterized by a master
device with low antenna height, internet connectivity by some
connection that does not utilize TV white space, and some means to
predict its path of mobility. This knowledge of mobility could be
simple (GPS plus accelerometer), sophisticated (GPS plus routing and
mapping function) or completely specified by the user via user-
interface.
The figure below shows an example deployment of this scenario.
\|/ \|/
| TDD Air Interface |
| |
+-|---------+ +-|---------+
| TVWS | | TVWS |
|Master Dev | |Master Dev |
+-----------+ +-----------+
\ (----) /
\ ( ) /
\ / \ /
( Internet )
\ /
( )\----------+
(----) | Database |
+----------+
Figure 8: Example illustration of mobility in TV white space use-case
A simplified operational scenario utilizing TV whitespace to provide
<Delete>peer-to-peer</Delete> connectivity service in a mobility
environment consists
of the following steps:
1. The mobile master device powers up with its WS radio in idle or
listen mode only (no active transmission on the WS frequency
band).
2. The mobile master has internet connectivity <Insert>, determines its
location, </Insert> and establishes a connection to a trusted white space
database (see Section 4.1 <Ed. Note>reference is to database discovery,
will be updated in next version</Ed. Note>).
3. The mobile master registers with the trusted database according
to regulatory domain requirements (see Section 4.2 <Ed.
Note>reference is to registration, will be updated in next version</Ed.
Note>).
4. Following the <Insert>successful</Insert> registration process, the
mobile master will send a
query to the trusted database requesting a list of available WS
channels based upon its current location<Insert>, other parameters
required by the local regulator (see Hotspot use case, step 4)</Insert>
and a
prediction of its
future location<Delete>, extrapolated from the motion or mobility
of the
device</Delete>. The current location is specified in latitude and
longitude. The method to specify the future location is TBD,
potential methods include movement vector (direction and
velocity), a set of latitude/longitude points which specify a
closed polygon where the future location is within the polygon,
or similar.
5. If the mobile master has met all regulatory domain requirements
(e.g. been previously authenticated, etc), the database responds
with a list of available white space channels that the mobile
master may use, and optional information which may include (1) a
duration of time for the use of each channel (2) a maximum
transmit power for each channel <Insert> and (3) notification of
any additional requirement for sensing</Insert>.
6. Once the mobile master has met all regulatory domain requirements
(e.g. authenticated the WS channel list response message from the
database, etc), the master selects <Delete>an</Delete><Insert>one
or more</Insert> available WS channel(s)
from the list for use.
7. The <Delete>other</Delete><Insert>slave / </Insert> user device
<Delete>in the peer-to-peer connection</Delete> scans the TV
bands to locate a mobile master transmission, and associates with
the mobile master. <Ed. Note>insert new step</Ed. Note>
8. The slave/user device queries the master for
a channel list, <Delete>based on</Delete><Insert>providing to the
master</Insert> the slave's device identification, <Insert>and optionally
its </Insert>
geolocation and <Delete>optionally</Delete> a prediction of its
future location.
<Delete>
9. If required by local regulation, the master device verifies the
slave's device identification with the database.
</Delete>
9. <Delete>If allowed by local regulation</Delete><Insert>Once the
mobile master has meet all regulatory domain requirements</Insert> (e.g.
the slave's device
identification is verified by the database), the mobile master
provides the list of channels locally available to the slave/user
device. <Delete>If the channel that the slave/user terminal is
currently
using is not included in the list of locally available channels,
the slave/user device ceases all operation on its current
channel. The slave/user device may scan for another Master's
transmission on a different channel.</Delete>
<Insert>
10. The mobile master moves outside the predicted range of future
positions in step 4, it must repeat the process to request a
channel list from the database, steps 4 through 6 above. If the response
from the database indicates a channel being used by the mobile master is
not
available, the master/AP must stop transmitting on that channel
Immediately.
11. The slave or user device must periodically repeat the process to
request a channel list from the master/AP, steps 8 and 9 above. The
frequency to repeat the process is determined by the local regulator. If
the response from the master/AP indicates that a channel being used by the
slave or user device is not available, the slave or user device must stop
transmitting on that channel immediately. In addition or optionally, the
database may send a message to the master/AP to rescind the availability
of one or more channels. The master/AP must then notify the slave or user
device of the rescinded channels. The slave or user device must stop
transmitting on that channel immediately.
</Insert>
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
