Download Installation work stage, interfaces

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

SQL wikipedia , lookup

Microsoft Jet Database Engine wikipedia , lookup

Microsoft SQL Server wikipedia , lookup

Database wikipedia , lookup

Concurrency control wikipedia , lookup

Open Database Connectivity wikipedia , lookup

Database model wikipedia , lookup

Relational model wikipedia , lookup

Clusterpoint wikipedia , lookup

ContactPoint wikipedia , lookup

Transcript
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.
2.
3.
4.
•
•
•
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
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
Online banks
???
Self service/
reseller
portal
Customer
services
interface
Operator
interface
HTTP
XML
Puhti
SQL
Address
database
HTTP
XML
Credit
information
database
HTTP
XML
Connection
database
SQL
ADSL port
database
SNMP
IP
DSLAM
SQL
SNMP
ATM
DSLAM
VoIP
subscriber
database
SQL
SQL
SSH/
Shell script
VoIP
production
systems
FTTH
connection
database
SQL
SNMP
Telnet
FTTH
production
systems
Service
Bus
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 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