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