June 2003

DSL Service Creation With "Extreme OSSs"

BY MARK H. MORTENSEN, Ph.D.

A new breed of Operations Support Systems (OSSs), �Extreme OSSs� have proven themselves to be very adaptable to the needs of Service Providers, providing tremendous value in their operations. In DSL service provisioning, they are making it economic for Service Providers to quickly provide DSL services to impatient customers.

DSL: POPULAR BUT DIFFICULT
Digital Subscriber Lines (DSLs) are hot. With over 30 million already installed worldwide, growing to more than 100 million by 2006 (according to RHK), the service is arguably one of the most popular to be offered since voice telephony was invented. The load on the Service Providers from DSL provisioning is significant, however. Loop qualification, possible dispatches to install CPE, main distribution frame crossconnects, and possible physical labor involved in adding equipment, etc. all contribute to the operations costs -- and are partially unavoidable since physical labor is involved. In addition to this, the provisioning of DSL services can require significant work by technicians who do not �do� anything physical -- they determine what the design of the service should be, and assign the specific equipment to be used. This work alone requires as much as 45 to 90 minutes -- often after a delay of several days, if the engineering department is overloaded. If a carrier were provisioning 20,000 lines per week -- a moderately successful campaign -- it would mean about 20,000 hours of engineering work a week -- and that would require 500 people for this function alone.

Why is this so hard? Because of the number of elements that are involved in a DSL service -- from the customer premises device, to the wire pair that connects to the local office, to the crossconnect in the office, to the port in a channel unit housed in a specialized unit, to the connection to an ISP (through logical bandwidth dedicated to the customer within a larger logical pipe that goes to the correct ISP, which is itself inside a physical transmission system). All this needs to be designed and assigned by the technician, and then the network configured. This is very time-consuming and requires accurate data on what resources are available in the network -- kept in an inventory system, or in a more sophisticated Service Resource Management (SRM) System that also provides mechanized and automated functions to assist in, or completely automate, the provisioning process.

By mechanizing the assign and design work, and controlling an overall automated provisioning process, these SRM systems are radically reducing the work involved in the provisioning process.

FLOW-THROUGH OSS FOR DSL
So how does one go about automating the provisioning process for DSL services? By hooking up the Service Provider�s Order Entry and Management functions (found in an OE/OM system or in a module of a CRM or Billing System) to the SRM System, to a Service Activation System. Customer requests are processed by the OE/OM system, sent to the SRM system where a set of pre-defined business process workflows is triggered, and the various engineering and operations tasks sequenced, whether they be manual or automated. Then the service is activated via a Service Activation (SA) function that mediates the dialogue with the network elements and configures them according to the determined design.

�EXTREME OSSs� WHAT�S SO SPECIAL?
Theoretically, any software system can be modified to provide the functions that have been described. But one breed of software that one could call �Extreme OSSs� is proving to be the best at doing the job. These OSSs use the latest technology and software architecture, and have been built with the �philosophy of the extreme�: Extremely Open, Extremely Customizable, and Extremely Extensible. Let�s examine these characteristics, and what benefits they are bringing to Service Providers.

Software Technology and Architecture: J2EE (Java 2 Enterprise Edition) software technology has now been proven to be the modern technology of choice for OSSs due to the speed it brings to prototyping and development efforts, allowing software developers to respond rapidly to Service Providers� requested features. And when combined with the proven N-tiered architectures (e.g., the three-tiered modern architecture of a database containing the data, a middle tier containing the business logic, and a presentation client tier) they have been shown to be super-scalar, matching the super-scalar hardware available from platform vendors.

Extremely Open: Fitting a new OSS into the existing OSS structure in a major Service Provider has been one of the major challenges of the industry since most of the OSSs were built to perform a specific function in a particular environment, but were not built with openness in mind. The Extreme OSSs are �Extremely Open� with regards to the ease with which they share the data they contain and with which transactions can be made pass to and from one OSS and other OSSs. Enterprise Application Integration (EAI) interfaces, Java Messaging Services (JMS) interfaces, Publish and Subscribe Data Interfaces, Web services, and a host of other techniques are available for interfacing these OSSs. Some OSSs are even opening what usually is an internal interface between their middle tier and client software, thereby supporting customers and Systems Integrators in their desire for specialized user interfaces targeted at specific user groups. With Extreme Openness, they can easily �roll their own� Java or Web user interfaces -- no longer slaves to the user interface the vendor happens to provide.

Extremely Customizable: Since no vendor has the resources to meet the exact needs of all Service Providers (one of the main reasons that Service Providers have traditionally built many of their OSSs themselves), to meet the specialized needs of any particular Service Provider requires either a customized, expensive code stream, or the OSS has to have been built with extreme customization in mind. These range from the mundane, like the ability for the administrator (not a programmer) to customize the system to meet particular security and organizational requirements, all the way up to the ability to dynamically extend the data model of a system, and the business processes employed in provisioning, without the need for code-level programming.

Extremely Extensible: With the �Extremely Open� and �Extremely Customizable� characteristics, what more would a Service Provider want? With the lifetime of a large OSS averaging over five years, the characteristic of �extensibility� is critical to meet the changing business and technology needs of a Service Provider. Vendors who engage in �Extreme Extensibility� open their database schemas to their clients, provide training and tools for the Service Providers to build models of new types of equipment or services themselves (as well as maintaining a library), and are built on commercially proven database management systems and commercially proven workflow management systems that can �ride the learning curve� of those specialized vendors.

So what�s the bottom line on what �Extreme OSSs� bring to Service Providers? It meets their particular set of needs, to fit into their environment, and to put the control in their hands for now and in the future.

CASE STUDY
The Extreme OSSs that have been implemented in a large European telecoms operator for DSL service provisioning are a case in point for both the benefits of Provisioning Automation in general, and for the benefits of using �Extreme OSSs� in the architecture. An existing Order Entry/Order Management System was adapted to an EAI bus architecture and passes the DSL orders to the SRM system via its open interface. It validates the orders according to rules in a Network Service Catalog (rules that can be customized and extended by the Service Provider), and then processed according to Business Process Templates that capture the particular processes desired by the Operator -- of course, that can be created or modified with advanced graphical tools by the Carrier itself. The business processes call extended Java Beans in the middle tier that encapsulate extensive knowledge of DSL technology, and work with templates of the available services and equipment (of course, configurable and extensible) to set the policies for the design and assignment. The Automation Beans (themselves, extensible) carry out the detailed automated processes and eventually lead to a full �image� of what the DSL service should be. Information is then passed to a Service Activation System for implementation. The system is, as of 1Q03, processing more than 5,000 orders per day.

Implementing such an automated process without Extremely Open, Configurable, and Extensible systems would have consumed vast resources and taken many months -- but due to the extreme nature of the OSSs involved, it was accomplished in less than nine months. The flexible nature of the OSSs also are allowing the system to be continuously modified by the carrier -- adjusting it themselves as the carrier learns more about the best way to provide service to their customers, the ultimate consumer.

Mark H. Mortensen is chief marketing officer and senior vice president of product management at Granite Systems. Granite Systems provides Service Resource Management (SRM) software for telecoms operators, worldwide, with wireless, wireline, optical and packet technology networks. For more information please visit www.granite.com.

[ Return To The June 2003 Table Of Contents ]