1 / 28

Planning an automatic provisioning system for a local telephone operator

Planning an automatic provisioning system for a local telephone operator. Instructor: Jorma Virtamo Supervisor: Jorma Virtamo This thesis was done at Partel. Introduction Services suitable for automation Service delivery processes Systems System interfaces Customer interface

Download Presentation

Planning an automatic provisioning system for a local telephone operator

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Planning an automatic provisioning system for a local telephone operator Instructor: Jorma Virtamo Supervisor: Jorma Virtamo This thesis was done at Partel

  2. Introduction Services suitable for automation Service delivery processes Systems System interfaces Customer interface Putting it all together: the Service Bus Agenda

  3. New services emerge at an ever increasing pace These services often require new production systems Operators need to be able to manage a large number of different systems with different system interfaces Solution: automate service delivery and provisioning processes, so that the different interfaces are hidden from the users Fully automated processes versus partially automated Not all services are suitable for automation When automating processes, they must still be possible to perform manually if the automated process fails Introduction

  4. Introduction :Service Oriented Architecture • Service Oriented Architecture, the new buzzword in provisioning systems • Parts of SOA applied in this thesis • “Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains”* • Capabilities are created to solve a specific problem • Each capability serves one or several needs • Services are used to bring capabilities and needs together • In software development, capabilities are often software functions that interact with the system • Capabilities are represented by operations in this thesis * Model for Service Oriented Architecture 1.0, Committee Specification 1, 2 August 2006

  5. Introduction :What needs to be done? • Find all services that are suitable for automation • Map the service delivery processes thoroughly • Find all production and information systems that are used in these processes • Find all operations used in the processes • Map the interfaces of these systems and determine the interface commands needed to perform the required operation • Determine what changes have to be done in order to automate the processes • Determine the need for new information systems that are needed in the automated process

  6. Services: Suitability for automation Included: • ADSL Broadband • VoIP telephony • FTTH Broadband • Wimax (not covered here) Not included: • PSTN • Cable TV • SDH

  7. Services: General service delivery process • Customer places order • Customer services enter order and customer information into customer and service management system • Potential installation workstage • Potential data programming workstage • Billing workstage • Order ready • Installation and data programming stages vary greatly between services • Other work stages are relatively similar, only the information that is handled differs between services

  8. Services: Puhti • Customer, service and product management, billing • Contains customer, product, contract and billing information • Also handles work distribution • When a customer places an order, customer services enters a new order in Puhti • If the customer does not exist in Puhti, a new customer is entered • Customer services add the desired products to the order in Puhti • If a product requires work to be done, Puhti issues work orders to the personnel specified for the product • When the person has performed his task, he acknowledges the work order. • When all work orders are acknowledged, the service is delivered

  9. Services: Puhti Puhti automation: • All information in Puhti is stored in an Oracle database • The Puhti database structure is very complex and documentation is lacking • Therefore, a thorough interface mapping is not done in this thesis • Getting information from Puhti is simple: SQL select. • Writing is much more complicated: the existing Puhti GUI hides most of the database structure, so when doing changes through the GUI, we do not know how it affects the database. • To automatically manipulate Puhti, we need to map all database tables and relationships between tables required when entering orders, work orders, customers etc. • This is possible but timeconsuming and therefore left for further studies outside this thesis

  10. Services: ADSL Broadband Different services: • New connection • Speed change • Firewall service on/off • Move connection • Change operator Work stages: • Order • Installation • Data programming • Billing

  11. Services: ADSL Broadband Installation work stage: • Installer checks if a copper pair route is connected from the central office/concentrator to the house. • Information currently scattered over several information systems: • Connection database, Microsoft Access • Connection cards • ADSL cards • Electrical charts • If a free route exists, the customer is already physically connected. • If no route exists, the installer must find a new route by searching for free pairs in the information systems. • These are then physically connected to the correct opposite pairs and the connection information is changed

  12. Services: ADSL Broadband Connection database: • Connection points, copper pairs, opposite pairs Installation work stage, problems: • Some information on paper cards • Connection database inflexible • Address connected to a route not mentioned in database • Address information for connection points lacking • Address connected to house connection point not found in database

  13. Services: ADSL Broadband Installation work stage, solutions: • Migrate database to MySQL for more open interfaces • Transfer all data from paper cards to new database • Add fields for connection point address, house connection point address and connected route address • Add correct addresses to all fields where applicable, for correct address information an official address database is needed

  14. Services: ADSL Broadband Installation work stage, interfaces: • SQL interface to the database needed • SQL queries for finding connected routes, free pairs and connection points • Search criteria can be e.g. the address a route is connected to, the address a house connection point is connected to • If no route exists, we need to find one. This is done by searching for opposite pairs in the distribution frames in the connection cabins found on the route from the house to the concentrator or central office

  15. Services: ADSL Broadband Data Programming work stage: • ADSL port information kept in an Excel table. For automation, a MySQL database is being developed. • Two production systems used, Siemens IP DSLAM and Nokia ATM DSLAM • VLAN/PVC values are managed from the table • The data programmer enters the port information for the correct port entry • Finds a suitable VLAN/PVC value. Which one is used depends on whether the DSLAM is based on IP or ATM • Logs into the correct DSLAM and configures the port - Using management terminal for Nokia ATM DSLAM - Using Telnet for Siemens DSLAM • Informs customer that the connection is ready to use

  16. Services: ADSL Broadband Data Programming work stage, interfaces: • The ADSL port database is accessed using SQL. • Ports are identified by port, card, and DSLAM numbers and the local exchange building ID where the DSLAM is located. • Simple SQL select queries are used for searches, update is used for changing the port entries. • Manual DSLAM configuration is done using Telnet or SNMP based management software. Depends on the DSLAM. • DSLAMs can be accessed automatically using SNMP or Telnet. SNMP is better suited for automatic provisioning.

  17. Services: ADSL Broadband Data Programming work stage, DSLAM SNMP interface: • To be able to configure DSLAMs using SNMP, the DSLAM MIB structure must be mapped and the OIDs for each MIB entry that needs to be retreived or changed must be determined. • The DSLAM MIB structure was mapped by capturing the packets sent by the management software and analysing the contents. • By configuring ports with distinct values, the OIDs could be mapped to these values. • When the structure was determined, tests were performed by configuring the DSLAM using SNMP and checking the results through the management software or Telnet interface. • The ports configured using SNMP were tested by connecting a modem to the port, testing connectivity to the Internet

  18. Services: VoIP • VoIP solution based on Asterisk • Configuring a VoIP account is done using management software • VoIP calls can be made using a computer, VoIP telephone or traditional PSTN telephone • If the customer wants to use a traditional telephone with the VoIP connection, an adapter can be purchased. • The adapter must be pre-configured so that it can retreive needed information from Partels web-server when it is first connected. • The VoIP delivery process does not require an installation work stage.

  19. Services: VoIP Data programming work stage: • The subscriber information is stored in a VoIP subscriber database, similar to the ADSL port database. • A new VoIP number is chosen. • The subscriber information is then entered into the VoIP server using management software. This can also be done using SQL. • A configuration file for the customer premises equipment (adapter) must be made. The input needed for this is the CPE MAC address, the VoIP number and the PIN number for the account. A configuration file generator is used for this. • The configuration file is placed on a web server so that it can be retreived by the CPE.

  20. Services: FTTH • FTTH services not yet offered to customers. • The choice of production system yet to be made. • This gives us the opportunity to plan the entire FTTH service delivery process with automation in mind. • A port/subscriber database similar to the ADSL port database is needed. • VLANs are assigned from the same database VLAN database used for ADSL broadband. This ensures that VLAN values are unique if required. • In the initial stages pre-connected routes from the central office to the subscriber premises are not financially feasible due to small amount of subscriptions. (Lasers are expensive!) Physical installation required. • As number of new FTTH connection increases, pre-connected routes become feasible. Physical installation not required. • Service delivery times will decrease significantly when this point is reached.

  21. Services: FTTH Operations: • Difficult to know exactly what operations are required • FTTH port database manipulation using SQL queries • - Get port information • - Set port parameters - Get VLAN • FTTH switch port configuration using SNMP/Telnet - Get port parameters - Set VLAN - Set speed - Other parameters

  22. Customer interface • For truly automated service delivery, we must also automate the customer interface • This is typically done by offering a web page through which customers can place orders • Authentication is difficult, especially for new customers • Web bank accounts can be used for new customers, customer IDs or contract numbers for old customers • The customer interface must have an open interface that passes the order requests to the other systems • If the customer interface needs separate interfaces to every external system, we are heading for trouble! • One solution to this is to use a Service Bus

  23. System overview Production systems: • IP DSLAM • ATM DSLAM • VoIP call server • FTTH switches Information systems: • ADSL and FTTH port databases • VLAN/PVC database • VoIP subscriber database • Puhti Interfaces: • Customer interface • Web bank interface Other: • Wimax systems (not included in presentation)

  24. Service bus • Instead of connecting different systems directly to each other, they can be connected to a central service bus • The systems only need to communicate with one other system • The service bus coordinates requests to and from all other systems • The service bus contains one interface for each system that is connected • Interfaces can also be standardised. We can require that new systems support one of the interfaces of the service bus. • External interfaces are used to connect e.g. customer or customer service interfaces to the bus. External systems can be forced to conform to this interface. (e.g. HTTP/XML) • Internal interfaces are used to communicate with production and information systems. These interfaces make use of e.g. SNMP, SQL, Telnet or some other system specific interface. • When the external XML interface is specified, external players can send their orders to this interface as long as they conform to the specifications. • This allows e.g. resellers and service operators to place their orders directly in the internal systems.

  25. Structure of an automated provisioning system

  26. Service bus Example: • The customer logs into the customer interface • Customer authentication • The customer orders an ADSL broadband connection through the customer interface • The order is sent in the specified XML format to the service bus • The service bus identifies the order and makes the corresponding entries in Puhti. Work orders for the automatic process are created. • The service bus then sends SQL queries to the connection database to find a route for the connection and allocates the required resources. The DSLAM and DSLAM port is returned. The installation work order is acknowledged in Puhti. • The service bus sends SNMP commands to the correct DSLAM to configure the port parameters. The data programming work order is acknowledged in Puhti. • The service bus acknowledges the billing work order in Puhti. • The order is acknowledged and the service delivered.

  27. Service bus Example, in case the automatic process fails: • The work order that failed is changed to manual. This way, the person responsible for the manual work stage can find the work order • The provisioning system can potentially send an e-mail to the person responsible if the automatic process fails • When the manual work stage is acknowledged, the automatic process continues

  28. Summary • Commercial alternatives, expensive! • Platform choice for service bus • New services require changes only in the service bus • Thus, new services can easily be added as long as their production systems have open interfaces • Automation requires fundamental changes in processes and information systems • Benefits include faster service delivery, smaller risk for errors in the processes, greater customer satisfaction, reduced workload and possible savings due to reduced amount of manual labour • Automation can be done to different degrees depending on services

More Related