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

Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy sub-task call



Sanjay-
I would have a problem with your definition of a "profile" in the 802.3 context. In 802 that term has traditionally been used to describe either a subset of one standard or a superset of several.

In a subset:
A "profile" is a set of options within a standard that define a particular implementation.
In a superset of several standards
A "profile" is a set of standards and the options within those standard that define a particular implementation.

JTC 1 had an effort for awhile that seems to have sort of died (but it seemed like a really good idea at the time) to standardize profiles. They set up an entire system to handle such a document which they called an "ISP" (International Standardized Profile)
REF: http://jtc1sc32.org/acronym_summary.html

Perhaps you could work within the above to meet your needs with something like: A "profile" is a set of options within a standard that define the interoperability requirements of a particular implementation.

Geoff Thompson


On 7/2/13 10:52 PM, Sanjay Goswami wrote:
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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
    <mailto: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
    <mailto: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
        <mailto: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 <mailto: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
        <mailto: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
        <mailto: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
        <mailto: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 <mailto: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
            <mailto: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
            <mailto: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
            <mailto: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
            <mailto: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]

            Sent: Friday, 28 June 2013 9:31 PM

            To: 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

            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.

            duane.remein@xxxxxxxxxx <mailto:duane.remein@xxxxxxxxxx>

            Director, Access R&D

            919 418 4741

            Raleigh, NC

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

            From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]

            Sent: Friday, June 28, 2013 3:38 PM

            To: 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

            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
            <mailto:marek.hajduczenia@xxxxxx>]

            Sent: Friday, June 28, 2013 10:48 AM

            To: 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

            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]

            Sent: Friday, 28 June 2013 3:22 PM

            To: 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,

            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.

            duane.remein@xxxxxxxxxx <mailto:duane.remein@xxxxxxxxxx>

            Director, Access R&D

            919 418 4741

            Raleigh, NC

            From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]

            Sent: Friday, June 28, 2013 5:42 AM

            To: Duane Remein; 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

            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]

            Sent: Thursday, 27 June 2013 10:38 PM

            To: 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

            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.

            duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx
            <mailto:duane.remein@xxxxxxxxxx%3cmailto:duane.remein@xxxxxxxxxx>>

            Director, Access R&D

            919 418 4741

            Raleigh, NC

            From: Avi Kliger [mailto:akliger@xxxxxxxxxxxx]

            Sent: Thursday, June 27, 2013 1:48 AM

            To:

            STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
            <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto: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]

            Sent: Thursday, June 27, 2013 1:46 AM

            To:

            STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
            <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto: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]

            Sent: Wednesday, 26 June 2013 11:24 PM

            To:

            STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
            <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto: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]

            Sent: Wednesday, June 26, 2013 2:45 PM

            To:

            STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
            <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto: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]

            Sent: Wednesday, 26 June 2013 9:05 PM

            To:

            STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
            <mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto: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