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