IP Telephony Provisioning Perils

In today’s fast-paced world, the "once-sleepy" cable industry has taken center stage in developing and deploying new services. But even as lucrative service offerings such as video-on-demand (VOD) and high-speed data have penetrated the market, it is incumbent upon operators to realize they are no longer simple cable providers. They are full-fledged entertainment and communication operators and have to think differently to remain competitive. Unfortunately, many operators fail to appreciate one of the most basic rules of the game—not all digital services are created equal. For example, the advent of digital video, with all its benefits and complexities, was still relatively straightforward from an operations systems support (OSS) perspective to deliver programming from a centralized location to the home. Reason being, the OSS (or subscriber management system) had to deal with only a single type of technology system (that is, conditional access systems) in the network to provision. High-speed Internet, premium digital cable TV and VOD introduced the next level of complexity as the industry’s collective engineering brainpower had to get used to the idea of asymmetrical, bidirectional communications. Now, the industry is on the edge of the next great hurdle: voice over Internet protocol (VoIP). But there is still a mindset with many cable executives that voice is merely another layer of digital data to be placed on top of existing infrastructure. Although correct in one sense, this belief fails to appreciate the many difficulties surrounding voice communications and the tremendous complexity it brings to virtually all aspects of the cable system and related business and operational processes: from the physical plant to the back office and even the workforce itself. Fortunately, these difficulties are not insurmountable, provided the operator clearly understands expectations. Through our work in preparing cable systems for advanced services, including IP telephony, we identify eight key areas in which voice telephony impacts existing systems and operational procedures and the OSS requirements thereof. Don t fear VoIP—rather, embrace it. It is the tip of the iceberg to offer myriad service opportunities, including the next evolution to services enabled via PacketCable Multimedia (PCMM). Here’s what to expect and areas to address from an OSS perspective, and also the requirements of other systems critical to automating services based on VoIP. With these firmly in mind, you will be well prepared to overcome any obstacles. Third-party responses In every voice telephony transaction, numerous steps are needed to handle both positive and negative responses from third-party systems. Many of these steps have underlying processes that require long-running transactions, due date management and manual intervention, which all must be carefully managed by an OSS. Today, high-speed data incorporates fairly simplified flow-through provisioning; that is, orders are entered by customer service representatives (CSRs) and the entire transaction is automated, so much so that operators can tell immediately whether the transaction was successful. In the voice world, this level of transaction simplicity is not applicable because of the number of systems and complex processes for management and completion. First, many more parameters are involved in every transaction. This is primarily a result of having to integrate the cable operator’s IP telephony service with the competitive or incumbent local exchange carrier (CLEC or ILEC) to automate the inter-carrier integration, which includes related electronic transactions for 911, local service request (LSR), long distance carrier selection, directory listing, calling name and local number portability (LNP). Coordinating timing of events between the cable operator and third parties is another complexity. For example, suppose a customer wants to switch from BellSouth to Cox Communications. Even if the technical personnel agree on a certain time for the telephone number port to take place, the systems involved may reject it, in which case there must be a negotiating process to settle on a date. More often than not, this process must include three entities: the cable operator, the new CLEC/ILEC service provider and the former CLEC/ILEC service provider, and all processes must be orchestrated carefully via an OSS to provide the customer with the services ordered, including the ability to make and receive calls. Customer care/diagnostics Cable operators’ customer care and billing systems must address these key requirements for end-to-end automation of services based on VoIP technology to be achieved. First, customer care screens must be able to handle voice telephony orders, which have more parameters and information to collect than those used to provision high-speed data. These VoIP order entry screens and account management will also have to accommodate integrated voice and data service orders. Second, billing systems must be able to create products and associated rate codes for voice telephony services. The ability to bundle voice telephony with high-speed Internet service offerings from a pricing, promotion and product code perspective must also be provided to ensure competitive service offerings are available to the operator’s subscriber base and homes passed. Finally, the customer care and billing system (the subscriber management system or SMS) must have an open and defined two-way "northbound" interface so the OSS can receive the relevant service order information for voice (alone and bundled with high-speed data), and so the OSS can communicate the order’s status and billing notification to the SMS. One of the major requirements for an SMS is the two-way northbound interface mentioned earlier. Northbound interfaces are required for subscriber self-provisioning and self-service—these are "must-haves" if operators hope to merge data and voice services into a single offering. Self-provisioning and post-activation self-service operations must be fully scalable, and the call center must be removed from day-to-day requests for service additions, changes and upgrades. SMSs must have open and fully defined two-way interfaces to authorize potential customers, authorize a change in service plan, and push new service requests to the billing system. On the diagnostic side, most call centers are already running less than optimally with makeshift tools for high-speed data that cannot be configured and adapted to handle other complex services in an integrated manner. With all the challenges of just getting VoIP technology deployed, little attention is being paid to the diagnostic and troubleshooting side of customer care. When a failure occurs in voice, many more systems are affected than in the data realm. Also, voice customers are much less forgiving of service outages and other problems compared to data customers. An OSS providing an integrated CSR system that can test service configuration and status, along with the system health and availability of IP, hybrid fiber/coax (HFC), Data Over Cable Service Interface Specification (DOCSIS) and PacketCable systems is required for robust service diagnostics that cover both high-speed data and VoIP services. This type of troubleshooting system must be able to walk customers through defined sets of exploratory questions, make specific recommendations to the subscriber to remedy the problem, and also run automated diagnostic tests in the background to isolate and discern the nature of the service outage or degradation. Self-provisioning Self-provisioning for IP telephony is very difficult, if not impossible, without the cooperation of device provisioning systems. A case in point: A lot of manual work and coordination is involved when technicians must draw an embedded multimedia terminal adapter (E-MTA) from central storage and assign it to the customer. The ability to take any qualified E-MTA from inventory, deliver or mail it to the subscriber, and have that CPE auto-discovered is paramount to the deployment scale of VoIP technology in the months and years ahead. In the very near future, enhanced operational and device management systems and the devices themselves will likely eliminate much of this manual labor. This said, all such systems need to have sufficient "smarts" to take advantage of auto-discovery technology, to help the network and operational systems recognize newly added devices and process new service order requests without operator or technician intervention. Additionally, a billing and customer care system with a well-defined "northbound interface" for performing credit checks and to allow the exchange of subscriber and service-related information between systems is required. A northbound interface also allows subscriber self-provisioning and self-service—must-haves if operators hope to merge data and voice services into a single offering. Without it, customer-driven service selection processes are not possible. Service architecture In the high-speed data service delivery network, a cable modem is connected to a cable modem termination system (CMTS), and the subscriber’s personal computer (PC) is logically associated with email and Web-hosting systems. Network routers connected to the CMTSs provide access to the Internet. A voice service delivery network architecture is much more complex. The device in the customer’s home (E-MTA) must be logically associated to a soft switch, a voicemail system, and device provisioning system and CMTS with the appropriate coordination of provisioning processes across all these systems. All these different touch points mean the OSS has that many more systems to talk to, and workflows are more complex with long running transactions and the need to manage the integrity, processing order and flow of service-related information. Also, the OSS needs to retain information on all network elements and their network topology relationships and be able to access this data immediately to process provisioning and diagnostic service requests. Servicing one area of the network may be different from another, and the appropriate service delivery network information must be maintained to determine if certain telephony services can be ordered and subsequently provisioned. For example, you might want to initiate voice service, but one part of the cable operator’s network is not DOCSIS 1.1 compliant, hence IP telephony cannot be delivered. The need for full management visibility of all those multi-technology domains and architectures is required for accurate service qualification and provisioning. Network coordination Because of the enormous variety of voice services, and the fact that services are constantly being added and dropped by the customer, the network must be as flexible as possible and modeled appropriately by the OSS. This means decisions surrounding vendors, technology, methods, operations and procedures must be made in a more cohesive and integrated manner. Primarily, this means OSS and vendor selection should be done in concert to ensure tight system integration and automated processing. A VoIP equipment vendor may have highly sophisticated technology, but if you have to integrate it and it can’t talk with other systems in a cohesive manner, you won’t be able to automate service provisioning. It is absolutely essential that operators select an OSS that can manage different vendors and technologies in heterogeneous network environments (such as PacketCable and session initiation protocol or SIP) and be able to rapidly define and deliver services according to the network’s capabilities. Make the OSS vendor selection right up front, and it will make your commercial integration and deployment of VoIP technology much smoother and with much greater certainty of success. Information accuracy Increasingly accurate plant records for service provisioning are a necessity, as are more accurate customer service address and account information. In the high-speed data realm, when a technician brings up a modem, it may not matter which CMTS it is routed to. But in telephony, PacketCable specs require the soft switch to know which CMTS is associated with each MTA so it can send a dynamic quality of service (DQOS) message to that CMTS. If more than one switch is being used, the network must know how users are divided among those switches, and it must be able to trace a path from the user to the CMTS and to the switch (call management server or CMS). If this network topology is not precisely defined in an OSS, and it is unclear which soft switch is to be activated, the results will be the inability to provide telephony service and an angry customer. Customer records are also vital for the emergency service requirements of telephony. Sure, a correct customer address is important for billing purposes, but for a 911 response, it’s not enough to have a simple address. A database must contain precise directions to the home, and it must be available to emergency services. This requires very sophisticated geographic systems and/or continual scrubbing of customer address data. Network reconfigurations When the inevitable network reconfiguration does arise, it will require that service topology information be updated across all network elements. For example, moving an MTA from one CMTS to another will require a notification of the change to the serving CMS. Until this notification is sent to the CMS, the customer won’t be able to make or receive calls. When this type of network reconfiguration is needed, this cannot wait for hours or days to occur; automated OSS processes and associated administrative tools must be available to migrate identified subscribers quickly. PacketCable and SIP System operators also need to consider the possibility of provisioning both PacketCable and SIP-based solutions because each technology may become necessary to provide unique service offerings. The OSS should support both solutions for voice, including SIP models that involve the integration of a PCMM policy server to guarantee QoS. Knowledge of the CMTS serving the customer is vital in this model as well, as information is required by the policy server. Supporting these various models requires not only the ability to handle different types of order management and associated service provisioning processes based on the type of service. This qualification should be based not only on the network, but also the CPE (MTA, ATA) currently available in the home. You will need to use all this knowledge not only in the provisioning flows, but also in network reconfigurations. A whole new mindset In conclusion, it would be tempting to assume that the solution to all these challenges is to simply build a better OSS internally or enhance an existing home-grown OSS. But these issues require more than simple automation. They require a whole new mindset. Operators need to look at common methods, processes and training that can be applied across the board to all digital services. A configurable, scalable and proven OSS is required to meet this set of challenges for cable operators. In many ways, a cultural shift, vs. a technological one, must occur. Best effort service may suffice for video or data, but not telephony. It’s not just the equipment that needs to go from 88 percent to 99+ percent availability. Personnel, systems and operational procedures all need to focus on keeping downtime to an absolute minimum. It would also be a tragic mistake for operators to continue to think of themselves as a single company providing three distinct services. Trying to manage separate video, data, voice and multimedia service silos with disparate OSSs is a recipe for disaster. To succeed, these services must coexist and be managed as equal partners in a new communications universe … and the OSS must be the center of that universe. Brian Cappellani is CTO of Sigma Systems. Reach him at [email protected].