>> would still like to get to grips with a deeper technical understanding, if possible, of what protol messages are sent and by what during a re-sync event.
>> I hope Kitz might add another section to her remarkably clear and consise treatise on DSL technology for the masses.
I'm afraid I cant do an in-depth on it, despite having tried to find information about this in the past myself, there doesnt seem to be anything that describes it, even in technical type journals. This may partially be down to certain events such as the DLM process being patented and certain info not being disclosed and also the fact that different routers can behave differently.
I wont put anything up on the main site until Im pretty sure of my facts, but as some of you know I do quite often theorise on the forums as long as the info isn't going to be taken as gospel.
There wont be any protocols as such.... and a loss of sync event event (not to be confused with a LoS - Loss of Signal) will likely be down to a couple of different factors:
1) Bitswapping.With the rate adaptive products used on LLU and Maxdsl, then
bit swapping will/can have an effect on what goes on. The bit swapping process on rADSL plays a big part in keeping your line connected. If the SNR in a particular channel gets too low, bit swapping enables the line to remain connected by shifting things around so that the line can cope with a certain amount of noise. Problem with bitswapping is that once a router has marked a channel as unavailable then until you do a full resync those channels may not be usable again and the only way round getting a higher sync again is to perform a full resync.
When there are insufficient usable sub channels to carry the amount of bits needed for your sync speed and there's insufficient SNR 'overhead' to swap the bits around, then your line will have to drop sync.
I'm ignoring
Seamless Rate Adaption at this point because currently afaik there's only UKO in the UK that uses this technology.
2) Error Rate and Alarm StateThis is where my knowledge gets flaky as there's not much info.... but here goes...
We are probably all familiar with CRC/HEC/FEC type errors we often see on our routers, but these are just the start of things. Although CRC/HECs are errors, there's also many different states that are recorded but not necessarily displayed by all routers. Its these error - or more correctly - alarm states that can cause a line to resync. Theres several different types of alarm states, a serious one is a LoS.. but there's other serious ones such as a UAS. When the router enters into an alarm state it will monitor the type of error for 'x' amount of time and if there are 'y' amount of incidents during that time frame then the router will attempt a resync. However if during the 'x' period, no further error state occur over 'z' period of time, then the line will recover.
'x', 'y' & 'z' could vary from different router manufacturers, but I shouldn't imagine it wouldn't be by much.
The alarm states are described on my page -
Router Line Stats - Errors.
Have a look for eg at
LoF and LoS.
If you have a bit of time to read the different error states you may be able to track a process through those.
----------
OK you now have what I know... so try piecing it all together and you will see that the Alarm States and Error Rates also plays a big part of this process, then combine this info with bit-swapping and see if you can come to any conclusion about what goes on.
Its probably easier to stick with what we do know and say resync will occur when theres insufficient SNR for bitswapping to occur and/or when the error rate gets too high... as thats all that most people normally need to know.
