Re: [STDS-802-3-EPOC] Resoruce block presentation in todays phy sub-task call
Eugene,
That is precisely what I was trying to communicate (and probably failed
terribly).
The MPCP gating process remains as it is, given the scope of the project,
which implies the use of grants as they are constructed right now. Any
mapping from time into frequency domain must be transparent and even if it
uses RBs, it is something that is not exposed to MAC in any fashion.
However, it then begs the question as to what relationship between grant and
RB is, how mapping is performed, and whether we need this level of
complexity at all, i.e., what it gives us at the end of the day.
Were we to move to a complete redesign of EPoC MPCP, then we could grant in
RBs. However, we are where we are today
Marek
-----Original Message-----
From: Dai, Eugene (CCI-Atlanta) [mailto:Eugene.Dai@xxxxxxx]
Sent: Tuesday, July 02, 2013 4:16 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" make sense for an OFDMA system, such as wireless. However,
for EPON MAC that supposes to be EPoC MAC with minimum change, RB may not be
as useful. In another word, RB is only useful if MAC aware it. But link GATE
to RB (redesign MPCP) goes too far, if this gate is open, then a lot of
other things will follow, we may not able to close the gate, and will end up
building an OFDMA PON. It may not a bad idea (OFDMA PON), but it is not in
our scope. If EPoC MAC does not aware RB then the usefulness of RB is very
limited, at most it could be used for management purpose via OAM for
example.
Eugene
________________________________________
From: Marek Hajduczenia [marek.hajduczenia@xxxxxx]
Sent: Tuesday, July 02, 2013 4:37 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
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>
mailto:sanjay.goswami@xxxxxxxxxxxx]
Sent: Tuesday, July 02, 2013 12:17 AM
To: Marek Hajduczenia; <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,
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>
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>
mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, June 28, 2013 3:21 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
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%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
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%3cmailto:duane.remein@xxxxxxxxxx>
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>
mailto:Eugene.Dai@xxxxxxx]
Sent: Friday, June 28, 2013 3:38 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
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%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
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%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,
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%3cmailto:duane.remein@xxxxxxxxxx>
duane.remein@xxxxxxxxxx<mailto: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%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
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%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
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%3cmailto:du
ane.remein@xxxxxxxxxx%3cmailto:duane.remein@xxxxxxxxxx>
duane.remein@xxxxxxxxxx<mailto:duane.remein@xxxxxxxxxx<mailto:duane.remein@h
uawei.com%3cmailto: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%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC
@LISTSERV.IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<m
ailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxx
EE.ORG>>
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%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC
@LISTSERV.IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<m
ailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxx
EE.ORG>>
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%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC
@LISTSERV.IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<m
ailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxx
EE.ORG>>
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%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC
@LISTSERV.IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<m
ailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxx
EE.ORG>>
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%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC
@LISTSERV.IEEE.ORG>
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<m
ailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx%3cmailto:STDS-802-3-EPOC@xxxxxxxxxxx
EE.ORG>>
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
________________________________
________________________________________________________________________
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