Paper #221, Location Services II

2001 Esri User Conference

Tuesday, July 10, 2001

3:30 PM - 5:00 PM

Room 19 - SDCC

An Architecture for Providing Location-Based

Telecommunications Applications Services

Clifford Behrens, Marek Fiuk, Chung-min Chen and Chit Chung

Abstract

Recent activities at Telcordia Technologies have focussed on delivering to customers over the Internet new telecommunications services, based on an architecture that uses location to integrate telecommunications and commercial geospatial data. ArcSDE® provides a consistent means for accessing data stored in different commercial databases; ArcIMS® is exploited to build maps with these data that can be delivered to thick (or thin) clients. This framework also provides the software interfaces needed to integrate highly-customized applications. An initial implementation of this architecture demonstrates its applicability for supporting interconnection consulting, network planning and service negotiation with Telcordia COMMON LANGUAGE® Products, specifically the LocateIt® System and CLONES.

1 Introduction

Telecommunications enterprises store information about their operations in disparate Operations Support Systems (OSSs). Through government deregulation and greater market competition, there are now compelling reasons to devise new ways of integrating this information to support next-generation network operations and services. Few keys seem better suited to enable integration of telecommunications applications data than location. Location, while having many representations, is already stored for data in some legacy products, and next generation OSSs are increasingly becoming locationally-aware. Georeferencing makes it possible to query databases spatially for useful information, but also creates an opportunity to summarize this information in maps.

Recent research activities at Telcordia Technologies have produced an architecture for delivering to customers over the Internet new map-enabled services that integrate telecommunications and commercial geospatial data. Esri's ArcSDE® provides a consistent means for accessing data stored in different commercial databases, and Esri's ArcIMS® is used to build maps with these data that can be delivered to thick (or thin) clients. An initial implementation of this architecture demonstrates its applicability for delivering map visualizations that support interconnection consulting, network planning and service negotiation, and other telecommunications business operations.

2 Business Challenges

In the past, as work associated with the planning, provisioning and maintenance of the public telecommunications network became automated, each of these functions became supported by separate work centers, unique operations support systems, and specialized craft persons skilled in the disciplined use of these. A consequence of this long legacy is the existence of many non-interoperating systems and the proprietary data they produced. Product groups formed around these systems and their data, with little concern for systems interoperability and data sharing.

The Telecommunications Act of 1996 has created a competitive environment that has forced existing service providers and their suppliers to think about their businesses in new ways. Data that were once viewed as disparate, and only needed to support one step in a service provider's business model, are now being examined with the more comprehensive view of enabling new business "solutions" models. These require a much tighter integration of systems and data. This focus on business solutions has motivated some to search for new approaches to system integration and data reconciliation.

Table 1. Locational referencing of telecommunications data.

Data Type	Example
Geographical coordinates	N402531 W1044736
Street address	700 71ST AVE, GREELEY, CO 80634
V and H	7350.00 5909.00
CLLI® code	GRELCO05
NPA/NNX (Area Code)	970
Misc.	place names, postal codes, FIPS, etc.

One approach to realizing the "solutions" view is to combine proprietary georeferenced data with other commercial sources, then build new services on these that support high-level decision-support functions, e.g., network planning and design. There are many obstacles to implementing this approach in the telecommunications domain where systems (and their data) have evolved independently. Data tend to be extremely heterogeneous and while many data have some locational references, these vary across applications in their coordinate system, scale, accuracy, syntax and format. For example, Table 1 above summarizes the manner in which locational referencing is provided for data managed by Telcordia software applications, using Greeley, Colorado as an example. In some cases geographical coordinates are provided for a feature. But this information may be stored in degrees, minute and seconds, or only in degrees. Moreover, the syntax applied to this information can vary in the use of "N" and "W" or "+" and "-" prefixes to indicate hemisphere; and there typically is little or no information about the reference datum for these coordinates. In some cases, only a street address my be available to mark location, and the number of characters available for this field may vary among different applications (with older systems constrained by shorter fields). The different abbreviations used in street names creates a significant data reconciliation problem. However, if a valid address is found, there exist numerous gazetteers that can provide map coordinates for it. Another way of representing location for telecommunications features is V&H (Vertical and Horizontal) codes. This is a transformation applied to geographical coordinates, developed years ago by researchers at Bell Labs, to simplify distance calculations. Here again, information about the datum used to reference the original geographical coordinates has often been lost. COMMON LANGUAGE® Location Codes (or "CLLI® codes") are another data type used to represent location of telecommunications features (discussed below in more detail). These codes typically have a "natural language" flavor, e.g., GRELCO resembles Greeley, CO, and may also have associated with them geographical and/or V&H coordinates. The NPA/NXX (or area code) is typical of a number of polygon-type data that may be referenced geographically by their centerpoints, or may even have boundary lines for them. (Wire Centers, LATA, Customer Servicing Areas and Distribution Areas are other examples of telecommunications administrative units for which commercial digital map data can be obtained.) Finally, a wide assortment of other data types such as unique place names, postal codes and other Federal Information Processing (FIPS) codes are also found in telecommunications applications data. From this brief overview, it is easy to appreciate the difficulties involved with using location as a means to integrate information across telecommunications systems.

It is also important to note that, while the solutions view emphasizes data sharing and systems interoperability, different telecommunications business processes still possess different requirements for geospatial data and software. For example, much higher resolution data are required to support processes such as network design and maintenance than network planning and service negotiation. Furthermore, while network engineering functions require many of the capabilities of a commercial GIS by exploiting relationships between map layers, other functions, e.g., network monitoring, often only use maps as a backdrop or canvass for a network display. The challenge is to create an environment that reduces the cost associated with data redundancy and software "overkill," yet provides only the data and software capability required by an application. The rest of this paper describes our recent efforts to address this challenge in a project that leverages location to provide map support over the Internet for two COMMON LANGUAGE® Products: the LocateIt® System and CLONES.

2.1 COMMON LANGUAGE, LocateIt and CLONES

Telcordia develops and sells location-based products as part of its COMMON LANGUAGE offering. These products combine numerics and mnemonics to establish code sets that are easy to remember and provide users with a shared method of identifying network components, interfaces and equipment. These products were created to help telecommunications companies exchange critical information with accuracy and precision to better achieve OSS interconnection.

The COMMON LANGUAGE® Address Analysis (LocateIt®) System is an application that provides precise geographic information for addresses, intersections, off-road points, and geopolitical boundaries. It features unique analysis and search algorithms that transform incomplete and partially inaccurate information into meaningful address information. The architecture of the LocateIt System is based on object-oriented software technology and uses OSMOS®, a Unisys® object-relational database management system. LocateIt can be accessed through a customized application programming interface (API) via client/server architecture, as a turn-key information system on a variety of platforms, as an interactive dial-up service, or as a batch reconciliation facility. It has been applied to solve a variety of business problems that require accurate geographic data analysis, such as communications switch box location, shipping address verification, sales lead identification, map drawing, tax jurisdiction identification, and determination of pricing for distance-based services.

The LocateIt system uses Dynamap/2000® and ZIP11 Address Coding Guide® data as data sources; the Dynamap/2000® data are updated on a monthly basis. These data include primarily street lines with the address ranges needed for performing address validation. The LocateIt system applies fuzzy logic algorithms to these data to produce valid addresses for an address it receives as input.

The Central Location Online Entry System (CLONES) is used to create, update and maintain all valid COMMON LANGUAGE Location Codes. CLLI codes are unique 11-character standardized geographic identifiers used worldwide to identify and describe three types of locations and entities placed at each: (1) network sites/entities, including such network locations as central office buildings, business and commercial offices, microwave radio structures and earth stations, (2) network support sites, including such locations as international boundaries or crossing points, end points, fiber nodes, cable and facility junctions, manholes, poles and repeaters, and (3) customers sites, including customer locations and associated circuit terminations, facilities or equipment for each specific customer. CLONES data are managed with the Informix Dynamic Server® DBMS, and currently access to CLONES is provided to subscribers through a text-based client, a telnet connection, or an RPC interface. It is important to point out that CLONES is a client for LocateIt as the latter provides address validation services to CLONES users as they create new CLLI codes.

The COMMON LANGUAGE product team, located in Telcordia's Software Systems organization, is eager to evolve its product line and explore new markets for its data and services built on these. A project was funded to explore the feasibility of providing map support for the LocateIt product (and to its clients that require address validation services), and of providing CLONES with a map query frontend and map visualization capability so that information stored in CLONES could be presented to remote users in maps. The latter capability might be particularly important to support Professional Services' business models, e.g., interconnection consultants who want more rapid access to CLONES information when working through planning scenarios with their customers. These model applications of the LocateIt and CLONES products have been useful for driving our thinking on prototype design. The attendant technical issues are described next.

2.2 New Business Applications

New Internet mapping services are being developed to support address validation by LocateIt, and to deliver maps of telecommunications features stored in the CLONES database. While some requirements and technical issues are shared by these two applications, e.g., data security, others differ and require somewhat unique approaches.

The motivation for providing mapping support for LocateIt was to improve the quality of address information in Telcordia databases. Address validation is a service with many potential clients, human and machine. Furthermore, since the LocateIt database is updated on a monthly basis, it is most cost-effective to use its data as a central source of address information for other Telcordia client applications. To make LocateIt services available to these clients it was necessary to update its API and make it more readily accessible to users over the Internet. In the latter case, it was assumed that a user could input an address, then the LocateIt system would return a valid address (or list of potentially valid addresses). The user would then be given the option of mapping these for further validation before permanently storing an address in a data base. Since this type of user only needs a map showing the valid address with minimal support of other layers, e.g., state boundaries, highways and roads, wire center boundaries, streets and CLONES site locations, and required little interaction with objects displayed in the map, only a thin (HTML) client was required. This level of map support is sufficient for those who only need to use the LocateIt system for standalone address validation, or for CLONES users who rely on the LocateIt system to validate addresses for their CLLI codes.

Interconnection consultants had more complex mapping requirements. First of all, additional map layers were required to provide proper context for CLONES information in their planning scenarios. For example, consultants are interested in knowing something about the demographics of a planning area, e.g., density of households and their average income for US Census Bureau's Block Groups, along with the telecommunications facilities deployed at sites within the planning area, such as "entities" recorded in the CLONES database. Since these consultants might also be working in areas less familiar to them, it is important to have more interaction with map features, richer visual cues, and more options to query CLONES spatially. Typically, these consultants have access to high-end desktop or laptop computers (with at least 128MB of physical memory). For this group of users a thick JAVA® client, capable of rendering maps and revealing attribute information for features in them, was required.

Our project team was tasked to deliver an architecture capable of supporting the requirements of both types of LocateIt and CLONES users. In addition, this architecture had to make maximum reuse of existing applications software, eliminate data duplication, minimize data and software licensing costs, provide a consistent means for accessing data stored in a variety of COTS DBMSs, and produce map visualizations from Telcordia and commercial data that could be delivered to either thick or thin clients over the Internet. This comprehensive set of business requirements led us to propose an Esri-based architecture.

3 Architecture and Implementation

Several technical issues needed to be solved before mapping support could be provided to LocateIt and CLONES users. Among the most critical of these was that all CLONES data, including locational information, were stored in Informix Dynamic Server business tables as simple data types. For mapping to be cost effective, programmatic means needed to be developed to create geometry for these attribute data, i.e., to spatially enable these tables. The intent was to accomplish this in a way that minimized the need for costly data conversion, and made it possible to create geometry for new CLLI® codes as they were created. (Our solution to this problem is discussed below.) Another major design consideration was to access map layers common to both LocateIt and CLONES applications from a single source, yet deliver these data with the resolution required to support the particular needs of both types of users. It was also anticipated that there would exist sometime in the near future a need to integrate the data exploited by CLONESand LocateIt with other Telcordia and non-Telcordia data, so a solution providing a consistent means for querying all of these data was desirable. For the reasons above, we proposed the TIMS (Telcordia Internet Map Service) architecture (shown in Figure 1) that makes use of Esri's ArcSDE and ArcIMS products.

Figure 1. Architecture of the Telcordia Internet Mapping Service for COMMON LANGUAGE Products.

As mentioned earlier, the LocateIt application is accessed by CLONES users, either through the CLONES application itself, or through the CLONES client. Another remote access mechanism is provided through a special-purpose RPC interface. To make the LocateIt application more accessible to both machine and human interfaces, a JAVA-RPC API is being developed. (This work is described below.) Map support for the LocateIt application is provided by an ArcIMS image server since only thin-client support is required. ArcIMS gets its CLONES map data through an ArcSDE® for Informix® interface, and other GDT® map layers stored in an Informix Dynamic Server database, also using ArcSDE for Informix as a data access mechanism. In this architecture a user may input an address into a Web browser and send it to the LocateIt service for validation. LocateIt returns a valid address (or list of possible valids) along with its geographical coordinates. These can be sent to the TIMS server with the information needed to render a map with the valid address as a centerpoint, or with the minimal bounding rectangle containing all of the points returned by the LocateIt system. The user can then determine whether the address is indeed valid, while also having the option of turning on/off available map layers for additional context. The map service just described supports only address validation. Again, this service is the same regardless of whether a user inputs an address directly to the LocateIt service through a Web browser, or through the CLONES system.

For interconnection consultants, CLONES provides a valuable source of data layers that require additional query support. Greater interactivity is provided by the ArcIMS feature server since it delivers map features along with their attributes. While some of the same data layers exploited by the LocateIt service can be accessed through ArcSDE and reused for this application, e.g., state boundaries, roads and wire center boundaries, access to other data layers is essential. The TIMS architecture allows some of these layers to be stored on the local map server and others on the client. This is particularly attractive when data are private, or when these data are very high resolution, making it undesirable to transport them over the network. For interconnection consultants, the ArcIMS JAVA client (with customized helper applications) is provided to users. As an example, one of these applications creates dialog boxes needed by a consultant to query CLONES for information about facilities deployed at network sites, represented as push-pins on a map. Another custom application allows a user to track his/her current location on a map taking input from a GPS receiver.

3.1 Address Validation Server

We chose to Web-enable the LocateIt server in the JAVA development environment because of its simplicity, multi-platform support, performance and scalability qualities. In fact, it's the only environment that offers scripting (JSP) and compiling (Servlet) alternatives employing the same language. Since LocateIt is currently implemented in C, not JAVA, a gateway or bridging technology was needed to link the JAVA Web server environment with the backend LocateIt server.

The existing LocateIt application is an RPC server that conforms to RFC 1831/1832. Our objective was to reuse this server with only the fewest changes necessary. All C RPC implementations provide an interface file called the .x file that specifies both a server application's data and procedures. Therefore, we were able to map JAVA calls to this specification so that the LocateIt server receives the same data stream for each procedure invocation. To accomplish this mapping and enable communications between JAVA clients and the LocateIt server, we used the Distinct ONC/RPC Toolkit®. One interesting aspect of this approach is that it supports JAVA-RPC communications in both directions. That is, an RPC server can also be implemented entirely in JAVA and called by C clients. This offers additional flexibility should the LocateIt product team decide to convert the LocateIt server to JAVA later on.

We have enabled LocateIt services to three types of Internet clients: Browsers capable of supporting XML, HTML browsers not capable of supporting XML, and programmatic XML clients. In our architecture, clients transmit HTML or XML messages encoding the service to be invoked (and their required parameters) to a Web server. To comply with industry standards and maximize the potential customer base, the XML messages are expected to conform to the SOAP1 1.1 specifications. The Web server houses a security engine which intercepts all requests and authenticates the requesting client, prior to passing the request to a presentation-processing engine. (Authentication is based on a previously acquired token provided to the requesting client during login.) The presentation-processing engine accepts these requests and, in the case of HTML, converts it to an XML message as if coming from an XML client. The XML message is then passed to an XML engine where the message is parsed and the corresponding backend LocateIt service is invoked. When the response from LocateIt is returned, the XML engine formats it into an XML response message and sends it back to the presentation-processing engine where the message is converted to HTML or passed directly through as XML, depending on the client. The presentation-processing engine may also pass an XSL style sheet as part of the XML processing instructions to a XML capable browser. This allows the client to fetch the style sheet associated with the XML and perform the intended rendering. The valid address information returned in the message, specifically its associated geographical coordinates, can then be used to query the TIMS map server.

3.2 Map Server Implementations

ArcIMS servers can be deployed as feature or image servers. The former delivers map features and their attribute information as XML objects for rendering by a thick client; while the latter renders a map and delivers it to a thin client as a bitmap. The TIMS architecture exploits both the feature and image server models.

3.2.1 Feature Server

Esri's ArcIMS feature server was chosen to deliver map information to interconnection consultants. The advantages of this option for this application included optimized local processing of frequent user requests (e.g., turning layers on/off, MapTips, feature highlighting) while minimizing involvement of the map server itself. This results in a mapping service that is more scalable, minimizes the number of roundtrip requests to the server and hence the impact of network congestion, and fast manipulation of map layers. There is also some support for dynamic creation and manipulation of map features (described later) and local rendering of the map data stream enables data caching on the client side.

The TIMS feature server does have some limitations. At the moment, the ArcIMS feature server supports only the Microsoft Internet Explorer® Web browser. Furthermore, the Arc IMS JAVA client requires a one-time downloading of several software components whose multi-megabyte size practically precludes initial connection with the TIMS image server through a dial-up modem.

3.2.2 Image Server

Esri's ArcIMS image service was selected to deliver maps to LocateIt and CLONES users because this option provides a solution for generating simpler maps involving less data processing. Consequently, there is no need for specialized proprietary software components and maps can be presented on both Microsoft® and Netscape® Web browsers, yielding more widespread deployment on the Internet.

The TIMS image server also has several limitations. Nearly every user action results in a request being sent to the image server, which obviously makes this alternative less scalable (though multiple servers can be run in parallel to mitigate performance problems). We have found that for maps with high-resolution features, e.g., parcels, there is noticeable degradation in server response time when compared to the feature server. In addition, certain tools that require local handling, e.g., MapTips, are not supported with this server option. Since the JAVAScript® library doesn't provide any facilities to implement dynamic layers, features cannot be animated; nor is there support overlaying local layers on a map.

3.2.3 Spatially-Enabling CLONES

ArcSDE provide a gateway for ArcIMS to access spatial data stored in relational or object-relational databases. The CLONES database stores spatial information, namely longitude and latitude, in two separate columns of fixed-length character type. Spatial information stored in this format cannot support efficient processing of spatial queries such as radius search. A better approach, which we have taken, is to use the Informix® Spatial DataBlade®, which supports native geographical data types and operations. After the CLONES database is spatially enabled, ArcSDE communicates with the Informix Dynamic Server via ODBS to run spatial queries and retrieve the results.

Informix's Spatial DataBlade allows users to define geometric columns that are directly supported by a DBMS. In our case, we create a column of ST_POINT type for each of the network site, network support site and customer site tables. The ST_POINT type is a sub-class of ST_GEOMETRY type and represents a point on a map. These columns are automatically generated by ArcSDE when the spatial layer is created. In addition, for each spatial column, the Informix Spatial DataBlade creates an R-tree index. R-tree is a 2-dimemsional generalization of B-tree and supports more efficient searches of spatial objects. While R-tree adds space overhead to the database, its performance gain on the search can be very beneficial.

The first step to spatially-enable a CLONES table is to register it with ArcSDE. This is done through the ArcSDE command "sdetable -o register -t

...". Alternatively, this can be done via the ArcSDE C API SE_registration_create(). Next, a spatial layer (a column) is created using the command "sdelayer -o add -l ". Alternatively, this can be done via the C API "SE_layer_create()". This command tells the Informix Dynamic Server to create a spatial column of ST_POINT type for the table. Up to this point, the spatial column is still empty. To populate it using the existing longitude and latitude information in the table, we choose to export this information to a file. The data are then converted to ST_POINT type and loaded to the column using the conversion function "ST_PointFromText ()".

When a CLLI® code is added or updated, the spatial column must be updated accordingly. There are various options to achieve this: (1) write an accompanied SQL statement to update the spatial column for each insert/update statement in the CLONES codes, (2) define a trigger for each insert/update statement that calls an SQL procedure to modify the spatial column, or (3) perform updates periodically as a batch process. We have chosen option (2). The first option is not satisfactory because it requires non-trivial modification of the existing CLONES server application. Also, because data accuracy is a major concern in CLONES applications, the third option is not favored. Once the CLONES database is spatially-enabled, mapping services can be defined and provisioned through ArcIMS, which connects to ArcSDE to access and query the spatial data stored in the Informix database. All of these map layers can be secured by placing each ArcSDE server behind a firewall.

3.3 Client Implementations

As mentioned before, the TIMS delivers maps to thick and thin clients, depending on whether the map is sent by an ArcIMS image or feature server. The capabilities of each are described briefly along with some key TIMS customization features.

3.3.1 Thick TIMS Client

With the thick TIMS client, an ArcIMS feature server renders maps requested by a client machine into the stream of map data and delivers it to the client machine. JAVA applets on the client machine render the data stream into maps, e.g., a detailed map and an overview map, and also feed it to other elements in the user interface such as a legend and scale bar. A screen snapshot of this client (running with the Internet Explorer browser) is shown in Figure 2.

Figure 2. The "Thick" TIMS Client.

Much of the functionality provided in this client already exists in the ArcIMS JAVA client; however, some customization was required to provide additional features important to interconnection consultants. Applets expose interfaces that can be exploited programmatically by custom scripts embedded in the TIMS client Web pages. Client-side events result in either a request being sent to the TIMS server or (in many cases) handled locally by an appropriate applet. For example, the TIMS map applet provides methods for manipulating, e.g., selecting, map features and retrieving data associated with these. It is also capable of generating locally maintained "acetate" layers that provide additional mechanisms for (limited) programmatic creation and manipulation of point-type map features.

The power of this approach can be better appreciated by closely examining Figure 2. The availability of map layers automatically adapts to the current map scale, and a user can select any of these layers to create maps that overlay point, line and polygon features. Certain of these layers can also encode numerical results in choropleth layers, such as the Block Groups layer that shows the concentration of households for block groups in the Greeley, CO study area. Other "out-of-the-box" tools are demonstrated in the figure. These include MapTips (the CLLI® code "GRELCOBC" for a network site, represented by a blue dot, is displayed when the cursor passes over it), and Identify which, after selecting a layer (e.g., CLONES Sites), allows a user to click-on a feature to query a backend database (in this case CLONES) for more detailed information about it (as displayed in the "Identify Results" box). In addition, we have written an applet that creates a Web page dialog through which a user can query a network site (or sites) for CLONES entity types, such as Frames, Non-Switching Entities, Software Entities, Analog Equipment and Digital Equipment. Animations for mapping dynamic features, e.g., moving vehicles, have also been introduced in TIMS maps through the use of acetate layers, represented by the red point labeled "My Location," which when demonstrated actually traces a path over the transportation network.

3.3.2 Thin TIMS Client

The "thin" TIMS client requires no more software than an HTML browser to display maps since all of the rendering is performed by the ArcIMS Image Server. A screen snapshot of this client using the Netscape browser is shown in Figure 3.

Figure 3. The "Thin" TIMS Client.

As with the thick client, much of the functionality of the thin client is currently "out-of-the-box." This client does have a somewhat different look but notice that many of the same tools, e.g., zoom, pan, Find, and Identify, are available. For example, Figure 3 shows the result of using the Identify tool to query CLONES for information about a network site (the blue dot near the map's center). With this client site attribute information is displayed in a frame located below the map. Only those requiring more intensive user interactions, e.g., MapTips, are missing, for reasons described earlier. We have not yet attempted to add customized query dialog boxes to this client since address validation does not require retrieval of detailed network information at the level of CLONES entities. This client also has some nice features not currently found in the thick client, such as the option to switch between a frame for selecting layers and another frame that displays a map legend (as shown). There is also a map print preview feature with the thin client.

4 Other Performance and Design Considerations

Both thin and thick TIMS clients currently support spatial query of backend databases using either place names or graphical bounding rectangles. For mobile users who are in the field and aren't sure of their location, we are also developing query by GPS coordinates with wireless delivery of maps. In this manner, the user, e.g., a right-of-way assessor, can query the TIMS to learn about all equipment of a particular type within a fixed distance from his/her current location. This location will be provided by a GPS receiver connected to the mobile client, either a laptop computer or PDA. We are currently experimenting with wireless connections to our TIMS servers to evaluate the efficiency of alternative strategies for delivering map features and their attribute data to mobile users.

We strongly believe that the design and deployment of map services should be guided by business problems. While it is certainly desirable (and cost-effective) to share available map layers in the distributed geospatial database among map servers, no more layers should be presented to a user than are necessary to help solve a business problem. The wrong approach is to create a "super server" that makes available to a user all map layers in the database, leaving it up to the user to sort through them to find the layers they need. Similarly, the choice of map server type, feature or image, should be determined by the map needs of end users and the capacity (i.e., processor speed and amount of physical memory) of their client machines. As in the current case, there is little reason to incur the additional overhead of feature-based services if the end user requires only simple maps and little interaction with their features.

5 Future Work

Access to mapping services on the Web, e.g., MapQuest® and others, has promoted greater map literacy among users. For example, most Web users now rely on Web mapping services to get navigation information before going on business trips and vacations. We have tried to exploit this new literacy to gather support for mapping services that integrate applications and data across Telcordia business units and product groups. It is our experience that when one group views another's data in a TIMS demo, they soon desire to have their own data added to the service. We encourage these groups to imagine new business opportunities that arise from delivering maps to customers with their data along with others'. Such discussions have led to new work using mapping services to support broadband network planning, broadband service negotiation, and interconnection consulting.

While much of our current work has focussed on building infrastructure for accessing locational information in Telcordia databases and delivering it in maps to users on the Internet, long term business opportunities derive from building new application services that exploit these data and infrastructure to support complex decision-making. In companies like Telcordia, the greatest asset is in the accumulated knowledge of its technical personnel. Our plan is to capture this knowledge in software applications that can be offered to subscribers as services over the Internet. In this manner, the Esri-based infrastructure described above represents only preliminary work needed to create a robust and reliable platform for providing more sophisticated software application services to our customers.

6 Trademark Notices

COMMON LANGUAGE, LocateIt System, and CLLI (code) are registered trademarks of Telcordia Technologies, Inc.

Internet Map Service, ArcIMS, Spatial Database Engine and ArcSDE are registered trademarks of Environmental Systems Research Institute, Inc.

Dynamap/2000 is a registered trademark of Geographic Data Technology, Inc.

ZIP11 Address Coding Guide is a registered trademark of Tele Atlas North America, Inc.

JAVA is a registered trademark of Sun Microsystems, Inc.

Informix Dynamic Server and Spatial DataBlade are registered trademarks of Informix Corporation.

OSMOS is a registered trademark of the Unisys Corporation.

ONC/RPC Toolkit is a registered trademark of Distinct Corporation.

MapQuest is a registered trademark of MapQuest.com, Inc.

Internet Explorer is a registered trademark of the Microsoft Corporation.

Netscape and JAVAScript are registered trademarks of Netscape Communications Corporation.

7 Acknowledgements

We would like to thank our colleagues in the COMMON LANGUAGE product group, particularly Ashok Ingle, Robert Schmidt, Bahram Soroosh, Amy Lipovsky and Gretchen Pozarycki for their contributions to the effort described in this paper.

8 Author Information

Clifford Behrens is a Senior Scientist in Telcordia Technologies Applied Research and directs the Statistics and Data Mining research group. Telcordia Technologies, Inc., 445 South Street, Morristown, NJ 07960-6438. Phone: (973) 829-5198, FAX: (973) 829-5981, email: cliff@research.telcordia.com.

Marek Fiuk is a Research Scientist in the Middleware and Mobile Applications group in Telcordia Technologies Applied Research. Telcordia Technologies, Inc., 445 South Street, Morristown, NJ 07960-6438. Phone: (973) 829-4195, FAX: (973) 829-5981, email: mfiuk@research.telcordia.com.

Chung-min Chen is a Research Scientist in the Information Services group in Telcordia Technologies Applied Research. Telcordia Technologies, Inc., 445 South Street, Morristown, NJ 07960-6438. Phone: (973) 829-4947, FAX: (973) 829-2645, email: chungmin@research.telcordia.com.

Chit Chung is a Senior Scientist in the Statistics and Data Mining group in Telcordia Technologies Applied Research. Telcordia Technologies, Inc., 444 Hoes Lane, Piscataway, NJ 08854-4157. Phone: (732) 699-2542, email: cchung@telcordia.com.

An Architecture for Providing Location-Based Telecommunications Applications Services