| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Steve,
I think we are stuck on what the term ‘bursty’ means. TDD in the downstream will not be able to be continuously on so that there are time periods in the channel for upstream bursts, what you called the downstream time window. The on/off rate will generally be on a fixed schedule (although the duty cycle will be configurable). I believe Ed is calling the ON time transmissions during the window ‘bursts’ which is a reasonable term for them.
While it is true that the TDD downstream is continuous during the downstream window it is still bursting on and off.
Thanks,
Hal
From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 8:49 PM
Ed,
The FDD upstream is likely bursty (like in EPON) where it sends data according to a schedule, if data is present to send. I would expect the TDD upstream to be the same.
The FDD downstream will likely send symbol all the time (like in EPON) even if data is not present. The TDD downstream may send symbols all the time, during the downstream time window, so it is more like FDD downstream than TDD upstream. I am not saying that is the only way to do it, but it may work much better than a bursty PHY, so I do not think we can say a priori that the TDD downstream is just like the FDD upstream. So I think we need to not force ourselves into that conclusion at this point.
Of course, we do not yet have an FDD downstream or upstream design, so even calling one “bursty” might be a bit premature. It will probably come out that way, but I do not think we can say it is guaranteed.
I do not think anyone is talking about adding another project. Actually, without specifying FDD and TDD the study group has not even specified that the solution is FDD so that is not clear unless we state it.
I think it is a good idea to be specific in our plans and state both FDD and TDD modes.
Regards,
Steve
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 6:19 PM
To: Shellhammer, Steve; Salinger, Jorge; 'stds-802-3-epoc@xxxxxxxxxxxxxxxxx'; 'chano.gomez@xxxxxxxxxx'
Subject: RE: [802.3_EPOC] Latest objectives proposal
Steve,
I’m not sure that I understand. The downstream will send a burst when it transmits in the slots used by the upstream. It can’t be continuous. A burst start and end is determined by the transmitting station (not the receiving station). In this case, the upstream and downstream are bursty. What is the difference to the PHYs?
I agree that there is interest in TDD solutions but there are also many TDD solutions in other standards groups. The question is whether adding another project to support TDD is needed for the EPoC task force. Is it feasible, is it compatible, and does it have a distinct identity. If it is a new PHY and a new MAC, it clearly is another project. If we can start by saying that the PHY is the same, it shows more hope than earlier ideas of 2 different PHYs.
Thanks,
Ed…
From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 5:16 PM
To: Ed (Edward) Boyd; Salinger, Jorge; 'stds-802-3-epoc@xxxxxxxxxxxxxxxxx'; 'chano.gomez@xxxxxxxxxx'
Subject: RE: [802.3_EPOC] Latest objectives proposal
Ed,
It is not clear to me that the downstream in TDD is bursty. That does not seem very efficient. I would think it would be a stream of symbols during the downstream time window. It is a little like the FDD downstream, but maybe a little different. That I why I prefer the term “mode” so that people know it is not a “big” change, but also maybe not identical.
I think there is support in the study group for both FDD and TDD, and I think it is important for the study group to make that clear to the working group in the objectives.
Regards,
Steve
From: Ed (Edward) Boyd [mailto:ed.boyd@xxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 5:06 PM
To: Salinger, Jorge; Shellhammer, Steve; 'stds-802-3-epoc@xxxxxxxxxxxxxxxxx'; 'chano.gomez@xxxxxxxxxx'
Subject: RE: [802.3_EPOC] Latest objectives proposal
Hi Jorge,
In my mind, we will have a burst PHY defined for the upstream operation of EPoC or EPON. I think that downstream of a half duplex system would be the same burst PHY. I don’t even see the need for the FDD or TDD description that Steve proposed. In EPON, the data detector in the PHY determines when to enable the laser and send data upstream. The half duplex PHY would enable the same function in the downstream. I agree that we are defining a PHY for Coax that supports burst mode and continuous mode of operation. I think that could cover our objectives for the PHY.
I think that all of the changes needed for half duplex (TDD) are in the MAC and MAC Control. This is traditionally where duplex is handled in 802.3.
Hope that helps,
Ed….
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 4:51 PM
To: 'sshellha@xxxxxxxxxxxx'; 'stds-802-3-epoc@xxxxxxxxxxxxxxxxx'; Ed (Edward) Boyd; 'chano.gomez@xxxxxxxxxx'
Subject: Re: [802.3_EPOC] Latest objectives proposal
Steve,
Thanks. Yes, that would work for me.
Ed,
Chano,
Would that work for you?
Thanks!
Jorge
From: Shellhammer, Steve [mailto:sshellha@xxxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 07:33 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Latest objectives proposal
Chano and Jorge,
The terminology we have started to use is a PHY with both FDD and TDD modes. That conveys the idea that FDD and TDD are very similar but they may have some differences.
Maybe that wording would work in the objectives.
--------------
Kevin,
Nice job in stimulating email traffic. J Will we be discussing the objectives on Friday?
Regards,
Steve
From: Gomez Chano (LQNA MED) [mailto:Chano.Gomez@xxxxxxxxxx]
Sent: Tuesday, May 08, 2012 4:01 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Latest objectives proposal
Hi Jorge, thanks for the clarification.
I tend to agree that supporting both FDD and TDD would be a good justification for having two PHY - although hopefully both PHYs would have enough commonalities that silicon vendors could easily implement both in the same chip without much duplication.
Chano
On May 8, 2012, at 3:17 PM, Salinger, Jorge wrote:
As one of the advocates for this objective, I'd like to clarify that the goal we are after is to have TDD system operation for passive coax plant and FDD for active coax plant. This is what might drive the need for 2 PHYs, and not the spectrum range.
In other words, we would like to operate a TDD system in passive coax plant networks above and below 1 GHz, or operate an FDD system in active coax plant networks above and below 1 GHz.
As for the question of why to have both TDD and FDD systems, the answer is that TDD systems have the benefit of not fixing the US:DS ratio (which is desirable flexibility), but active cable systems would not support a TDD system and would have to operate on a FDD system.
In summary, it is desirable to operate TDD everywhere in the spectrum, but since that is not possible to do so in active coax plants then the best solution is to have both TDD and FDD systems. FDD systems can be used in passive and active coax plants, but the lowest common denominator of just having an FDD system is undesirable because we are slowly but surely driving to passive networks everywhere over time.
If having TDD and FDD systems can be achieved with a single PHY, then that's great. If not, then let's have one PHY for TDD and one for FDD.
Hope this is clear and makes sense.
Thanks!
Jorge
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, May 08, 2012 05:45 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Latest objectives proposal
In that case, “Specify at most two PHYs … “ should be simpler to parse … I guess nobody will specify 0 PHYs …
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: 08 May 2012 22:29
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Marek,
I agree there is no worry about more than two PHYs. So here is a modified proposal.
Specify at least one PHY and two PHYs if necessary to support subscriber access networks using the EPON protocol and operating on point--‐to--‐multipoint RF distribution plants comprised of all--‐coaxial cable or hybrid fiber/coaxial media.
If others think the current wording will not be confusing when going to IEEE for SG approval then I am not adamant about it. I know the EPoC group has this understanding, it is outside readers who may find the current text indicating a preference for more than one PHY.
Hal
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, May 08, 2012 4:20 PM
To: Hal Roberts; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Never before was there a problem with such an “understanding”. I would not be averse to the change you propose, but see it as unnecessary nonetheless. We have spoken until now about two cable plant types (at most) so it would be a clear indication for two PHYs (at most)
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: 08 May 2012 22:10
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
If you think “at least one PHY” must remain, then we should have more than an ‘understanding’ that the industry is driving towards a single PHY solution. The way it reads now, one might think that if we define one PHY we meet our objectives and if we define multiple PHYs we exceed our objectives.
The following wording does not preclude two PHYs but doesn’t require the reader to have ‘an understanding’ that the industry is driving to a single PHY solution.
Specify at least one PHY and at most two PHYs if necessary to support subscriber access networks using the EPON protocol and operating on point--‐to--‐multipoint RF distribution plants comprised of all--‐coaxial cable or hybrid fiber/coaxial media, with a goal to limit
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, May 08, 2012 3:50 PM
To: Hal Roberts; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Neither are my preferred choices of words – I would certainly like to have them nailed down further.
However, given the discussion we had at the last meeting, I think leaving the option of doing two PHYs is OK as long as we understand that the industry is driving towards a single PHY solution. Put it in other words. If we write down “one PHY” and a year from now we figure out we need two, we need at least to modify objectives, which is not as easy as it seems. If we write down “at least one PHY” right now and one year from now we figure out we can do everything with a single PHY, we are good to go.
From the safety perspective, I think it is prudent to leave it as it is and work diligently to make sure no more than one PHY is needed.
Marek
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: 08 May 2012 21:36
To: Marek Hajduczenia; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Marek,
Define “minimal augmentation to MPCP” for me please.
There are plenty of undefined terms in the document, I don’t see why the term “flexibility” has a higher burden than other terms.
We will define flexibility more precisely when we know what the channel models are. If you are still confused what flexibility means it means variable “QAM constellation density, FEC, guard interval and frame structure”.
We should eliminate the opening for multiple PHYs until someone can show that we can’t do what other standards 802.16e, LTE have done with more difficult channel model variations.
Hal
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Tuesday, May 08, 2012 3:25 PM
To: Hal Roberts; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Hal,
Define “enough flexibility” for me, please.
Marek
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: 08 May 2012 21:21
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Latest objectives proposal
Charaf,
Yes, I have heard the same and would submit the same reasoning I sent out before, “If a single PHY can operate over the wildly varying conditions found in wireless transmission (i.e. LTE or Wi-Fi with huge swings in signal strength, interference, multipath etc) surely a single PHY should suffice within the more controlled cable environment”.
Obviously the PHY parameters would have to be adjustable, i.e. QAM constellation density, FEC, guard interval and others. This is what is done in LTE and Wi-Fi.
What shouldn’t need to change is subcarrier spacing, symbol duration and other more difficult to change parameters.
As I sent out before, “The burden of proof should be on demonstrating the need for two PHYs.”
Having said all of that, it is much more likely that two PHYs might be considered to work well with TDD vs FDD.
With FDD the downstream would be a continuous signal (with idle patterns when no data is sent) just like DOCSIS which allows easy synchronization to the downlink and eliminates the need for preambles at the beginning of a burst (i.e. there are no bursts in the downstream). Whereas with TDD we have to define downstream frames and upstream frames along with guard times.
LTE solves this with two types of frame structures, Type 1 for FDD and Type 2 for TDD (see below).
As long as we consider two frame structures as defined under one single PHY then we still need only one PHY.
“The burden of proof should be on demonstrating the need for two PHYs.”
Therefore I would suggest a variation on Gomez’ suggestion:
"Specify one PHY to support subscriber access networks using the EPON protocol and operating on point-‐to-‐multipoint RF distribution plants comprised of all-‐coaxial cable or hybrid fiber/coaxial media, with enough flexibility to operate both below and above 1GHz and in TDD or FDD duplexing modes."
Thanks,
Hal
<image001.png>
From: Charaf HANNA [mailto:charaf.hanna@xxxxxx]
Sent: Tuesday, May 08, 2012 2:37 PM
To: Hal Roberts; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: RE: [802.3_EPOC] Latest objectives proposal
Gentlemen,
From the 5 Criteria discussion, it seems to me the reference to more than 1 PHY has to do with passive versus active coax plants rather than below versus above 1 GHz.
Charaf
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]
Sent: Tuesday, May 08, 2012 2:03 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Latest objectives proposal
Kevin,
If a single PHY can operate over the wildly varying conditions found in wireless transmission (i.e. LTE or Wi-Fi with huge swings in signal strength, interference, multipath etc) surely a single PHY should suffice within the more controlled cable environment.
Hal
From: Noll, Kevin [mailto:kevin.noll@xxxxxxxxxxx]
Sent: Tuesday, May 08, 2012 1:53 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] Latest objectives proposal
There is some concern that operating in the lower bands is significantly different than operating above 1GHz, thus the PHY might need to be different. The reason for "at least one" is not to have equal and competing specifications, but to allow for two implementations that address multiple sets of coaxial conditions.
If the same goal can be attained by a single configurable PHY, then we would probably be okay with that.
--kan--
From: "Gomez Chano (LQNA MED)" <Chano.Gomez@xxxxxxxxxx>
To: Kevin Noll <kevin.noll@xxxxxxxxxxx>
Cc: "<STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Latest objectives proposal
Hi,
I did not attend the last conference calls, but I have been following progress through the reflector. I have a question about the wording in Objective 1, which is now
"Specify at least one PHY to support subscriber access […]"
while previous proposal was:
"Specify a PHY to support subscriber access networks […] "
Can somebody clarify the rationale for the new wording, which seems to "almost" encourage the group to develop more than one PHY? We have all seen other IEEE groups that quickly yielded to the temptation of adopting multiple PHYs as soon as they realized that having the group agree on a single PHY was hard work. I would hate to see the same thing happening in EPoC, as this would cause market fragmentation and slow down adoption.
The objective should be "one PHY". Only if the group finds at a later stage a very good reason to develop more than one PHY then that option should be considered.
Just to be clear, for me it would be OK if the PHY for downstream and upstream channels have different parameters. As long as vendors do not have to face the decision of choosing between multiple and equally valid PHY options when implementing their products, that would still qualify as "one PHY" for me.
Best Regards
Chano Gómez
Lantiq North America
On May 8, 2012, at 9:38 AM, Noll, Kevin wrote:
<epoc_objectives_for_may_2012.pdf>
<="" p="">
<="" p="">
<="" p="">
<="" p="">
<="" p="">
<="" p="">
<="" p="">