Re: [802.3_EPOC] Action items for September 2012 meeting

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

David,

Just to make thing extra crisp

Cyclic Prefix (CP) – A redundant set of IFFT time samples appended to the beginning of an OFDM symbol to introduce an effective delay between individual OFDM symbols. The k redundant CP samples attached at the beginning of the IFFT output are identical to the last k samples of the IFFT output. The associated effective delay, (k x (1/BW), is used primarily to combat multipath echo effects, and the CP approach chosen for its discrete signal processing efficiencies.

The problem that I see now is that we need definitions of IFFT time sample, OFDM symbol, as well as IFFT output. The last term is kind of iffy, because on one hand it seems that it is continuous and on the other, that it is discrete and has certain repetitions included within in. I believe it will become clearer when we pin point where this IFFT is in the layers of the EPoC stack.

Marek

From: Urban, David [mailto:David_Urban@xxxxxxxxxxxxxxxxx]
Sent: 07 August 2012 07:31
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

I suggest

Cyclic Prefix (CP) – A redundant set of IFFT time samples appended to the beginning of an OFDM symbol to introduce an effective delay between symbols. The k redundant CP samples attached at the beginning of the IFFT output are identical to the last k samples of the IFFT output. The associated effective delay, (k x (1/BW), is used primarily to combat multipath echoes, and the CP approach chosen for its discrete signal processing efficiencies.

I looked at 802.11, MoCa, and LTE and they did not seem to formally define CP, however, I did find the following quote in an LTE book.

“The CP is generated by duplicating the last G samples of the IFFT output and appending them at the beginning of x_k.”

In these specifications CP is described as a time duration in ns or microseconds and also as a length in IFFT time samples, typically as a fraction of Nfft such as 802.11 GI length = Nfft/4

I think you should avoid using the term “symbols” to describe IFFT time samples.

In 802.11 the channel bandwidth is 40 MHz with Nfft=128. An OFDM symbol consists of 128 subcarriers and the IFFT output consists of 128 time samples with a sample period of (1/40MHz=25ns) for a useful symbol time of 128*25=3,200 ns. The GI length is Nfft/4=32 samples, so the time duration of the GI is 32*25ns=800ns. The OFDM symbol period is equal to the GI plus the useful symbol period, 3200+800=4000 ns=4microseconds.

The symbol period of 802.11 is 4 microseconds. If you’d use the CP definition below then you’d conclude that the OFDM symbol period of 802.11 was 25 ns.

Dave Urban

Comcast

From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
Sent: Tuesday, August 07, 2012 3:19 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

Rob,

Thanks for the input. I captured your suggestions in version R5 as attached. I modified wording here and there to make it cleaner.

Also, perhaps I am reading it wrong, but the interleaver seems to me to be equal to scrambler. If that is indeed the case, I’d suggest we use scrambler instead, which is a common term used in other clauses, rather than introduce a new term.

Marek

From: Robert Howald [mailto:wdcf34@xxxxxxxxxxxx]
Sent: 06 August 2012 21:28
To: Marek Hajduczenia
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

Hoping I am not a revision behind or two on this acronyms and definitions document (using Marek's rev 4 as the latest that I see in my inbox).....

Some considerations and suggestions for blank spaces in Rev 4:

CDN (a comment): The acronym CDN is commonly used in CATV architectures to refer to “Content Distribution Network.” Typically that’s the network and control plane built out behind the access edge to access and transport video streams and files from video processing sites, storage, cache servers, etc, to and from hubs and headends. I am ok with leaving it as is, as the paths should not often cross with our work here, but thought I should identify that in case any MSOs see a potential for confusion.

I'd recommend defining both of the following (not only the second one as currently called out) for clarity:

Cyclic Prefix (CP) – A redundant set of symbols appended to the beginning of an OFDM frame to introduce an effective delay between frame payloads. The k redundant CP symbols attached at the beginning of the frame are identical to the last k symbols of the frame. The associated effective delay, (k x the OFDM symbol period), is used primarily to combat multipath echoes, and the CP approach chosen for its discrete signal processing efficiencies.

Cyclic Prefix Overhead – The inefficiency incurred in an OFDM system as a result of the use of a cyclic prefix to combat multipath.

Also try out…

Interleaver – A signal processing structure used to scramble bit or symbol transmissions in such a way as to increase the robustness of the transmission to bursts of noise or interference which otherwise would results in a series of consecutive errors. Consecutive error events are often difficult or impossible for common forward error correction techniques to mitigate. With the bit or symbol disturbances distributed by interleaving, error correction techniques are more likely to be effective.

QAM – Quadrature Amplitude Modulation. If QAM needs more...."A commonly used digital communications technique whereby multiple bits are encoded into a single symbol by the mapping of a specific bit pattern to an amplitude and phase value for the symbol."

Rob H

On Mon, Aug 6, 2012 at 11:18 AM, Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx> wrote:

Jorge,

I believe there is an ongoing discussion from Tom, so I am going to wait until it is sorted out before making further changes …

Marek

From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: 05 August 2012 20:44

To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

NOTE: I'm resending this Email without the diagram that Hesham had sent because the size of the Email exceeds the maximum Email size allowed by the Email reflector.

John,

I like your wording suggestion. Sounds much better than what I had, which now that I read it again sounded awkward as you said.

Marek,

If there is no further discussion, I suppose you will make the change in the definition, right?

Hesham,

I think we are saying the same thing, but in a different way. While there is agreement on the cross-over frequencies for low and mid-split systems, for the high split different folks consider different top ends, such as 200, 300 and even 400 MHz. But, what we can all agree on is that the split is above 108 MHz, below which you would have a mid-split system. So, in the definition of high split, instead of referring to an absolute figure for the split as we did in low and mid-split systems, we just say "where the split occurs above 108 MHz" (since there is no agreement on what that would be). Does that make sense?

Thanks!
Jorge

From: Hesham ElBakoury [mailto:Hesham.ElBakoury@xxxxxxxxxx]
Sent: Sunday, August 05, 2012 03:56 PM
To: John Ulm <julm@xxxxxxxxxxxx>; Salinger, Jorge
Cc: John T. Chapman <jchapman@xxxxxxxxx>; Emmendorfer, Mike <Mike.Emmendorfer@xxxxxxxxxx>
Subject: RE: [802.3_EPOC] Action items for September 2012 meeting

I found the following illustration for the 4 types of split in a presentation by ARRIS that was presented by Dan Torbit in SCTE seminar on Engineering for All IP.
Jorge was the moderator for this seminar.

It seems from this illustration that the high split crossover is 200MHZ instead of 108MHz.

John Chapman presentation in the last NCTA shows the following splits:

[JDS: I removed a diagram from Hesham's original Email to accommodate the size limit of the EPoC Email reflector]

I have seen other presentations from Cisco where high split crossover point is 200MHz (not 400MHz).

Is there a universal agreement on the definition of these splits ?

Thanks

Hesham

From: John Ulm [mailto:julm@xxxxxxxxxxxx]
Sent: Sunday, August 05, 2012 12:25 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

The wording on the High split definition comes across as a bit awkward. I'd suggest we mirror the wording for Mid split:

High split: an HFC network requiring a diplex filter in which the upstream
is transported in spectrum below the downstream, and where the cross-over
between the upstream and downstream occurs above 108 MHz
Does this work?

-- john
On Sun, Aug 5, 2012 at 10:17 AM, Salinger, Jorge <Jorge_Salinger@xxxxxxxxxxxxxxxxx> wrote:
Marek,

I think that after much discussion on the terms low, mid, high and top
split, we ended up with the definitions included below. I *think* that the
version you have in the list of terms that you just sent is not the latest
one. Hopefully I did not miss a later update, but please correct me if I
am wrong.

Regards,
Jorge

Low split: also known as sub-split, an HFC network requiring a diplex
filter in which the upstream is transported in spectrum below the
downstream, and where the cross-over between the upstream and downstream
occurs between 42 and 54 MHz in 6 MHz channel plan systems and between 65
and 85 MHz in 8 MHz channel plan systems

Mid split: also known as extended sub-split, an HFC network requiring a
diplex filter in which the upstream is transported in spectrum below the
downstream, and where the cross-over between the upstream and downstream
occurs between 85 and 108 MHz

High split: an HFC network requiring a diplex filter in which the upstream
is transported in spectrum below the downstream in spectrum above 108 MHz

Top split: an HFC network requiring a triplex filter in which there are
two upstream bands, one transported in spectrum below the downstream with
the cross-over as per either the low, mid or high splits defined above,
and another transported in spectrum above the downstream.
-----Original Message-----
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Reply-To: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
Date: Sunday, August 5, 2012 8:45 AM
To: EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Action items for September 2012 meeting

>Dear colleagues,
>
>The list of terms was updated, as shown in the attached document with
>tracked changes. Note specifically the extension in definitions of TDD and
>FDD and difference between these modes and half and full duplex, which I
>quote from the current version of P802.3bh (future 802.3-2012).
>
>I would also like to ask for input on missing terms and definitions. Is
>there any specific wording that you would like to see in the definition
>which is currently missing? If so, please do let me know.
>
>Thank you
>
>Marek
>
>-----Original Message-----
>From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>Sent: 26 July 2012 18:22
>To: 'STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx'
>Subject: RE: [802.3_EPOC] Action items for September 2012 meeting
>
>Dear colleagues,
>
>Attached please find the updated version of the list of terms. If I do not
>hear any additional requests for new terms by Friday EBD, I would like to
>proceed to collect proposals for definitions, especially for terms which
>do
>not have currently any definitions assigned to them.
>
>Marek
>
>-----Original Message-----
>From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>Sent: 24 July 2012 07:27
>To: 'Duane Remein'; 'STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx'
>Subject: RE: [802.3_EPOC] Action items for September 2012 meeting
>
>Duane,
>
>The 2008 version of the standard will be long gone by the time we get to
>any
>serious technical work, so the references were only incorrect indicating
>the
>standard's year.
>
>I believe some key terms should be included in the list, even if they just
>point to 802.3 specification, at least to prevent discussions on what is a
>single PHY, where people would interpret the term freely, in a manner not
>really consistent with 802.3 definitions
>
>Regards
>
>Marek
>
>-----Original Message-----
>From: Duane Remein [mailto:Duane.Remein@xxxxxxxxxx]
>Sent: 23 July 2012 12:15
>To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>Cc: Duane Remein
>Subject: RE: [802.3_EPOC] Action items for September 2012 meeting
>
>Marek,
>Give that this is a tool to help everyone learn the "proper" language I
>don't see the need not to copy definitions from 802.3. I've done that for
>all the "see Std IEEE 802.3-2008, 1.4.xx" references in the attached. Note
>that your references were incorrect, were you using clause numbering from
>the maintenance draft and not the 2008 edition as indicated?
>Best Regards,
>Duane
>
>FutureWei Technologies Inc.
>duane.remein@xxxxxxxxxx
>Director, Access R&D
>919 418 4741
>Raleigh, NC
>
>-----Original Message-----
>From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]
>Sent: Monday, July 23, 2012 10:48 AM
>To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>
>Jorge, et al.,
>
>Here is the updated list of terms accounting for recent discussions and
>suggestions.
>
>I am off hiking
>
>Marek
>
>-----Original Message-----
>From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
>Sent: 23 July 2012 07:40
>To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>
>All,
>
>Based on everyone's comments, I would suggest the following definitions:
>
>HFC: a hybrid fiber-coax cable network, in which fiber is used to transmit
>analog RF signals (note: this definition excludes the case where we have
>digital return, but I think that's OK)
>
>Low split: also known as sub-split, an HFC network requiring a diplex
>filter
>in which the upstream is transported in spectrum below the downstream, and
>where the split between the upstream and downstream occurs below 42 MHz
>in 6
>MHz channel plan systems and 65 MHz in 8 MHz channel plan systems
>
>Mid split: also known as extended sub-split, an HFC network requiring a
>diplex filter in which the upstream is transported in spectrum below the
>downstream, and where the split between the upstream and downstream occurs
>below 108 MHz
>
>High split: an HFC network requiring a diplex filter in which the upstream
>is transported in spectrum below the downstream, and where the split
>between
>the upstream and downstream occurs below 216 MHz
>
>Top split: an HFC network requiring a triplex filter in which there are
>two
>upstream bands, one transported in spectrum below the downstream occupying
>spectrum as per either the low, mid or high splits defined above, and
>another transported in spectrum above the downstream.
>
>
>Regards,
>Jorge
>
>-----Original Message-----
>From: Tom Staniec <staniecjt@xxxxxxxxx>
>Reply-To: Tom Staniec <staniecjt@xxxxxxxxx>
>Date: Monday, July 23, 2012 9:00 AM
>To: EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>
>>Good morning all
>>
>>I want to point to some historical perspective on the topics below.
>>
>>Historically:
>>
>>SUB-SPLIT: defined as a cross over point of 42 MHz where the sub-low
>>return is below 42 MHz with the forward being above.
>>
>>That places an EXTENDED SUB Split at 88 MHz, the start of the FM radio
>>band, where everything below 88 MHz would represent return and
>>everything above
>>88
>>MHz is the forward.
>>
>>MID-SPLIT defined the cross over point of the diplex filter as 108 MHz
>>where everything below 108 MHz represents the return band. Everything
>>above 108 MHz represents the forward.
>>
>>HIGH SPLIT is a little more difficult to define. Traditionally the high
>>split was placed above channel 13 top end frequency is 216 MHz where
>>everything below 216 MHz is return and above is forward network.
>>
>>TOP SPLIT is interesting and, again, historically first appeared as a
>>result of TWC FSN (Full Service Network - if my memory is correct) a
>>proof of concept network built in Orlando, Florida but was referred to,
>>in my recollection, as HIGH RETURN. So I think we need to rethink and
>>reflect on how this is described. To Jeff's point, today this reflects
>>a "tri-plex filtering system.
>>
>>Incidentally, HIGH RETURN, at the time was considered not feasible for
>>use for 2 reasons: 1- it placed a top end limit on what cable operators
>>could offer for services and limited channel growth and 2- it required
>>too much power to operate a return in for a communications channel.
>>With everything moving to an IP delivery which frankly could mean
>>unbounded channels the capacity limit in number 1 above may be moot. As
>>for number 2, because power amplifier technology has evolved along with
>>modulation, detection and error correction schemes, this may be more
>>attainable but also may require significant changes in network
>>architecture.
>>
>>I hope this presents some perspective which we may want to follow for
>>consistency at this point.
>>
>>Regards
>>Tom
>
>
>-----Original Message-----
>From: <Finkelstein>, Jeff Finkelstein <Jeff.Finkelstein@xxxxxxx>
>Reply-To: Jeff Finkelstein <Jeff.Finkelstein@xxxxxxx>
>Date: Sunday, July 22, 2012 11:03 PM
>To: EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>
>>To me top-split means a triplex scenario where a second split goes
>>above the downstream, not necessarily only for an upstream but that is
>>how we typically view it.
>>
>>Some scenarios have a legacy upstream being below the downstream, then
>>a second upstream being above the downstream spectrum. I think this is
>>what has been referred to as top-split in respect to this discussion.
>>
>>________________________________________
>>From: Noll, Kevin [kevin.noll@xxxxxxxxxxx]
>>Sent: Sunday, July 22, 2012 10:47 PM
>>To: Finkelstein, Jeff (CCI-Atlanta); STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>>
>>I have always understood top-split to mean that the upstream goes above
>>the currently designed upper plant limits. Usually this means >750MHz
>>or in some contexts >1GHz. Agreed that it isn't always clear on the
>>exact frequency, but it is clear that it is higher than a high-split.
>>
>>--kan--
>>
>
>
>
>>-----Original Message-----
>>From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
>>Sent: Monday, July 23, 2012 1:30 AM
>>To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>>
>>Jorge,
>>
>>I included both proposed definitions. Until clarification on the use of
>>top-split is made, I will keep the term in the list tentatively and
>>follow the discussion.
>>
>>Marek
>
>
>-----Original Message-----
>From: <Kelsen>, Mike Kelsen <michael.kelsen@xxxxxxxxxxx>
>Date: Sunday, July 22, 2012 4:32 PM
>To: "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx>
>Cc: EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>
>>Jorge,
>>
>>I'd lean towards #1 and keep the top split definition even if just to
>>say it was considered and dropped for various reasons.
>>
>>-Mike
>>
>
>
>>
>>-----Original Message-----
>>From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
>>Sent: 22 July 2012 10:28
>>To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>>
>>Marek,
>>
>>I think I would correct the definitions of Mid- and High-split, as
>>follows:
>>
>>Mid split: an HFC network in which the split between the upstream and
>>downstream occurs between 65 and 100 MHz
>>
>>High split: an HFC network in which the split between the upstream and
>>downstream occurs above 100 MHz
>>
>>I still have some concern about a conflict between the definitions of
>>High-
>>and Top-split since they could overlap. Maybe we could solve it in one
>>of two ways: 1. add something like "the upstream transmission occupies
>>spectrum below the downstream" for low-, mid- and high-split
>>definitions, or 2. Get rid of the top-split altogether since we won't
>>be considering that option (as we discussed in the meeting in San
>>Diego).
>>
>>I wonder what others, especially my MSO/CL colleagues, think.
>>
>>Thanks!
>>Jorge
>>
>>
>>----- Original Message -----
>>From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
>>Sent: Sunday, July 22, 2012 12:14 PM
>>To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
>><STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>>Subject: Re: [802.3_EPOC] Action items for September 2012 meeting
>>
>>Marek,
>>
>>To add to your list, here is a start for the definitions for the
>>various splits, and one additional definition (HFC):
>>
>>HFC: a hybrid fiber-coax cable network, in which fiber is used to
>>transmit analog RF signals (note: this definition excludes the case
>>where we have digital return, but I think that's OK)
>>
>>Low split: an HFC network in which the split between the upstream and
>>downstream occurs below 65 MHz
>>
>>Mid split: an HFC network in which the split between the upstream and
>>downstream occurs below 100 MHz
>>
>>High split: an HFC network in which the split between the upstream and
>>downstream occurs below 200 MHz
>>
>>
>>Top split: an HFC network in which the upstream is placed above the
>>downstream
>>
>>Hope this helps.
>>
>>Jorge
>>
>>
>>
>>-----Original Message-----
>>From: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
>>Reply-To: Marek Hajduczenia <marek.hajduczenia@xxxxxx>
>>Date: Thursday, July 19, 2012 3:48 PM
>>To: EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>>Subject: [802.3_EPOC] Action items for September 2012 meeting
>>
>>>Dear colleagues,
>>>
>>>Following the discussion in the morning, focused on the preparation
>>>for September 2012 meeting, I would like to start discussion on
>>>terminology for EPoC, as attached to this email. What I did so far,
>>>was to go through the contributions discussed so far, to collect the
>>>terms which were used most commonly in presentations and discussions,
>>>with the special focus on terms generating heated discussions
>>>(infamous
>PHY).
>>>The content is colour coded:
>>>
>>>- a term in green indicates that we have already a solid definition in
>>>802.3, which ought to be reused without changes
>>>- a term in yellow indicates a term which is specific to EPoC, and I
>>>felt sufficiently capable to propose the pass at the definition
>>>- a term in red indicates a wording which I collected from one of
>>>contributions, but it requires either further discussion,
>>>clarification or confirmation whether it is needed at all.
>>>
>>>In the first pass through the list, please indicate whether any
>>>critical terms are missing or unnecessary. My intent at this time is
>>>to collect a complete list of terms, before we plunge into producing
>>>missing definitions.
>>>Please keep all discussion on the reflector so that we do not talk
>>>past each other or repeat proposals. I will try to keep the list
>>>updated as frequently as needed.
>>>
>>>Given that definitions are critical for technical discussions on
>>>individual proposals, I'd suggest we complete the phase of collecting
>>>terms by the 28th of July, at which time I will move to generating
>>>individual missing definitions.
>>>
>>>Regards
>>>
>>>Marek
>>>
>>>______________________________________________________________________
>>>_
>>>_
>>>
>>>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
>>
>>_______________________________________________________________________
>>_
>>
>>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
>>
>>_______________________________________________________________________
>>_
>>
>>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
>>
>>_______________________________________________________________________
>>_
>>
>>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
>>
>>_______________________________________________________________________
>>_
>>
>>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
>
>________________________________________________________________________
>
>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
>
>________________________________________________________________________
>
>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
>
>________________________________________________________________________
>
>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

________________________________________________________________________

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

<="" p="">

Robert L. Howald, Ph.D.

Fellow of Technical Staff
Solutions Architecture

Motorola Mobility

407-242-9977

rob.howald@xxxxxxxxxxxx

<="" p="">