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

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

Introduction 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 : 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

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

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

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

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

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

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

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: 1.Connection database, Microsoft Access 2.Connection cards 3.ADSL cards 4.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

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

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

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

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

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.

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

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.

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.

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.

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

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

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)

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.

Structure of an automated provisioning system

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.

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 to the person responsible if the automatic process fails When the manual work stage is acknowledged, the automatic process continues

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