[AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted

Mark ZZZ Smith markzzzsmith at yahoo.com.au
Mon Sep 15 11:35:08 EST 2014



>________________________________
> From: Paul Brooks <pbrooks-ausnog at layer10.com.au>
>To: ausnog at lists.ausnog.net; jeremy at visser.name 
>Sent: Friday, 12 September 2014, 18:03
>Subject: Re: [AusNOG] Strange ADSL problem - troubleshooting / diagnosis advice wanted
> 
>
>
>On 10/09/2014 3:28 PM, Jeremy Visser wrote:
>
>On 10/09/14 14:39, Paul Brooks wrote: 
>>ADSL2+ is supposed to re-train to a new sync rate seamlessly without
packet drops, whereas the older ADSL1 had to effectively drop the
line, re-sync, generate a new bitfield table per tone to cope with
changes to background noise and cross-talk that caused a need for a
re-sync. 
>>I thought that was a feature of VDSL2, not ADSL2+. I’d be interested to see a source on that as happy to be wrong.
>Its actually goes back to ADSL2:
>
>G.992.5 Jan 2009  ADSL2+
>
>https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.5-200901-I!!ZPF-E&type=items
>
>
>Page 'ii':
>This Recommendation defines several optional capabilities and
    features:
>– transport of STM and/or ATM and/or Packets;
>– transport of a network timing reference;
>– multiple latency paths;
>– multiple frame bearers;
>– short initialization procedure;
>– dynamic rate repartitioning;
>– seamless rate adaptation;


So I've looked a bit into SRA in the past. I think theoretically it is a good idea. From what I recall it was an option on Ericsson DSLAMs on a per-line basis. 

I think the trouble with it is that as above shows it is optional, and on the few modems I looked at that support it, it had to be manually enabled. Getting non-technical customers to do that successfully on a large scale would be impossible. 

Secondly, I don't think the return for the time an ISP spends enabling it is high enough. Drop outs do annoy customers, however it also prompts them to contact the helpdesk, and that seems to be the way ISPs are in the habit of reactively identifying line faults. My understanding of SRA is that it would hide all or most dropouts from a "reactive support" ISP.

(I'd like to see ISPs proactively identifying line faults by either using their sessions database to identify lines/customers with lots of dropouts, or alternatively, start proactively walking through their DSLAM network looking for excessive dropouts etc. or dramatic changes in line characteristics. You'd either identify customers who don't realise they have a fault or save time of customers who do and need to find time to call the helpdesk. In either case you'd increase your customers' satisfaction with your service, and also be able to use those proactive fault calls to fill in quiet times in the helpdesk.)  


>- extended impulse noise protection;
>- erasure decoding;
>- virtual noise;
>- impulse noise monitor.
>"
>
>G.992.3 April 2009 ADSL2:
>
>https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.992.3-200904-I!!ZPF-E&type=items
>
>Page 'ii':
>"This Recommendation defines several optional capabilities and
    features:
>• transport of STM and/or ATM and/or Packets;
>• transport of a network timing reference;
>• multiple latency paths;
>• multiple frame bearers;
>• short initialization procedure;
>• dynamic rate repartitioning;
>• seamless rate adaptation;
>• extended impulse noise protection;
>• erasure decoding;
>• virtual noise;
>• impulse noise monitor."
>
>"Relative to Recommendation ITU-T G.992.1, the following PMD-related
    features have been added:
>• New line diagnostics procedures available for both successful and
    unsuccessful initialization
>scenarios, loop characterization and trouble-shooting.
>• Enhanced on-line reconfiguration capabilities including bitswaps and seamless rate adaptation.
>• Optional short initialization sequence for recovery from errors or fast resumption of operation.
>• Optional seamless rate adaptation with line rate changes during showtime."
>
>Clause 8.16:
>"8.16 On-line reconfiguration of the PMD function
>On-line reconfiguration of the PMD function is intended to allow
    changes in the control parameters
>without interruption of service and without errors (i.e., bitswap,
    dynamic rate repartitioning and
>seamless rate adaptation)."
>
>VDSL2 doesn't really add much functionality to ADSL2 other than the
    vastly expanded frequency range.
>
>cheers...
>
>
>
>
>
>Paul.
>
>
>
>
>
>
>_______________________________________________
>AusNOG mailing list
>AusNOG at lists.ausnog.net
>http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>


More information about the AusNOG mailing list