Figure 1 Major Components of Advanced Communications Network
[Qingwang Hao]
Advanced Services Operations Systems (ASOS) is an Integrated Product Offering (IPO) from Lucent Technologies that provides advanced services operations support to Hybrid Fiber-Coax (HFC) broadband networks. ASOS is equipped with various GIS capabilities for displaying network equipment, alarms, jobs and field technicians over a geographic background of street networks, city boundaries, wire center boundaries, etc., and performing various high performance online spatial operations such as geocoding, reverse geocoding, and spatial data retrievals.
ASOS has been developed and deployed to support Pacific Bell's Advanced Communications Network (ACN) project. This paper gives an overview of ASOS and highlights its GIS architecture and capabilities.
Early GIS applications are often built as standalone systems for specific needs. These applications often do not interact with other applications in real time. The only exchange of information with other applications is through manual file transfer. For a long time, the GIS industry advocated that GIS technology should be the center of a GIS application. This philosophy is reflected in most of the GIS software packages on the market today such as ArcInfo, ArcView, MapInfo, Intergraph MGE, etc. All these GIS software packages have their own programming languages that support applications development. As such, many GIS applications have been built based on the GIS software alone. This approach has been very successful in promoting the GIS technology in many application areas such as environmental planning, resource management, marketing, and also in supporting academic research. While this is a good approach in building standalone GIS applications in some application areas, it has significant limitations in building large scale mission critical business applications such as telecommunications network management. The software that manages network operations are usually referred to as operations systems (OS). Modern operations systems are usually characterized as follows:
The above characteristics are significantly different from traditional GIS applications. It is also apparent that it would be difficult, if not impossible, to build such a system using a GIS software alone.
In this paper, the Advanced Services Operations Systems
(ASOS) that has been developed for Pacific Bell by Lucent Technologies
will be discussed. The focus will be on the GIS components of
ASOS.
ASOS is an integrated operations system for Hybrid Fiber Coax (HFC) broadband networks. It has been developed using object-oriented analysis, design and programming techniques. The architectural approach was to develop a collection of application assets as reusable components that can be integrated in different combinations to meet various needs of different customers. Pacific Bell is one of the first customers of ASOS. It is also by far the largest customer of ASOS in terms of number of application assets. The ASOS product offering to Pacific Bell consists of fifteen application assets that work together to support Pacific Bell's Advanced Communications Network (ACN) initiative. This paper will only discuss the Pacific Bell implementation of ASOS. For simplicity, ASOS will be used to refer to the Pacific Bell implementation in the rest of this paper.
ACN has two major sub-networks: (1) Lucent's second generation Hybrid Fiber Coax access network which carries both video and telephony services; and (2) an interactive video delivery network that interconnects the access network with intelligent video servers to deliver enhanced video services. The key attributes of the network are the intelligent addressable devises called Network Interface Units (NIU's) which are placed at or near the customers' premises and transponders which are placed in most ACN equipment for surveillance purposes. The Fiber Node is a device that connects the fiber portion and the coax portion of the network. Each Fiber Node serves a geographic area in which a collection of living units are located. By having video services and telephony services share many of the same network facilities, the benefits of the operations technology used in both environments can be merged. Figure 1 shows the major components of ACN.
Building and operating the ACN involves three major processes:
The network planning, engineering and construction for most of the HFC network (all network equipment and links except for NIU's) is not managed by ASOS. This process is supported by Pacific Bell's Network Creation Platform (NCP) which includes DB-Able system from Information and Graphics Systems (IGS) for outside plant and Pacific Bell's Central Office Engineering Topology (COET) system for inside plant. After the network construction and testing are completed, the network topology is provided to ASOS.
The provisioning process includes three components: pre-installation of NIU's, customer subscription and service activation. During pre-installation, NIU's are installed at the customers' premises and the NIU "registers" itself with the network. Network element identities are shared, network relationships are established, and soft dial tone service is delivered, all automatically. At the same time, the installer, through a work item, provides the NIU serial number and the living unit address information and the network supplies ASOS with network/service access data. During subscription, the customer calls Pacific Bell to arrange for service. Customer and account information are obtained, desired services/features are determined, and a telephone number is assigned. During activation, ASOS sends messages to the network to dynamically activate the customer requested services and features.
The maintenance process supported by ASOS is proactive as well as reactive. It supports prevention, detection and confirms trouble resolution. In the prevention mode, the work management components of ASOS manages manually entered programmable work items (RF leakage detection, network element preventive maintenance) and automatically dispatches technicians. Network maintenance functions are performed routinely and network elements are replaced before reaching their normal lifecycle. In the detection mode, the detection/analysis components of ASOS routinely performs polling operations to obtain alarm and status information from the network elements and then analyzes the information in the context of the physical network topology. Alarms are correlated to identify failures, to pinpoint their physical locations, and to determine the list of affected customers associated with each failure. The work management components of ASOS, after receiving the network failure reports, generate work items and dispatch technicians for service restoration. If a customer calls in to report or inquire a problem, the customer contact employee will be able to use the service correlation lists to advise the customer with relevant information concerning repair operations.
ASOS interacts with many other Pacific Bell systems for exchanging messages and/or data files as illustrated by Figure 2. The following external systems are directly or indirectly involved in GIS related operations in ASOS: P*B BGIS (Pacific Bell Broadband GIS), LUCI (Living Unit Create Interface), DB-Able, COET (Central Office Engineering Topology), CCP (Customer Care Platform), CPAG (Conversion Processes and Assistance Group), VIP SMS (Video Information Provider Service Management System), and HDT (Host Digital Terminal). P*B BGIS is the single data source for all the geographic reference data as well as parcel centroid locations that are needed to support ASOS operations. It also provides the living unit address change information to ASOS. The geographic reference data provided to ASOS include generic data (county and city boundaries, streets, railroads, rivers and lakes) from Thomas Brothers as well as Pacific Bell specific data (wire center boundaries and fiber node service area boundaries). LUCI provides the initial information of all living units served by the ACN by fiber node. DB-Able and COET are systems used for network design and construction. They provide ASOS with the ACN network topology for both inside plant and outside plant. CCP is the source of customer service requests and customer trouble tickets for telephony customers. CPAG is the source for NIU installation requests at customer premises. VIP SMS is the source of video customer service requests and information provider trouble tickets. HDT is the source of all network alarms.
Figure 3 shows all the components of ASOS and the three-tiered architecture. The whole system is divided into three layers:
The GUI layer provides access to the ASOS applications for invoking transactions. The application server layer is responsible for accepting and processing requests from users and external systems and delivering responses to the requestors as appropriate. A user or an external system request may involve actions by several application server components. The database server layer is responsible for all RDBMS database access and maintenance of the database integrity. The GUI layer does not have direct access to the database layer. Communications between application components, and between GUI and applications are based on CMIP (Common Management Information Protocol) mappable G2++ messages. Communication between an ASOS application and an external system is based on CMIP or FTP depending on the nature of the connection.
As illustrated in Figure 4, the following application assets are directly or indirectly involved in GIS-related operations:
The roles of all the involved components of ASOS in the GIS architecture are briefly described below.
GISDM is a special ASOS component that provides spatial data management and GIS capabilities. It routinely receives geographic reference data and parcel centroid locations from P*B BGIS through an FTP interface and stores them in a central GIS database (GISDB) while at the same time provides online geocoding, reverse geocoding, and other spatial data retrieval services to other application assets via PNDM and GUI. After each update, the geographic reference data are processed and distributed to all GUI workstations as background for displaying network equipment, alarms, jobs and technicians. This is the only component in ASOS that employs commercial GIS software.
PNDM is the ASOS component that provides network topology data management capabilities. It receives network topology data from DB-Able and COET on equipment locations, equipment, and links between equipment during network creation and redesign. It provides network topology information on network elements to LS to support LS's alarm correlation efforts. It also provides the location and address information to MPM and PPM in supporting their effort to create dispatch jobs. The address information in PNDM is retrieved from either LUDM via a parcel number or GISDM via a pair of geo-coordinates. Certain parcel numbers of equipment locations are also retrieved from GISDM.
LS is the ASOS component that performs analysis and correlation of alarms. It accepts network events and alarms from HDT-EM. All alarms are forwarded to the GUI for display and are correlated based on the network topology provided by PNDM to determine root cause or probable cause. Once a root cause or probable cause is determined, it requests MPM to create network trouble tickets (NTT) as appropriate for further processing, which may result in the dispatch of field technicians.
MPM is the central ASOS component for the creation and processing of all maintenance work items (MWI) which include network trouble tickets (NTT), customer trouble tickets (CTT), information provider trouble tickets (IPTT) and for your information IPTT (FYI IPTT). It accepts requests for MWI creation and other related operations from several sources, including LS, CCP via CRM, VIP SMS via VIP GW, FA, and the ASOS GUI. These MWI's may not contain any location and/or address information when they are created. If an MWI requires the dispatch of a technician, such information will be retrieved from PNDM and/or LUDM and a request will be sent to DM to create a dispatch job with location, address and other appropriate information.
PPM is the central ASOS component for the creation and processing of all provisioning work items (PWI) which include telephony customer requests (TSR), video customer requests (VSR), Cutover (COWI), POTS installations (PIWI), and NIU installations (NIWI). It accepts requests for PWI creation and other related operations from several sources, including CCP and CPAG via CRM, VIP SMS via VIP GW, and the ASOS GUI. These PWI's may not contain any location and/or address information when they are created. If a PWI requires the dispatch of a technician, such information will be retrieved from PNDM and/or LUDM and a request will be sent to DM to create a dispatch job with location, address and other appropriate information.
DM is the ASOS component that provides dispatch management capabilities. It provides the engines for processing job creation, update and cancellation, making bulk and dynamic job assignments to technicians. Job dispatch location and other information are provided to the technician through FA. Jobs can be selected based on job status, admin status, work item type, etc. and provided to the GUI for display. Similarly, a technician can also be selected based on their status and skill sets and sent to GUI for display.
FA is the ASOS component that tracks field technicians. It receives dispatch assignments and address information from DM and pass the information to the appropriate technicians through a handheld terminal. It also allows the technicians to update job status and create network trouble tickets. It also provides remote access to other applications for supporting the completion of field work.
LUDM is the ASOS component that manages all living unit information. It receives from LUCI all living unit information, including addresses and parcel numbers which are initially from P*B BGIS. Address updates are received directly from P*B BGIS. The address information is provided to PNDM, CRM, PPM, MPM, GUI and the CPAG system to support various ACN operations.
HDT-EM is the ASOS component that is directly connected to the HFC network. It processes all events and alarms in the HFC network and filters out the non-service affecting ones and forwards the ones that do affect services to LS for further processing.
CRM is the ASOS gateway for processing customer telephony service requests and trouble reports. The processing may result in the generation of the following types of work items: customer trouble tickets (CTT), telephony service requests (TSR), cutover work items (COWI), POTS installation work items (PIWI), and NIU installation work items (NIWI). The work items are forwarded to MPM or PPM for further processing.
VIP GW is the ASOS gateway for processing video customer service requests and communicating with video information providers. The processing may result in the generation of the following types of work items: information provider trouble tickets (IPTT), for your information IPTT (FYI IPTT), and video service requests (VSR). The work items are forwarded to MPM or PPM for further processing.
The ASOS GUI provides map-based user interfaces for network creation, fault management and dispatch management activities, on which network equipment, alarms, jobs and technicians can be displayed over a geographic background with appropriate type and status information. Users are provided with the following capabilities:
ASOS uses a single coordinate system across all of California that is based on a customized Lambert Conformal Conical projection. The reason to have a single coordinate system across the entire region is because ASOS is required to provide users the capability of viewing the entire Pacific Bell territory. The projection parameters are selected to minimize display distortions.
Data management in ASOS is distributed across ASOS components. Each data object is owned by one ASOS component which has full control of the object. Most objects are accessible only by its owner. This is to achieve maximum independence in between application components. However, there are cases when some data objects need to be shared among several components to enforce database integrity and/or to achieve reasonable performance. In such cases, the other components are granted read-only access to the data objects. As such, the entire ASOS database is divided into several logical databases. Among them are GIS Database (GISDB), Physical Network Database (PNDB), Living Unit Database (LUDB), Alarm Database, Dispatch Manager Database, Maintenance Work Item Database, etc., to name a few. All logical databases except for GISDB are Oracle databases and are managed by their perspective owners. The following gives a brief description of GISDB.
GISDB consists of three components: an ArcStorm database that contains all the data received from P*B BGIS, an Oracle table containing all parcel locations which is shared by GISDM, PNDM and LUDM, and a collection of UNIX files that provide the references for geocoding. This does not seem to be a good design. However, there was little choice when the system was first designed in early 1995. At that time, ArcStorm was the only GIS data management software that supports transaction processing and can manage a large GIS database in a seamless manner. If it is designed today, the Spatial Database Engine (SDE) will probably be the product of choice for spatial data management in ASOS. In that case, the ArcStorm component and Oracle component of the GISDB would be in one component since Oracle can be used as the RDBMS for the SDE database. As for the question of whether the SDE database can be used for supporting geocoding is still questionable. The major problem is the creation and maintenance of geocoding indexes within the SDE database. This feature is not supported in the current release of SDE (R2.1). We certainly hope that this will be supported in the future. This is important for mission-critical client-server systems that require geocoding capability at the server side.
To efficiently manage all GIS data, the ArcStorm database is organized into three ArcStorm libraries each of which contains one or more data layers that are close in spatial data density. The detailed street layer and the parcel centroid layer are stored in one library that has the smallest tile size. The state boundary layer is in a separate library by itself and contains only one tile. All the rest of the data layers are organized into another library that has an intermediate tile size. Major factors that determined the final selection of tile sizes are as follows:
The number of I-nodes needed for an ArcStorm library can be extremely large if the tile size is too small. For a tile size of 8 km by 8 km, the number of I-nodes will be approximately 1.2 millions to cover all of California. Although the number of I-nodes in a UNIX file system can be increased, UNIX file systems are not designed to handle such large number of I-nodes. Having a large number of tiles also severely degrades the performance for database create and update operations. On the other hand, data retrieval and display performance favors smaller tile size. Therefore the selection of tile size must be balanced among these factors. The actual tile sizes in ASOS/GISDB are as follows:
The sizes were selected based on extensive performance testing and UNIX administrative considerations. Create and update operations to the ArcStorm database are performed using ArcInfo AML facilities. Data retrieval operations from the ArcStorm database are performed using the ArcSDL library.
The only reason to have a shared parcel location table is to enforce parcel data integrity across all ASOS components. This is achieved using Oracle's referential integrity facility. Parcel additions, updates and deletions are performed using the ArcInfo DBI interface.
The geocoding engine in GISDM is built using the MatchWare Callable Library (MatchWare/CL) from MatchWare Technologies, Inc. The implementation requires an address reference file, a shape file, and an index file. These files are created and updated as the ArcStorm database is built up. It is true that geocoding is supported by ArcInfo, its algorithm does not meet the requirements of ASOS since it does not allow misspelling of addresses. Although ArcView also provides geocoding capabilities, it is not suitable to be used in an online server environment because of integration constraints and its limited flexibility for customizing matching specifications. Besides, neither ArcInfo nor ArcView can geocode directly based on the ArcStorm layer. Therefore, even ArcInfo or ArcView is used for geocoding, a separate address coverage or shapefile must also be created for this purpose. This gives ArcInfo and ArcView little advantage over MatchWare/CL. On the other hand, MatchWare/CL has significant advantages. First, it is provided as a C library. Therefore it is straight forward to integrate it into the ASOS/GISDM architecture. Second, it provides very high speed. Our experience indicates that only a small fraction of a second is needed to geocode an address on an HP G40 machine. It would take even less time on a HP T500 server which is the ASOS application server machine in production. Third, it has an state-of-the-art address matching algorithm that provides a high hit rate even with misspelled and truncated addresses. Fourth, it is highly customizable. This is important to meet specific requirements.
Because one coverage may need to be put into two
GISDB components, a transaction control mechanism is implemented
in the GISDM create and update process. The transaction mechanism
guarantees that the whole process is atomic for any data layer.
For example, a street coverage is either put into both the ArcStorm
database and the MatchWare reference files or not put into any
of them at all.
Spatial data in ASOS is loaded from the following sources:
GIS data is loaded from P*B BGIS in four load types:
Major steps of the data loading process are as follows:
Network topology data is loaded from DB-Able and COET in six load types in a manner similar to GIS data loading method. Network topology continuity is checked during the loading process. Since the coordinates are stored in NAD83 State Plane coordinate system in the NCP systems, they are converted to the ASOS coordinate system based on the Lambert Conformal Conical projection. Living unit data loading from LUCI and P*B BGIS is also based on an FTP interface.
Since GISDM is the major GIS component of ASOS, this section examines the GISDM architecture in more detail. As shown in Figure 5, all GISDM processes can be divided into three categories:
The database maintenance processes are responsible for data loading from P*B BGIS and distribution of converted GUI GIS data to all GUI workstations. Major steps of this process has been described in the ASOS Spatial Data Loading section. The rationale and functions of the daemon processes are briefly described as follows.
There are different approaches in distributing GISDM functionality into different server processes. The three basic approaches considered are as follows:
In GISDM, the second approach has been adopted because of several reasons:
There are five GISDM application server processes:
Basic functions of the communication gateway process are as follows:
Three approaches are considered in designing the communication gateway:
The first approach is adopted because of the following reasons:
As demonstrated above, ASOS is a very sophisticated system that is composed of many components. The GIS-related operations are distributed across several components while GISDM provided the major GIS functions. Because of the scale of the project, ASOS is developed in a distributed environment. The different development teams belong to many organizations within Lucent and are located in several geographic locations. Developing the GIS functions in such an integrated system posted many challenges that do not exist in the development of traditional GIS applications.
One of the decisions made during the early stages of the project was to use Lucent's proprietary GUI building tool DCS (Display Construction Set) for all ASOS GUI components. One of the reasons was for consistent look and feel. Another reason is that ASOS decided to use uniform communication protocols across all ASOS components. While both ArcInfo and ArcView support inter-application communications, the RPC (remote procedure call) protocol used in ArcInfo and ArcView was not the protocol chosen by ASOS. A third reason is more organizational than technical. ASOS management made a decision to have a central GUI team for the development of all ASOS GUI components. This team had extensive experience with DCS but had little knowledge of GIS and commercial GIS tools. All these factors contributed to the final decision. The successful completion of the GUI development proved that the decision was not unreasonable. However, the ASOS GUI is rather primitive in terms of GIS capabilities. As more and more companies choose Windows as their GUI platform, Lucent's future GUI products will primarily target the PC platform using off-the-shelf GIS components such as MapObjects for building the GUI GIS capabilities.
ASOS is a distributed client-server system in which the client workstations access the application servers through a wide area network (WAN). Ideally, all data should only be stored in a central database that can be accessed by all workstations. In ASOS, however, all GIS data are reformatted and distributed to all GUI workstations. There are two major reasons for doing so. First, because of the magnitude of the data volume, dynamic retrieval of GIS data across a WAN may not be feasible for a system like ASOS that has hundreds or even thousands of users. Doing so would create significant network congestion and severely affect the performance of the entire system. Second, the GIS data management system ArcStorm does not provide such capabilities. Remotely mounting the GISDB file system on all GUI workstations over a WAN is not only unreliable but also violates the requirement of independence between the GUI and the database. There have been discussions of replacing ArcStorm with Spatial Database Engine (SDE) in future releases for its true client-server capability. However, network performance still remains a big concern.
ASOS as a whole is an object-oriented system. The OO technologies are applied in nearly all phases of the development process, including requirements definition, system analysis, system design, and implementation. C++ is the language that was chosen for implementation. There are several reasons for using the C++ language for ASOS implementation.
To the implementation of GISDM, the last item was
more significant. While it is possible to use ArcInfo's interpretive
AML language for the implementation of most of the GISDM functions,
it is impossible to meet the requirements for inter-application
communication, error logging and tracing. Besides, the AML implementation
of some of the online functions was also considered to be insufficient
on performance. One performance requirement is that on average
a user should get a response in 2.5 seconds after issuing a request.
This includes time for communication, application processing,
database processing, and GUI display. Because of these issues,
GISDM has been implemented using a mixture of AML, and C++ with
ArcSDL, and MatchWare/CL. Specifically, ArcStorm database create
and update operations are performed by an ArcInfo RPC server
executing AML scripts. C++ is used for implementing the create
and update of the geocoding reference files. The create and update
main process flow, error logging and tracing are also written
in C++. The RPC mechanism is used for the communication between
the create and update main process with a ArcInfo RPC server
process. All the GISDM server processes are implemented using
C++. Access to the ArcStorm database and some INFO files are done
through ArcSDL functions. Access to the geocoding reference files
and address matching functions are performed through MatchWare/CL.
Many problems were encountered in the integration of all these
components, some of which required assistance from Esri and MatchWare
Technologies for appropriate resolution.
This paper discussed some GIS-related issues in the
development of the Advanced Services Operations Systems (ASOS)
for Pacific Bell. ASOS is an integrated product that consists
of many application assets in which GIS-related activities are
distributed across many assets. Integrating GIS capabilities in
such a large system posted tremendous challenges that would have
never been encountered in developing smaller standalone GIS applications.
Developers have less freedom in choosing GIS tools for implementation
because of some architectural requirements and constraints. Our
experience also indicates that the traditional GIS tools such
as ArcInfo and ArcStorm are less than satisfactory for developing
large scale integrated systems. Many system components must be
developed using low level routines to meet stringent architectural
and performance requirements. The newer API-based SDE product
may provide some advantages for this type of systems development.
However, it also has significant limitations, at least in its
current release. To complement SDE's limitations, Esri is developing
a GISData Server [1]. The architecture of the Esri GISData Server
is very similar to the ASOS/GISDM architecture except that it
uses SDE instead of ArcStorm. However, it still stores data separately
from the SDE/Oracle database for the purpose of geocoding and
routing. While this is indeed a solution, in my opinion, it should
only be considered as a short term solution. For SDE to become
a truly robust component for building mission critical systems
like ASOS, it needs to provide a way to support high performance
geocoding and routing capabilities without storing large amount
of data at the operating system level. The structure of the ASOS/GISDB
as well as the Esri GISData Server database is not a robust solution
since it complicates the database backup and recovery procedure.
As for the client side, MapObjects seems to be in the right direction
for embedding GIS capabilities into large scale operations systems.
It is unclear at this point whether ASOS will be upgraded with
the new generation of GIS tools. It is clear, however, that these
new tools will be used in Lucent's new GIS-related operations
systems development.
The development of ASOS and in particular the GISDM
component has been a truly team effort. It would have been impossible
without the contributions of all team members from both Lucent
and Pacific Bell. TASC, Applied Geographics, MatchWare Technologies,
and GIS Technology also contributed to the implementation of GISDM.
I would like to thank Ken Fitzgerald for initiating the effort
for a paper presentation at this conference and for actively supporting
this effort. My thanks also goes to Bart Goldberg of BFR, and
Jan Ledoux and Donna Murphy of Pacific Bell for reviewing the
draft manuscript and providing insightful comments.
[1] "Esri Develops Tools to Complement SDE",
Esri ARC News, Fall 1996, p.33.