Uverse

AT&T's U-Verse service delivers television (IPTV), telephone (VOIP), and Internet service. The most common installations are categorized as FTTN (Fiber to the Node). A node, also known as a VRAD, is installed in a neighborhood. Transmission from the node to the home is via VDSL2 technology (nominally up to 50 Mb/s) over existing telephone copper connections. Maximum bandwidth available varies according to distance from the node and cable quality, but service is generally said to be available up to 3500 feet from the node.

Previously, we had been Comcast subscribers. Comcast's service is a conventional CATV system, with Internet and VOIP services based on the DOCSIS v2 standard. We only used Comcast's TV service, however, since we were subcribers to AT&T's ADSL service for Internet access, and AT&T "POTS" for voice.

U-verse is much more challenging than cable in an Amateur Radio environment, where RF transmissions up to 1.5 kW are often seen in the HF frequency ranges that U-verse's VDSL2 signaling requires (0 - 8.4 MHz). These web pages describe my ongoing work to maximize compatibility between U-Verse and ham radio.

U-verse Evaluation at AA6E

These pages are to record our Uverse installation and to document compatibility experiments with Uverse and Amateur Radio operations. The data here obviously only apply to our particular circumstances. Your mileage may vary! (Items may appear to be somewhat randomly ordered. This is a combination of a technical log and some explanation of how the system is supposed to work.)

Previous block diagram

AT&T U-Verse "triple play" installation at AA6E, 12/24/2010 - Block Diagram

The distance from the NID (box outside house) to the RG is about 30-35 ft, from the RG to STB is about 20-25 ft.

Activity Log

January, 2012 Maybe I spoke too soon? After months of relatively stable operation, winter has arrived, and we are seeing fairly frequent errors. Most are correctable, but a number are uncorrectable leading to Link Retrains in the worst case. Here is the UVRT error table (now using version 1.9.0.0) that greeted me when I started up this evening:

I must add that my transmitter has been off the air during these error sessions! Are we seeing some other ingress of interference? Has the line just degraded due to an intermittent connection, weather problems, or ...?

December, 2011 Year-end Update. As I passed the 1-year anniversary of getting the U-Verse service, it is useful to note how things are doing now. The Amateur Radio interference issues haven't changed much, but fortunately (?) I have not been active enough on the air (especially on 80 and 40 meters) to cause much trouble with our TV operation. What has changed is that AT&T's lines seem to have improved. We now get many fewer serious data errors and have had no unplanned resyncs for a long time now -- until the last few days when we've had some 20 link retrain events! We also had several days of unavailability after Hurricane / Tropical Storm Irene. (Our power was out, and the UPS battery threatened to fade, so I shut it down for much of the time. The U-Verse signal seemed to continue without interruption.)

The following display from UV Realtime shows an interesting development. We are now getting a maximum downstream bit rate over 32 Mb/s. Even though we are still working with a "19/2" profile (19Mb/s down, 2 Mb/s up), the software indicates that we ought to be able to step up to 25/2. This may be worth pursuing, although we wouldn't need the extra HD channel or extra Internet capability that would result.

May 5, 2011

The U-Verse retrain activity (with no ham radio work) has improved rather dramatically (see graph below). It appears that the network has really stabilized considerably. We just don't see the 2-minute outages that occur with a RG retrain. Now, that could be a real network improvement, or it could be an "accidentally" favorable RG training setting that just happens to be a lot better than anything it achieved before. I lean toward the former option, because the loss of sync and large error bursts we were seeing several times a day just don't seem to be there anymore.

None of this makes us feel good about Amateur Radio compatibility -- because I was off the air for all of the "good" time during the past several weeks. Yesterday (5/4), I tested 40 M transmission at all power levels. I could seriously upset my home CO detector (very loud!), but the RG sailed through. (I wasn't checking STB performance, so there could have been issues there.) On 80 M, the story was pretty similar to what we had before. I could apparently operate CW (key down for 30 s) at 100 W, and the RG would adapt. At higher power levels, 300 - 700 W, I could indeed kill the RG session.

One new wrinkle is that when the RG recovered its balance after my last 80 M test, it did not train very well. See following

The problem (if I understand correctly) is that the downstream "bits" (VDSL2 channels) are over-committed, i.e. > 100% are in use. This may signify an unstable configuration. If everybody wanted to use all the bits they were "entitled" to (TV, Internet, VOIP) the session would not work. Perhaps it would force a retrain. "Bits in use" is generally rather under 100% - maybe 90%. I have seen this behavior before, but retrains came often enough that it did not last long. Now, with our newly "stabilized" line (??), it's not clear how long the over-commitment will last. I suppose the worst that will happen is a forced retrain at some point, after which we should be back in the normal range -- if there is no RF interference.

I did a manual RG reset on 5/5 to see how much better it could get if it "forgot" about the bad RFI episode it had had. The result: Max Rate now 25,581 Kbps download. Line capacity 72.2%,. Max bits 6,164, Reserve bits 582, bits in use 90.6%. Much better.

March 28, 2011

We seem to have a pattern of multiple days with no RG retrain events, then a burst of activity for several days. But as of 4/25/2011, we have had over four weeks of no retraining! (There was little Amateur Radio activity in this period.) Here are some graphical results: (updated: 5/4/2011)

It appears that the latest tech visit may have improved our connection's reliability. There are longer periods of sanity between error burst days. There has been no apparent effect on sensitivity to Amateur Radio transmissions, however. (These do not appear on this graph.)

I checked the distribution of RG retrain events vs hour of day and day of week. This is definitely not a random distribution. There is a strong peak at 8 - 9 AM, but no clear dependence on day of week. Is this due to techs out there doing work on the lines? The error rate does not seem to correlate with hours of peak TV or Internet usage.

March 4, 2011

We had a period of 8 days (2/24 - 3/3) with no RG retrains. Remarkable! But I had not been on the air with Amateur Radio in that time. Time to get back on 40 and 80 meters. A little bit of operating on 40 M CW at up to 100 W showed no RG errors. (I was not checking the STB, but historically the STB has frozen my TV service with 40 M activity.) On 80 M, we are back to our old habits. As the operating power is increased, the FEC error rate increases. When I operate at "full" (100W) power, there are many FEC and CRC errors, and eventually the RG loses sync and enters its 2 minute retrain cycle. (This is not really full power. Full power here is 1,000W!)

After last night's activity was done, the RG seems to be back to its old habits. There have been at least 3 retrain events since ham transmissions ceased.

The appearance is that the RG trys to "anneal" its frequency channel assignments and may get itself into a sweet spot in the absence of local RF interference. It can go for many days without serious upset (only occasional small bursts of correctable FEC errors) until it is upset by strong local RF activity.

Feb. 27, 2011

We called for a tech visit to deal with our persistent retraining RG and marginal line conditions. The U-Verse tech arrived and very kindly agreed with my assessment that we have problems with our outside lines. He called in for an "I&R" truck (Installation and Repair, I think, a completely different organization within AT&T). The I&R fellow (also very friendly and interested in my issues) came on Feb. 15. He spent several hours working on our lines, interrupting service 6 or 8 times as (I imagine) he worked his way along our line back to the fiber node (VRAD). When he departed, I did a manual RG reset, and indeed the line quality looked better (higher max. bit rate). But over the course of a week, the RG trained itself back to a condition roughly the same as before. (Right now, we have 29,716 kbps downstream and 22.8 dB attenuation.)

Furthermore, we continue to get sporadic RG retrains about as often as before, averaging 2-3 per day. Sometimes, like the present moment, we may get 3 or 4 days without retrains, but then we go back to the old pattern.

Question to myself: Is there any correlation between retrain / error rates and my own TV/Internet operation? I shouldn't think so.

Feb. 4, 2011

Using an SRL QS1R SDR receiver to check upstream transmission. An current probe next to the RG-6 coax to/from NID provided a clear but weak spectrum. No strong peaks seen.

Jan. 20, 2011

After worrying a lot about ham radio ingress to the VDSL2 line, I have a different problem now (in addition to others, not instead!): On low-power 40 M transmission (WSPR mode at 10 W), I see almost complete breakup of TV. VDSL2 (RG) is not upset -- there are no FEC errors and no loss of sync. Phone and Internet service are fine, also. This appears to be an STB issue. It is an unfortunate fact that my HPNA coax runs parallel to the RG-213 antenna feed, about a foot away on the outside of the house. The HPNA run is now about 40 feet, after we reorganized our TV installation. I tried shortening the HPNA run temporarily. It helped, but only a little. I moved my Westel HPNA filter from the RG end to the STB end, and that did help. Now I can run reliably at 10 W, but not at 100 W. The STB seems surprisingly sensitive at 7038 +/- kHz. (I have tried filtering the power line and have eliminated the HDMI and HDTV as culprits.)

Jan. 4, 2011

After December tech visit, we may have quieted some of my ham-related ingress problems by switching to coax from the NID to the RG and by adding a few more filters. 40 meters is looking pretty good. However, the Max. Rate is down to 28,809 Kbs (at the moment) from over 32,000 Kbs before. That means we are running with 80.6% "bits in use" (19/2 profile). This is too high to allow for much channel reassignment. In particular, we may not be able to adapt well to 80 meter transmissions.

Even without any local ham activity (i.e., when the local op is watching TV!), we are getting service drop-outs (of the 2-minute recovery type). This are really unacceptable outages for "triple-play" service. They kill all Internet, telephone, and TV service, after all.

I expect to call in the trouble to AT&T again soon.

How VDSL2 (U-Verse) sends data

U-Verse uses VDSL2 standard signaling -- modulating each of up to 1972 carriers ("tones") with a certain portion of the digital data stream. The number of bits (bits/sample?) that are carried by each carrier tone is called the "bit loading".

You can monitor the bit loading through the RG's webserver (Settings -> Diagnostics -> DSL) i.e., http://192.168.1.254/xslt?PAGE=C_5_3 via standard IP address. A more useful display is available with the either of the monitor programs U-Verse Realtime or VDSL Monitor. (See software list below.)

More on Bit Loading

Bit loading is the term for the number of useful data bits (per sample?) that are assigned to a particular VDSL2 frequency channel. See Dynamic Spectrum Management and Scholarpedia article on Digital Subscriber Line.

Our U-Verse connection uses ITU G.993.2 protocol, Profile 8c, Plan 998 (according to U-Verse Realtime). This corresponds to the following parameters (Wikipedia):

U-Verse channel assignments, as reported by VDSL Monitor program, 12/2/2010, (Tones in use reflect the limitations of my particular connection.)

Adapting to RF Interference

The Residential Gateway adapts to narrowband interference by reassigning data bits from the affected frequency (tone) channels to unused channels elsewhere in the spectrum. This works as long as there are enough spare channels available.

Experimental results and interpretation: Bitloading adapting to transmissions

Jan-Feb 2011 Performance Info

These data mainly are about the "Loss of Sync" (LoS) events, as experienced first-hand (while I was online or viewing TV) or through the RG's Training History log, as seen through VDSL Monitor software. The log data is cleared when we do a major reset or power cycle operation. In some cases, LoS events will be missed. The true outages will happen more often than reflected here.

N.B. None of these LoS events were caused by local Amateur Radio activity! (AA6E was off the air.)

Jan., 2011
(skip in monitoring)
Jan 25: (mon. started 1100 EST) LoS 1331.  [1400-1600 local Amateur transmission tests. causing some LoS.] Monitoring continues afterward.
Jan 26: no problems (big snowfall)
Jan 27: no problems
Jan 28: no problems
Feb. 1: no problems for 7 days!
Feb. 2: power cycled several times checking possible RFI to Amateur 80 M band receiver.  LoS 1911 (after tests completed)
Feb. 3: LoS 0956 1410 1727
Feb. 4: LoS 1424  (then some RFI tests) LoS 2333
Feb. 5: LoS 0000 0041 1001 1057 1224 (manual reset 1332 to clear high FEC condition)

These data may suggest that the RG can get itself into a "good" state where LoS events may not occur for a week or more. (There are still FEC bursts that are not recorded here.) When the RG is reset (losing training history), it may take multiple days LoS (& retraining) cycles for it to find the "good" state again. (This is just a suggestion, because it is equally possible that something changed outside the house to give a relatively good week of data.)

I have seen a number of times when the RG retrains itself into a "bad" (high FEC state). This will persist for a long time -- hours at least.

Oct-Dec 2010 Performance Info

• Training_History_2010_12_19 from VDSL Monitor showing last week of retraining events. Not all of these caused loss of RG sync, but we are seeing 1 or 2 resync events per day -- with no local ham radio activity or any other notable electrical activity.

I'm not sure if "resync" is the correct term. I am referring to the RG losing connectivity for 1-2 minutes with flashing red "service" light.

• VDSL data of 11/30/2010 as gathered by U-Verse Realtime application.

• VDSL data of 10/7/2010

Bad RG State

On Feb. 5, 2011, we saw a condition that has appeared before a number of times. The RG suffers an LoS event -- loss of sync, causing a retrain. After the RG comes back on line, the FEC error rate is high and relatively stable, whereas the FEC error rate before was very low or zero. This state will persist indefinitely until the next retrain that generally cures the problem. We see high FEC but no CRC errors. User-level services (TV, Internet, VOIP) do not seem to be affected by this condition. See Bad RG State Data.

RF Compatibility Measurements log. (2010)

"Breaking news" about this project and other ham activities may be available at blog.aa6e.net. This site is meant to provide a cumulative database of the evaluation work at AA6E. Please return periodically for new data.

U-Verse Technical Software

I have found these programs to be very helpful.

• U-Verse Realtime. Available at http://www.uverserealtime.com/ (Windows)

This program gives great displays of current statistics, bit loading, STB usage, DVR usage, etc. It can operate as a limited web server, also.

• VDSL Monitor 2Wire 3800HGV-x. This is available at http://adslm.dohrenburg.net/download/download.php . (Windows)

This program displays basic statistics numerically, but its value for me is its "chart recorder" mode of displaying error counts as a function of time (over last ~2.5 hours). It can also upload results to an FTP server.