| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Except that Jorge seems to have walked away from the same meeting with a different understanding of what was agreed to on the call. Unfortunately, I was not able to attend this morning's call, so I can't add my interpretation of the decision; however, having seen the "numberless" one written out, I would argue very strongly for the simpler "numbers included" version that Jorge wrote up below (which is what he thought was agreed to). Thanks. Matt From: Marek Hajduczenia <marek.hajduczenia@xxxxxx> Date: Monday, August 13, 2012 11:48 AM To: Matthew Schmitt <m.schmitt@xxxxxxxxxxxxx>, "STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx" <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx> Subject: RE: [802.3_EPOC] Definitions of sub, mid, high and top splits Matt,
We had a discussion on this on the call today and decision was taken. I do not want to revert what was agreed on the call yet again.
I fixed the name of the mid split per suggestion
Marek From: Matthew Schmitt [mailto:m.schmitt@xxxxxxxxxxxxx]
Marek, Unfortunately, I find the "numberless" definitions more confusing. I think this is a case where using specific numbers does not impact our flexibility in any
way, because these are merely numbers and not limitations or performance requirements. So I would vote to use Jorge's language. BTW, it's "mid split" not "middle split". Thanks. Matt From:
Marek Hajduczenia <marek.hajduczenia@xxxxxx> Let’s see if the proposed changes work – I used values as examples only, keeping definitions clean from any numbers.
Let me know if this works.
Also, items marked in yellow highlight need more attention. If I do not hear any proposals for their definitions, I will remove them in the next
version – I’d rather prune than keep items we do not need. Marek From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Jorge,
The impression that I had was that we were to exclude specific numbers from these definitions … making them more flexible.
Marek From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
All, I think that after much discussion on the terms low, mid, high and top split, we ended up with an agreement on what to define and
what to leave out. Based on my interpretation, I modified the definitions as included below. Hopefully I did not miss any suggestions, but please correct me if I am wrong. Regards, Jorge Low split: also known as sub-split, an HFC network requiring a diplex filter, in which the upstream is transported in spectrum
below the downstream, up to 42 MHz in 6 MHz channel plan systems and below 65 MHz in 8 MHz channel plan systems Mid split: also known as extended sub-split, an HFC network requiring a diplex filter, in which the upstream is transported in
spectrum below the downstream, up to 108 MHz High split: an HFC network requiring a diplex filter, in which the upstream is transported in spectrum below the downstream, above
108 MHz Top split: an HFC network requiring a triplex filter in which there are two upstream bands, one transported in spectrum below the
downstream with the cross-over as per either the low, mid or high splits defined above, and another transported in spectrum above the downstream. From:
Matt Schmitt <m.schmitt@xxxxxxxxxxxxx> Tom, I completely agree that what we are trying to do here is just define terms, not define new splits. I wonder if that's been part of the problem resulting in a
surprising amount of discussion. :-) The splits themselves, if they need to be codified, should be dealt with in the spec, not in a table of definitions. If we can all agree on that, I think we should be able to wrap this up fairly easily. Also, to clarify, I am talking about defining ranges for the definitions of what constitutes a sub, mid, or high split, which is what we (almost) agreed upon
until the discussion kicked back up again. By that definition — and this is the one I'm arguing for as well — your example below of an upstream band that goes up to 168 MHz would be defined as a "high split" option, because it's above 108 MHz but remains
below the forward path. So from a definition POV I think we can cover all of those possibilities. Now, as to what we define in the spec for the capabilities of EPoC devices — how high of an upstream must be supported, the degree of flexibility in operator
with less than that total amount — that's an entirely different story. It's an issue we'll need to tackle for sure, although not one we need to deal with just now. I hope that clarifies things. Thanks! Matt
|