Subject: [paws] Mobility Use Case

From: <[email-masked]>
Date: Thu, 13 Oct 2011 15:50:14 +0000

Hi,

I have not seen any comments on the mobility use case below. If the work
group is OK with the use case, it will be included in the next update of
the draft.

Regards,
Scott

On 9/30/11 7:12 AM, "ext [email-masked]"
<[email-masked]> wrote:

>Hi,
>
>Here is draft text for the mobility use case.
>
>================
>
>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 in
>peer-to-peer or ad-hoc networks. 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.
>
>
>A simplified operational scenario utilizing TV white space to provide
>peer-to-peer 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 and establishes a
>connection to a trusted white space database (see use case "TVWS database
>discovery above).
>
>3. The mobile master registers its current geolocation, address contact
>information, etc. associated with the owner/operator of the master with
>the trusted database administrator (if not currently registered).
>
>4. Following the 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 and a prediction of its future location,
>extrapolated from the motion or mobility of the device. 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 been previously authenticated, 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.
>
>6. Once the mobile master authenticates the WS channel list response
>message from the database, the master selects an available WS channel from
>the list for use.
>
>7. The other user device in the peer-to-peer connection scans the TV bands
>to locate a mobile master transmission, and associates with the mobile
>master. The slave/user device queries the master for a channel list, based
>on the slave's device identification, geolocation and optionally a
>prediction of its future location.
>
>8. If required by local regulation, the master device verifies the slave's
>device identification with the database.
>
>8. If allowed by local regulation (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. 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.
>
>================
>
>
>This represents only one of many possible use case scenarios. Looking
>forward to the group's discussion.
>
>
>Regards,
>Scott
>
>
>On 9/22/11 5:59 PM, "ext Peter Stanforth" <[email-masked]>
>wrote:
>
>>Thanks Scott
>>Your suggestions sound good to me. The third suggestion came from
>>conversations we have had with government agencies, it is not part of any
>>current White Space regulation. The politicians and the bureaucrats both
>>suggested that the way that government spectrum would be made available
>>on
>>a secondary basis (similar to white space) would be if the agency got
>>compensated for it's use.
>>Peter S.
>>
>>On ThuSep/22/11 Thu Sep 22, 3:01 PM, "[email-masked]"
>><[email-masked]> wrote:
>>
>>>
>>>Hi Peter,
>>>
>>>Good comments. Reviewing them one by one...
>>>
>>>First. We will re-write the location based service use case to be a
>>>generic "regulatory requirement" use case, focusing on the registration
>>>information as you suggest.
>>>
>>>Second. Ability to withdraw permission is essentially same as the "kill
>>>switch" described by Ofcom in their "Implementing Geolocation" document.
>>>We proposed to add this either as a separate use case or included it to
>>>an
>>>existing use case.
>>>
>>>Third. We generally agree with the principle and would like to include
>>>the
>>>capability. Probably the question will be asked if this is in scope. We
>>>would like to identify a regulator who has indicated a need or desire
>>>for
>>>this.
>>>
>>>Fourth. We will include a new use case for mobility, FCC has already
>>>identified this as a valid use case.
>>>
>>>Regards,
>>>Scott & Raj
>>>
>>>
>>>
>>>On 9/15/11 10:12 AM, "ext Peter Stanforth" <[email-masked]>
>>>wrote:
>>>
>>>>I have a number of comments on the use cases proposed in the draft.
>>>>
>>>>First the location based service seems too specific to an advertising
>>>>model as opposed to a more generic case of an edge device (slave)
>>>>requesting the location information about a serving master device from
>>>>the
>>>>DB. There may well be other reasons for the slave to request
>>>>information
>>>>about the master. One instance I can think of is to determine who owns
>>>>the
>>>>master (registration information) it may be that the slave only trusts
>>>>certain masters or has a cost basis to chose one available master over
>>>>Another.
>>>>
>>>>Second. The whole concept is predicated on an ability to provide access
>>>>to
>>>>spectrum into the future. I believe that much spectrum (owned by
>>>>emergency
>>>>services, defense agencies and others) will not be made available
>>>>without
>>>>an ability to withdraw the permission should a predefined emergency
>>>>situation emerge. There are several ways to address this requirement
>>>>but
>>>>I
>>>>think
>>>>a use case that considers such a scenario is required.
>>>>
>>>>Third, Access to spectrum, as a licensed or unlicensed device, may
>>>>require
>>>>payment. It seems highly likely that government agencies (spectrum
>>>>holders) will need to be
>>>>persuaded to make spectrum available. This may be in the form of the
>>>>Agency/holder getting some compensation for the use of the spectrum.
>>>>This
>>>>would
>>>>require that use of the spectrum be tracked such that some backend
>>>>billing
>>>>or clearing house system could deal with payments.
>>>>
>>>>Fourth, The concept of mobility is not described. Mobility could be
>>>>addressed by providing a vector or an area to the DB which would result
>>>>in
>>>>a set of available channels being delivered.
>>>>
>>>>Finally there is no "White Space" only shades of grey. So I think it is
>>>>important to consider
>>>>that not all spectrum is equal and that the DB may have to provide some
>>>>weighting or other
>>>>Criteria to describe suitability of the available channels for use.
>>>>Note
>>>>that this is unrelated
>>>>to any Co-existence criteria.
>>>>Regards,
>>>>Peter Stanforth
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>
>>>>_______________________________________________
>>>>paws mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/paws
>>>
>>
>
>_______________________________________________
>paws mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/paws