Advertisement

  • Business Impact of an OSS Solution Business Impact of an OSS Solution
    Next-generation OSS solutions are designed to help service providers achieve success in the marketplace by delivering superior customer service and rapid time to market for new products and services. A powerful OSS solution can also help service providers meet these goals while controlling and reducing operating costs.

    QoS
    QoS is a measure of the service quality provided to a customer. This measurement can be very subjective, and the ability to define it depends upon the technology being used. For example, circuit networks utilize dedicated, 64-kb connections to support service delivery. This provides high-quality service because only the traffic for a specific session can utilize the dedicated network path, but it also is bandwidth inefficient. For example, if two people on a voice call are not speaking, bandwidth goes unused. In a world where time is measured in milliseconds, even a half-second of unused airtime is an enormous waste of resources, and may be considered poor QoS by a customer. In contrast, consider IP, one of the leading technologies for enabling next-generation communications services. An IP session can utilize multiple paths to complete its delivery and only uses as much bandwidth as it needs, allowing traffic to mix on network paths in order to maximize bandwidth usage. The downside of IP telephony, however, is that its best-effort delivery model does not guarantee delivery of packets in order, in a timely manner, or at all. In this case, the inability to guarantee packet delivery may be considered poor QoS by a customer, who may sacrifice inefficient bandwidth usage to guarantee delivery. Acceptable QoS levels are established and must be maintained in order to retain customers. As a result, service providers must be able to deploy and successfully manage a solution or combination of solutions that meet customer the customer’s QoS requirements. For example, to provide real-time applications over IP networks that meet high customer QoS standards, such as for a financial institution, a solution might include using VPNs and IP over ATM.

    Data Warehousing
    Measuring QoS compliance requires having access to accurate and timely data. While traditional OSSs may be adequate for the service provider’s day-to-day operations, they lack the ability to provide these vital performance metrics. Next-generation OSSs can quickly and efficiently access historical data by taking advantage of data warehousing technology. Data warehousing consists of storing information from disparate systems in a central repository or a single database and carefully managing the data to ensure its integrity. Management can draw upon this valuable asset when access to the latest business intelligence is necessary, not only for QoS analysis but also to analyze market trends and adjust product strategies accordingly.

    Operational Efficiencies
    To provide ROI, an OSS solution must help the service provider execute and hopefully realize productivity gains in their business processes. Most OSS solutions today are considered commercial off-the-shelf (COTS) applications. While some packages do offer out-of-the-box functionality, most are designed to be customized to meet the unique needs and requirements of the service provider. For example, a sophisticated OSS solution will offer workflow management capabilities out of the box and also enable users to create customized and automated processes that take further advantage of next-generation OSS functionality. In this fashion, a next-generation OSS can afford the service provider a realistic means of enhancing and/or re-engineering business processes to reduce costs, increase productivity, and accelerate time to market for products and services.

    The Importance of Flexibility
    Given today’s dynamically changing marketplace, flexibility also is a key requirement in a next-generation OSS solution. A technology-neutral OSS is built upon an architecture that supports current, new, and emerging technologies, enabling service providers to respond immediately to changes in their business climate whether the changes stem from marketing decisions, new technologies, or regulatory requirements.

    more

  • Operations Support of Data Services Operations Support of Data Services
    OSS solutions must be able to support increasingly complex requirements as service providers add new and emerging service technologies to their product offerings. Technologies such as IP, frame relay, asynchronous transfer mode (ATM), and DSL are becoming increasingly prevalent network technologies. While service providers have been managing Frame relay and ATM for several years, the demand for more feature-rich services has necessitated next-generation OSS solutions that support the complexities of service level agreement (SLA) management, usage-based billing, and flexible quality of service (QoS) parameters.
    IP, the technology that drives the Internet, is developing into a carrier-grade technology that will enable a more advanced and widely available mix of voice and data services. Like frame relay and ATM, IP services demand support to ensure high QoS. Two major hurdles must be overcome to ensure QoS. First, service providers must adopt QoS that can map to both connection-oriented and connectionless protocols. Second, they must address the integration of an IP address management system.

    Data Service Provisioning
    For broadband data service offerings, a service provider must address the bandwidth between two locations as well as quality of service and/or service category parameters as they relate to the particular permanent virtual circuit (PVC), such as the ATM virtual circuit (VC) in the example below. After provisioning the equipment, the provider defines a virtual layout for the field to use for the actual mapping of the VC to the equipment.

    Data Service Activation
    To support end-to-end automation, the service provider must be able to pass virtual layout information to the network management layer (NML) for activation purposes. This involves using an NML manager to activate the appropriate equipment. Understanding the service provider’s network is key to this process because service providers cannot activate a PVC for an endpoint that is not under their control. State-of-the-art OSS solutions enable service providers to achieve real-time activation and provide tight coupling between the service management layer (SML) and NML.

    Advent of Broadband Access
    Broadband access technologies also are having a huge impact on a service provider’s OSS. DSLs and cable modems are currently the leading data access technologies being deployed in the United States.
    The DSL technologies that enable existing local loops (the copper wires that connect end users to the public network) to carry higher-capacity data streams come in several flavours. They also permit simultaneous voice and data streams to travel over the same wire pair. To support DSL technologies successfully, incumbent service providers must have an accurate, up-to-date view of their copper infrastructure, such as loading coils and bridge taps. Internet service providers (ISPs) and CLECs also have major concerns about getting access to unbundled loops and a clear view of the communication path to the incumbent provider.

    A central office (CO) must incorporate two components to enable DSL technologies: a splitter and a DSL access multiplexer (DSLAM). The splitter distributes the voice traffic to the POTS network and the data traffic to the DSLAM. It is possible that the splitter will become obsolete as the demand for an all-in-one box increase. The DSLAM communicates with a DSL modem installed at the end-user location and aggregates multiple DSL streams into a switch for transport on high-capacity circuits using various multiplexing schemes. DSLAMs are managed and maintained much like other end-office equipment, but many OSSs do not yet fully support DSL technology. DSL modules must be added to older OSS systems to enable automatic provisioning and management of DSL services.
    DSL technology has several core functions that the OSS needs to support. For example, the DSLAM and splitter, while specific to DSL technologies, are very similar to existing equipment, such as routers and switches, in terms of equipment inventory. Supporting customer premises equipment (CPE), on the other hand, may be a new challenge for the service provider. However, providers with a managed service offering may find they also can handle the CPE network aspects.
    DSL technology has several core functions that the OSS needs to support. For example, the DSLAM and splitter, while specific to DSL technologies, are very similar to existing equipment, such as routers and switches, in terms of equipment inventory. Supporting customer premises equipment (CPE), on the other hand, may be a new challenge for the service provider. However, providers with a managed service offering may find they also can handle the CPE network aspects.


    More complex broadband access scenarios involve incorporating VCs along with voice services. Traditional OSSs have not viewed DSL as capable of providing this type of service. One approach is to handle the cable pair as a channelized T-1 circuit capable of handling both voice and data circuits. The scenarios typically encountered range from offering DSL on the cable pair with no voice service, to offering a small office with multiple users a DSL solution involving voice channels as well as several VCs that each have differing levels of service (such as an analog phone, a PVC for Internet access, a PVC to corporate headquarters, and an Internet phone connection).
    One of the challenges with DSL technologies is that they are susceptible to a number of network pitfalls. For example, local loops that are equipped with special noise filters or load coils will filter out the frequencies at which DSLs operate, rendering them ineffective. Additionally, some services can create interference on DSL lines. If a DSL loop rides in the same bundle as a loop delivering one of these services, the DSL service can be disturbed. Also, some older copper wires, installed years ago, are simply insufficient to support DSL service. Some RBOC regions lack detailed line records that can alert service providers to potential problems; this may be due to line records being kept on spreadsheets or even by hand. As a result, detailed line records may be not only lacking but also not up to date and accurate where they do exist. A strong, next-generation network inventory system is thus critical to the effective deployment of DSL services.

    more

  • OSS Interconnection OSS Interconnection

    Regulations
    A critical portion of the Telecommunications Act of 1996 and its associated orders deals with OSS interconnection. In this context, interconnection refers to regulations requiring the regional Bell operating companies (RBOCs) to allow competitors limited access to their customer databases and various OSS functions, such as preordering, ordering, and provisioning. (Preordering is the process by which a competitive local exchange carrier [CLEC], with permission from the customer, requests data regarding that customer from an RBOC.) The Federal Communications Commission (FCC) will not permit RBOCs to enter the long-distance market until, among other things, they provide interconnection that state regulatory commissions and the FCC have deemed sufficient to enable competition. RBOCs and incumbent local-exchange carriers (ILECs) have built, or are in the process of building, interfaces that provide interconnection to CLECs. Interconnection is an extremely complex and time-intensive issue that the communications industry has been working several years to resolve. In the meantime, carriers often rely on manual means, such as phone calls and faxes, to exchange customer data and service orders. Manual processes are highly error-prone and slow-insufficient in a highly competitive environment.

    Interconnection Challenges
    The largest problem RBOCs face is facilitating access to information residing within their OSSs. Typically, the RBOC OSSs are standalone, proprietary mainframe systems that were never designed to share information with external systems or trading partners. The RBOCs have invested large sums of money in these systems and the data contained within them. As a result, it is necessary to develop applications designed to extract information from RBOC OSSs. RBOCs continue to work toward a solution that facilitates information sharing that meets government requirements for fair competition while retaining the integrity and proprietary design of RBOCs.

    OSSs
    RBOC legacy systems are not designed to partition customer data in other words, to store data for RBOC customers that have sought service with a CLEC, such as in a reseller arrangement. Additionally, external interfaces must be added to facilitate integration with external systems. Without such integration, next-generation functionality such as flow-through ordering and provisioning cannot be achieved. To accommodate next-generation interconnection, RBOC systems must also be able to respond to commands coming from an interconnection gateway in order to fulfil CLEC requests for customer data.
    There are many conceptual and technological approaches to systems integration between RBOCs and CLECs. These approaches involve technologies such as middleware, transaction processors (TPs), workflow systems, and object engines. Middleware is a term commonly applied to integration technology, and it is often used interchangeably with TP. These technologies present common application programming interface (API) into which a system can be integrated to manage data translation and exchange among disparate systems. Workflow systems often work in conjunction with TPs, providing multiple, dynamic APIs and managing data flow and task sequencing, while the TP handles data conversion. Object engines use technologies such as the Object Management Groups (OMG's) common object request broker architecture (CORBA) or Microsoft’s distributed component object model (D’COM). Object engines abstract application interfaces into definable, flexible software objects that allow applications to communicate in a uniform manner.

    While RBOCs work to make their systems accessible to CLECs, they must also develop interconnection interfaces and integrate them with their systems and business processes. Because there is no industry standard or consensus about how this should be accomplished, RBOCs often rely on technologies they already use for information exchange with large customers and interexchange carriers (IXCs). These technologies are not necessarily intended for interconnection but provide the most economical alternative for RBOCs because a large amount of the required application code is already in place. The most common protocol being used for interconnection includes various versions of electronic data interchange (EDI). EDI was originally designed to enable the exchange of business documents, but is now being used for ordering and pre-ordering.

    Gateway/API Functions
    Many vendors have brought flexible gateway and/or API products to market, intended to help CLECs develop the interfaces necessary for interconnection with RBOC OSSs. The TeleManagement Forum, an industry organization devoted to the implementation of telecom standards such as the TMN, has led an initiative to develop guidelines for a common interconnection gateway platform (CIGP). The goal of the CIGP is to apply vendor-neutral, industry-common technologies to OSS interconnection in order to assist CLECs in developing interconnection interfaces. Most of the vendors that have developed gateway products have been involved in the CIGP initiative.
    The primary function of gateways and APIs is to manage the interfaces between CLEC and RBOC OSSs. These interfaces handle data integrity and security between carriers as critical customer and service data is exchanged. One of the most important aspects of gateways and APIs is to perform error checking on service orders as they are passed between carriers. With manual processes, a CLEC often sends service orders to an ILEC or RBOC that end up lost in a pile of faxes for several days. When orders are reviewed, they are rejected if they are incomplete or inaccurate, and this can happen frequently. Incomplete and inaccurate orders are returned to the CLEC for reprocessing. This can add days and even weeks to the ordering process. Gateways and APIs can reduce these errors by reviewing all orders before submission to the ILEC and returning any incomplete or inaccurate orders for instant review.
    Another critical function of gateways and APIs is to facilitate the preordering process. In this process, the CLEC secures permission from a potential customer to obtain customer data from the ILEC. This data consists of a customer profile, outlining all the service provided to the customer by the ILEC. This data is often transferred in the form of universal service order codes (USOC). There are thousands of codes, each of which is typically very cryptic. Manual processing is extremely time-intensive, requiring a CLEC customer representative to research a large catalogue to determine the services provided and to build sales quotes for similar offerings. Next-generation gateways can read USOC codes and match them to a CLECs product catalogue database to automatically generate product offerings and sales quotes, making the CLEC customer acquisition process far more efficient. Once this information is obtained, next-generation OSS solutions also provide product catalogue capabilities that enable customer service representatives to up sell additional related products and services to customers, often in the form of cost-effective service bundles, such as caller I.D., call waiting, and conference calling.


    more

Subscribe to: Posts (Atom)

Followers