Re: [802.19] Straw Poll

Thread Links	Date Links
Thread Prev	Thread Next	Thread Index	Date Prev	Date Next	Date Index

Ben,

IEEE 802 participants / leadership are heavily involved with supporting P2030, and have been invited by NIST to contribute / participate. 802.15 in particular is planning to play a heavy role. The problem is I already know of 802.16 equipment providers who have starting shipping product in that space. And I’m sure 802.11 will have a play. The deployments are (I believe) typically at VHF / UHF frequencies (essentially whitespace propagation) and a cell could easily cover a 20 mile radius. While it might not be the exact focus of this group, I do believe the work here will be relevant.

Bottom line, I don’t think we are suggesting that we are somehow doing smart grid standardization. But the smart grid standardization efforts (such as P2030) are looking to leverage existing standardization efforts to further their cause. It would not shock me if this effort quickly become relevant in that arena. Again, this is just a personal opinion. This was supposed to be an aside, so I’ll let it go now.

Thanks!

Mat

Matthew Sherman, Ph.D.
Engineering Fellow
BAE Systems - Electronics, Intelligence, & Support (EI&S)
Office: +1 973.633.6344
Cell: +1 973.229.9520
email: matthew.sherman@xxxxxxxxxxxxxx

From: Benjamin A. Rolfe [mailto:ben@xxxxxxxxxxxxxx]
Sent: Thursday, August 13, 2009 12:35 PM
To: STDS-802-19@xxxxxxxxxxxxxxxxx
Subject: Re: [802.19] Straw Poll

All,

There are lots of activities wrt to 'smart grid' in SDOs besides 802. There is a P2030 which most of you know about, which is where some work for the upper layers should be going on wrt 'smart grid'; and a browse of the NIST SG website shows the vast breadth of work being done, in at least 20 SDOs by my count (and probably more to join it). Most of that is based on the assumption that IP is used as the transport. In fact, the last NIST workshop left the impression that "its IP or the highway" so to speak (there were a few objections still). A LOT of that activity is regarding security. I am not sure it makes much sense to add yet another SDO group working on smart grid cyber-security, but I am just a wireless guy and no security expert. One thing that is obvious is that there is a great deal of overlap in efforts of various SDOs. Adding to that overlap is not really helpful.

Regarding the scope of dot-19 work here, I see the desire to have an 'end to end' coexistence solution, but I also see some negative consequences of abandoning the benefits of layered protocols. It may be too late to change this for TVWS, but it seems that requiring devices to support IP (and other specific upper layer protocols) to access the medium in a band is not a good approach, and limits the kinds of devices and uses to "internet centric" (and it seems, internet connected). Are we starting out with the assumption that every single device to operate in TVWS has such capability? That seems an important thing to state explicitly in the scope, if true.

I have to agree enthusiastically with Mariana that the scope and limitations of 802 should be clearly documented and not just the folklore passed down from one generation of member to the next ;-).

Cheers!

-Ben

----- Original Message -----

From: Sherman, Matthew J. (US SSA)

To: STDS-802-19@xxxxxxxxxxxxxxxxx

Sent: Thursday, August 13, 2009 6:26 AM

Subject: Re: [802.19] Straw Poll

Hi Mariana,

I like this approach and will take it upon myself to push this issue at the EC level. I am very aware of the emerging Smart Grid opportunities and what it represents for 802.16 products. I think you for pointing it out to this group.

Best regards,

Mat

Matthew Sherman, Ph.D.
Engineering Fellow
BAE Systems - Electronics, Intelligence, & Support (EI&S)
Office: +1 973.633.6344
Cell: +1 973.229.9520
email: matthew.sherman@xxxxxxxxxxxxxx

From: Mariana Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx]
Sent: Thursday, August 13, 2009 5:05 AM
To: Sherman, Matthew J. (US SSA); Shellhammer, Steve; WHITESPACE@xxxxxxxxxxxxxxxxx; 802. 19 TAG (stds-802-19@xxxxxxxx)
Subject: RE: Straw Poll

Hi Matt,

My approach is based on personal experience.

In 16h we have defined initially a full Coexistence Protocol, using UDP and TCP/IP. Note that we did NOT propose a new transport protocol (higher layers), but used the existing IETF standards. We have encapsulated our information elements as payload of these protocols. The only thing needed was to ask IETF for assigning two dedicated ports (administrative issue).

We did not pass even the approval inside of 802.16. We were said that we will not pass the EC approval. We had to retain only the information elements of the protocol and it was a significant work to do this and adapt the draft to the management structure in 16g. An EC member told me that only the management and control will be ok.

I would be happy to see that 802 EC has a decision for allowing the use of the existing IETF or other standards organization transport protocols and give us the liberty to define end-to-end solutions. In addition, those interfaces related to cellular applications, like Subscriber Identification (SIM), interfaces to Network Servers for user authentication, accounting and billing, etc. should also be allowed. Note that in general the protocols used at higher layers for these applications are IETF’s.

I would recommend acting on two parallel tracks:

Write a TVWS Coex. PAR for fast approval, using the 802 “de facto” limitations. If EC decides to change its approach (see 2), the PAR can be changed at a suitable time.

Start in EC a process with the objective to identify what is needed and decide what should be allowed in the future. This will take probably significant time, because the outcome should be a document, establishing “de jure” the 802 rules in this matter.

The problem is not only with this PAR, but also with PARs related to security and probably Smart Grids     applications. You may not be aware that 3GPP had discussions about the SIM support for Smart Grids.

Regards,

Mariana

From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of Sherman, Matthew J. (US SSA)
Sent: Wednesday, August 12, 2009 11:22 PM
To: Shellhammer, Steve; Mariana Goldhamer; WHITESPACE@xxxxxxxxxxxxxxxxx; 802. 19 TAG (stds-802-19@xxxxxxxx)
Subject: RE: Straw Poll

Actually, there may be restrictions somewhere in 802.1 based on the architecture. As you know 802.1 claims the interface to the upper layers and has a PAR in that area. However, I view these restrictions as self imposed since they aren’t in our formal scope. I believe this is a current area of debate for the EC and want to make clear to everyone that my statements are my person view, and not a formal position of IEEE 802.

Thanks!

Mat

Matthew Sherman, Ph.D.
Engineering Fellow
BAE Systems - Electronics, Intelligence, & Support (EI&S)
Office: +1 973.633.6344
Cell: +1 973.229.9520
email: matthew.sherman@xxxxxxxxxxxxxx

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 4:18 PM
To: Sherman, Matthew J. (US SSA); Mariana Goldhamer; WHITESPACE@xxxxxxxxxxxxxxxxx; 802. 19 TAG (stds-802-19@xxxxxxxx)
Subject: RE: Straw Poll

Matt,

                I think you have hit on the difference between and 802 rule and an 802 unwritten rule.

                It would be useful if the EC confirmed your position since we have all heard for many years that 802 does Layer 1 and 2, nothing more.

                I think for some of this coexistence work we may need to go higher so I hope the EC does not object.

Steve

From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of Sherman, Matthew J. (US SSA)
Sent: Wednesday, August 12, 2009 11:05 AM
To: Mariana Goldhamer; WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: RE: Straw Poll

Hi Marianna,

I have no objection you your straw poll, but would like to know that origin of your statement that the higher layers are out of scope.

The IEEE 802 scope statement from the P&P reads:

The scope of the LMSC is to develop and maintain networking standards and recommended

practices for local, metropolitan, and other area networks, using an open and accredited process,

and to advocate them on a global basis.

While I don’t think we should try and do the job of the IETF, I see a lack of ‘end to end’ standards for the protocols we develop. For instance, WiMAX in essence standardizes the 802.16 architecture and protocol aspects above the MAC layer because (in my opinion) no standards organization takes on the task. The identity of many systems (such as WiMAX and WiFi) is directly tied to the MAC/PHY they are based on. In my opinion there is nothing that keeps this group from creating systems level end to end standards that include work above the MAC. However, I encourage that we leverage work being done by other SDO as much as possible and not reinvent the wheel.

Anyway, if you know of other restrictions that I don’t, I’d be happy to hear them.

Best regards,

Mat

Matthew Sherman, Ph.D.
Engineering Fellow
BAE Systems - Electronics, Intelligence, & Support (EI&S)
Office: +1 973.633.6344
Cell: +1 973.229.9520
email: matthew.sherman@xxxxxxxxxxxxxx

From: Mariana Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 1:45 PM
To: WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: Re: [WHITESPACE] Straw Poll

Hi Steve,

There are big differences between my Question 2 and the existing poll Question 2, reproduced below:

“Should the group develop a media agnostic (backhaul or wireless) higher-layer (above layer 2) coexistence protocol and mechanism?”

First, my proposal is in the 802 scope (the management is allowed in 802, while the higher layers not); secondly, it is no need for specifying “coexistence mechanisms”, as the management may include mechanisms and they are also covered in my Question 1. It is possible in 802 to define the primitives (information elements) of a management protocol. The full transport (higher-layer) protocol may be selected and recommended by the group from the existing IETF protocols. I hope that the 802 EC will not oppose that the standard will also include this recommendation.

It is missing, in my Question 1, a definition for “agreed”. In my view, should be agreement between the interested 802 WGs. Agreement means that each of the relevant WGs approve the medium access protocol (and the management part) and this is a condition for the standard approval. This approval is also some sort of indication that the protocol will be really implemented by the industry. Developing a standard not recognized by the interested parties does not make sense.

Regards,

Mariana

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 8:14 PM
To: Mariana Goldhamer; 802. 19 TAG (stds-802-19@xxxxxxxx); WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: RE: Straw Poll

Why do you want to ask Question #2? That is basically one of the two questions in the current straw poll.

Steve

From: Mariana Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 10:08 AM
To: Shellhammer, Steve; 802. 19 TAG (stds-802-19@xxxxxxxx); WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: RE: Straw Poll

Hi Steve,

Thanks for your offer J

Probably the best will work for me the following:

1. Should there be a coordinated coexistence mechanism that relies on an agreed medium access protocol?

Yes

No

2. Should the group develop, in addition to the above coordinated coexistence mechanism, a media agnostic (backhaul or wireless) management protocol (centralized and/or distributed)?

Yes

No

Regards,

Mariana

From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 7:54 PM
To: Mariana Goldhamer; 802. 19 TAG (stds-802-19@xxxxxxxx); WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: RE: Straw Poll

Marianna,

                I cannot change the straw poll once I start it since that will disturb the results. Also, we agreed on that wording during the conference call.

                I could however run another straw poll. Based on your email would the following straw poll work for you?

Should there be a coordinated coexistence mechanism that relies on an agreed medium access protocol?

·         Yes

·         No

Steve

From: Mariana Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx]
Sent: Wednesday, August 12, 2009 7:05 AM
To: Shellhammer, Steve; 802. 19 TAG (stds-802-19@xxxxxxxx); WHITESPACE@xxxxxxxxxxxxxxxxx
Subject: RE: Straw Poll

Steve,

My preference is not included in the straw poll. A coordinated mechanism not necessarily needs inter-system communication.

Would you please include in the straw-poll a 3d variant?

Should there be a coordinated coexistence mechanism that relies on an agreed medium access protocol?

In addition, the operation of such protocol may benefit from inter-system communication or management, such that should be possible to select this option together with the other options.

In case when the management or the communications are not feasible from different reasons, such a mechanism can still work and provide improvements.

Regards,

Mariana

From: whitespace@xxxxxxxx [mailto:whitespace@xxxxxxxx] On Behalf Of Shellhammer, Steve
Sent: Wednesday, August 12, 2009 3:36 AM
To: 802. 19 TAG (stds-802-19@xxxxxxxx); 802TVWS (WHITESPACE@xxxxxxxxxxxxxxxxx)
Subject: Straw Poll

Here is the straw poll that we developed during today’s 802.19 TVWS coexistence conference call.

There are two questions.

http://www.surveymonkey.com/s.aspx?sm=J72GB3TSQWDjygAAOWJHvw_3d_3d

I will check it later this week and send out the results.

Steve

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(43).
************************************************************************************

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
************************************************************************************