Hi, Section 4.7 Rapid deployed network for emergency scenario also includes the proxy concept. Would be good if Andy, Mike & Juan Carlos could consider that one also.
Section 4.8 Mobility is very similar to the train or ferry concepts. Perhaps Peter could improve that use case. Kind Regards, Scott -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ext [email protected] Sent: Wednesday, January 18, 2012 11:45 AM To: Patil Basavaraj (Nokia-CIC/Dallas); [email protected]; [email protected] Subject: Re: [paws] next steps for the wg I agree the proxy master concept should be documented. Mike Fitch, Juan Carlos Zuniga and I are drafting an expansion of the M2M use case (as requested at the last F2F) which already alludes to the proxy concept. Including it in the M2M use case may be sufficient to draw out the requirements. We will post the use case update this week on the reflector. Regards Andy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 18 January 2012 00:09 To: [email protected]; [email protected] Subject: Re: [paws] next steps for the wg Thanks. I think the use-case would be useful to document in the I-D. It provides the proxy model use case for consideration. Rgds, -Raj On 1/17/12 5:46 PM, "ext Peter Stanforth" <[email protected]> wrote: >Raj >I will look at the existing use cases again and either propose an >update or a new one. Two specific use cases. >One is an "AP" on a train or ferry serving white Space clients with a >non white space backhaul. This I believe is your mobile master. >The simplest scenario I can give is for a multi master solution - say a >collection of construction or farm equipment In the US today these >would all be classified as High Power and would have to individually >request channels however this is very inefficient and allowing some >master to proxy within a predefined area would be preferable. >Regards, >Peter S. > >On TueJan/17/12 Tue Jan 17, 6:32 PM, "[email protected]" ><[email protected]> wrote: > >> >>Hi Peter, >> >>I concur with your comment. Just a quick clarification question about >>the scenario wherein the mobile master is supporting devices that >>either roam within a polygon or cannot accurately locate themselves.. >>First of all I am not sure I understand what these other devices are >>that are relying on the master. Maybe a more complete use case >>description would help. >>We do not have such a scenario in the current document and could >>consider it. >> >>-Raj >> >>On 1/17/12 5:25 PM, "ext Peter Stanforth" <[email protected]> >>wrote: >> >>>I would like to see this be described in a more generic way. I agree >>>with Raj that this is all about providing information for more than a >>>point on a map but there are several possible scenarios for which a >>>query for a "polygon" could be requested. It could be a very long >>>thin polygon if the request is related to a road or railroad or a >>>fairly square polygon if the request is for a venue or even a field. >>>While the use case may be a mobile master it could also be for a >>>master that is supporting devices that either roam within the polygon >>>or cannot accurately locate themselves within the polygon. >>> >>>On TueJan/17/12 Tue Jan 17, 6:17 PM, "[email protected]" >>><[email protected]> wrote: >>> >>>> >>>>Hi Gabor, >>>> >>>>On 1/12/12 8:26 PM, "ext [email protected]" >>>><[email protected]> >>>>wrote: >>>> >>>>>We did not have any discussion on P.9, so I'd like to get comments >>>>>on the list about this: >>>>> P.9: A master device MUST be able to query the whitespace >>>>> database for channel availability information for a >>>>> specific expected coverage area around its current >>>>> location. >>>> >>>>This requirement addresses the need associated with a white space >>>>master device which is mobile. >>>>The master device may query channel availability for a specific >>>>contour or a set of locations on a certain path for example. >>>>Hence this requirement is primarily about allowing the query to >>>>contain information that goes beyond just a specific lat/long co-ordinate. >>>> >>>>-Raj >>>> >>>>_______________________________________________ >>>>paws mailing list >>>>[email protected] >>>>https://www.ietf.org/mailman/listinfo/paws >>> >> > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
