PDF of this tutorialFrom a business perspective, the NAP is the LEC’s primary DSL customer. As a packet-over–DSL wholesaler to NSPs and other DSL retailers, the NAP moves data over a dedicated DSL infrastructure using a pure data network (whereas an NSP will add content—value—for distribution to end users). As the owners and builders of the DSL network, NAPs typically maintain bulk arrangements with a variety of NSPs.
Architecturally, the NAP’s co-location facilities include test access systems and DSLAMs, which forward packets to the data network. Loops from the NAP’s co-location connect to an MDF. They link to DSL modems over the same outside plant as lines for analog, integrated services digital network (ISDN), T-1, and other DSL flavors.
On the copper side of DSL, one of the NAP’s greatest challenges remains speeding the line service request (LSR) process to acquire copper loops more rapidly. Additionally, the NAP and LEC must tightly integrate service assurance processes for faster identification and resolution of network faults. On DSL’s data side, the NAP must maintain tight interoperability with NSP processes for two-way communication of network status (see Figure 5).
Figure 5. NAPs’ Systems as the Middleman
NAPs also need visibility into network performance to plan and engineer for capacity needs within DSLAMs and data networks. To provide specific levels of quality to their users, NSPs establish design rules on issues such as the level of concentration in links and data aggregation. In response, NAPs must have the ability to look into the network’s performance to help its NSP customers assess the need to acquire more broadband capacity.
The NAP must also determine how to manage service assurance across such multivendor equipment and systems as the following:
- Digital-loop carriers
- Multiple-dwelling units (MDU)–based DSL arrangements
- ATM and frame-relay switches
- Aggregation devices
- CPE
- Routers
- Disparate databases containing information on customers, service profiles, and billing history
For NAPs relying upon manual processes, configuration problems are difficult to pinpoint and resolve. At the loop level, these NAPs can’t accurately measure physical distance, line noise, and spectrum interference with manual processes. Furthermore, as NAPs add more services into the local loop, spectrum interference will change. With more DSL and other digital services coming to rely on local loops, the noise floors of all pairs in the binder groups will rise, affecting the ability of DSL modems to provide consistent, high-quality service.
Although many NAP–LEC interconnection agreements address spectrum purity and compatibility, they do not specify which provider maintains responsibility for issues such as repairs and costs.
The DSL infrastructure also poses a management challenge because it uses many new, multivendor network elements based on different technologies, using various protocols to communicate their data in different formats, such as the following:
- Transaction language 1 (TL1)
- Simple network management protocol (SNMP)
- Common management information protocol (CMIP)
- Common object request broker architecture (CORBA)
Without visibility into a fault management process, it is difficult to determine whose services are affected. If an ATM switch raises an alarm indicating port failure, it will report the information as a physical problem on the port or a problem on a set of either virtual channels (VCs) or virtual paths (VPs), depending on configuration. To understand how these types of problems affect specific customers, the NAP needs the ability to correlate network outages to services. An integral part of service assurance, correlation enables service-impact analysis, helping NAPs to prioritize repairs for NSP customers and capitalize on interconnection agreements with the LEC.
