|
|
This chapter covers basic system operation and the performance metrics captured as a result of system operation in a Digital Off-Hook (DOH) configuration. Understanding performance statistics becomes easier if you understand the process that the Cisco 6100 goes through to establish connections.
When a connection request is initiated by a Cisco 675 or 605, the ATU-R modem sends an ADSL start tone through the remote POTS splitter across the subscriber loop and into the Central Office (CO) POTS splitter. The CO POTS splitter routes the start tone sequence to that subscriber's line interface module (LIM) port. Each subscriber loop is hardwired to a specific POTS module port, and subsequently to a specific LIM port. The LIM notifies the LIM controller in the same chassis that one of its ports is requesting connection to an ATU-C modem.
The LIM controller signals the system controller (SC) in the multiplexer chassis (MC) that an ATU-C modem connection is requested. Provided that a modem is available in the logical pool, the SC, via a round robin distribution algorithm, decides which ATU-C modem within the logical pool will handle the connection. The SC then instructs the LIM controller to cross-connect the LIM port to the selected ATU-C port.
The LIM port (subscriber line with ATU-R modem at the far end) and the designated ATU-C modem are then connected, a successful connection counter is incremented for the logical pool, the line, and the subscriber ID. Now, the modem training sequence begins.
The Carrierless AM/PM (CAP) rate-adaptive ADSL (RADSL) transceivers used in Cisco's ATU-Cs and ATU-Rs are capable of training at a number of different discrete settings within each of four baud rates. Because the upstream and downstream data paths are transmitted in different frequencies, they train independently.
Cisco's CAP RADSL implementation supports a number of ADSL training options that can be used to control subscriber traffic. The following background information provides an overview of the training process.
In general, ADSL transceivers seek an upstream and downstream data rate that can be maintained as long as the amount of line noise does not cause a bit error rate (BER) in excess of 1x10-7. Line noise is a function of reach and disturbers. As reach and/or noise in the loop increases, upstream and downstream payload rates decrease. Also, the thinner the copper wire, the more susceptible it is to noise. As line noise is not constant, a certain amount of line noise fluctuation is tolerated without affecting the trained rates. This fluctuation is known as noise margin. Noise margin must be supplied to the transceivers when using the multi-band method of training (multi-band is discussed further below).
Because upstream and downstream payloads are transmitted in different frequency ranges, the two payload rates are established independently. Layer 2 protocol data units (PDUs) are encoded into Layer 1 (ADSL) transmission frequencies using baud rates (also known as symbol rates) and constellations. Different baud rates are used to achieve different payload rates. CAP RADSL transceivers support one baud rate for establishing upstream payload rate - 136 Kbaud, and three baud rates for establishing downstream payload rate: 340, 680, and 952 Kbaud. These baud rates enable CAP RADSL implementations to support downstream payload rates ranging from 7168 Kbps to 640 Kbps, and upstream data rates ranging from 1088 Kbps to 91 Kbps.
Because the user can change the noise margins for a subscriber line, a line which was training before may not train at the new margin. Therefore, a warning is issued to alert the user to use caution when changing the margin.
Cisco recommends that the margin be set for 6 dB upstream and 3 dB downstream to provide performance similar to the pre 2.2 Cisco 6100 releases. The default values for margin in ViewRunner for HP OpenView are 6dB upstream and 3dB downstream.
Valid CAP RADSL constellations are 256UC, 256, 128, 64, 32, 16, 8, and 8ER. Note that the 128, 32, 8, and 8 extended range (ER) constellations are not supported with downstream baud rates of 952 or 680. Because of this, some upstream/downstream payload combinations cannot be achieved. The following table shows valid upstream and downstream payload combinations used in the initial releases of Cisco's 6100 and 675 products:
| UPSTREAM | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
| Baud | 136 | 136 | 136 | 136 | 136 | 136 | 136 | 136 |
|
|
| Const | 256UC | 256 | 128 | 64 | 32 | 16 | 8 | 8ER |
| Baud | Const | Payload | 1088 | 952 | 816 | 680 | 544 | 408 | 272 | 91 |
| 952 | 256UC | 7168 | X | X |
| X |
| X |
|
|
D | 952 | 256 | 6272 | X | X |
| X |
| X |
|
|
O | 952 | 64 | 4480 | X | X |
| X |
| X |
|
|
W | 952 | 16 | 2688 | X | X |
| X |
| X |
|
|
N | 680 | 256UC | 5120 | X | X |
| X |
| X |
|
|
S | 680 | 256 | 4480 | X | X |
| X |
| X |
|
|
T | 680 | 64 | 3200 | X | X |
| X |
| X |
|
|
R | 680 | 16 | 1920 | X | X |
| X |
| X |
|
|
E | 340 | 256UC | 2560 | X | X | X | X | X | X | X | X |
A | 340 | 256 | 2240 | X | X | X | X | X | X | X | X |
M | 340 | 128 | 1920 | X | X | X | X | X | X | X | X |
| 340 | 64 | 1600 | X | X | X | X | X | X | X | X |
| 340 | 32 | 1280 | X | X | X | X | X | X | X | X |
| 340 | 16 | 960 | X | X | X | X | X | X | X | X |
| 340 | 8 | 640 | X | X | X | X | X | X | X | X |
| 136 | 256UC | 1024 | X | X | X | X | X | X | X |
|
| 136 | 256 | 896 | X | X | X | X | X | X | X |
|
| 136 | 128 | 768 | X | X | X | X | X | X | X |
|
| 136 | 64 | 640 | X | X | X | X | X | X | X |
|
| 136 | 32 | 512 | X | X | X | X | X | X | X |
|
| 136 | 16 | 384 | X | X | X | X | X | X | X |
|
| 136 | 8 | 256 | X | X | X | X | X | X | X |
|
Note the following with respect to the table above:
The 680-Kbaud with a 256 constellation entry has been selected as the Cisco 6100/675 default for achieving this payload rate, as it supports a slightly better reach based on 24 ISDN near-end cross-talk (NEXT) disturbers.
The 340-Kbaud with a 128 constellation entry has been selected as the Cisco 6100/675 default for achieving this payload rate, as it has the advantage of being compatible with any of upstream data rate selections. The 680-Kbaud option is limited to 1088, 952, 680 or 408 kbps upstream payloads.
Given that the service provider is unlikely to be concerned with the technicalities of selecting a similar data rate setting through two different baud rates, the following table simplifies the selection process slightly. The data within this table illustrates valid rate combinations for upstream and downstream rates.
| Upstream Rate | |||||||||
|---|---|---|---|---|---|---|---|---|---|
Downstream |
|
|
|
|
|
|
|
|
|
Rate |
| 1088 |
|
|
|
|
|
|
|
kbps | 952 |
|
|
|
|
|
|
|
|
kbps | 816 |
|
|
|
|
|
|
|
|
kbps | 680 |
|
|
|
|
|
|
|
|
kbps | 544 |
|
|
|
|
|
|
|
|
kbps | 408 |
|
|
|
|
|
|
|
|
kbps | 272 |
|
|
|
|
|
|
|
|
kbps | 91 |
|
|
|
|
|
|
|
|
kbps |
|
|
|
|
|
|
|
|
|
7168 kbps |
| X | X |
| X |
| X |
|
|
6272 kbps |
| X | X |
| X |
| X |
|
|
5120 kbps |
| X | X |
| X |
| X |
|
|
4480 kbps |
| X | X |
| X |
| X |
|
|
3200 kbps |
| X | X |
| X |
| X |
|
|
2688 kbps |
| X | X |
| X |
| X |
|
|
2560 kbps |
| X | X | X | X | X | X | X | X |
2240 kbps |
| X | X | X | X | X | X | X | X |
1920 kbps |
| X | X | X | X | X | X | X | X |
1600 kbps |
| X | X | X | X | X | X | X | X |
1280 kbps |
| X | X | X | X | X | X | X | X |
1024 kbps |
| X | X | X | X | X | X | X |
|
960 kbps |
| X | X | X | X | X | X | X | X |
896 kbps |
| X | X | X | X | X | X | X |
|
768 kbps |
| X | X | X | X | X | X | X |
|
640 kbps |
| X | X | X | X | X | X | X |
|
512 kbps |
| X | X | X | X | X | X | X |
|
384 kbps |
| X | X | X | X | X | X | X |
|
256 kbps |
| X | X | X | X | X | X | X |
|
|
|
|
|
|
|
|
|
|
|
Legend: |
|
|
|
|
|
|
|
|
|
Invalid |
|
|
|
|
|
|
|
|
|
Valid |
| X |
|
|
|
|
|
|
|
The actual training procedure is a function of transceiver-controlled parameter exchange and algorithms designed by Cisco to place parameters around valid data rate selections from the above table.
The following rules apply to the training sequence:
With the above rules in place, the ATU-C has complete control over upstream and downstream data rate selection. Valid upstream and downstream data rate combinations are selected from within the ViewRunner for HP OpenView management interface and communicated to the ATU-C per the following procedure:
In a subsequent product release, Cisco's QuickDial will be supported. With QuickDial, this train sequence only occurs once per subscriber (barring unusual changes in loop characteristics). After the initial train sequence, training coefficients are stored in the SC, enabling subsequent trains to occur rapidly.
This section includes information related to receive signal quality, receiver gain, and transmit power where it applies to noise margins on the Cisco 6100s. Each of these trained line attributes is displayed in ViewRunner in the ATU-C Module Properties > Status dialog.
The Cisco 6100 operator can now change the noise margin (upstream and downstream) for each subscriber line. The following window shows the ATU-C Module Properties window for a session in progress. The various train parameters are identified here.

Receive signal quality (SQ) is a measure of the signal quality of the upstream channel (from ATU-R, in the case, the Cisco 675). It is represented in units of dB.
This value is used to estimate the bit error rate (BER) or signal-to-noise ratio (SNR) margin of the received data. It takes into account the total signal-to-interference ratio (SIR), where the interference includes background noise, cross-talk, residual inter-symbol interference, residual echo from the neighboring upstream or downstream, and distortion.
For 7 Kft loops, it is fairly common to observe receive SQ of 37-44 dB, with average interference and a 6 dB noise margin setting. For 10 Kft loops, an SQ range of 32-35 dB would be common. As loop length increases, the SQ will decrease. Long loops (12-15 Kft) or loops that have bridge taps could have an SQ in the dB range of the low 30s. Very long loops (+ 15 Kft) can even train with an SQ as low as 20 dB @ dB margin. If noise margin is reduced to zero, even longer loops could train with an SQ of as low as 12 dB.
The above data is provided as a perspective on likely observed SQs. Stating explicit valid SQ ranges for a given loop reach is, however, not particularly valuable. The number and variety of interferers, wiring (outside plant and in-home), etc. creates so many different scenarios that specific data is not always helpful if trying to institute, for example, a corrective action by moving a pair to a different binder group as a remedy.
Note also that one of the great values of RADSL is that it removes the need for the operator to figure out these values for optimum performance. So, they are presented to primarily as an indicator that the trained loop is exhibiting expected characteristics, rather than necessarily for troubleshooting purposes. For a given training session, it should be remembered that if RADSL cannot overcome loop characteristics such that even the lowest upstream/downstream data rates are not supportable, these layer 1 attributes will not be displayed anyway.
It is also important to understand the SQ is not a function of the data rates. In fact the opposite is true. Data rates are a function of the SQ. For a given requested upstream/downstream data rate combination (as selected in ViewRunner), if the transceivers cannot maintain the data rates to a 10-7 BER (with a 6 dB noise margin insertion), then the transceivers will seek the next lowest data rate combination where the BER can be preserved.
ViewRunner for HP OpenView allows the operator to configure a noise margin. This is valuable if, for example, a subscriber requests 7.168 Mbps x 1.088 Mbps, but the loop quality is not sufficient to hold the BER to less than or equal to 10-7, the subscriber's RADSL train could perhaps settle to 6.272 Mbps x 1.088 Mbps. In this scenario it could be that interference is causing the downstream channel to have just enough noise to where the 7.168 Mbps data rate cannot quite be achieved with the 6 dB margin hit. Reducing the noise margin (that the transceivers must take into account for determining the best data rates to lock into) to 3 dB might, however enable the full 7 x 1 service to be provided.
Receiver gain is a measure of loop attenuation over the entire CAP RADSL frequency spectrum. The ATU-C has an algorithm that enables it to boost receiver gain such that attenuation can be corrected for proper support of a given receive data rate.
The ATU-C algorithm attempts to keep gain to a minimum to prevent Near-End Cross-Talk (NEXT). However, if loop conditions warrant, the algorithm must boost gain enough to insure the minimum signal level required is received.
Factors that tend to cause receiver gain to be boosted are associated with loop impairment, specifically attenuation (length) and/or the presence of bridge taps. Receiver gain is fairly independent of noise. So if the gain is high, it may mean indicate a long loop, or a loop with a significant bridge tap.
Bridge taps do not affect the upstream channel as much as the downstream channel. Since we only display upstream receiver gain in ViewRunner, a higher than normal gain is most likely an indicator of loop length.
The following receive gains have been observed in testing:
| Reach (Kft) | Receiver Gain (dB) |
|---|---|
16 | 42 |
14.5 | 39 |
11 | 27 |
9 | 21 |
8.7 | 19 |
Transmit power is a measure of the downstream Power Spectral Density (PSD) mask. T1E1/97-104R2a states that the PSD for the downstream channel shall have an upper limit of -40 dBm/Hz in the nominal passband region with no variation exceeding -37 dBm/Hz. However, the maximum transmit power is really the decision of each network provider. As power is boosted, reach can be extended for a given data rate. At the same time, however, the boosted signal can become a greater disturber for other services.
T1E1/97-104R2a also specifies that the PSD for the upstream channel shall have an upper limit of -38 dBm/Hz nominal with no variation exceeding -35 dBm/Hz.
The ATU-R's transceiver determines its transmit power during the training process as it tries to fulfill the upstream data rate request. It tends to try to support the requested data rate at the lowest possible transmit power so that near cross talk in the Cisco 6100 is minimized.
The Cisco 6100 is equipped with a variety of connection counters, train counters, and threshold counters used to capture system performance statistics:
These counters are used to provide individual subscriber, LIM port, and ATU-C modem port statistics. Displayed statistics are derived from these counters.
Once a LIM port and ATU-C modem have been successfully connected, a successful connection counter increments for both the logical pool and the line, and the modem training sequence begins.
If all modems within the logical pool are busy, the SC sends a busy tone to the ATU-R modem and increments the logical pool blocked connection and line blocked connection counters.
After the connection between the LIM port and ATU-C modem has been established, the training sequence as described above begins.
If the ATU-C modem and ATU-R modem train, a successful train counter increments for the ATU-C modem. If the ATU-C modem and ATU-R modem fail to train, a failed train counter increments for the ATU-C modem.
Two threshold counters are also available per logical pool: 80% and 100% modem utilization. These two threshold counters provide the following statistics:
The sum of the above three statistics is equal to the total connection requests handled by the logical pool.
In addition to the integer connection counters, connection activity is also represented in terms of percentage connections in each category.
The Logical Pool Performance window provides feedback on the current performance of each logical pool in a DOH systems. The window allows you to select a particular physical and logical pool, and provides the following performance statistics for that selection:
These statistics are captured in the views described below. To access any of these views, right click on the MC and select the 6100 Performance option.
Each Performance Management dialog has its own set of associated counters. It is important to recognize that these counters are reset under certain conditions. The specific counters and the conditions under which a counter is or is not reset are described in the following sections.
Counters are reset under the following conditions:
The Performance Management Pool Summary view provides a snapshot of successful and blocked connections, and successful and failed ATU-C trains. Additionally, summary statistics indicating the number of trains at or below 80% logical pool utilization, over 80%, and blocked requests per logical pool are provided.

The Cisco 6100 maintains the following pool summary counters on each defined pool:
Pool summary counters get reset in the following situations:
The Performance Management Subscriber window lists a snapshot of all successful and blocked connection activity by subscriber. Additionally, summary statistics for the number of subscribers, number of successful cross-connects, and number of blocked cross-connects are provided.
This view can be accessed by putting your cursor over the outside area of the appropriate LCC, right clicking, and selecting the 6100 Performance > Subscriber option.

The following table, Table 9-4, describes the fields on the screen.
| Field/Tab | Description |
|---|---|
Pool | Contains two parts: The physical pool to which provided statistics apply, either A or B, and the logical pool within the physical pool to which provided statistics apply, either 1, 2, or 3. |
Subscriber ID | The unique identifier by which the subscriber is known. |
Successful Xconn | The number of successful cross-connections achieved for that subscriber ID since the last time the counter was reset. |
Blocked Xconn | The number of blocked cross-connections realized for that subscriber ID since the last time the counter was reset. |
DOH Performance | Two counters display the total time and block time in minutes experienced by the logical modem pool since its creation or since the last system reset. A blocked minute is any minute during which one or more subscribers is refused modem port assignments in response to DOH connection requests due to 100% modem utilization. The total time is the number of minutes that the logical modem pool has been in existence or since the last system reset. These counters are displayed on the Pool Performance dialog. |
The Cisco 6100 maintains the following subscriber counters:
Subscriber counters get reset in the following situations:
The Performance Management Line Ports view lists a snapshot of all successful and failed ATU-C trains by line port.

The following table, Table 9-5, describes the fields on the screen.
| Field/Tab | Description |
|---|---|
Pool | Contains two parts: The physical pool to which provided statistics apply, either A or B, and the logical pool within the physical pool to which provided statistics apply, either 1, 2, or 3. |
Line Port | The line port location by chassis, slot and line port number |
Successful Trains | The number of successful trains achieved for that line port since the last time the counter was reset. |
Failed Trains | The number of failed trains realized for that line port since the last time the counter was reset. |
The Cisco 6100 maintains the following per line port counters:
Line port counters get reset in the following situations:
The Performance Management ATU-C Ports view lists a snapshot of all successful and failed ATU-C trains by ATU-C modem port.

The following table, Table 9-6, describes the fields on the screen.
| Field/Tab | Description |
|---|---|
Pool | Contains two parts: The physical pool to which provided statistics apply, either A or B, and the logical pool within the physical pool to which provided statistics apply, either 1, 2, or 3. |
ATU-C Modem Port | The ATU-C modem port location by chassis, slot and line port number. |
Successful Trains | The number of successful trains achieved for that ATU-C modem port since the last time the counter was reset. |
Failed Trains | The number of failed trains realized for that ATU-C modem port since the last time the counter was reset. |
DMT-1 training statistics are displayed from within the existing ViewRunner performance display. To access the DMT-1 performance data, double click on the DMT modem from the ATU-C performance data table to get to the DMT training graph.
The existing table that shows performance statistics, such as successful trains, failed trains, etc., has been modified to allow single lines of the table to be selected. Once you have selected a line of the table for a DMT ATU-C module, a button on the performance dialog enables to allow you to display a graphical representation of the Bit Allocation, SNR, and Receiver Gain for that module. The graph can be refreshed or closed using available buttons on the display. The range of the training statistics display is the same as that specified in the MIB.
In ViewRunner for HP OpenView, the user can open as many ATU-C graphs as are allowed by the windows system limit.
The Cisco 6100 maintains the following counters on each ATU-C port:
An ATU-C port counter gets reset in the following situations:
Two current connection activity displays are provided:
For ATU-Cs or LIMs in a Digital Off-Hook configuration, the port status window displays a Connected To group box. This box identifies the specific LIM and ATU-C ports currently connected to one another, and provides a Properties button to open the opposing port's module property tab.
This group box is dimmed when the port's Usage State is Idle.

The Active Connections view lists a snapshot of all currently active connections in the Cisco 6100. To open the active connections dialog, right click on the MC and select the Active Connections option. The following window appears. The next three figures present the Active Connections window first in the far left position, then scrolling right for the last two figures.



You can use the logical service oriented navigation to go directly to the desired entity by clicking on any blue hyperlink in the screen.
Table 9-7 below describes the fields on the screen.
| Field | Description |
|---|---|
Pool | Displays the name of the physical and logical pool. |
Active Connections | Displays the number of active connections associated with a physical or logical pools. |
In Service Modems | Displays the number of in-service modules that you have assigned to a logical pool and whose modules and ports are unlocked. |
% Usage | The Active Connections field divided by the In Service Modems field. |
Subscriber ID | Displays the identifier by which the subscriber is known. |
Line Port | Displays the chassis, slot and port number to which the subscriber ID is associated. |
ATU-C Port | Displays the chassis, slot and port number to which the line port is connected. |
Pool | Displays the physical/logical pool in which the line port and ATU-C modem port are members. |
Modem State | Displays whether the modem is trained, training, or not trained. |
Actual Up | Displays the actual upstream train rate at which the subscriber is training. This rate may never be higher than the Provisioned Up rate. |
Actual Down | Displays the actual downstream train rate at which the subscriber is training. This rate may never be higher than the Provisioned Down rate. |
Rx SNR | Signal to noise ratio for ADSL upstream (receive side) data channel. |
Provisioned Up | Displays the upstream rate set by the CO, the maximum upstream rate at which the subscriber can train. |
Provisioned Down | Displays the downstream rate set by the CO, the maximum downstream rate at which the subscriber can train. |
Provisioned Up Margin | Displays the upstream noise margin provisioned by the operator. |
Provisioned Down Margin | Displays the downstream noise margin provisioned by the operator. |
Actual Down Margin | Displays the downstream noise margin actually occurring within that provisioned by the operator. |
Actual Up Margin | Displays the upstream noise margin actually occurring within that provisioned by the operator. |
The Active Connections dialog includes fields for provisioned upstream and downstream bit rates, actual trained upstream and downstream bit rates, and received signal to noise ratio. Additionally the dialog now includes totals of active connections by pool and the current usage level of each pool.
![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Fri Apr 23 14:27:16 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.