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



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

    a) Are we redefining  these terms?

    b) 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="">


------------------------------------------------------------------------

________________________________________________________________________

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