Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Marek,
Thanks for the message — some good comments. My apologies in advance for a long reply, but I want to make sure I respond to your concerns adequately.
First, I am not necessarily suggesting packet re-ordering to try to flush out FEC codewords, etc; or that I am trying to push PHY awareness into MPCP for this purpose. Instead, what I'm suggesting is simply that the more modems are sharing a common MCS profile (which includes FEC), the more likely that you'll happen to get packets grouped together that happen to use the same FEC, and therefore you have improved odds of being able to use long codewords instead of shortened codewords. You'll still need a shortened last codeword, and I'm quite confident you'll need to use it more than in a system where all modems share the same MCS (which will affect efficiency some), but I believe it won't be a situation where you need a shortened codeword on all packets (and the associated overhead).
This gets back into the main point that, based on the currently available data, we and our members have agreed that the benefits appear to outweigh the negatives (such as the FEC issues or increased complexity), and so we're continuing to develop a solution geared around that proposition. Maybe it will turn out that we can't solve all of these problems in a reasonable manner. But if we can, then I think it benefits everyone if we were to contribute that solution to this process for consideration to be included in the Baseline Proposal.
Also, to be very clear, what I am talking about is taking those ideas that might be developed elsewhere and contributing them to this process for the consideration of this team. In the final analysis, this is a group of (very smart) individuals who are attempting to work together to develop a solution to a specific problem, and any proposal should be considered within the context of that process and following the rules of that process. I am not proposing to do otherwise, nor do I think that people should adopt anything that we bring in simply because it's the "DOCSIS way" (or some other technology's way) -- I believe the proposals should be considered on their own merit and decided upon as such.
At the same time, this is not the only group working to develop a solution to the problem of delivering multi-Gbps data over a coax or HFC network, and given that both the problem and the network involved are more or less the same, it would not be surprising for the same solutions and conclusions arrived at in one group to be applicable to the other. For that matter, I (and many others) believe that in the end, alignment of the PHY layers between different solutions for this same marketplace has the potential to be a tremendous benefit to everyone, including operators (customers) and vendors (producers). Due to that perceived benefit, we have decided to work to try to make that happen. It will most likely require looking at things differently at times on both sides to make it work, as well as a good two-way dialogue (as we all have things to learn from each other), but many of us would definitely like to try.
In the end, this team will need to decide what they believe is best for EPoC, just as we, our members, and our participating vendors will need to make what we believe to be the right choices for DOCSIS. I sincerely hope that they are the same (or at least substantially close), but if not, so be it. However, I'm definitely going to take a shot at it.
Thanks.
Matt
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
Date: Tuesday, October 9, 2012 4:41 AM
To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx<mailto:m.schmitt@xxxxxxxxxxxxx>>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [802.3_EPOC] Questions on varanese_01_0912.pdf
Matt,
Not to beat on the dead horse, but if you plan to “line up groups of packets together and still use long FEC codewords”, this starts to look like a downstream DBA to me, involving additional packet delay to fit into the next right FEC word so that it can be sent downstream in the right moment of time. To me, it seems that this approach would make MAC Control (MPCP in specific) PHY aware, since right now MPCP will have to know when the right FEC word starts and ends, when to start downstream transmission and what specific overhead it will involve. Note also that EPON does not do that right now, so what you’re suggesting moves the project away from the whole “EPON Protocol for Coax” approach the project started with into “let’s do it the DOCSIS way” approach.
While everything is possible, I question how that would fit into the overall framework of things in Ethernet. You would not be adding only downstream scheduler and PHY awareness, but also the need to rapidly change the effective data rate in PHY (from one FEC word to another) which would need to be accommodated by in the MAC Control and configured somehow in PHY so that the idle deletion function removes extra idles (assuming 10G-EPON like mechanism is employed). There are also all the aspects related with burst like transmission in downstream to consider, something that is not trivial to build reliably when we’re talking about synchronizing on a single FEC codeword (no matter how long it is) and then hunting for a new one to come at some undefined time in the future. Unless you’re talking about downstream scheduling, which is a completely new ball game altogether.
In summary, I agree with Ed here. We need much more study in here coming from folks interested in this solution to evaluate all the merits of such a proposal and how it would fit into the Ethernet networking model and specifically, functional separation between MPCP, MAC and PHY. You can do certain things in DOCSIS, since the concept of MAC and PHY is interleaved there into a single large box, while in 802.3, layering is strictly observed. This imposes some constrains on how we can do things here, but also guarantees scalability and reuse of existing designs. Remember that one of the reasons listed for EPoC was tapping the Ethernet ecosystem, something you won’t be able to do if the EPoC design is dramatically different from anything that has been done for Ethernet to date.
Regards
Marek
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Sent: Monday, October 08, 2012 23:49
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Ed,
I agree that there will be issues to work out, and we are actively working through them. However, one point to make clear is that such an approach does not necessarily require the use of a downstream MAP or Gate message — there may be other approaches which mitigate both the latency that results and the need to add new MPCP messages (and the processing involved in generating them). Or even if it does involve such a message, it doesn't necessarily need to be constructed based on packets already received. There are definitely options and that could address some of these issues.
As for the efficiency issue, the expectation is that by having a very limited number of profiles, and with the majority of CNUs most likely being in just a couple of them, you should still generally be able to line up groups of packets together and still use long FEC codewords. There may be somewhat of an efficiency hit due to greater use of shortened codewords, but we believe it can be significantly mitigated.
Many of the other issues you've mentioned are ones we're aware of and looking into solutions for; again, we'll share those as we get them worked out. But we believe they're all solvable, and that we should be able to mitigate the complexity and these issues. As for the issue of how this interfaces to the Ethernet MAC, that's something I'm less familiar with, and that we should explore further.
In the end, I agree that we need to make a complete technical proposal that lays out the answers to these questions, and has backing from a wide array of people. For now, I just want to get the idea out there, and let folks know that this is the current consensus among my members.
Thanks.
Matt
From: "Ed Boyd (Edward)" <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
Reply-To: "Ed (Edward) Boyd" <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
Date: Monday, October 8, 2012 5:26 PM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Hi Jorge,
I agree that more analysis is needed for EPoC. I think that we need to better understand the penalty and if it is even possible without a radically new Ethernet standard. As far as DOCSIS and EPoC having the same PHY, it is a great goal if it can fit with the Ethernet standard and goals. If it has to diverge here, maybe EPoC is a single downstream profile and DOCSIS supports multiple profiles. EPoC will have a simpler lower delay downstream with a fixed data rate pipe that is similar to EPON. DOCSIS could be configured to run in the simple mode or with multiple profiles. It is too early to say now but I would imagine that we will run into many examples of EPoC being a subset of the DOCSIS options.
Take care,
Ed….
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Monday, October 08, 2012 3:10 PM
To: Ed (Edward) Boyd; stds-802-3-epoc@xxxxxxxxxxxxxxxxx<mailto:stds-802-3-epoc@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Ed,
Not trying to answer all your questions and comments, which I think are very good, but to share some thoughts…
We went through this same topic for DOCSIS 3.1, and although the conclusions are likely not all directly applicable in the same way for EPON/EPoC, the plant aspects should be, even in the case of the path characteristics from the OCU-CNU vs that of the CMTS-CM. With respect to those conclusions, we find that the distribution of SNR levels at our entire population of employed CMs, both within individual nodes and across our entire footprint, and when evaluating CMs or just MTAs, varies significantly. This would result on some CNUs being capable of operating at considerably higher modulation orders while others being limited to lower modulation order. So, in an effort to maximize overall system performance for all CNUs, we find that having a small/finite variety of modulation/coding schemes per service group should help significantly.
Hope that explains the rationale for implementing a small/finite number of MCS (rather than just one per SG). And, given our goal of making the D3.1 and EPoC PHYs the same, we would like to explore doing the same in EPoC.
There was some preliminary discussion about this during the meeting in Geneva (see the attached presentation from Andrea), in which data collected at Comcast was presented and the concept of adaptive modulation was introduced. We should expand on the analysis moving forward.
Regards,
Jorge
From: Ed Boyd <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
Reply-To: Ed Boyd <ed.boyd@xxxxxxxxxxxx<mailto:ed.boyd@xxxxxxxxxxxx>>
Date: Monday, October 8, 2012 4:19 PM
To: EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Hi Matt,
I would like to see an analysis on the benefits and the complexity added for the MCS. There was a presentation with quite a few supporters asking for a broadcast downstream because it is simple and provides the lowest delay. From my point of view, I fail to see how multiple profiles will work without a significant change to the EPON/EPoC system and a huge increase in the complexity. I see much longer delay and therefore a penalty to the upstream efficiency (more polling) and CNU cost (more buffering in up and down). I don’t see how limiting the number of profiles helps much. If you have more than 1, you need generate a downstream MAP and that is the start of the trouble. Here are my areas of concern:
1) Downstream Efficiency
To generate the MAP, you need to buffer data and send the MAP in advance. The MAP must have error correction and it should be in a known position so you can recover after losing a frame. How do we handle frame boundaries, MAP location, and symbol boundaries? The long efficient FEC would be replaced with shorter codes or shortened code words. The FEC would be less efficient and not as effective, correct? How do we handle variable frame lengths and the MAP frame location being fixed? It would be inefficient to stop at frame boundaries?
2) Variable Data Rate to the MAC
The downstream data rate will depend on the destination of the frames, their mapping within the symbol blocks, and the FEC code word. I think that there would need to be multiple PHY/MAC interfaces (XGMII) and back pressure signals but this is a guess. I can’t think of another solution since the MAC control couldn’t calculate it as we planned for sub-rating.
3) Downstream Delay
A block interleaver must be used since a convolutional would hold packets between profiles. To do the buffering and sending of the MAP in advance, I think that we would have 2-to-4 interleaver blocks of delay. I’m almost sure that it is 4 blocks. If it is a block interleaver versus convolution, it is twice the delay. If that is the case, the MCS interleaver delay will be 4 to 8 times more. In my example, we had a 250us interleaver delay so this change would be 1ms or 2ms delay.
4) Complexity
The interleaver is a huge amount of memory at 5 Gbps but it will be 4 to 8 times larger with the multiple profiles. There is also the complexity of buffering the packets, calculating the FEC overhead, and then mapping it to the carriers. To help with efficiency penalty for packets to different destinations, some have suggested grouping the packets together by profile. Obviously, this will cause problems with the fixed delay required for the timestamps unless you add a re-ordering buffer on the receiver. A receiver will be handling multiple FEC blocks in parallel since it will be receiving from multiple profiles for multicast and unicast packets.
Thanks,
Ed…
From: Victor Blake [mailto:victorblake@xxxxxxxxxxxxxxx]
Sent: Monday, October 08, 2012 11:27 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Hal,
Is there an assumption being made here that “impairments” will be automatically identified and some algorithm will be followed to determine the mcs(MCSes ?) that will be used ? Might it not be the case that these would be determined in advance by operator’s administrative settings (aka configurations).
Just want to ask because it sounds like an assumption to me (because it may be the case – I’m begging the question here, that an operator may want to elect a specific subset of supported MCSes and then presumably have some level of automation from there.
-Victor
From: Hal Roberts [mailto:Hal.Roberts@xxxxxxxxx]<mailto:[mailto:Hal.Roberts@xxxxxxxxx]>
Sent: Monday, October 08, 2012 1:54 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Matt,
I agree that a number of MCSs should be defined and that a specific set of MCS attributes could consist of a profile, as you propose. The Channel Model should inform the choice of MCSs. To do this, the Channel Model should not be a single set of parameters/impairments but identify a range of values for each impairment, where necessary.
Hal
From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]<mailto:[mailto:m.schmitt@xxxxxxxxxxxxx]>
Sent: Monday, October 08, 2012 12:24 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
As an FYI, if deployed for residential services, especially early on I think that you might have numbers of devices per OLT port on the order of what might be done for a DOCSIS service group, achieved by aggregating a number of OCUs onto a single OLT port. That could easily be on order of 250-500 CNUs per OLT port. Probably less in actuality, but I think we should be prepared for those types of numbers.
Over time, I agree with Jorge and Ed that it will likely get smaller (by disaggregating those OCUs onto different OLT ports), probably on order of 64 CNUs for a single OLT port (give or take). The key, though, is that we need to design the system to handle more than that.
Business services might be closer to the 64-128 number to start, ramping down to smaller numbers over time.
Note that the above is my personal opinion; I have not talked to my members to generate a specific consensus position on that topic.
Marek, as to your point about SNR variance… The problem is that even if there are only 2 devices, while statistically the odds are lower that there's a significant spread in SNR, there's still a chance that they will be spread quite a bit. Additionally, if you're looking at multiple OCUs aggregated to a single OLT port, the odds of significant SNR spread between devices sharing that single OLT port (because they're on different OCUs) is actually quite high.
I believe very strongly that we need to adopt some sort of mechanism in EPoC that allows for different CNUs to operate with different Modulation and Coding Schemes (MCSs). I believe you can get the majority of the benefit with a limited number of "profiles" that CNUs could be grouped into, but I think you will need at least on order of 3-4 of these.
Thanks.
Matt
From: <Salinger>, Jorge Salinger <Jorge_Salinger@xxxxxxxxxxxxxxxxx<mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx>>
Reply-To: Jorge Salinger <Jorge_Salinger@xxxxxxxxxxxxxxxxx<mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx>>
Date: Sunday, October 7, 2012 4:07 PM
To: "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Right, I meant to describe things in the longer term.
Maybe in a nutshell, on could say that networks will be designed in such a way that the number of CNUs/OLT port will be to be similar to the number of ONUs/OLT port, by aggregating several OCUs/OLT port initially as CNU penetration is low, and by splitting OCUs into more OLT ports as the number of CNUs grows. I think his would apply to both resi and business services.
Does that make sense?
Jorge
From: Edwin Mallette <edwin.mallette@xxxxxxxxx<mailto:edwin.mallette@xxxxxxxxx>>
Date: Saturday, October 6, 2012 3:02 PM
To: "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx<mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx>>, EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
In general it makes sense, I think what Jorge describes might be true in time – not sure that's true "day-1." In fact I can easily see a case where we might dabble with aggregating as many CCDNs together to a single 10G-EPON port to efficiently utilize the bidirectional capacity (and efficiently utilize our Capex and Opex spend). In the early days where we have 120MHz or less of downstream bandwidth, I can see attempting to aggregating 10 CCDNs together, as an example, for mostly residential services. As a result you might see a pretty high number of scheduled services (LLIDs.)
Eventually I think we'll trend to having the number of CNUs in a CCDN roughly equivalent to what we could see with ONUs per OLT port (32 or 64) and accordingly we'd see the OCUs per OLT port trend to one or two if that makes sense.
Ed
From: Jorge Salinger <jorge_salinger@xxxxxxxxxxxxxxxxx<mailto:jorge_salinger@xxxxxxxxxxxxxxxxx>>
Reply-To: Jorge Salinger <jorge_salinger@xxxxxxxxxxxxxxxxx<mailto:jorge_salinger@xxxxxxxxxxxxxxxxx>>
Date: Saturday, October 6, 2012 12:24 AM
To: <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Personally, I think that for the use case of residential services, there would be few OCUs/OLT port, yielding an effective number of CNUs/OLT port that is similar as the number of ONUs/OLT port. For business services, since the subscriber density is lower, there would be multiple OCUs/OLT port, and even in that case the number of CNUs/OLT port would be lower than for residential services. Does this make sense?
JD,
Ed,
Does what I describe make sense to you?
Thanks!
Jorge
From: Marek Hajduczenia <marek.hajduczenia@xxxxxxxxx<mailto:marek.hajduczenia@xxxxxxxxx>>
Date: Friday, October 5, 2012 6:12 PM
To: "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx<mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx>>, EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: RE: [802.3_EPOC] Questions on varanese_01_0912.pdf
Jorge,
Makes sense. Have you given a thought to bandwidth available per CNU in the case of “hundreds of CNUs per ONU” ? That seems that a single 10G OLT port might be shared by several thousands CNUs, leaving bandwidth per CNU less than attractive.
Just trying to see what the target scenario might be and what number of CNUs to expected subtended to a single OLT port
Marek
From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Friday, October 05, 2012 22:57
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
I wanted to share some thoughts on this…
I think that there are two deployment scenarios and two use cases that MSOs are considering. One of the deployment scenarios is where the OCU is deployed close/next to the node and the EPoC signals traverse amplifiers, and the second where the OCU is deployed past the amplifier. The two use cases are business and residential services.
For the use case of residential services, in the first deployment scenario there could be hundreds of CNUs per ONU, and in the second there would be far fewer CNUs/OCU. For the use case of business services, in either of the deployment scenarios there would be far fewer CNUs per ONU.
Does this make sense?
Thanks!
Jorge
From: Marek Hajduczenia <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
Reply-To: Marek Hajduczenia <marek.hajduczenia@xxxxxx<mailto:marek.hajduczenia@xxxxxx>>
Date: Friday, September 28, 2012 5:47 AM
To: EPoC Task Force <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>>
Subject: Re: [802.3_EPOC] Questions on varanese_01_0912.pdf
Thank you Andrea,
Please see inline
Marek
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxx]<mailto:[mailto:marek.hajduczenia@xxxxxx]>
Sent: Friday, September 28, 2012 10:29
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: [802.3_EPOC] Questions on varanese_01_0912.pdf
Dear colleagues,
Here are some questions on the varanese_01_0912.pdf presentation which did not get sufficient time for discussion. I’d appreciate if they were answered via reflector so that everybody benefits from these clarifications:
- How many taps have been examined in total in this study? I do not care much about names, types but rather to see what the sample size we are looking at and whether it is representative of a large network as a whole rather than a single CMT port or not.
[AG] I think it is mentioned in the slides, we have 140 subscriber (CNU) ports for the model, we considered all of them in the analysis. As you can see from the curves, since this is a model and small variability have not been included, SNR curves overlap when users are attached to same last splitter – in reality, the CDF is more continuous like shown in the measured valued, rather than step-wise. Does that answer your question?
[mh0928] This begs a question then. Is this a number of CNUs that you’d consider typical? What I am trying to understand whether the scenario that was presented is the worst-case, best case or average (what can be expected in majority of deployments)? Would it be possible for an operator to use more tailored service groups to optimize them for SNR performance and to avoid complicating the design of devices, allowing for more optimized performance, rather than complicating the design of active devices?
- What is the most probably SNR distribution for a much smaller population of CNUs connects to a single CLT port? I assume that you will see some difference in SNR but it is not very likely to be as high as it was presented at the meeting for the whole measured population of taps and ports.
[AG] That may be the case, depends on how the few users are distributed in the plant. However, the question is whether this would be representative of a realistic plant – measurements are over population of ~240 modems, so it seemed to us that 140 (already smaller) was in the correct ballpark. Do you see any use case for much smaller plants, we could include in the analysis?
[mh0928] This is something that operators should speak to. However, when I look at the OLT driven deployment model with several CLTs deployed in field, I’d not expect each CLT to be connected to 150+ CNUs. That would easily reach thousands of CNUs visible to a single OLT, which brings the available bandwidth down drastically, while burning a lot of bandwidth on scheduling overhead. I’d like to understand the trade-off here, that is all.
Please consider presenting more focused study for the next meeting, focusing on a number of drop sections to show what is expected to be seen on a single CLT port. While I am not against adaptive loading on per CLT port, I do not believe that this contribution has sufficient footing to justify adaptive loading on per CNU basis.
[AG] What we shown is one CLT port and 140 CNU ports attached for the modeled plant – for measured values, each plant is one node and ~240 CM all attached to the same coax distribution tree (Comcast may provide more clarifications in case) – we can make it more clear and improve in the next steps.
Regards
Marek Hajduczenia, PhD
ZTE Portugal
Technology Strategy Department
Edifício Amoreiras Plaza,
Rua Carlos Alberto da Mota Pinto, nr. 9 - 6 A,
1070-374 Lisbon, Portugal
Office: +351 213 700 090
Fax: + 351 213 813 349
Mobile: +351 961 121 851 (Portugal)
________________________________
<="" p="">
________________________________
<="" p="">
________________________________
________________________________
<="" p="">
________________________________
<="" 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