Thread Links | Date Links | ||||
---|---|---|---|---|---|
Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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. From: Mariana
Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx] 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:
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) 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. From: 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) 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. From: Mariana
Goldhamer [mailto:marianna.goldhammer@xxxxxxxxxxxx] 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: 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] 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: 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] 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 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(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). ************************************************************************************ |