WO2002093407A2

WO2002093407A2 - System and method for managing the administration of tecommunication

Info

Publication number: WO2002093407A2
Application number: PCT/EP2002/005444
Authority: WO
Inventors: Volker Paul Bauer; Bartel Madeleine Rene De Lathouwer; Ronald Orlemans; Rogier Dijk
Original assignee: Koninklijke Kpn N.V.
Priority date: 2001-05-15
Filing date: 2002-05-15
Publication date: 2002-11-21
Also published as: WO2002093407A3

Abstract

Method and software program for realising an administration of an infrastructure comprising at least one infrastructure object. At least one aspect of the infrastructure is identified, said at least one aspect representing a specific function of the infrastructure and forming an exploitable network. Also relevant infrastructure objects belonging to the at least one aspect are identified, and a graph comprising vertices and edges are build, stored and updated. The vertices and edges correspond to the identified relevant infrasturcture objects, in which the infrastructure objects have mutual client/server relationships, which may be repetitive. Graph theory is applied to administer the infrastructure.

Description

SYSTEM AND METHOD FOR MANAGING

THE ADMINISTRATION OF INFRASTRUCTURES

Field of the invention The present invention is related to a system and method for managing the administration of infrastructures. In particular, it is related to a future proof managing method and system of a telecommunications infrastructure.

Background Nowadays people are able to build very complex and ever growing infrastructures, like for instance traffic infrastructures, processor infrastructures and telecommunication infrastructures. Therefore it becomes increasingly important to develop methods in order to administrate these complex infrastructures.

A decade ago the technical infrastructure of telecom operators was largely dominated by PSTN, which was characterized by a unique relationship of a telephone number, a telephone connection and a wire pair. The rise of techniques such as ISDN and ADSL has changed this situation dramatically. It is now e.g. possible to offer different services using the same wire pair with different telephone numbers. Conventional administration systems of infrastructures are currently not suited to deal with these kind of complications.

Fixed copper networks presently carry a large variety of signals, e.g. signals using the PSTN spectrum and signals using the ADSL-spectrum. In the near future it is to be expected that different signal spectra will be exploited by different operators. Moreover the liberalization of the telecommunication market requires the former monopolists to offer access to their infrastructure to competitors resulting in the necessity to distinguish between property and exploitation of the infrastructure. Conventional infrastructure administration systems are not suited to deal with this situation.

The present telecommunications infrastructure is sometimes referred to as "the worlds biggest machine". This infrastructure involves a lot of different networks like fixed copper or fibre networks, mobile networks (GSM, GPRS, UMTS, fourth generation networks) and satellite networks. The complexity of contemporary infrastructures is dealt with by structuring the infrastructure in detail.

Problem definition and aims of the invention Complex infrastructures are difficult to manage. A problem associated with these complex infrastructures is that they are subject to technical changes almost continuously. Therefore it is very difficult to obtain and maintain an accurate detailed overview of the infrastructure at a particular moment in time, since there usually is a significant delay before changes are implemented. Another problem with contemporary infrastructures is that they are subject to changes in the laws governing the particular infrastructure. In order to comply with the latest changes in law it is necessary to be able to adapt the administration of the infrastructure within the prescribed period of time.

Yet another problem is that due to intervention of competition authorities or mutual agreements an infrastructure might be shared between different parties or operators. The administration of the infrastructure has to be flexible enough to enable this situation.

Still another problem is that an infrastructure has to cope with yet an unknown future. New technological improvements as well as new services may have to be implemented. The administration of the infrastructure therefore has to be flexible enough to be easily adapted to new developments.

Still another problem of existing administration systems for infrastructures is that the management of such a system is very time consuming and therefore expensive.

It is another problem that existing administration systems are not able to calculate the cost-impact if certain changes are introduced in the infrastructure.

The present invention aims to provide a novel method and system to administrate all possible changes occurring in an infrastructure accurately and fastly, while being capable of coping with future developments.

Summary

In an aspect of the present invention a method and system is disclosed for the administration of an infrastructure applying graph theory. Fig. 2 shows a representation of the systems' architecture. Fig. 3 shows an alternative representation of the systems architecture. Figs. 4A-E shows an example of the invention. Figs. 5A-B show a further example of the invention.

Fig. 6 shows a further example of the invention. Figs. 7A-B show a further example of the invention.

Description

For the purpose of teaching the invention, preferred embodiments of the method and devices of the invention are described in the sequel. It will be apparent to the person skilled in the art that other alternative and equivalent embodiments of the invention can be conceived and reduced to practise without departing from the true spirit of the invention, the scope of the invention being only limited by the claims as finally granted.

Implementation

In Fig. 1, a graph is shown comprising eight nodes or vertices A...H and eight edges 1...8, each edge connecting two nodes. The edges and nodes represent the characteristics of an infrastructure object in a specific aspect. In this description, an aspect is meant to be a specific function or use of an infrastructure, which provides for an exploitable network. The aspects in a telecommunication network may be 'connection', 'signal', 'conduction' and 'space'. Infrastructure objects in a telecommunication infrastructure may e.g. be trenches, cables, cable jackets, fibres, dividers, antennas, filters, multiplexers, modems etc.

The infrastructure objects of a telecommunications network have mutual client- server relationships, which are modelled using paths through the graph. A PE tube (e.g. represented by nodes A, B and edge 2 in Fig. 1) forms a path, which gives space to (or carries) a conductor tube when looking at the 'space' aspect. Here, the PE tube is a server, providing space to its client, the conductor tube. In its turn, the conductor tube may be regarded in the aspect 'conduction' as having a server relation to its client, e.g. a 6 cable. This allows a modelling of an infrastructure, in which the infrastructure objects have mutual client/server relationships, which may be repetitive, using a graph representation with edges and nodes.

At another aspect, e.g. signal, data streams may be regarded as infrastructure objects which are needed to provide certain services in a telecommunications network. In this case, the client/server relationships may take the form of stacking/unstacking relations, i.e. several data streams may be stacked into a single main data stream, which is transported over a trunk line of a telecommunication network. At some intermediate point along the trunk line, one or more of the original constituents of the single main data stream may be retrieved, or the single main data stream may be unstacked.

An aspect that can be identified is e.g. the housing that considers the connectivity in relation to tube spaces. If e.g. sewer tubes are used as prefab channels, this aspect becomes relevant. Various methods can be used to identify the relevant aspects possessing the desired connectivity. The graphs comprise a number of vertices and nodes. Paths may be identified as a route through the graph, crossing a vertex or edge only once. The path may be stored by storing the vertices at the end points and intermediate edges. Paths are associated with e.g. capacity and routing. Capacity indicates that a path is part of a stock, and routing indicates whether routing via the path is present. For the user of the present system, only the end points of a path in terms of ISO's are communicated and not the vertices and edges.

When the relevant aspects of the infrastructure have been identified an ISO- classification can be made. ISO's might be of restricted use. These restrictions are recorded in the ISO characteristics and in the business rules establishing the use of the ISO for each application. E.g., for a Y-connector the angle made might be recorded and the business rule might state that the angle should be larger than 90 degrees for using a guide tube. This may also be implemented for equipment functions, in which an equipment ISO is characterised by e.g. elementary functions (such as modem, adsl filter, multiplexer, switch, cross connect,...). The ISO's are characterised by a number of attributes, such as identification, material, cost, location, etc. The geographical location of an ISO 20 is always a point location and is determined by means of addressing. A single location might be addressed in several ways, i.e. a location might have several addresses. The size of a 7 location can be expressed by the accuracy of the address. Formal and informal addresses can be distinguished, the former being discrete, systematic and zoomable (coordinates, global positioning system (GPS) etc.), the latter being non-zoomable (Postal Code, relative addressing). Examples of administering a telecommunication network using the client/server relationships between infrastructure objects and the use of graph theory on the infrastructure representation of the present invention are described below as Examples referring to Figs. 4, 5 and 6.

For certain types of ISO's, it may be required that a norm location is stored, e.g. using co-ordinates. Also, for each ISO and user a preferred addressing type may be defined. By using formulas for formal addresses and translation tables for informal addresses, the different types of addressing may be interlinked and exchanged. For the relative address types, no translation table is required as these are linked to an ISO having a formal address. Formal addresses are discrete, systematic and zoomable, and formulas may be used to convert one type of formal addressing to another type. Examples of formal addressing methods are WGS 84, which is used in e.g. the Global Positioning System GPS, and Rijkscoordinates, which are used in The Netherlands, but require accurate maps and measuring instruments to use. Informal addresses are usually not zoomable. Examples of informal addresses are

Postal Codes, relative addressing (referring to another object or ISO having a formal address), or free textual addressing. Translation tables may be used to convert an informal type address to a formal type of address. Relative addressing may use naders to further detail the address of an ISO. A nader may comprise three parts: a textual indication ('three steps to the left'), a formal indication of the type of relation ('next to', 'in'), or a formal reference to another information source (e.g. a hyperlink or a binary large object).

As an example, a building has a formal address in Rijkscoordinates. In the building, a switchboard is located (relative address). The switchboard has connectors, which may be addressed as connector a in switchboard. In this manner, one can zoom to details in an increased manner.

The present invention is preferably implemented using Object Oriented technology. Object serialisation allows the state of an object to be recorded, thus 8 allowing administration of an installed base (infrastructure) and also planning of future infrastructures. The toolbox of the implementation is also able to keep versions of the infrastructure which may be merged into the installed base.

Specialisation techniques are used to extend a generic core into an infrastructure administration, resulting in inheritance. First, logically related functionality and data are combined within one class in a process called abstraction. Using inheritance, specialised subclasses can be created, which can use its parent's functionality and data, and which can be used instead of any of its ancestors. Thus a subclass can take any 'shape' of its ancestors, also indicated by polymorphism. Object-oriented technology also allows encapsulation, i.e. the implementation of an object is hidden behind a well- defined interface, to make a clear distinction between the specification and implementation of an operation. This way, the implementation of an object can be changed without changing the parts that use the interface.

Architecture

Fig. 2 shows a possible architecture for the administartion method and system of the present invention.

Because the infrastructure administration has to be future proof, the method and system have to be able to administer any kind of infrastructure. To achieve this the system is based on a very generic core or kernel 61 (indicated by the acronym DARK (Delden ARchitecture Kernel)) that is able to administer any kind of network modelled using graph theory. On top of the core or kernel 61 there is a layer of generic infrastructure objects (GISO) 62 that constitute the infrastructure. In order to build a real world administration, these generic ISO's 62 have to be specialized into concrete business domain ISO's 63 like cable-sections, cross wires etc. The layered architecture, as shown in Fig. 6, from generic to specialised, separates the layers that will hardly ever change form the layers that will change almost continuously. Another advantage is that it hides the lower layers behind the top-most layer. The components in the topmost layers are preferred to be the only components that are visible to client systems (as indicated by the User Interface UI 64).

Next to the ISO functionality, the architecture comprises support for Spatial data 65 (or geographic data) and Versioning 66 (support for different versions which may arise when planning new parts of infrastructure). 9 The proposed system is a distributed client/server-based system. The purpose of interface distribution is to allow client systems to talk to a remote system as if it were local. Other systems might use the proposed system to administer their infrastructure. The interface of the proposed system (the interface of ISO's, tracing, versioning and spatial functionality) is preferably distributed to the client systems using messaging middleware 67 (e.g. GAIA, TIBCO, Tuxedo). Distributed computing standards like EJB, CORBA, RMI or DCOM let the client systems talk to proxies and might be used as well. An advantage of this option is that these standards hide the necessary messages to distribute the request. For performance improvement the toolbox might be able to do distributed cache management (i.e. for GIS applications), indicated by the cache 68 in the middleware layer 67.

The proposed system consists of the following components:

• The Architectural Kernel (DARK) 61

• GISO 62 • ISO (available to client systems) 63

• Tracing (available to client systems) 69

• Spatial (available to client systems) 65

• Versioning (available to client systems) 66

• Storage The architectural kernel (DARK) 61 is responsible for adding or removing vertices and edges and consistency. The edges and vertices refer to ISO's 63. Also the DARK kernel 61 manages the client/server relations for the various ISO's 63. The Generic ISO manager 62 builds on the functionality exposed by the architectural kernel and adds the generic functionality used by all specific ISO's 63. Fig. 3 shows a different representation of the basic system architecture. Graphs comprising vertices, edges and client/server relations have been identified as a repetitive phenomenon for each and every aspect of an infrastructure. Therefore the method and system are based on the graph functionality 71 performing operations as Creating, Reading, Updating and Deleting (CRUD) the vertices, edges and client/server relations and tracing paths through graphs.

The functionality of every ISO 20 can be divided into a generic and a specific part. The generic part 72 might be identical for all ISO's 20 and comprises e.g. the CRUD ISO. Besides this generic ISO-functionality the generic part supports spatial 10 data (i.e. geographic data or locations) and versioning (i.e. support of different versions that arise due to planning of new parts of an infrastructure).

The user of the present method may select a specific view by selecting an aspect, being one of the earlier identified aspects 'connection', 'signal', 'conduction' and 'space'. Then, infrastructure objects may be selected. For each infrastructure object, a number of operations may be executed, such as create the default aspects of a specific ISO, load and save. The default aspects may be given a value and other attributes may be added. The system provides a basic tracing functionality to trace through the graph in a systematic fashion. Graph tracing is used to find a path in a graph. The trace package must not make any assumptions about needing to cache the entire graph in proprietary data structures (either in memory or on disk) before a trace can be carried out. The trace package must be able to discover connections as it traverses the graph. This discovery preferably uses the same database handle as the core code to ensure that transactional integrity is maintained. The supply of "elements connected to the current element" could be either via direct database access, or via the object access routines within the system itself. The tracing functionality can be used e.g. to compute the lowest cost route through the graph, irrespective of the way the costs are measured. In the example of the system architecture in Figs. 2 and 3 the trace functionality is packaged as a service within the core of the system object model. Integration of the trace functionality within the core of the system will most easily be achieved via a trace toolkit or library that can be called from the core.

The specific functionality may be implemented by using plug-ins as shown in the figure (blocks 73, 74). Additional functionality 75 as e.g. reporting functionality or additional tracing functionality can be obtained using the plug-in mechanism as well, even as a later addition to the system. Together with the core functionality the plug-ins provide a complete working system for administering infrastructures, which may e.g. provide answers to questions and execute actions.

In order to provide a generic core or kernel and specialised ISO's the system may be designed and built using object oriented technologies. In an embodiment, the system can be built using object-oriented techniques known to the person skilled in the art to obtain the flexibility needed to implement new technologies without needing to alter the data model. To store objects, the system can use some form of database. Although the majority of applications are built with 11 relational databases, the proposed system preferably considers object databases as they provide the most natural environment for storing objects. However relational databases might be used as well. An important reason to use object oriented databases is that they offer complex object support, rich many-to-many data element relationships, inheritance of characteristics and similar requirements not well met by conventional table-oriented designs. The database system can be equipped with concurrency control, recovery and backup facilities, distributed database capabilities, performance monitoring and/or security provisioning means.

There are various ways to handle the spatial storage of the files. A key determinant of the architecture of spatial storage relates to how the data are spatially indexed and spatially filtered on retrieval. The system is able to support long transactions that may span multiple update sessions of the database, i.e. versioning. Versioning e.g. allows multiple "what if analysis to be run against the same set of data or allows updates to be hidden from other users, whilst still being stored in the main database. Using long transactions does not mean that normal or short transactions are not used. Versioning can be implemented as part of the database core as well as an overlay on top of the database.

Graphic caching is provided to speed up the performance of the system. Processes such as Stock-building, Delivery, Maintenance and Service (SDMS) use the system as described (see Fig. 3). The Stock-building processes 76 particularly drive the plug-ins with the CRUD ISO functionality. The Delivery processes 77 particularly drive the plug-ins that trace paths through a graph.

Examples of using the system

The first example considers a Stock-building request as shown in the Figs. 4A-E. A mechanic is assigned to connect two already existing tubes. After the assignment has been fulfilled, the infrastructure has changed and the administration of the infrastructure needs to be updated. This is done by using the Stock-building application. The Stock-building platform sends a request to the plug-in via the specific ISO-interface as shown in Fig. 4C. This request comprises the instruction "CONNECT TUBE" and parameters "TUBE ID: 20, TUBE ID 40, TUBECONNECTION S2". Examples of other instructions are PLACE CABLE, CONNECT CABLE, INSTALL 12 DIVIDER etc. These are specific instructions for the individual ISO's. The plug-in translates the specific instructions to generic instructions, such as "REMOVE" and "LOAD". Within the kernel the definitions of the ISO's are stored, in this case of the ISO's tube and the welding part. Considering the 'space' aspect in the original situation (Fig. 8D) two graphs, constituted by the ISO's tube 20 and tube 40, can be identified. The ISO-definition of the tubes state that these ISO are edge-like and can be connected to other tubes (connectivity). After the update of the administration one graph network in the 'space' aspect can be identified. Tube 20 and tube 40 have been connected by means of the welding part S2. The completion of the process is reported to the operator of the system.

A further example of administering infrastructure is shown with reference to Fig. 5. In Fig. 5A, the actual physical elements are shown, and in Fig. 5B the graph representations of the model used for administration according to the present invention. As a starting point, a first ISO, being a first PE tube 90 is defined by two new nodes 100 and 101 and a first new edge 111. A second ISO, a Plesson coupling 93 is added by assigning the node 101 to the Plesson coupling 93. A third ISO, being a second PE tube 91 is added, first by defining a further node 102 and assgning this node 102 to the ISO PE tube 91, and secondly by defining a second edge 112 between the nodes 101 and 102, and assigning the second edge 112 to the ISO PE tube 91. In the now existing tube assembly, two conductor tubes 94, 95 may be inserted. A path a is defined as a new path comprising edges 111 and 112. This path is associated with the space provided by the first and second PE tube 90, 91 and Plesson coupling 93. Thus, the ISO's 90, 91 and 93, or better edges 111 and 112, from the server providing the path a. The path a may now give space for the two conductor tubes 94, 95, which thus have a client relation. This is effected by defining four new nodes 103, 104, 105, and 106. A new edge 114 is defined between nodes 105 and 106, and is associated with the ISO first conductor tube 94. Also, a further new edge 113 is defined between nodes 103 and 104 and is associated with the ISO second conductor tube 95. Finally, a use relationship is made between the path a and the ISO's first and second conductor tube 94, 95.

The following items are stored in the administration system: Path a is build by edges 111 and 112 (PE tubes 93, 94) and is used by edges 113 and 114 (conductor tubes 94, 95). As the characteristics are stored as client/server relationships, the 13 following is also stored: edge 111 constructs path a; edge 112 constructs path a; edge 113 uses the space provided by path a; and edge 114 uses the space provided by path a.

In Fig. 6, an example is shown how a circuit (service) is administered. Two parallel wires 120, 121, each consisting of two segments, are administered in the present method by representing the wire ISO's 120, 121 as a combination of nodes and edges. The first wire 120 is represented by node 131, edge 124, node 133, edge 125 and node 135. The second wire 121 is represented by node 132, edge 123, node 134, edge 126 and node 136. The pair of wires 120, 121 constructs a circuit 122, which is represented by the path a. The path a may provide a connection for a predetermined signal. The path a is created by assigning the wires 120, 121. At its turn, the path a provides the necessary space for the predetermined signal 129. and may be associated with the ISO signal 129, represented by edge 130 between nodes 137 and 138. For a user of the present administration method, it may sometimes be sufficient to only look at the signal 129 (as represented by nodes 137, 138 and edge 130), and at other times it will be necessary to look at an other aspect, i.e. the physical circuit 122 foπned by the two wires 120, 121, and represented using edges 123...126 and nodes 131...136. For the administration of the infrastructure it will then suffice to either apply the graph theory to either the first graph (top of Fig. 10) or the second graph (bottom of Fig. 10). The flexibility of the present method and system is shown with reference to Fig. 7A-B. In this figure, an infractructure owned by a first party comprises a first tube 142, second tube 144, third tube 146 and connecting Plesson couplings 143 and 145. The set of tubes and couplings are provided with modular connection points 140 and 141. For the first party, the infrastructure is administered using edges and nodes 150...156 for every ISO 142...146, as shown in Fig. 7B. However, for a second party, which wants to use the space provided by the PE tubes between the two modular connection points, the only interest is a path 157 provided by all infrastructure objects 140...146. For this, a path 157 may be assigned between the outermost nodes 150, 153 of the first party infrastructure. The path 157 may also be regarded as providing space to a second party tube channel, which may represent this path using a graph only comprising an edge 160 and two end nodes 158 and 159. The second party may then administer e.g. cables in the tube channel by assigning client/server relationships between the tube channel and the cable. 14 Also, the infrastructure shown in Fig. 7A may be expanded, e.g. by connecting two further PE tubes 147, 148 to the already existing tube channel. When administered by the first party, the two further PE tubes 147, 148 will be added in the graph with nodes and edges 150...156. However, the two further PE tubes 147, 148 may also be installed by the second party, and administered by the second party. In this case, the two PE tubes 147, 148 will be added to the second party's graph as edge 161 and node 163, respectively edge 162 and node 164. This graph may then construct a further path 165, which may represent a further tube channel providing space.

Claims

15 CLAIMS

1. Method for realising an administration of an infrastructure comprising at least one infrastructure object comprising the steps of: identifying at least one aspect of the infrastructure, said at least one aspect representing a specific function of the infrastructure and forming an exploitable network; identifying relevant infrastructure objects belonging to the at least one aspect; building, storing and updating a graph comprising vertices and edges, the vertices and edges corresponding to the identified relevant infrastructure objects, in which the infrastructure objects have mutual client/server relationships, which may be repetitive, and applying graph theory to administer the infrastructure.

2. Method according to claim 1, in which the infrastructure is a telecommunications infrastructure, an access telecommunications infrastructure, or a traffic infrastructure.

3. Method according to claim 1 or 2, in which the infrastructure is a telecommunications infrastructure and the at least one aspect comprises one or more of the group of connection, signal, conduction, and space.

4. Method according to one of the claims 1 through 3, in which characteristics associated with the at least one infrastructure object are stored.

5. Method according to claim 4, in which the characteristics comprise identification, location, cost and/or business rules for use of the infrastructure object.

6. Method according to one of the claims 1 through 5, in which the graph theory is used to determine a path connecting two end points. 16

7. Method according to one of the claims 1 through 5, in which the graph theory is applied to determine a least cost routing path , the path connecting two end points.

8. Software program for administering an infrastructure comprising at least one infrastructure object, the software program comprising computer executable instructions, which when loaded on a computer allow the steps of one of the claims 1 through 7 to be executed.

9. Software program according to claim 8, in which the software program is layered and comprises a kernel for storing the infrastructure objects and associated characteristics, creating, reading, updating and deleting edges/vertices representing an infrastructure object to form at least one graph and checking the consistency of the at least one graph; a generic infrastructure object layer for creating, reading, updating and deleting infrastructure objects, for support of spatial data functions and for support of versioning functions, the generic infrastructure object layer using functions of the kernel; a specific infrastructure object layer comprising plug-ins for interfacing with a user interface by using functions of the generic infrastructure object layer.

10. Software program according to claim 8 or 9, in which the software program is implemented using object oriented techniques.

11. Software program according to claim 8, 9 or 10, in which plug-ins are used to identify for an infrastructure object characteristics, the characteristics comprising type of object, attributes, aspect identification, edge/vertex modelling for specific aspect, business rules for use of infrastructure object, connectivity between infrastructure objects.

12. Software program according to one of the claims 8 through 11, in which a plug-in is provided for performing a trace functionality.

17 13. Software program according to one of the claims 8 through 12, in which the software program is implemented as a client/ server system, the client implementing the user interface functions.

14. Software program according to one of the claims 8 through 13, in which the user interface comprises functions for build-up of stock and/or functions for supply.

15. Software program product comprising a software program according to one of the claims 8 through 14.