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

Planning an automatic provisioning system for a local telephone operator

Embed Size (px)

DESCRIPTION

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 - PowerPoint PPT Presentation

Citation preview

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 Access2. Connection cards3. ADSL cards4. 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 overviewProduction systems:• IP DSLAM• ATM DSLAM• VoIP call server• FTTH switchesInformation systems:• ADSL and FTTH port databases• VLAN/PVC database• VoIP subscriber database• PuhtiInterfaces:• Customer interface• Web bank interfaceOther:• 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

IPDSLAM

ADSL port database

VoIP subscriber database

Puhti

Self service/reseller portal

Service Bus

SQL

SQL

SQL

Address database

HTTPXML

Credit information database

HTTPXML

Connection database

SQL

Online banks ???

SNMP

VoIP production systems

SQLSSH/

Shell script

FTTH connection database

SQL

FTTH production systems

SNMPTelnet

ATM DSLAM

SNMP

Customer services interface

Operator interface

HTTPXML

Service busExample:• 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 e-mail 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