Subject: Re: [paws] draft update to PAWS UC&R

From: Gerald Chouinard <[email-masked]>
Date: Fri, 24 Feb 2012 14:36:22 -0500

Scott,

Attached is a polished-up version of section 4.2.2 on "Wide-Area or Rural
internet broadband access".

Besides some minor typos, I have tried to clarify that items 1 to 6 are for
the master/BS initial operation. I have added the concept of an optional
verification of an available channel list that would apply over an area
around the BS so that the CPEs, when they try to associate with the BS,
would use a channel that in known not to interfere with incumbents at their
location.

Items 7 and 8 relate to the actions to be taken by the slave/user devices.

Item 9 now deals with the process at the master/BS to add a new slave/user
device to the network. Three different cases are covered for the master/BS
to take a decision.

Item 10 now deals with the 'steady state', i.e., the repeated query process
at the master/BS to maintain the association with its slave/user devices.
(It used to be covered in both items 9 and 10.) It now covers the cases
where: a) the operating channel is available to all devices, thus no change;
b) the operating channel is no longer available to the master/BS, in such
case, it needs to alert its associated terminals and move to the new
operating channel; c) if one of the slave/user devices can no longer operate
on the current channel, then the master/BS may decide to either: c1) drop
association with that terminal or, c2) move to another available channel in
the list to accommodate that terminal as long as that channel is available
to the master/BS and all other associated slave/user terminals.

This should clarify the decisions that need to be made at the master/BS in
all cases and make the text clearer.

Respectfully submitted,

Gerald

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, 21 February, 2012 10:17
To: [email-masked]; [email-masked]
Subject: draft update to PAWS UC&R

Hi,

Attached is a draft version-03 update of the use case & requirements. This
is not an official release; in order to avoid confusion I have removed the
heading & some boiler-plate text at the beginning of this draft. In order to
improve the quality of the draft, I am asking a few of the people who have
been active in the discussions if you have some time to review this interim
document for accuracy, to verify that it reflects the results of the email
reflector discussion. Your review of the entire document is warmly welcomed,
but if you are pressed for time, a focused review on those sections where
you have provided comments is much appreciated. Note that Chapter 6
"Requirements" is not yet updated, I will be posting this section to the
reflector for comments shortly. 

If you find any errors or omissions in implementation please let me know and
I will correct those. If you find technical errors or corrections, first
let's discuss how we can review those comments on the email reflector and
reach consensus there. Then I can update the draft.

Also attached for your reference is a spreadsheet that identifies the
specific email discussions that I have implemented. There is some overlap in
these threads due to the "opportunistic" nature of the email discussions.

Kind Regards,

Scott

---

From: <[email-masked]>
Date: Fri, 24 Feb 2012 19:57:34 +0000

Hi Gerald,

Your corrections are good improvements, thank you. I will include these to the draft assuming no objections.

Kind Regards,
Scott

From: ext Gerald Chouinard [mailto:[email-masked]]
Sent: Friday, February 24, 2012 1:36 PM
To: Probasco Scott (Nokia-CIC/Dallas)
Cc: [email-masked]; 'apurva mody'
Subject: RE: draft update to PAWS UC&R

Scott,

Attached is a polished-up version of section 4.2.2 on "Wide-Area or Rural internet broadband access".

Besides some minor typos, I have tried to clarify that items 1 to 6 are for the master/BS initial operation. I have added the concept of an optional verification of an available channel list that would apply over an area around the BS so that the CPEs, when they try to associate with the BS, would use a channel that in known not to interfere with incumbents at their location.

Item 9 now deals with the process at the master/BS to add a new slave/user device to the network. Three different cases are covered for the master/BS to take a decision.

Item 10 now deals with the 'steady state', i.e., the repeated query process at the master/BS to maintain the association with its slave/user devices. (It used to be covered in both items 9 and 10.) It now covers the cases where: a) the operating channel is available to all devices, thus no change; b) the operating channel is no longer available to the master/BS, in such case, it needs to alert its associated terminals and move to the new operating channel; c) if one of the slave/user devices can no longer operate on the current channel, then the master/BS may decide to either: c1) drop association with that terminal or, c2) move to another available channel in the list to accommodate that terminal as long as that channel is available to the master/BS and all other associated slave/user terminals.

This should clarify the decisions that need to be made at the master/BS in all cases and make the text clearer.

Respectfully submitted,

Gerald

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, 21 February, 2012 10:17
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: draft update to PAWS UC&R

Hi,

Attached is a draft version-03 update of the use case & requirements. This is not an official release; in order to avoid confusion I have removed the heading & some boiler-plate text at the beginning of this draft. In order to improve the quality of the draft, I am asking a few of the people who have been active in the discussions if you have some time to review this interim document for accuracy, to verify that it reflects the results of the email reflector discussion. Your review of the entire document is warmly welcomed, but if you are pressed for time, a focused review on those sections where you have provided comments is much appreciated. Note that Chapter 6 "Requirements" is not yet updated, I will be posting this section to the reflector for comments shortly.

If you find any errors or omissions in implementation please let me know and I will correct those. If you find technical errors or corrections, first let's discuss how we can review those comments on the email reflector and reach consensus there. Then I can update the draft.

Also attached for your reference is a spreadsheet that identifies the specific email discussions that I have implemented. There is some overlap in these threads due to the "opportunistic" nature of the email discussions.

Kind Regards,
Scott