Re: Can someone explain why cable suffers on upload?
 

I see ADSL as the "same" amount of fibre as VM, only that the Coax part of the network uses less lossy cables, and amplifiers etc to prevent signal loss

With FTTC, the fibre goes far closer than with Cable, but as Seph and Qasi have already pointed out, the two mediums cannot be compared

Re: Can someone explain why cable suffers on upload?
 

Totally agree. In addition, it was the need to provide backwards compatibility with the broadcast TV standards that drove DOCSIS down it's limited path.

Cable is still limited by it's need to co-exist with the TV spectrum which is also made worse by the increase in HD channels.

If cable has a future then you could see the amplifiers in the streets side cabinets being replaced with VDSL style equipment and fibre being pulled to those cabinets. The coax from cabinet would then be dedicated to a subscriber but have a much higher bandwidth than even the best twisted pair.

Re: Can someone explain why cable suffers on upload?
 

That would be infeasible for some areas where the coax from the cabinet is shared with one drop for a whole block or even street. Upgrading that to dedicated coax would require the same amount of work as a complete FTTP system which would render it pretty pointless.

Frankly dedicated coax isn't required. The sheer capacity of it means even if you divided it four ways with dedicated channels per subscriber you'd still get higher speeds than an average VDSL line (ideal coax has about 6Gbps capacity last I recall, increasing to 10Gbps with DOCSIS 3.1). "Fibre deep" architectures are the future though, they just don't have to go that deep.

Re: Can someone explain why cable suffers on upload?
 

Presumably there is a future standard that moves the TV streams off the traditional frequencies and pushes them across the IP layer instead, YouView style? That would open up an obscene amount of spectrum for raw broadband transit.

Re: Can someone explain why cable suffers on upload?
 

I don't see how it's,"Bodged" like you say? The CATV system always had a return path and was designed for it. The Plain Old Telephone,(POTS) was just that when invented but has now evolved into providing an Internet service, Data, ect

Re: Can someone explain why cable suffers on upload?
 

Perhaps he means the return paths wasn't intended to he heavily used for mass data or non symmetric, like most data only systems are.

Re: Can someone explain why cable suffers on upload?
 

A house I lived in that was built ~1985 had cable - it was pure analogue direct to standard TVs with no return path at all. The cable was very thick maybe 10 or 12cm over the insulation as I recall. The area was cabled by NTL later but after I'd moved - sfaik they ignored all the old cable system and put in new.

Re: Can someone explain why cable suffers on upload?
 

Yet again we’re in danger of digressing off topic but without deliberately appearing to criticise or even ridicule your “presumption” I am genuinely interested on what basis you predicate this “obscene amount of spectrum for raw broadband transit” by future migration to TVoIP?

Currently both TV and BB(Data) are combined prior to (e)QAM and injected in a set frequency plan that is limited by the overall spectrum (5-1002MHz) currently dictated by DOCSIS3(.0)RFI infrastructure.

It’s currently therefore somewhat irrelevant whether you feeding TV,VOIP etc (or DATA) on downstream because they all are restricted by DOCSIS 144byte frame encapsulating a MPEG2/4 packet that either contains a raw (MPEG2/4) media stream or IP?

In fact using a DOCSIS for TVoIP just adds an additional protocol layer as far as I can see?
As unless you migrate to a higher compression algorithm (MPEG6 and /or QAM1024/2048 etc) in order to increase bandwidth utilisation then the alternative as you suggest means effectively discarding the DOCSIS wrapper overhead altogether ala BT21CN Infinity with Ethernet IP last mile?

Now I would suggest therefore that your presumption naively over trivialises the rather significant problems of logistics of how you get from A to B while maintaining backwards compatibility over the current physical RF infrastructure?
Clearly once again I am suffering from a senile comprehension problem and missed some enlightenment that is apparently embodied in your presumption?

If you accept the bandwidth is constrained by DOCSIS mac layer then removing this means a total redesign of the headend! Thats an awful lot of CAPEX outlay on replacing existing CMTS and also upgrades at client end.
Plugging in a NIC/ETHERNET is one thing but disposing of existing CM/SH is quite a challenge in itself, let alone visiting 4Million households given the need to replace a F connector with RJ11 Ethernet port not easily dismissing the fact that the underlying physics will still limit the segment length of Ethernet to only a few hundred metres without deploying Frame Relay,ATM, SONET intervening solutions?.

Now QAS has already alluded to a more practical roadmap by referring to DOCSIS3.1
That not only gives some more symmetry by introducing OFDM which primarily introduces 200MHz either at low,mid or top end splits for upstream but also set’s the foundation for expanding the current 5-1002MHz spectrum into future 1.4MHz-2.4MHz expansion commensurate with Satellite!
All that can be done while maintaining a practical migration of backwards compatibility without disproportionate investment in Head-end and existing client CPE….except….

Even that doesn’t necessarily highlight the difficulties VM face with their current RF Plant? The homologation of legacy franchises means a diverse range of line extender/street cab amps are proliferated through various area infrastructures.
Remember that a significant amount of RF plant was initially poached (off-the-shelf) from our US cousins a couple of decades ago and these Bidi Amps were centred on on DOCSIS/RFI of 5-55MHz/108MHz-860MHz in line with 6MHz NTSC as opposed to current (euroDOCSIS) split of 5-65/85MHz and 88MHz-1002MHz split of 8MHz bandwidths of PAL/SECAM for Europe etc!

VM stated a year or so ago that as part of their network upgrades 38,000 street cabs in the uk would need checking/refurbishing? It we employ some simple maths on that figure then published VM Company reports state there are 4.9Million TV/BB subscribers in the UK. This equates to approx 128 active customers per cab. However the initial flood cabling was designed as Homes Passed Per Node.

So if I walk down my road I observe that the street cabs are placed/spaced approx equivalent to 48 homes per cab and my feed from a primary street cab only has 24tap board, 1 main amp and 3 secondary amps. That infers there are 3 secondary “passive” cabs potentially supplying a total of circa 170 for my cable segment. Of course that deployment is factored on a street of semi detached 3/4 bed houses with an approx 15m frontage with shared drive.
The population demographics thus vary considerably with other parts of say Brighton with Victorian/Edwardian 3 story town houses that have subsequently in the decades now been converted to flats/apartments. Thus what was once classified as a single home passed with something like 14 rooms has now become at least 3 x 4 room separate domiciles! Consequently what was originally calculated 15yrs years ago as a static 25%-40% take-up rate HPPN has trebled since then with no complimentary civil engineering to offset ducting capacity and street furniture limitations!
Further more, obviously there is more than one type of DOCSIS/RFI topology deployed (to support QAS’s post) such that not all RF actives are soley contained within street cabs UK wide but can also be contained within cable pits as well!

Now we have the complexity of trying to extrapolate VM’s 38000 street cab figure to equate potential upgrade of number of cascaded amp chains that could either require minimal replugging of diplex filters or even replacing totally!
Even if these details weren’t commercially sensitive VM is not going to disclose any further useful detail because as can be seen above it will inevitably be area dependent anyway!
We can only speculate on what proportion of 38000 is upgrading street cabs because of tap board congestion and/or standardising amps to euroDOCSIS latest (or hopefully DOCSIS3.1) standard?

Also remember that every DOCSIS/HFC MSO worldwide is inexorably being driven towards a N+1 customer driven topology target before eventually looking towards a FTTP solution whether it be DPON or something radically different and VM haven’t even embodied a MTA second order product yet that is already an option with current NetGear VMDG485 product/chipset options!

So concluding on the initial opening question just how far is this future TVoIP premise of yours? I can’t realistically see this within 10yrs yet let alone 5? DOCSIS still has plenty of latent expansion potential with DOCSIS3.1/x even before another major point release?!!!

As I said earlier it's a genuine question...... enquiring minds really would like to know...... ;)

Re: Can someone explain why cable suffers on upload?
 

Jesus christ mate it was just an idea? Calm down.

Re: Can someone explain why cable suffers on upload?
 

Don't get the Horse going - and don't call him "Jesus", Jesus!

Re: Can someone explain why cable suffers on upload?
 

Now that's just what I was thinking but the horse beat me to it.... ;)

Oh and on my earlier post should anybody read it the coax was 10-12mm obviously not cm as my sausage fingers dictated.

Re: Can someone explain why cable suffers on upload?
 

I'd assumed it was a reference to how 'evolved' systems often don't provide an optimal solution to a problem.

i.e

Coaxial cable TV systems were adapted to also carry data (and digital TV) but this lead to a system which was heavily asymmetric. In addition, keeping optimal contention ratios in this system can be very costly (re-segmentation).

Analogue POTS were adapted to carry both analogue telephony and data but were limited by line length and quality constraints.

In my view, this form of evolution is often driven by commercial constraints but also the short term view held by most companies today.

Re: Can someone explain why cable suffers on upload?
 

Thanks qasdfdsaq and Eeeps, that's what I meant- hence the "little" rather than "no" need for a return-path (see kwikbreaks version of the "fat pipe") :)

Re: Can someone explain why cable suffers on upload?
 

To be fair he's not entirely far off. The implication is TV uses a large, and static amount of bandwidth on every cable, even for those many customers who don't have TV. By delivering only the TV channels that are being watched (essentially making all channels "on demand") a huge amount of capacity could be freed up.

Say 75 channels are in use for TV delivery, vs. somewhere around 16 for broadband, no single user is ever going to be watching 75 channels (plus radio) at the same time! So if the point was ever reached that all the current passive splitter cabinets ended up having mini-CMTS' put in them, with dedicated coax to each subscriber, then the vast majority of that coax's capacity would be going to waste delivering traffic that is literally being ignored when it could be used for faster broadband delivery.

Even if we never got close to one node per customer, a node with 50 subs on it are still unlikely to ever get close to consuming all 75 TV channels simultaneously, meaning most of the capacity is *still* going to waste when compared to, e.g. an efficient IP-multicast system.

Personally I'd like for VM to eradicate all broadcast TV channels and re-purpose the spectrum for broadband, because I don't watch TV and want faster internet. But even that wouldn't solve the issue of crippled upstream, since almost all the upstream is already being used for internet services anyway; in fact it'd even further skew the upload/download ratios on offer.

Re: Can someone explain why cable suffers on upload?
 

To me is no doubt IPTV replacing cable tv would help cable greatly on frequency capacity.

The problem is a few things I think.

First is ofcom, I think they differientate between broadcast tv and iptv so I think they would have an issue with it. After that for IPTV to be trusted it has to be reliable, no glitches due to eg. buffering that I think for someone like VM to pull off would be extremely diffilcult, after that is CPE replacements, network redesign etc.