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



Victor-
I would like to reinforce your point with some history.
One of the most significant features of Ethernet over its history has been its ability to work without management.

There was no standards-based management at all for Ethernet from 1980 until 1992.

Back in olden times it was widely expected that Ethernet would be replaced by (various PHY flavors of) FDDI when the world needed to move up from 10 Mbps to 100 Mbps. It didn't happen largely because SMT (the management piece of FDDI) was needed to get it started and was such a pain. Instead we just took the FDDI Phys and stuck them under Ethernet for the 100BASE-T standard.

The reason that Auto-Negotiation is such a success is that it works and works well without intervention.

It would be a major disservice to everyone, vendor, provider and customer alike to go outside this 802.3 tradition.

Geoff Thompson

On 7/2/13 6:31 AM, Victor Blake wrote:

Avi, et. al.

Agreed, the term is appropriate -- widely used in similarly functioning wireless systems. Also agreed that it (quoting Avi) "should not be visible to upper layers" . I would go a step further to suggest "must not be visible to upper layers". One of the principal improvements of this technology is the automation of these functions in the lower layers in order to avoid the problem of a slow to change, manual provisioned spectrum management. Since the goal is automation, IEEE Ethernet on top, then it belongs automated and hidden in lower layers.

-Victor

*From:* Avi Kliger [mailto:akliger@xxxxxxxxxxxx]
*Sent:* Tuesday, July 02, 2013 7:46 AM
*To:* 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]

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

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

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

________________________________________________________________________

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