Table Of Contents
Cisco Subscriber Registration Center
for Service Providers
Executive SummaryThe demand for high-speed data services is booming by any measure. According to Allied Business Intelligence, the number of subscribers to residential data-over-cable services will leap from 3.3 million in 1999 to 58.6 million in 2005—with the United States accounting for 14 million of those subscriptions.1 In addition to cable, high-speed data services are also offered by fixed wireless providers, and via satellite as well. By any measure, the growth of high-speed data services is phenomenal.
To win a share of this surging market—and make it profitable—service providers face a battle on two fronts. On one side, consumers demand a rapid rollout of reliable broadband data services. On the other, Operations Support Systems (OSSs) must be transformed to support new data and voice services without sacrificing legacy systems. If service providers wait until their OSSs are upgraded to support cable modems and other intelligent devices, they inevitably cede market share to other broadband technologies such as digital subscriber line (DSL) and fail to tap new revenue streams. Yet an aggressive deployment of cable modems or voice services can create provisioning gridlock and swamp OSSs with demand.
Today, installation commonly involves one or two technicians spending hours on a single site, driving up the costs of activating service. For example, technicians may have to install a two-way splitter to link the cable to both the set-top box and the cable modem. Even in cases where rewiring is minimal, the technician must still manually record the hardware address of the cable modem and call it in to a customer-service representative, who must then manually enter the information into a database that will authenticate the user.
Upgrades—such as attaching additional computers or peripherals to the cable modem, or adding voice service—can be just as time-consuming and costly. As one report put it, "Getting modems installed is only half the battle. Once the modem is up, customers may alter configurations and server connections by installing new pieces of software. Although the provider doesn't cause the problem, if the customer doesn't have access, the problem falls into the provider's lap."2 Difficulties multiply at the headend as well. Often the lack of scalability in both servers that support data and element-management systems makes it difficult for OSSs to handle the explosive growth in broadband customers.
And the costs add up. As illustrated in Figure 1, Cisco found that the average service provider that passes two million homes typically experiences a market demand for new services by 500,000 users over a three-year period. But because of manual provisioning, the operator can meet less than half of that demand. Automated provisioning not only allows the service provider to capture a greater share of the market, but can also save $100,000 in network administration per 2000 users per year. Similarly, one service provider estimated that reducing field operations by implementing automated provisioning could save $50 million per 500,000 users over a three-year period.
Cisco Subscriber Registration Center (CSRC) provides a way to achieve those savings—and capture new revenue streams with additional broadband services. It takes advantage of the Data-over-Cable Service Interface Specification (DOCSIS) standard to provide the powerful Dynamic Host Configuration Protocol (DHCP) needed for high-speed data. It also includes Domain Name System (DNS) server support for name resolution and Trivial File Transfer Protocol (TFTP) for configuration file downloads to cable modems.
CSRC also supports the Digital Audio Visual Council (DAVIC) Digital Video Broadcasting (DVB) standard prevalent in Europe and an important component of digital set-top boxes widely distributed in the United States.
Building on Cisco Network Registrar (CNR) to customize and automate the provisioning of cable modems, CSRC provides genuinely intelligent device management. This can greatly reduce or even eliminate the costly truck rolls—and set the stage for a retail-driven market for customer-configured broadband services. CSRC can scale to support the burgeoning number of subscribers who require support from the largest of cable operators and service providers. There's no need to modify CSRC as new services come on stream. It supports provisioning and intelligent device management for high-speed data, residential voice over IP (VoIP), digital set-top boxes, and fixed wireless alike—out of the box.
Figure 1 A National Service Provider Network Architecture
Just as important, CSRC centralizes the information about these new subscriber devices and services in order to support overall subscriber management, administration, and reporting. That, in turn, strengthens OSSs: the CSRC provisioning application programming interface (API) allows the full integration of OSS and business process software, enabling true end-to-end flow through provisioning.
For example, workflow management applications from software development partners such as Sigma Systems Group or AP Engines can harness data from CSRC to drive key business processes. As a result, order entry, service definition, billing and rating services, and customer care are all closely integrated with accurate, timely subscriber device and services data. Thus with CSRC, an operator can choose from a variety of vendors to build next-generation OSSs in order to handle new services efficiently while ensuring compatibility with existing OSSs. (See details below.)
The architected, layered approach to development reflected in CSRC prepares the ground for further developments: Cisco is committed to building on CSRC to provide a distributed architecture with powerful, centralized provisioning capabilities for a range of tiered services. By deploying CSRC today, service providers can position themselves with a device provisioning engine (DPE) that will support multiple devices and technologies—including emerging standards such as PacketCable—from this single, powerful platform. This also prepares a service provider to meet the increasingly complex security requirements as well as the rapid advances in next-generation OSS technology. The result will be a rollout of broadband services that is increasingly automated, cost-effective, and profitable—and the evolution of those services to increase revenue flow.
Three Components of End-to-End ProvisioningDesigned to support auto-provisioning and self-provisioning for DOCSIS 1.0 and 1.1 devices, CSRC is designed to work with cable modem termination systems (CMTSs) using the Cisco uBR Universal Broadband Router Series of CMTSs. The innovation and capabilities that CSRC brings to service providers can best be seen in a three-tiered model of end-to-end provisioning.
Figure 2 Architecture for End-to-End Provisioning
Customized and automated protocol servers, including DHCP, DNS, and TFTP, form the basis of a DOCSIS cable modem provisioning system by providing full-featured and scalable naming and addressing services for service-provider networks.
Intelligent device management, supported in CSRC, provisions, configures, and manages end-user devices and supports administration and reporting tasks as well as automating the provisioning of subscriber services. CSRC also assigns the type and appropriate quality of service (QoS) to each user—such as high-speed data, VoIP, or specific features based on devices and the services the service provider makes available to its subscriber base.
Business process integration is achieved by building on top of this intelligent device-management platform. The CSRC provisioning API is used to draw upon information on subscriber devices, registration, and class-of-service (CoS) information for use in OSSs and business support systems, from straightforward billing applications to extensive, sophisticated workflow applications.
Each of these three elements is needed to create a total provisioning solution. For example, a service provider that seeks to provide high-speed data services must be able to integrate device configuration components of the provisioning system with back-office applications. That's why CSRC can play such a pivotal role: Not only does it support provisioning DOCSIS devices to provide new broadband services efficiently and cost-effectively, it also includes extensions that support individual applications such as billing as well as other OSSs—both legacy systems and next-generation implementations.
Building on a Strong Foundation: Cisco Network RegistrarCSRC draws upon the CNR protocol server functions—DNS, DHCP, and TFTP—to configure devices and define services. CSRC builds on the extensibility offered through CNR extension points to call scripts of C/C++ code. Because CNR is essential to both self-provisioning and auto-provisioning, it's important to have a more detailed understanding of its capabilities.
The following pages outline the capabilities of CSRC today—and how it can help service providers maximize revenue in the new broadband applications.
DNS SupportThe DNS implementation in CNR supports dynamic updates and is multithreaded to ensure high performance. It includes a lightweight, embedded high-performance data repository to further improve both performance and scalability. It was one of the first DNS servers to support Incremental Zone Transfer and DNS Notify, which lets primary servers notify secondary servers that something has changed, and transfer only the changed information. This scenario sharply reduces network traffic that zone transfers would otherwise require.
Other important features include support for Naming Authority Pointer (NAPTR) resource records (Request for Comment 2915), which enables a more flexible approach to map names to resources, locations, and servers, a capability that is important for mapping telephone numbers to Session Initiation Protocol (SIP) URLs for residential VoIP applications.
Figure 3 Device Provisioning Registrar 2.0 Architecture
CNR is compliant with all relevant Requests for Comment (RFC) draft standards for DNS servers by the International Engineering Task Force (IETF), including:
•RFC 974, 1034, 1035 (core DNS concepts)
•RFC 1995 (incremental zone transfer)
•RFC 1996 (notify)
•RFC 2136 (dynamic update)
•RFC 2052 (server resource records)
•RFC 2915 (NAPTR resource records)
Moreover, CNR interoperates with the Berkeley Internet Name Domain (BIND) implementation of DNS by importing BIND configuration files and allowing zone transfers between BIND and CNR. Together, these DNS capabilities allow the primary DNS to automatically update the secondary DNS with any changes in resource records. As a result, it is standards based and fully interoperable.
DHCP SupportThe same open, comprehensive approach can be seen with the CNR implementation of DHCP, which includes:
•DHCP RFC 2131, 2132 (automatic allocation of reusable network addresses and additional configuration options)
•BOOTP RFC 951, 1497 (Bootstrap Protocol, for automatic request and transfer of IP address)
•RFC 2136 (dynamic update of DNS)
The CNR DHCP server provides client-class support, which creates a meta-level grouping of PCs and other end-user devices according to the Media Access Control (MAC) address. It enables the assignment of PC and cable modem devices to key categories such as "trusted," "untrusted," "billing expired," or "max lease time authorization." It also supports providing private (net 10) IP addresses where necessary.
The comprehensive CNR support of DHCP helps to achieve a highly effective fail-over capability. If one DHCP server goes down, a backup is able to keep providing DHCP services with no interruption of service. The result is greater fault tolerance—if a power outage, for example, takes down one DHCP server, a second DHCP server can take over the function of DHCP leasing.
TFTP SupportCNR also offers multithreaded, high-performance TFTP. Most TFTP implementations are process based, and thereby limit performance. In CNR, by contrast, TFTP can handle multiple, simultaneous requests for DHCP leases, much as a word-processing document allows a user to print and edit a document simultaneously. This is especially important in the event of a temporary interruption of electrical service. Upon resumption of service, subscribers send requests for DHCP leases en masse—and the CNR implementation of the TFTP server must be able to handle this massive demand for configuration files.
What's more, the superior TFTP performance in CNR means that it consumes fewer system resources. For example, it runs on a less powerful server than would be required to achieve similar performance with another TFTP implementation.
CNR configures IP addresses, and assigns them to cable modems based on the appropriate policies. The DHCP response contains the file name and location so that the modem can request the proper file from the TFTP server. CNR determines what type of device is accessing the network, and then determines whether or not the device has been provisioned before. Next, CNR allows the establishment of a CoS based on the MAC address, and stores the address of the device making a DHCP request. This sets the stage for CSRC.
Running on UNIX and Windows systems, CNR includes a high-performance internal database, which allows CNR to support up to one million users, and to grant as many as 1800 leases per second under sustained heavy DHCP traffic loads. CNR is easily extensible through interaction with Lightweight Directory Access Protocol Version 3 (LDAPv3) directories, and through "extension points" that enable customized DHCP message processing.
Provisioning in CSRCCSRC is designed to limit truck rolls during service expansion. It does so in two main ways:
PreprovisioningIn preprovisioning scenarios, a service provider can record the MAC address of a cable modem and ship it to a customer—or a retail outlet can capture that information at the point of purchase. That information is then passed to CSRC for inclusion in its database. The service provider can thus associate the information with a predetermined CoS that is deemed appropriate for that subscriber. When the subscriber plugs in the cable modem, it is immediately recognized by CSRC, provided with an IP address, and configured for the appropriate predetermined level of service.
Self-ProvisioningSelf-provisioning requires a different workflow for service providers—for which CSRC provides the necessary support. CSRC forces all subscribers coming onto the network to register for service before getting properly configured and gaining access to the Internet. In the self-provisioning scenario, it is assumed that the subscriber has a live cable feed. In this case, the service provider may direct a subscriber to a retail store or have the subscriber order a cable modem and install it with the use of a splitter. Subscribers can then connect to a TV on one side and a PC on another.
In a self-provisioning workflow, the service provider may have no knowledge of the subscriber who may, for example, try to plug it in at home without contacting the service provider in advance. CSRC will receive this request, query its database, and determine that the MAC address is new to the system. CSRC then provides the modem a provisional or temporary IP address, followed by a DOCSIS configuration file for a predetermined default level of service. CSRC then also issues the PC its temporary IP address, and at that point the subscriber is temporarily provisioned.
Next, the user is directed to a spoof DNS server. There, subscribers see in their Web browser a form inquiring about their subscriber status and forcing them to register for whatever type of high-speed data service the service provider wishes to offer.
At that stage, the Web page instructs the subscribers to reboot their PC. CSRC will automatically reboot the subscriber's cable modem. This repeats the process of obtaining a MAC address, except this time it is tied to a particular level of service in the CSRC database. CSRC provides the configuration file to the cable modem and appropriate IP address to the modem and PC based on the service requested during this initial registration process.
Most service providers offer a combination of "top-down" auto-provisioning and self-provisioning. CSRC is designed to support these hybrid environments.
CSRC: Building on a Powerful FoundationFirst, CSRC can be used to prevent promiscuous provisioning by checking the LDAP database for the MAC address of the incoming device. If it finds no such address, it grants a small amount of bandwidth—a default level of service—to allow the device restricted access to a spoof DNS server, where the user is presented with service registration pages and must enter the necessary subscriber information.
Next, CSRC stores the appropriate device and service information in its directory, reboots the cable modem, and assigns it an IP address via its DHCP server and the correct level of service based on the users' request and the service provider's authorization. If the DHCP request contains the MAC address of an authenticated user, it can be used to trigger the appropriate CoS. For example, an IP phone with one type of MAC address triggers one CoS, a PC another. A particular MAC address can be linked with a reserved dynamic IP address, thereby allowing a virtual static IP address when needed. The CoS is provisioned from the top down and stored in LDAP. The modem "learns" the appropriate CoS via the TFTP configuration file returned in the DHCP response.
CSRC also works with CNR to specify the scope of service. After determining which IP address a device should get, CSRC can associate different gateways, DNS servers, and other DHCP option values with that device. At that point, the CNR TFTP server can provide the appropriate configuration files—a particular level of bandwidth for a high-speed data service offering, or residential VoIP services. And through the use of technology extensions, CSRC can also support registration of non-DOCSIS cable modems.
Together, CNR and CSRC provide the basis for tiered subscriber services. For example, a DHCP request from a particular MAC address can be associated with such services—say, the amount of bandwidth could be increased or the modem could be provisioned to support five PCs behind it. Or, a service provider can use these capabilities to offer preset services packages, such as family platinum, which, for example, may allow Web access for the children's PC but block access to inappropriate sites.
Manual provisioning of broadband services can be dangerous to service providers. As the experience of DSL service providers makes clear, aggressive moves to capture market share without adequate provisioning and OSSs in place can drive costs sky-high and result in poor customer satisfaction. Cable network operators and fixed wireless network providers must avoid the same pitfalls—and the CSRC support for auto-provisioning and self-provisioning can help them to do so by providing two distinct work flows for better management and cost-effectiveness.
CSRC CapabilitiesAs we have seen, Cisco Subscriber Registration Center supports mass deployment of broadband services—virtually without truck rolls and disruption of service. More than this, it allows service providers to deploy high-speed data service today using DOCSIS 1.0 devices and migrate to multiservice offerings under DOCSIS 1.1. Alternatively, CSRC enables service providers to build broadband service around DVB/DAVIC set-top devices and support residential voice services in a Simple Gateway Control Protocol and Media Gateway Control Protocol (xGCP) environment.
CSRC and DOCSISBy supporting DOCSIS 1.0, CSRC enables service providers to roll out Internet access right away. Typically, data services would revolve around issues such as the number of devices. In a residential environment, there might be a family package with a cable modem with two PCs behind it. Alternatively, a small office/home office (SOHO) environment may have 5 Mbps downstream and 2 Mbps upstream, with ten or more PCs attached to the cable modem.
CSRC and Residential Voice ServicesIf a cable modem contains analog voice (RJ-11) ports, CSRC can support residential VoIP services using basic xGCP standards and DHCP Option 14. CSRC can support an xGCP call agent to handle call feature processing and connection to the Public Switched Telephone Network (PSTN) by associating a telephone number with the Frequently Qualified Domain Name (FQDN) of the cable modem. CSRC provisions the FQDN of the call agent on the modem so the modem can locate a call agent for outgoing calls. It also ensures that the call agent is provisioned with the telephone number (TN)/FQDN information so that it can locate the appropriate modem for incoming calls.
CSRC and Set-Top Boxes (DVB/DAVIC)The typical set-top box contains three components—a DOCSIS modem, a DVB/DAVIC modem or component, and middleware. Each component has its own MAC address and must be provisioned separately. CSRC can provision the DVB/DAVIC device for data services via the digital line card at the cable headend.
Security in CSRCCSRC allows service providers to implement the security features of the DOCSIS standard, which encrypts traffic flows between the cable modem and the CMTS in the cable headend.
DOCSIS 1.0 provides the baseline privacy interface (BPI) standard for encryption. Rather than use authentication methods such as passwords or digital signatures, BPI checks the MAC address of the cable modem to see whether it is qualified to receive a key for the appropriate services. BPI, however, cannot protect against a hacker who masquerades as a cable modem with an authorized MAC address. BPI+, implemented in DOCSIS 1.1, remedies this shortcoming.
In addition, CSRC, the CNR DHCP server, and the Cisco uBR series of CMTSs support the new DHCP LEASEQUERY message. By sending the LEASEQUERY message to CNR DHCP, the uBR CMTS can verify the source IP address of all upstream datagrams, and can transmit downstream datagrams without relying on any broadcast Address Resolution Protocol (ARP) packets, even after a uBR reboot. With this message, the uBR CMTS can prevent the theft of subscriber IP addresses in the cable network.
ScalabilityCSRC supports the service provider's urgent need for scalability, too. A four-server configuration can support several hundred thousand devices, depending on such factors as the number of CPUs in the server and their speed, the amount of memory in the system, the redundant array of inexpensive disks (RAID) configuration, the LDAP implementation being used, and the lease renewal rate. By spreading out DHCP servers, CSRC also provides for highly scalable fail-over.
Extension PointsThe other major innovation in CSRC is its provisioning API for tight integration with OSS and business processes. This allows each service to be tied to the appropriate order entry, customer service, and billing systems.
These business process extensions to CSRC are examined in detail below. First, it's helpful to consider the possibilities for future developments in CSRC.
Future Directions for CSRCThe service-provider marketplace is changing rapidly, and so must the ability to provision rapidly evolving services. CSRC today provides support for residential voice in an xGCP environment while setting the stage for packet cable (Session Initiation Protocol/Distributed Call Signaling [SIP/DCS]). It also prepares service providers for migration to a decentralized architecture that will support local caching of information for higher performance, configuration of both DOCSIS 1.1 and non-DOCSIS cable modems, and enhanced security. This evolving architecture will provide greater scalability and flexibility while strengthening centralized management and integration with billing systems or OSS applications.
To help service providers achieve these goals, Cisco has focused CSRC development on these key objectives.
ScalabilitySupport for subscriber self-provisioning and auto-provisioning of cable modems is a great advance over manual rollout of broadband services. Yet its very success in driving a retail-driven model for broadband access devices will create new challenges.
That is why CSRC was designed to evolve into a decentralized, highly scalable system—a model that separates device provisioning into local servers, or DPEs, while the overall subscriber registration and provisioning API functions reside in a central site or regional distribution unit (RDU). Ideally, these distributed servers could be placed close to large concentrations of users. The DPE will be able to cache the necessary configuration information from the central site and manage existing customers locally, thereby provisioning devices without establishing connectivity with the RDU. The DPE would also handle the TFTP configuration files, making service activation faster. This is especially important as DOCSIS 1.1 devices roll out. When you go beyond tiered service selection into feature selection, there is a requirement for a configuration file per modem that must be maintained.
Figure 4 Broadband Provisioning Registrar 2.0 Architecture
This new architecture works very efficiently. When a device appears on the network and requests service, the DHCP server first checks with the local cache in the DPE to see if this device has already been provisioned. If so, it renews its IP address and provides the correct configuration file for the service that has been previously approved. If it is a new and unknown device—or a device requesting a new level of service—it forwards the request to the RDU for processing. When approval is obtained, the DPE can then provision the correct CoS along with an assigned IP address. When the service is provisioned, the information is maintained not only in the data store at the central RDU but at the distributed DPE as well. And because this configuration is based on dynamic DOCSIS device provisioning via an embedded data store, service providers will no longer have to depend on LDAP to maintain subscriber information, but can use a transactional database that is optimized for provisioning. Moreover, API extensions support other technologies for OSS and other applications.
Figure 5 A Regional Architecture for End-to-End Provisioning
This scalability is important for several reasons. As service providers offer different service packages to subscribers, the number of DOCSIS configuration files will grow. For example, a residential subscriber could have three different levels of data service and voice service using a media-termination-adapter (MTA) device. Another subscriber may select one data port and four voice ports. This growing number of configuration files could easily become unmanageable—especially in situations in which users are responding to new promotional offerings. By contrast, a distributed architecture based on DPEs to maintain and dynamically generate configuration files and a centralized RDU with subscriber information can handle these additional demands for configuration files even as the network grows to support additional subscribers.
ReliabilityThis distributed model would also ensure synchronization and allow for fail-over to another distributed server if an outage occurs. That way, customers can remain on line during an outage—they can reboot and obtain the necessary configuration files from another distributed server.
In such a decentralized architecture, the provisioning engine and embedded data store are maintained as two separate entities. Although LDAP remains a standard that could be supported, the rapid growth in broadband services will likely require a high-performance embedded database.
StandardsAlthough support for DOCSIS is crucial to support self-provisioning and auto-provisioning of broadband services, the architecture for provisioning should not be dependent on any particular standard. Ideally, a subscriber provisioning application should support DOCSIS and proprietary devices as well as the DVB/DAVIC standard widely deployed in Europe. Such architecture should be general enough to support provisioning for virtually any device on a service-provider network as well as services offered over those devices such as residential VoIP.
Voice SupportAlthough high-speed data represents a tremendous market opportunity today for service providers, voice service is the next major market opportunity. Therefore, it's crucial that an operator's platform for provisioning data services positions the organization to support telephony services as well—not as an add-on, but as a central part of the architecture.
Today's support for residential VoIP is based on the xGCP standard. However, the next generation of CSRC will support provisioning of every relevant broadband voice service—such as the SIP/DCS standard and the emerging PacketCable standard.
PacketCable, initiated by CableLabs, brings the power of the Internet directly into telephony applications. For example, the standard includes real-time multimedia services—not only high-speed data and IP telephony, but also such features as multimedia conferencing. In order to achieve this, PacketCable will provide capabilities with PSTN interoperability while ensuring the QoS necessary for such demanding applications. And because it's an industry-wide standard, it will allow PacketCable devices to coexist and be provisioned by a common provisioning server.
SecurityThe security available in DOCSIS 1.1 meets the needs of service providers that provide broadband services today because the overwhelming majority of cable modems receive virtually the same configuration—for high-speed data. But this will not be the case as voice services are rolled out. Consider a subscriber to traditional telephony services such as voice mail, call forwarding, incoming caller ID, and caller ID masking. Users of VoIP will, of course, want similar services—and the configuration that supports them will have to be maintained somewhere in a persistent state.
Such configurations change much more frequently than with data services over cable modems—a user will want to forward calls to the home to a cell phone, for example—so the service provider will need to support such changes quickly. For example, a user might initiate a change through a Web site, a change that would then generate a dynamic configuration file. The subscriber registration center must be powerful enough to support these rapid changes. The next generation of CSRC will enable this by building on the capabilities of dynamic DOCSIS configuration file generation and using a distributed architecture to provide the appropriate configuration file—quickly and easily.
All this poses a security challenge. If, for example, caller ID is mapped to IP data, a hacker could trace that information unless it is encrypted. Indeed, where PSTN voice services usually function with no security, VoIP services must achieve a higher standard. A trusted relationship must be established among, for instance, cable operators, local service providers, and interexchange carriers, because a user who must make a long-distance phone call has to have a certificate that allows the call to go through. Again, that certification has to be maintained securely in the event that the cable modem or IP phone has to be rebooted. Cisco is working toward solving this problem in the next generation of CSRC by playing a major role in the development of the PacketCable
Security Standard. The PacketCable standard specifies the powerful Kerberos authentication system (an authentication system developed at MIT) combined with public key/private key technology, where encryption and decryption are performed using different keys.
CSRC: Helping to Build a Broadband-Ready OSSAs we have seen, CSRC provides the building blocks of a complete provisioning system. Through CNR, it offers the DNS, DHCP, and TFTP services that form the basis of identifying the subscriber device. And as an intelligent device-management system, it allows service providers not only to associate a CoS with a given IP address, but also to automate provisioning and allow self-provisioning. In turn, API extensions offer all the necessary interfaces to billing and OSS applications—both legacy systems and innovative, next-generation OSS implementations.
Although the self-provisioning and auto-provisioning capabilities of CSRC enable the mass rollout of broadband services, such rapid deployment can itself cause enormous problems if the proper OSS is not in place. Even if truck rolls are virtually eliminated, customer-service representatives could become deluged with e-mail notifications of service activation. These would have to be processed through normal data entry—at best, cutting and pasting data into a billing record.
Compounding this problem is that many service providers are in transition from mainframe-based legacy OSS systems. Although business processes within these systems may be automated, they are often "stovepipe" applications that make it difficult—if not impossible—to share information across the enterprise. In the cable space, most were developed for cable television (CATV), and they simply cannot accommodate broadband data services. Inventory-management systems are often closely associated with CATV services, too, and cannot easily handle cable modem or other broadband access devices. Element-management systems, furthermore, are typically independent of OSSs, because they were associated with particular types of equipment, such as set-top boxes. The recent series of mergers and acquisitions among service providers have complicated matters further by bringing together many incompatible systems under a single administrative roof.
Cisco developed CSRC to be able to support legacy OSS systems today while marking a path to new implementations in the future. The dynamic approach and decentralized architecture of CSRC allows service providers to begin by linking provisioning to billing systems, adding other OSS capabilities if and when they are needed. The API can also support specific workflow applications in order to provision subscribers with particular services, such as high-speed Internet access and Web hosting. For example, CSRC can be integrated with order-entry applications or tied to e-mail notification systems—quickly and inexpensively. It can just as easily be tied to workflow systems as well.
In other cases, service providers may use CSRC with a powerful new class of OSS systems designed to meet the rapidly changing demands of a highly competitive market.
Next-Generation OSSs for Service ProvidersWith the rapid demand for broadband services, many leading developers are rolling out next-generation OSS packages that can both provide a transition from legacy OSS and support new broadband services such as high-speed data, VoIP, and video on demand. That's why Cisco developed CSRC with extensions to support the workflow applications now available from next-generation OSS providers.
The TeleManagement Forum has outlined the goals of next-generation OSS.3 The highlights include:
•Replacing "stovepipe" standalone OSSs to a common infrastructure
•Centralizing data both logically and physically to provide a common view of both customer and operational data
•Reusing components of business-process software for greater efficiency
•Using object-oriented design for both device management and OSS functions
•Creating workflow applications that automate manual tasks while allowing for flexibility in the business-process sequence
•Building a technology-neutral architecture to benefit from multivendor environments
The key to next-generation OSS is the abstraction of business-process flows. That is, business-process flows should be contained in an entity independent from the underlying components. When service of a component is invoked by a particular business-process flow, it performs the requested service without reference to the business logic. And with a given level of abstraction from the underlying network technology, the business-process flow can function as usual, even when supporting a brand-new service. The same is true for the underlying code itself.
An open architecture and object-oriented approach is essential for today's fast-moving service-provider environment. For example, each new iteration of broadband services—VoIP or video on demand, for example—will have a particular business-process flow that can easily be incorporated into this technology-independent, object-oriented OSS environment. These business-process flows operate across numerous third-party systems when provisioning a subscriber's service.
It is critical to consider how these systems inter-relate with one another to deliver and manage service offerings. Cisco CSRC addresses these complexities. It is the centralized access provisioning capability for a range of tiered services, in tandem with a leading provisioning OSS, that provides the carrier-class IT-centric functionality to complement the workflow engine.
In addition, robust workflow implies supporting carrier-class software engineering technologies and architectures, such as enterprise application integration (EAI), connection management, protocol translation, dynamic load balancing, distributed object architectures such as Common Object Request Broker Architecture (CORBA), multithreading, and messaging. These technologies, well known in the legacy telecom OSS environment, are crucial to the success of a multiservice service-management platform.
As Tim Spencer and Mark Anglin of Sigma Systems Group point out, the challenges in defining and deploying new services is far greater than the workflow that manages the process flows: "Flow-through automated provisioning is a comprehensive systems-intensive undertaking. The activity must be orchestrated by an adaptive, intelligent service mediation layer that can implement and make use of the inherent capabilities of those applications, network elements, and service providers incorporated in the delivery and management of a service to the end user."4
In their view, service management is a critical element in providing next-generation OSSs, and object-oriented technology is crucial to its success. For example, a service-management system might have to simultaneously support several systems—one that handles a subscriber who is self-provisioning a cable modem, a service-provider element-management device that supports the provisioning, the network operator responsible for the underlying infrastructure, and a Management Information Base (MIB). Only object-oriented technology can support the multiple relationships between these systems and define their various roles in relation to operations management.
Although the overall specification for next-generation OSSs is technology neutral, it's already being mapped onto widely used object-oriented frameworks such as CORBA and Java/Enterprise JavaBeans (EJB). This has enabled many developers to offer next-generation OSS products specifically designed to meet the needs of service providers as they develop broadband services. Several, such as Sigma Systems, are members of the Cisco ecosystem of developers—an open, multivendor environment that fosters the type of collaboration that makes the Internet so dynamic and powerful.
CSRC and Sigma Systems Group
As an alternative to the CATV-specific OSS and device management, Sigma has designed a generic service model for service providers to support the fast development and deployment of new services while reducing complexity. Its central goals follow:
•Support self-activation and provisioning of new broadband services over the Web
•Reduce the stress on customer-service representatives by providing service diagnostics, service advisories, and trouble-ticketing integration
•Provide first-level service diagnostic triage tools integrated with service management that integrates the physical delivery service with enterprise workflow
Sigma's Cable Broadband in a Box suite draws upon CSRC data to coordinate the tasks involved in service provisioning. Thanks to parallel decomposition and multithreading capabilities, it can execute large numbers of service orders simultaneously. It contains:
•Customer Portal to allow subscribers to self-provision service with controlled access to the OSS
•Business Gateway to exchange information with business support systems such as customer care and billing
•Service Gateway to support other systems, such as content and application services, communications, directory services, and 911 access
•Network Gateway to mediate service requests within the network itself, including routers, switches, and the CMTS
Sigma provides integration with CSRC via the Java provisioning API. Through CSRC, it can support creation, modification, deletion, suspension, and reactivation of subscriber devices, and it draws upon the service packages created in CSRC to support multiple tiers of high-speed data services.
In the future, Sigma will work with CSRC to support provisioning of VoIP and set-top boxes and, as they become available, PacketCable devices. Together, they will support scalability to support millions of devices. Cisco and Sigma are also collaborating on ways to help multiservice-operator (MSO) service providers deploy managed access networks to provide an easy means for cable operators to offer subscribers a choice of service providers. For more on Sigma Systems Group, go to www.sigma-systems.com.
Figure 6 Sigma Systems and CSRC
Summary: Innovation and Support for Service Providers in the Broadband Era
Cisco is committed to working closely with service providers as they engage in the challenge of meeting the demand for broadband services. CSRC is an example of that commitment.
Because CSRC runs on basic protocol servers, it achieves basic interoperability. Along with CNR, CSRC is customizable and automated. It offers intelligent device management to handle a variety of cable modems and set-top boxes. It includes integrated subscriber service management for workflow applications and OSSs to better handle the evolving types of broadband services. And crucially, it includes extensions to support business-process integration for other applications.
In the near term, CSRC provides an efficient alternative to manual rollouts with self-provisioning and auto-provisioning of high-speed data services. That same cost-effective approach can be used to support residential VoIP services—from xGCP today to the powerful PacketCable standard in the future.
As we have seen, CSRC is highly extensible, so subscriber and registration information used for provisioning can be closely tied to billing systems as well as the emerging next-generation OSS implementation. The Cisco encouragement of an ecosystem of developers ensures that service providers will have a range of industry-leading OSS providers to choose from.
And that's just the beginning: CSRC is developing a powerful, decentralized architecture that scales to support the millions of potential subscribers. For more information about Cisco solutions for the service-provider environment, visit www.cisco.com.1 Kim Renay Anderson, "Cable Vs. DSL: Round 2," TechWeb News, October 6, 2000. http://www.techweb.com/wire/story/TWB20001006S00032 Karan J. Bannan, "Cross-town traffic: All you do is slow me down, say users to swamped providers," Internet World, January 15, 20013 See www.tmforum.org4 Tim Spencer and Mark Anglin, "Automated Provisioning: It's Much More Than Workflow." Cited with permission from the authors.