Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy sub-task call
Sanjay,
Needless to say, the whole topic of "profiles" is touchy in this group J
Marek
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Wednesday, July 03, 2013 6:53 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Victor,
A Profile is another term which is defined in other per-existing standards
to describe the nature of transmission for a given PHY so the receiver has
the highest probability of receiving it successfully. This is also sometimes
referred as modulation profile.
It mainly consists of the bit loading for symbols in a given subcarrier (can
vary from subcarrier to subcarrier or a set of subcarriers) based on either
the noise/interference/impairments in a given network or the
availability/non-availability of certain subset of the spectrum based on
either other services or known interferences in that network resulting in
certain subcarriers to either completely muted in a given network
permanently or temporarily in-active, or perform on a reduced bit loading. I
think the PHY experts can provide a better explanation of this.
In IEEE 802.3bn EPoC group we have had a major discussion and even a
sub-task force to address multiple modulation profiles in downstream.
What Ed was trying to present in his slides was that "a method exists where
one can solve the existing EPON one dimensional time domain granting with
OFDMA two dimensional frequency and time mapping, without any involvement of
MAC layer no matter if all the CNUs have the same upstream profile (simpler
and easier problem to solve) or they have different upstream profile (more
complex and bit more involved and expensive problem to solve)".
What Ed clearly put in his disclaimer is that he was NOT trying to define
the parameters for the OFDMA PHY in his solution.
Once the PHY parameters are well defined for EPoC (which in turn will
solidify "profile/profiles"), Ed's method can be further refined to work on
those parameters.
Regards,
-Sanjay
On Jul 2, 2013, at 6:43 PM, "Victor Blake" <victorblake@xxxxxxxxxxxxxxx>
wrote:
Sanjay,
This further requires defining the profiles (referred to in Ed's
presentation) then (if one accepts this proposed method) ..
Has any work been done on what those profiles would be ?
-Victor
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 6:10 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Hello Duane,
Slides 6-9 and 12 in the following presentation explain how the TQs can be
converted to Frequency and time for a single common upstream profile for all
CNUs.
http://www.ieee802.org/3/bn/public/nov12/boyd_01_1112.pdf
A more detailed version makes sense once the PHY parameters are completely
defined. If you have any specific questions which are not clear from Ed's
presentation, we can try to address those.
Regards,
-Sanjay
On Jul 2, 2013, at 2:35 PM, "Duane Remein" <Duane.Remein@xxxxxxxxxx> wrote:
Sanjay,
I agree that Ed suggested a 1D to 2D mapping but so far no one havew
provided any details on how this function will work. That should change
after the Geneva meeting and this was part of the call for presentations (I
would expect something from Broadcom on this given that Ed put forward the
idea).
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 3:27 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Victor,
My understanding is that Ed already presented an approach to solve this
problem you described and Marek referred to that approach in one of his
email as 1D to 2D mapping. Ed clearly specified how grants in time domain
can be mapped to time and frequency domain without CNUs stepping on each
other.
Regards,
-Sanjay
On Jul 2, 2013, at 11:59 AM, "Victor Blake" <victorblake@xxxxxxxxxxxxxxx>
wrote:
The problem of dependence is that with a deterministic system, controlled by
the CLT (as Duane describes), there must be means to grant fractional
bandwidth. Currently (again correct me if I am wrong), the grant is done in
the time domain. The "challenge" is that the bandwidth available at any
given "time" may be across more than one frequency (more specifically in
time and frequency - aka RB's).
More particularly, the question is - can we grant in time, w/out respect to
frequency and allow the CNU's to autonomously elect frequencies without
interfering with each other (see below) - answer is no - unless some other
means of making these decision autonomously (within CNU), but in such a way
that there is no conflict with other CNUs also making the same autonomous
decisions. At the very least it is at most elevated to the CLT (and not to
EPON) - it's a starting point. But still have to spend some time figuring
out if we really need to add more parameters to grants or if there is a way
to otherwise guarantee they will not be the same. For example, could there
be an algorithm derived from existing parameters ?
Sorry, no answers here. I think I understand the challenge, but would like
to see us think about this before concluding that we must populate this top
down. would like to avoid that at all costs.
-Victor
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: Tuesday, July 02, 2013 2:22 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Duane-
You make a good point.
For example, the current DMLT project proposal proposes to fragment packets
to intersperse other traffic.
Such a mechanism would have exactly the problem that you point out.
We are staring to badly stretch our concepts of layer independence.
It will cause problems and unintended consequences.
The result will be an Ethernet that no longer has the attractive simplicity
that made it such a success.
Best regards,
Geoff Thompson
On 7/2/13 10:09 AM, Duane Remein wrote:
Marek,
I think you've made a very good observation, some grant sizes will be
invalid because we will not have the ability to transmit in 16 ns (TQ)
granularity, OFDMA just isn't as flexible as good ol' optics. My opinion is
that the upper layers (above the MAC) will need to understand the
granularity that is allowed for in EPoC grants. IF not then you will waste a
great deal of resources because you will need to round down to the nearest
OFDM transmission bucket (or Resource Block as has been proposed in numerous
presentations).
Think of it this way. You have a CNU with a 2000 byte frame to transmit. The
CLT grants X TQs but the CNU, because of transmission granularity can only
use X-n TQs so nothing gets transmitted. Not a good situation.
Best Regards,
Duane
FutureWei Technologies Inc.
duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Tuesday, July 02, 2013 11:49 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Avi,
Please note that granting is done in units of TQ, which is also something
that you would need to take into consideration in your calculations. Not all
combinations would be valid.
Furthermore, what you're effectively after is restriction on the size of
grants allocated to the CNU. For that to work, we do not need to introduce
yet another concept into the already loaded draft
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 4:33 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek, Sanjay
A resource block would be a minimal unit of x symbols and y subcarriers that
can be detected by the receiver. (I prefer to use x for symbols and y for
subcarriers since we are using to the horizontal axis for time and vertical
for frequency).
In the latest proposal we had, we assumed y and x can be configurable (per
system, all CNUs using the same RB size), and minimum values for y and x
were 4 and 6, respectively. However we can think of ways to reduce y further
to be a single sub-carrier.
To answer Marek's questions: the conversion between granted times and RBs
would be done by the CNU as part of the 1D to 2D scheduling. As an example,
if the OFDMA symbol is 20 uSec long and has 4000 subcarrier, each
subcarrier/symbol can be translated to 20u/4000 = 5nSec (I am omitting the
CP size for the simplicity of the calculations). For the case of x*y RBs,
one RB unit is translated too x*y*5nSec, or 120nSec for the case of x=6 and
y=4.
Partial RBs are not possible.
The CLT would know the size of the RB as it is a fixed size.
The IFG should probably be configured to the size of at least one RB to
insure no collisions.
Avi
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 6:02 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek,
Ethernet has a concept of Byte and also has a concept of minimum size of a
frame which can be transmitted to be considered a valid transmission.
Resource element and resource block are similar terms used by OFDMA PHY.
They are in no way or shape related to byte or minimum frame size in
Ethernet but conceptually they are similar.
My understanding is that a given CNU transmitter requires a minimum x number
of sub-carriers and a minimum y number of symbols for that transmission to
be successfully received at the CLT.
What I see you are stating is that can we get away with a single subcarrier
and a single symbol (called a resource element) as the smallest unit.
Ed's presentation assumed x=1 and y>1 but TBD. I think PHY experts can
answer these questions better
1. What is the minimum value for x and y needed for a successful
transmission?
2. Given that y is same, does the incremental value of x has to be same or
can it be less?
Regards,
-Sanjay
On Jul 2, 2013, at 6:02 AM, "Marek Hajduczenia" <marek.hajduczenia@xxxxxx>
wrote:
Avi,
How would that conversion happen? Would it be possible to allocate partial
RBs? How does the CLT know what the size of RB is? This stuff raises just
more questions than it answers.
What is wrong with the design that Ed originally had, i.e., where grants are
converted into carriers without the use of any RBs ?
Marek
From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 12:46 PM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek,
Resource Block (RB) is a structure that is convenient for the PHY
transmissions, and should not be visible to upper layers. The CNU PHY would
get time allocations via grants and would convert them into RBs for
transmission. RBs are PHY structures with pre-configured number of
sub-carriers and OFDMA symbols, and pilots structure. Pilots are required
for the receiver for time and frequency synchronization and for channel
estimation.
As I believe there was no intention to redesign the MAC or MPCP in order to
support the RB structure
Avi
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Tuesday, July 02, 2013 11:37 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Dear Sanjay,
Using something in a presentation does not necessarily mean that it is
something we either need, or defined for our own use. I appreciate the
education on this topic, but I am still unclear as to why we need it in the
first place, considering that all allocation in EPON (and EPoC ?) would be
done via grants, which have nothing (absolutely) to do with frequency
allocation.
It is true that CNUs would convert time-based allocation into set of
carriers, but that would be done in a matter transparent to CLT, in which
the CLT does not explicitly allocate specific carriers to the specific CNU.
Now, were we to say that we want to redesign MPCP for the use in EPoC and
provide explicit carrier allocation, the discussion would be different. But
then also we would need a different project, since it is hardly a reuse of
EPON MPCP, but rather its redesign.
Marek
From: Sanjay Goswami [mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 12:17 AM
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek,
Resource block, resource element, slot are some of terms which are already
defined in other standards related to OFDMA. These terms were used in the
Details on Upstream Pilots and Resource Block Configuration for EPoC
<http://www.ieee802.org/3/bn/public/may13/pietsch_3bn_01_0513.pdf>
presentation by Avi Kliger and Christian Pietsch in May 2013 IEEE 802.3bn
Victoria meeting. In Phy Link Ad-hoc meeting last week, Syed Rahman
presentation focused on efficiency of Upstream Resource blocks. The
questions all of us are asking revolve around the following:
Are we redefining these terms?
What is the scope of these terms?
Both are important questions. My objection was (which I see is also your
objection) related to the scope and visibility of these terms. Changing the
GATE format and making these PHY resources visible to OLT seems to break the
layering rules. It also makes operating with existing equipment in field
much more difficult. In my view, we should not be touching the EPON MAC
layers unless its absolute must.
Another important aspect which Duane pointed out is the visibility of these
PHY terms. The questions is "Are these programmable values in PHY?" If Yes,
then how these are provisioned?
I would suggest that since Duane is suggesting these changes, he can bring
up these as Straw Poll in next Phy Link Ad-hoc meeting.
Regards
Sanjay
-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, June 28, 2013 3:21 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Duane,
In EPON, we somehow get away without specifying all that and yet operators
are able to get the most of the EPON systems. Putting too many knobs is a
simple way to overcomplicate the design and then end up with
interoperability problems. I am against putting too much rope out. The
strength of the Ethernet is in simplicity and reliability, and not
complexity and configurability taken to extreme.
Put it in different perspective - what is wrong with the current definition
of a grant, which has nothing to do with frequency bands, allocations etc.
and which was already proposed to be mapped into spectrum without upper
layers being aware of this fact? Are you trying to revert this agreement and
go towards redefinition of GATE MPCPDU structure and its meaning?
Regards
Marek
-----Original Message-----
From: Duane Remein [ <mailto:Duane.Remein@xxxxxxxxxx>
mailto:Duane.Remein@xxxxxxxxxx]
Sent: Friday, 28 June 2013 9:31 PM
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Eugene,
If you keep this hidden from 802.3 then there will be no opportunity for the
operator to vary this to account for the network. Is this OK with all
operators?
I agree that there is no need for the MAC to be aware of this, I don't agree
that the upper DBA layer should necessarily be unaware of this nor that the
operator should not be able to control the RB size via MDIO should they
choose to do so.
Best Regards,
Duane
FutureWei Technologies Inc.
<mailto:duane.remein@xxxxxxxxxx> duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
-----Original Message-----
From: Dai, Eugene (CCI-Atlanta) [ <mailto:Eugene.Dai@xxxxxxx>
mailto:Eugene.Dai@xxxxxxx]
Sent: Friday, June 28, 2013 3:38 PM
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
I would be careful to introduce a concept such as "resource block" or what
ever you might call it into 802.3bn. "Resource block" make sense in DOCSIS
3.1 OFDM because CMTS completely aware RF PHY. In 802.3bn, CLT/OLT does not
know or aware RF PHY OFDM parameters; the grant is based on TQ. If we go
that far open the door to let CLT/OLT aware OFDM, I am afraid it will
deviate from our original plan too much.
Eugene
________________________________________
From: Marek Hajduczenia [marek.hajduczenia@xxxxxx]
Sent: Friday, June 28, 2013 10:48 AM
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Duane,
My point is much simpler - if this new thing is essentially a grant, why not
use "grant" rather than create a new term for it ?
Marek
From: Duane Remein [ <mailto:Duane.Remein@xxxxxxxxxx>
mailto:Duane.Remein@xxxxxxxxxx]
Sent: Friday, 28 June 2013 3:22 PM
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek,
I would welcome your input on how to make a less confusing definition. I
would have no problem replacing GATE with grant.
Best Regards,
Duane
FutureWei Technologies Inc.
<mailto:duane.remein@xxxxxxxxxx> duane.remein@xxxxxxxxxx
Director, Access R&D
919 418 4741
Raleigh, NC
From: Marek Hajduczenia [ <mailto:marek.hajduczenia@xxxxxx>
mailto:marek.hajduczenia@xxxxxx]
Sent: Friday, June 28, 2013 5:42 AM
To: Duane Remein; <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Duane,
Such a definition is confusing at best - you seem to assume that we allocate
specific range of spectrum via GATE message, and we can do so only in time
domain. We also do have a term already in GATE - "grant" - and I am not sure
why we need to define yet another one to speak about apparently the very
same thing.
Marek
From: Duane Remein [ <mailto:Duane.Remein@xxxxxxxxxx>
mailto:Duane.Remein@xxxxxxxxxx]
Sent: Thursday, 27 June 2013 10:38 PM
To: <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
I agree we havn't a formal definition. I would purpose something like: "a
set of sub-carriers connected in time related in frequency, but not
necessarily contigeous in frequency, allocated by a single GATE message".
Best Regards,
Duane
FutureWei Technologies Inc.
<mailto:duane.remein@xxxxxxxxxx%3cmailto:duane.remein@xxxxxxxxxx>
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx>
Director, Access R&D
919 418 4741
Raleigh, NC
From: Avi Kliger [ <mailto:akliger@xxxxxxxxxxxx>
mailto:akliger@xxxxxxxxxxxx]
Sent: Thursday, June 27, 2013 1:48 AM
To:
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@LISTSERV.
IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
In the joint upstream pilot contribution by QCOM+BRCM we described what we
called a RB. It wasn't a "formal" definition though.
From: Marek Hajduczenia [ <mailto:marek.hajduczenia@xxxxxx>
mailto:marek.hajduczenia@xxxxxx]
Sent: Thursday, June 27, 2013 1:46 AM
To:
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@LISTSERV.
IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Thank you for confirmation, Syed,
It is hard for me then to understand proposals towards such an undefined
entity .... Is anybody actually planning to define this term ?
Marek
From: Syed Rahman [ <mailto:Syed.R@xxxxxxxxxx> mailto:Syed.R@xxxxxxxxxx]
Sent: Wednesday, 26 June 2013 11:24 PM
To:
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@LISTSERV.
IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Marek,
* To the best of my knowledge, so far we have not decided on a
formal resource block definition.
* There have been multiple presentations which talked about resource
blocks for different applications (pilots, burst markers, et cetra..)
* Attached is one such presentation
Thanks,
Syed
From: Marek Hajduczenia [ <mailto:marek.hajduczenia@xxxxxx>
mailto:marek.hajduczenia@xxxxxx]
Sent: Wednesday, June 26, 2013 2:45 PM
To:
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@LISTSERV.
IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
Dear colleagues,
Have we ever really generated a consented definition of the whole "resource
block"? I have been looking through a number of contributions and it seems
that it is kind of give, yet I must have missed a formal definition of what
this really is. Could anybody point to where it was defined (if it was done
before) or try to come up with a consistent definition of what this is (at
best, relative to EPON for simpler comprehension) ?
Thank you in advance
Marek
From: Syed Rahman [ <mailto:Syed.R@xxxxxxxxxx> mailto:Syed.R@xxxxxxxxxx]
Sent: Wednesday, 26 June 2013 9:05 PM
To:
<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@LISTSERV.
IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [STDS-802-3-EPOC] Resoruce block presentation in todays phy
sub-task call
All,
Attached is the presentation I gave in today's Phys sub-task force call.
Thanks,
Syed
________________________________
<="" p="">
________________________________
<="" p="">
________________________________
________________________________
<="" p="">
________________________________
<="" p="">
________________________________
________________________________
<="" p="">
________________________________
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
<https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
<https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
<https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1>
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
<="" p="">
_____
_____
_____
<="" p="">
_____
<="" p="">
_____
_____
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1