WO1997015133A1

WO1997015133A1 - A support function for a network element

Info

Publication number: WO1997015133A1
Application number: PCT/SE1996/001327
Authority: WO
Inventors: Kurt Davies Jonsson; Carina Marie Runefjord
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1995-10-19
Filing date: 1996-10-18
Publication date: 1997-04-24
Also published as: KR19990064317A; SE9503675L; CA2235403A1; SE9503675D0; JPH11513824A; AU705857B2; EP0856217A1; NO981714D0; SE515343C2; NO981714L; AU7354196A

Abstract

The invention relates to a method for transforming data to a desired format in a network element. The network element is included in a data network with an operations support system (104) for operation and maintenance of the network, and comprises a resource layer (106) including resources (108) in the form of hardware and software. The resources include network element functions providing services in the network, as well as resources used for realizing the network element functions. Furthermore the network element includes an operations support view (110) consisting of software and in which the network element (102) from the operations support system (104) looks like consisting of a number of resource representations (114) and is used by the operations support system for managing a respective resource and network element function in connection with performing a network element function. The method implies that on demand an operation is started including that data in the resource layer are fetched by a communication function (122). The communication function sends these data to be transformed to the desired format by a transformation function (124). The transformation function carries through the transformation and returns the transformed data to the communication function for forwarding to a desired instance.

Description

A support function for a network element.

Technical Field of the Invention.

The present invention generally relates to generic support for feeding out and post managing data in a data system.

More particularly, and according to a first aspect, the invention relates to a network element included in a data network with an operations support system for operation and maintenance of the network, and comprising a resource layer containing resources in the form of hardware and software, including network element functions providing services in the network, as well as resources used for performing the network element operations, an operations support view consisting of software, in which the network element from the operations support system looks like consisting of a number of resource representations and is used by the operations support system for managing the respective resource and network element function in connection with performing a network element operation.

According to a second aspect, the invention relates to a method for creating a support function in a network element that is part of a data network having an operations support system for operation and maintenance of the network, said network element comprising a resource layer containing resources in the form of hardware and software, including network element functions providing services in the network, as well as resources used for performing the network element operations, an operations support view consisting of software, in which the network element from the operations support system looks like consisting of a number of resource representations and is used by the operations support system for managing the respective resource and network element function in connection with performing a network element operation.

According to a third aspect, the invention relates to a method for performing, on request, an operation including transforming data available in a resource layer in a network element to a desired format and providing such transformed data for a desired instance, said network element being included in a data network with an operations support system for operation and maintenance of the network, and comprising said resource layer as containing resources in the form of hardware and software, including network element functions that provide services in the network, as well as resources which are used for performing the network element operations, an operations support view consisting of software, in which the network element, from the operations support system, looks like consisting of a number of resource representations and is used by the operations support system for managing a respective resource and network element function in connection with performing a network element operation.

From a network element of the kind indicated above, different markets and users have a need to obtain information in a desired data format. An example of such information is data stored in a log. It can e.g. be the question of requirements on a certain type of security management, such as encrypting the data asked for. Formatting can be needed, e.g. in the form of a simple transformation to ASCII format.

In the case of log records, the log record format used for storing usually differs from that required by an external user. It is likewise possible that the real information transmission will be performed while using a file managing system of the type FTAM according to ISO 8571, the user then taking the role of "initiator" according to the definition that this concept has obtained in FTAM.

From efficiency reasons it would be desirable that getting, formatting and transferring of data records shall be able to be carried through in as few steps as possible. This in turn requires effective cooperation between several independent sets of software. In the case of log record management, fetching of a log record is e.g. handled by general software in a basic system, as well as the transfer. The formatting, on the other hand, is managed by software belonging to the application that has fed the log records into the log in the first place. For such an operation scenario it is necessary for the network element to be able to present the transmission parts as "virtual files" in a "virtual file store" towards FTAM.

Description of Related Art. US 5.299.304 discloses a method and a device for identifying multistep format transformations of documents.

US 5.317.676 discloses interactive definition of filters for performing data transformations in series and thereby provide more complex mathematical operations on data. US 5.339.392 discloses a method to create a video presented document that is definable by a user and shows changes in real time data. The user can choose the real time data to be used, as well as where and in which format and look this shall be performed. US 4.559.614 discloses transformation of data sent from a remote information management system operating with a first internal code format, into the internal code format of a second, receiving information management system.

EP 0.631.246 discloses control of object representations in a user interface of a data management system. When an object is selected for presentation, the object is transformed to a presentable format in accordance with its attributes.

EP 0.567.834 discloses a data receiving architecture that admits free definition and redefinition of the format of document forms without requiring reprogramming of data processors that receive and use data on the forms in question.

EP 0.408.132 discloses a system for management of data files. The system has a modular design with a control module and a plurality of transformers, which each is intended for a particular type of transformation.

EP 0.350.654 discloses a data management system in which an input record is transformed to a record of a unitary format. All file formats are made unitary. A desired record is read out from a file and transformed to an arbitrary format.

EP 0.377.783 discloses the use in a transition step of a language representation that shall facilitate optimization of transformations in a data program that is compiled.

Summary.

One object of the invention is to state a support function, for use in a network element of the kind defined by way of introduction, that enables simple transformation and transfer of information available in the resource layer to a format desired by an external user.

A further object is to state a method of producing a software component intended for use in such a support function. Still an object is to state a method to transfer data to a desired format in a network element of the kind indicated by way of introduction.

The network element according to the first aspect, as indicated by way of introduction, comprises a support function located in the resource layer and including a communication function for communicating with a user, and for fetching and providing, on request, data available in the resource layer, and a transformation function for transforming these fetched data to a desired format. The method according to the second aspect, as indicated by way of introduction, comprises the steps of creating in said resource layer, as a part of said support function, a communica¬ tion function to be used for communicating with a user and for fetching and providing, on request, data available in the resource layer, a number of software components in the form of loading modules by interlinking for each software component a number of compiled software units, each consisting of a separate¬ ly compilable source code, and a transformation function for transforming the fetched data to a desired format, and comprising a number of transformation components for executing each a said software component.

The method according to the third aspect comprises the steps of fetching and sending by means of a communication function, located in the resource layer, said data available in the resource layer to a transformation function, likewise located in the resource layer, and transforming these data to the desired format by said transformation function, returning the transformed data to the communication function and forwarding by the communication function the transformed data to the desired instance.

According to the first aspect of the invention there is thus included, within the resource layer of the network element, a support function comprising, on the one hand, a first software function intended for getting and providing data appearing in the resource layer for post management, on the other hand, a second software function that communicates with the first software function and is intended for receiving data provided by the first software function, and post management of these to a condition required by an external user in the network.

For a user, the support function according to the invention constitutes a tool enabling getting and transforming/formatting data in records into external format. After that, data can be fed out via file transfer or other external communication, such as tapes, writers, etc., that is available in a current system.

The transformation proper is performed by an exchangeable transformation function used by the support function. The trans- formation function can be selected in run time and the available set of transformation functions can be increased in run time.

Such a transformation function consists of at least one transformation component that in turn can use one or more exchangeable transformation functions. Thus, it is possible not only to select but also to compose new transformation functions in run time.

Each transformation component has a characteristic interface that establishes the type of input data as well as output data. A connection point for a transformation function has likewise a characteristic interface. A transformation function can be connected to a connection point if, and only if, the two interfaces are identical. Connection points for transformation functions can be available in any software component, e.g. in a transformation component.

A transformation function is a transformation component that has transformation functions connected to all its connection points (e.g. a transformation component that has no connection points) . By way of definition its characteristic interface is identical to that of the transformation component.

Each application/market can implement suitable such transformation components, and reuse and change transformation components in runtime. It is possible to create any format, standard formats inclusive, this thus implying that adaption to existing standard is made possible.

Brief Description of the Drawings.

The invention will now be described more closely below with reference to the attached drawings, on which

Fig. l in a schematic view illustrates connection between operations support, data and resources in a network element according to the invention,

Fig. 2 in a similar view as in Fig. 1 schematically illustrates the structure of a transformation function that transforms data to a format required by an external user,

Fig. 3 in a similar view as in the preceding Figures schematically illustrates the structure of a superior support function in which the transformation function is included,

Fig. 4 is a view that in more detail illustrates a possible structure of a transformation function,

Fig. 5 is a view, that schematically illustrates getting/- collecting information from a log for post management,

Fig. 6 is intended to illustrate more closely certain contexts in connection with management in two management views described with reference to Figs. 1-3,

Fig. 7 illustrates an example of a scenario according to Figs. 5 and 6,

Fig. 8 shows a sequence diagram for illustrating the way of operation of the functions included in Figs. 6 and 7, Figs. 9-13 schematically show some examples of post management according to the invention.

Detailed Description of Embodiments. Figs. 1-3 illustrate data and operations support views for a network element 102 included in a data network that in the present example is assumed to form part of a telecommunication system. The data network is shown as containing an operations support system for operation and maintenance of the network, represented by a block 104. The block 104 is also intended to represent an external user, as will appear from the following.

The network element 102 contains resources 108 in the form of hardware and software in a resource layer 106. The resources

108 can include network element functions which each provides a service in the network, as well as other resources used for performing the network element operations.

For the operations support system and external users there are two different views/protocols consisting of software. Both views represent the same resources but one shows an operations support view and the other one a file management view. Interfaces for operations support and file management are indicated at 110 and 112, respectively.

In the first case it is assumed that it is the question of an object oriented view of the kind appearing more closely in the Swedish patent 470,456. In this document concepts are used that can also have their origin in an international standard denomina¬ ted TMN, that relates to management of telecommunication networks from operations support systems. The TMN standard has been developed by an organization denominated ITU-TS (International Telecommunication Union for Telecommunication Standardization) and is described in its recommendation M.3010. The ITU-TS recommendations in turn are based upon international standard recommendations suggested by an international organization denominated ISO (International Standardization Organization) . It should, however, be emphasized that the invention is not limited to use in a network element with an object oriented operations support view. In the operations support view the network element 102 looks like consisting of a number of managed objects 114 from the operations support system 104. The managed objects 114 are included in a management information base 116 and are used by the operations support system 104 for managing resources included in the resource layer 106 in connection with performing network element operations. Referring to the patent 470,456 and TMN standard, management information base is an abstract concept, and shall thus not be mixed up with a physical data base that is used for permanently storing data in a system.

A file management view is usually used when transferring great data amounts from a network element to an operations support system or external users. The data transmission can be performed via different protocols depending upon the operations support system used. In the examples that follow, a view via the protocol FTAM (File Transfer, Access and Management) according to the ISO standard 8571 will be used.

In the file management view the network element 102 looks like consisting of a number of information identifying entities 118 from the operations support system or an external user, which can be used by the operations system or external users to get information from the resource layer 106. The information entities 118 correspond to Virtual File (VF) in FTAM and are therefore designated VF in the Figures, as well as VF objects henceforth below. VirtualFile in FTAM is an information entity capable of indicating either origin or destination for a sequential data transmission. The VF objects 118 are, however, in the present case included in a file server entity 120, that consists of software realizing a file management view of resources contained in the resource layer 106. The file server entity 120 can therefore be said to have the character of VirtualFileServer, and is therefore designated VFS in the Figures, and VFS object henceforth below. Although only one such VFS object is shown in Figs. 1-3, a number of different such VFS objects can be used in a system. The concept of VFS = VirtualFileServer in the present connection shall however not be mixed up with VFS = VirtualFile- Store in FTAM, that essentially corresponds to the union of all VFS:s, that such a number of VFS:s in the meaning of VirtualFile¬ Server has.

For closer details regarding VFS = VirtualFileStore and VF, reference is made to the above mentioned standard ISO 8571. As a characterizing part of the invention the resources 108 in the resource layer 106 comprise a first software function 122 forming a communication function which, as ordered by the operations support system or an external user, is intended to get and provide information existing in the resource layer 106 for post management. In the file management view the communication function 122 is represented by VSF 120. As another characterizing part of the invention, the resource layer 106 likewise includes a second software function 124, forming a transformation function, which communicates with the communication function 122 and is intended for receiving information that in accordance with the above has been fetched by the communication function 122 and is provided thereby. In a post management process the trans¬ formation function 122 transforms this information to an external format required by the customer. The two above identified functions 122 and 124 can be said to form main portions of a generic support function for feeding out and post managing data in a data system, said generic support function henceforth also being denominated GOPS, that stands for "Generic Output and Postprocessing Support". GOPS is a tool enabling an operator to transform/format data in records to external formats. Data can thereupon be fed out to a user via file transfer or other external communication, such as tape, writer, etc., that is available in the current system.

The transformation proper will henceforth be denominated GPP, which stands for "Generic Post Processing". The denomination GPP will also be used for the function 124. GPP consists of an arbitrary number of transformation components, defined more closely below, which perform transformations of data. GPP enables an application/market to implement suitable transformation components, and to reuse and change transformation components in run time. An adaption to existing standard is also made possible.

By transformation component is thus here meant a function that transforms data. As will be described more closely below transformation components can be linked together for forming a pipeline that in turn is an application of GPP. Each trans¬ formation component is intended to have the same input/output interface. The transformation of data in transformation compo¬ nents is application/market dependent to a high degree.

In other words, the support function GOPS is a common name for functions that get and feed out information, e.g. from a system log, and shall be able to be used in different ways to suit applications and markets. One example is formatting and feeding out TT records (Toll Ticketing) , i.e. debiting data within the mobile telephony that is stored in logs in an internal format .

Fig. 1 is mainly intended to generally illustrate the connection between operations support, data and resources in the network element 102. The information in the resource layer 106 is not in a file format and must therefore be transformed by means of GPP 124 before being presented to the operations support system or an external user. GPP shall also provide an operations support view of the transformation, which is indicated by it being shown as represented by a managed object 126 in the management information base 116.

In a similar view as in Fig. 1, Fig. 2 schematically illustrates the structure of the GPP function. For this purpose a block 202 designated R_GPP (R: Resource) is an enlarged view of the GPP function 124 included in the resource layer 106. In this view a chain 204 of transformation components is indicated.

Fig. 3 is intended to likewise schematically illustrate how GOPS can be regarded as something that connects together the VFS view, the transformation and the operations support view and in that connection makes a call and controls the output of data. In the Figure, a block 302 designated FMA_GOPS (FMA: FileManage- ment Adaption) constitutes an enlarged view indicating a GOPS function. The view 302 has been placed to cover VFS/VF 120/118 for indicating that GOPS is represented by VFS 120 in the file management view. In the operations support view the GOPS function 302 is represented by a managed object MO_GOPS (MO: Managed Object) designated 304. Sight lines 306 from the function 122 in the resource layer 106 to the block 302 also enclose the view 202 of GPP to indicate that besides the function 122 also the function GPP 124 is contained in GOPS. Since Figs. 1-3 as an example are assumed to relate to use of file transmission according to FTAM, the file management view includes a "responder" according to FTAM, denominated FTAM_Responder below and indicated by a block 308. A correspon¬ ding "initiator" according to FTAM, denominated FTAM_Initiator below, is included in the block 104, and can consist of the operations management system or an external user.

According to the definition provided in FTAM, a responder is a "file service user" that accepts "FTAM regime establishment", that is asked for by an initiator. As a "file service user" a part of an application is then defined, that from a conceptual point of view invokes the FTAM service, and as an initiator a "file service user" is meant that asks for "FTAM regime es¬ tablishment". In ISO 8571, e.g. the first part 8571-1:1988 on pp 17 and 18, a summary of the file service and its support protocol is provided, wherein i.a. the role of FTAM_Responder at estab¬ lishment of "FTAM regime" appears. In Annex A in the same part some examples of use of FTAM are included, in the form of sequence diagrams.

Thus, GOPS 302 has representations 304 and 120 in the operations support view and file management view, respectively, and thereby interconnects the file management view, the trans¬ formation function 124 and the operations support view so that a data record post managed by the GPP function can be transferred to the operations support system or an external user. Fig. 4 contains an enlargement of the view 202 in Figs. 2 and 3 and, at the same time, schematically indicates the communication between the functions 122 and 124. An origin 402 of data in the function 122 is connected via an interface 404, transformation components 406.1-406.4 and interfaces 408.1-408.3 located therebetween, and a further interface 410 to a destina¬ tion 412 for the data. The illustrated number of transformation components and interfaces located therebetween is used only as an example. An arbitrary number is thus possible.

Each of the transformation components 406.n has a role or a subtask in a data processing in the transformation function 124. One or more of the transformation components 406.1-406.4 can be said to realize a specific operational step or case of use in the system according to Fig. 4. A group of mutually related such cases of use forms a function that can be a part or the whole of the transformation function 124.

Each transformation component 406.n executes a software component in the form of a loading module that contains one or more software units which each can consist of a separately compilable source code quantity. The software units implement and use the interfaces 408.n.

Each of the interfaces 408.n consists of a quantity of type definitions and definitions of two role definitions for a transformation component each.

An example of an interface is a function prototype, F, with appurtenant role definitions. The role definitions shall specify the semantics of the funtion call, i.e. that what is expected by a part calling the function, and what the function is expected to do. If a software unit A provides a matching function it iε natural to say that A implements F. In the same way it is natural to say that a software unit B that only makes use of F for calling the function, uses F. It is not difficult to find examples of interfaces, where it is less obvious which side that uses the interface and which side that implements it. In such cases it is the role definitions that decide the concrete meaning of the terms use and implement.

To produce a software component a number of compiled software units are interlinked. In that process most of the interfaces will obtain a unique implementation and all uses of such interfaces within the software component will be statically associated with this implementation. When a software component is loaded into a processor some further of these interfaces will be associated with a unique implementation. The interfaces remaining thereafter are denominated open and are here of a particular interest. A loaded software component is characterized by which open interfaces it implements and which it uses.

Before a software component can be used in a case of use, the use of its open interface must be defined. A software component that has at least one open interface provides a set of abstract connection points. Each abstract connection point uses or implements one of the open interfaces.

For a given case of use some software components are obligatory. If the obligatory software components include open interfaces they must be provided with configuration information that makes it possible to interconnect a user with the implemen¬ tation for each open interface.

A case of use will be configured as follows. The first step consists in selecting the software components to be included. When this has happened, also a set of open interfaces has been obtained. The next step consists in determi¬ ning, for each of the software components, which transformation component, or components, it shall occupy in the current case of use. When this has happened there is, for each transformation component, a concrete point of connection corresponding to each abstract point of connection in its software component. The last step consists in matching user and implementation for all concrete points of connection. Obviously, two concrete points of connection can be matched only if one of the corresponding abstract points of connection uses and the other one implements the same open interface.

In a simple case of use the interfaces 404-410 can be of a type here denominated Offer/Accept (0/A) . More particularly there is the question of a method call interface, the denomination of which depends upon the fact that offer and accept are main methods to be used for the communication. When two objects communicate via the interface, one of these shall furthermore take the role of "source", and the other one the role of "sink". The data flow over the interface runs from source to sink.

The origin 402 is associated with a generic interface 403 in the function 122 that admits transfer of arbitrary records to the GPP function 124 for transformation.

The destination 412 is associated with a generic file transmission interface 413 that allows transmission of data to an arbitrary transmission mode, or other mode of transportation.

The chain of transformation components 406 can form a pipeline, e.g. of a similar kind as the pipeline concept in UNIX. The difference is that the Offer/Accept interfaces allow the transformation components to execute in the same process so that the cost of the management is minimized. The Offer/Accept interfaces act in both directions, contain flow control and do not copy data. From the point of view of definition, the trans- formation components shall be users of this interface.

The described concept for the transformation function 124 implies the following advantages and possibilities for the designer and the operator:

- arbitrary data transformation, i.e. not only formatting, - arbitrary file transmission protocol or other file management (tape, writer, etc.),

- a maximum amount of generic functionality, i.e. a high level of design support,

- a minimum of design and implementation for the applica- tion,

- reuse of already designed transformation components,

- possibility of changing transformation components in an operating system, but not during file transmission,

- possibility of adaption to standard, existing and future, by adding transformation components,

- possibility, depending upon the requirement of the market or the application, to be able to supply records and files on an arbitrary format.

The post management function GPP is an abstract resource object with predefined methods and parameters, but. the real management within the object is application specific.

GPP can thus be regarded as a box into which it is possible to introduce different data transformations as long as determined rules for transformation components are followed. These are, on the one hand, that the transformation components shall use an established interface, such as the 0/A interface, and, on the other hand, have input and output types, where the output type of a transformation component shall suit the input type of the next transformation component in the pipeline.

Certain markets/users can have requirements on flexibility with respect to format and/or transformations, and other ones with respect to efficiency in the transformation. The require¬ ments are somewhat contradictory, but both can be fulfilled. If efficiency for a fixed format is desirable a transformation component can be designed with an optimized code for the specific format. If flexibility is desired, a library is designed with selectable transformation components.

To be able to use a maximum of generic functionality it is required that analysis is performed with respect to where the information contents must be known, and where it is the question of data. In most cases it is the question of data, i.e. a container of bits that shall be transported, stored, sent, etc. As long as it is the question of data, generic functions can be used, as soon as it is the question of information, the function must be specialized.

Preferably, the GPP function is designed from the beginning with a basic transformation component. The reason for this is that the designer of the GOPS function cannot know which formats different users/markets will have for their information. Accordingly, it is the application/market designer that shall thereafter specialize this component for the desired purpose. As an example, an operator can adapt the format of the records to a data base format used in a local post management system. This is possible by specializing the basic transformation component.

As an example, a schematic account will be given here by means of Figs. 5-8, and outgoing from the design of a network element described with reference to Figs. 1-3, of how the GOPS function 122 in Figs. 1-3 can be used for getting and feeding out information. In this example, "getting" means getting information from a log.

If no formatting or other data management is performed, it is the question of the internal format being transferred. This property is usable e.g. if the managed information is transformed outside the system. In this case the GOPS function is a support for feeding out log records as virtual files.

Fig. 5 indicates how an information generating object 502 sends a notification 504 to a log 506, where it is stored as a log record. From the log 506 the log record can now be fetched by GOPS 122, that after formatting and managing of it, sends the information packet, thereby obtained, further according to arrow 510.

Notifications can be regarded as information carriers. TMN standard defines a support object denominated EFD (Event Forwarding Discriminator) as a collector of notifications, but notifications can alεo be collected in logs for intermediate storing.

Notifications can be of two types, viz. managed object notifications or resource notifications. The log can subscribe to both types of notificationε. Notifications must be formatted and managed before being fed out.

Notifications are stored as log records and the log records are fetched from the log.

Mass data, i.e. not individually selected data, should be transferred as files for capacity reasons, but each application can select arbitrary file transmission available in the network element.

Feeding out of formatted records is performed via a generic interface. The file transmission protocol is an independent interface. The feeding out interface is generic in the sense that the same methods and parameters will be used by all objects that can be selected for feeding out at establishment of GOPS. The file format belongs to the selected feeding out object. As an example, an object as the one in the present example, can consist of an implementation of FTAM, and another one of FTP. The generic interface supports the same methods for both implementations.

Fig. 6 illustrates the principles for the way of operation of the GOPS function in the example according to Fig. 5. In a horizontal direction the Figure is divided into three sections, viz. an operationε εupport management view 602 via the interface 110, a view 604 of a part of the resource layer 106 (Fig. l) , and a file management view 606 via the interface 112 (Fig. 1) . Dashed vertical lines of separation between the three views are designated 608 and 610, respectively. The management view 602 contains the managed object 304 for the GOPS function 122 (Figs. 1 and 3) in the resource layer 106. The view 604 contains, besides the function 122, the log 506 and the GPP function 124 (Figs. 1-3) . In the file management view 606 the representation 120 (Fig. l) of the GOPS function 122 as well as FTAM_Responder 308 (Fig. 3) are included.

With reference also to the sequence diagram in Fig. 8, Fig. 6 illustrates how a demand is sent, arrow 802, via the responder 308 included in the file management view, arrow 614, for obtaining one or more log records from the log 612. The demand originates from an initiator, which is represented by the block 104 in Figs. 1-3 according to the above. The demand is forwarded, arrow 616, via the GOPS representation 120 to the GOPS function 122. The GOPS function 122 sends a request according to arrow 617 for obtaining a current log record or records from the log 612. The log records are sent to the GOPS function 122 according to the arrow 618 and are forwarded by the later to the GPP function 124 with a request, arrow 620, for post management, i.e. transformation to a format desired by the initiator 104. The GPP function 124 performs the required transformation and sends, arrow 622, the data thus post managed, e.g. in the form of files, to the GOPS function 122. The GOPS function 122 sends, arrow 624, the files further via the GOPS representation 120 and responder 308, arrow 626. Via the responder 308 the files at last reach initiator 104, according to arrow 804 (Fig. 8) .

In the described example, the initiator 104 can be an arbitrary actor, e.g. the operations support system, a billing center, etc. The post managed data obtained from the GOPS function 122 can, however, besides file transfer, e.g. via FTAM as described above, also be fed out through another external communication, such as tape, writer, etc., that is available in a current system. The G0PS_M0 representation 304 (Fig. 3) in the operations support view of the GOPS function 122 is established when a system such as the one in Fig. 6 is started. By the representa- tion 304 the operations support system establishes and controls the rules for that applicable in this system. Thus, as an example, it is established which logs that shall be used, how the GPP function shall be designed, i.e. the number and character of its transformation components, which rules that are valid for the communication with external users, e.g. the rules for file establishment in the example according to Fig. 6.

In Fig. 7 an example of a scenario according to Figs. 5 and

6 is illustrated, being a case within the mobile telephony wherein a billing center subscribes to traffic data, so-called TT records (Toll Ticketing) , which are stored in logs in an internal format. By means of GOPS and via FTAM the billing center obtains these traffic data. Fig. 7 shows a network element 702 containing traffic information generating objects 704.1-704.n, which can represent mobile telephony subscribers, an operations support system 706, a log 708 and an intermediate storing memory 710. Furthermore the file server entity GOPS-VFS 120, the GOPS function 122, the GPP function 202 and FTAM responder 308 are indicated. The billing center, forming an external user is designated 712 and contains the FTAM initiator 104.

Via the operations support system 706 traffic data from the objects 704 are εtored in the log 708. The traffic data, on which the billing center 712 subscribes, are thereafter intermediate stored in the memory 710.

During off peak hours the billing center 712 collects and fetches intermediate stored traffic data from the memory 712 via the log 708. The communication and the process is performed in the same way as has been described for Figs. 6 and 8, and the arrows included in Fig. 7 have therefore obtained the same reference numerals as the corresponding arrows in Figs. 6 and 8.

With reference also to the sequence diagram in Fig. 8, Fig.

7 illustrates how a request is sent, arrow 802, from the FTAM initiator 104 to the FTAM responder 308 to obtain one or several log records from the log 708. The request is forwarded, arrow 614, via the GOPS representation 120 to the GOPS function 122, arrow 616. The GOPS function 122 sends a request according to the arrow 617 to obtain current log record or records from the log 608. The log records are sent from the intermediate storing memory 710 via the log 708 to the GOPS function 122 according to arrow 618. The log records are forwarded by the GOPS function 122 to the GPP function 124 with a request, arrow 620, for post processing, i.e. transformation to the format desired by the initiator 104. The GPP function 124 performs the requested transformation and sends, arrow 622, the data thus post pro¬ cessed, e.g. in the form of files, to the GOPS function 122. The GOPS function 122 sends, arrow 624, the files furtheron via the GOPS representation 120 and responder 308, arrow 626. Via the responder 308 the files at last reach the initiator 104 in the billing center 712, according to arrow 804.

With reference to Figs. 9-12 a number of further examples are given in the following in the form of a run time view of post processing by means of the GPP function.

Fig. 9 is essentially identical to Fig. 5, and therefore the same reference characters as in Fig. 5 are used in cases where appropriate. In short, an information generating object 502 sends a notification 504 to a log 506, where it is stored as a log record. From the log 506 the log record is fetched by GOPS 508, that after formatting and processing by the GPP function, designated 902, sends the thereby obtained information packet further according to arrow 510. The purpose of Fig. 9 is to illustrate that post processing is developed for minimizing the need of managing information and, when the need arises, to make these occasions/functions as flexible as possible. The structure and contents of the in¬ formation need to be known in a few defined places, indicated by an oval 904 in Fig. 9, as well as in Figs. 10-13. In Fig. 9 such an oval 904 is thus present in the information generating object 502 and the GPP function 902. In Fig. 9 the GPP function is shown as being intended for being managed immediately before output, but could as well be used before logging (not shown) . A market can require the same record delimiters for different types of records and therefore it can be usable to implement these as a separate object for reuse. This property can be developed further to provide a layered support structure for post processing. With reference to Fig. 10 the GPP function 1002 can, as an example, contain a transformation component 1004 for opening an information packet coming in at 1006, a transformation component 1008 for translating tags to market specific tags, a transformation component 1010 for formatting, and a trans¬ formation component 1012 for record delimiting. Further examples not shown, of tasks for transformation components are sorting of records according to a desired order, aggregation of tables, compiling of records from instrument readings, etc. The internal structure of the GPP function admits use of 0-n separate functions and thereby reuse of application objects.

Fig. 11 is intended to illustrate an example wherein a log

1101 has collected information from persistent objects in notifications, which shall be post procssed by a GPP function

1102 included in a GOPS function 1104. In the GPP function 1102 the notifications are opened by a transformation component 1106, compiled and formatted by a transformation component 1108, and record delimited by a transformation component 1110. The result is thereafter fed out, arrow 1112, by the GOPS function 1104 in a file format 1114.

It is possible to transform data in several steps, depending upon the purpose of the transformation. As an example Fig. 12 is intended to illustrate a possible security management scenario. An object 1202 adds a checksum, arrow 1203, to a security notification 1204, that is thereafter logged as a log record 1205 in a log 1206. From the log 1206 the log record 1205 is fetched by a GOPS function 1208. In a GPP function 1210 included in the GOPS function 1208 formatting is performed of a transformation component 1212, encrypting by a transformation component 1214 and record delimiting by a transformation component 1216. The result is sent from the GOPS function 1208 in a file format 1218.

It is also possible to optimize in different ways for attaining flexibility or capacity/throughflow. Fig. 13 iε intended to show, as an example, a posεible debiting management εcenario.

From an output 1302 for call records a notification 1304 is sent for logging as a log record in a log 1306. From the log 1306 the log record is fetched by a GOPS function 1308. In the GOPS function 1308 a GPP function 1310 is included. By a trans¬ formation component 1312 included in the GPP function ₁₃10 transformation is performed to a code optimized for a specific market and application.

Claims

Claims .

1. A network element included in a data network with an operations support system (104) for operation and maintenance of the network, comprising a resource layer (106) containing resources in the form of hardware and software, including network element functions providing services in the network, as well as resources used for performing the network element operations, an operations support view (110) consisting of software, in which the network element (102) from the operations support system (104) looks like consisting of a number of resource representations (114) and is used by the operations support system for managing the respective resource and network element function in connection with performing a network element operation, a support function (122,124) located in the resource layer and including a communication function for communicating with a user, and for fetching and providing, on request, data available in the resource layer, and a transformation function for trans¬ forming these fetched data to a desired format.

2. A network element according to claim 1, wherein, in a file management view (112) consisting of software, the network element, from the operations support system (104) or an external user (712) , lookε like consisting of a number of data file identifying objects (118,120) which can be used by the operations support system for data file transmission in the resource layer to a resource, that can be used by an external user, said communication function (122) iε represented by a managed object (304) in the operations support view (110) and by a data file identifying object (120) in the file management view

(112) for thereby connecting together the file management view

(112) , the transformation function (124) and the operations εupport view (110) so as to allow a data file transformed by the transformation function (124) to be transferred to a resource used by an external uεer (712) .

3. A network element according to claim 1 or 2, wherein the transformation function comprises a number of transformation components intended for each its kind of transformation.

4. A network element according to claim 3, wherein each of the transformation components has a role or subtask in a data operation in the transformation function.

5. A network element according to claim 4, in which one or more of the transformation components realize a specific operational step or cases of use, and a group of mutually related such cases of use form a function that can consist of part of or the whole transformation function.

6. A network element according to any of claims 3-5, wherein each transformation component executes a software component in the form of a loading module that contains one or more software unitε which each can consist of a separate compilable source code quantity.

7. A network element according to claim 6, wherein the software units implement and use interfaces consisting of a group of type definitions and two role definitions for each a trans- formation component.

8. A method for creating a support function in a network element that is part of a data network having an operations support εystem for operation and maintenance of the network, said network element comprising a resource layer containing resources in the form of hardware and software, including network element functions providing services in the network, as well as resources used for performing the network element operations, an operations support view consisting of software, in which the network element from the operations support syεtem looks like consisting of a number of resource representations and is used by the operationε support system for managing the respective resource and network element function in connection with performing a network element operation, said method comprising the steps of creating in said resource layer, as a part of εaid εupport function, a communication function to be used for communicating with a user and for fetching and providing, on request, data available in the resource layer, a number of software components in the form of loading moduleε by interlinking for each software component a number of compiled software units, each consisting of a separately compilable source code, a transformation function for transforming the fetched data to a desired format, and comprising a number of transformation components for executing each a said software component.

9. A method according to claim 8, comprising the stepε of interconnecting, when linking together the compiled software units, a unique implementation with a number of interfaces implemented and used by the software units, so as to statically associate all uses of such interfaceε within the software component with said unique implementation, and interconnecting, when loading a software component into a processor, a further number of interfaces implemented and used by the software units with a unique implementation, for providing a number of remaining open interfaces for implementation and use in a loaded software component.

10. A method according to claim 9, comprising the steps of preparing a software component for use in a case of use by defining the application by its open interface, providing by a software component having at least one open interface a set of abstract connection points which each uses or implements one of the open interfaceε.

11. A method according to claim 10, comprising configurating a case of use by selecting, in a first step, εoftware components to be included for obtaining a set of open interfaces, determining, in a second step, for each software component, the transformation component or components it shall occupy in the current use case, whereby there is obtained for each trans¬ formation component a concrete connection point corresponding to each abstract connection point in its software component, matching, in a third step, user and implementation for all concrete connection points.

12. A method for performing, on request, an operation including transforming data available in a resource layer in a network element to a desired format and providing such trans¬ formed data for a desired instance, said network element being included in a data network with an operations support system (104) for operation and maintenance of the network, and compri¬ sing said resource layer (106) as containing resources (108) in the form of hardware and software, including network element functions that provide services in the network, as well as resources which are used for performing the network element operations, an operations support view (110) consisting of software, in which the network element (102) , from the operations support syεtem (104) , looks like consisting of a number of resource representationε (114) and iε uεed by the operationε εupport system for managing a respective resource and network element function in connection with performing a network element operation, said method comprising the stepε of fetching and sending by means of a communication function, located in the resource layer, said data available in the resource layer to a transformation function, likewise located in the resource layer, transforming these data to the desired format by said transformation function, returning the transformed data to the communication function and forwarding by the communication function the transformed data to the desired instance.

13. A method according to claim 12, in which the network element includes a file management view (112) consisting of software, wherein the network element from the operations support syεtem (104) or an external user (712) looks like consisting of a number of data file identifying objects (118,120) which can be used by the operations support system for data file transfer in the resource layer to a resource that can be used by an external user, comprising the stepε of repreεenting the communication function by a managed object in the operations support view and by a data file identifying object in the file management view so as to connect together the file management view, the trans¬ formation function and the operations support view and thereby allow a data file transformed by the transformation function to be transferred to a resource used by an external user forming said instance.

14. A method according to claim 12 or 13, in which, for obtaining data of a desired format, a user sends a request regarding this to the network element that starts a corresponding procesε comprising the steps of forwarding the request to the communication function, fetching by the communication function basic data, corre¬ sponding to said data in a desired format, from a resource included in the resource layer and containing said basic data, sending by the communication function said basic data to the transformation function with a request for transformation to the desired format, performing by the transformation function the requested transformation and sending of the transformed data to the communication function, and forwarding by the communication function the transformed data to the external user.

15. A method according to claim 14, in which the transformed data are transmitted from the network element to the user via file transmission or by any other external communication.

16. A method according to claim 14 or 15, comprising starting the process by establishing a representation for the communication function in the operations support view, and establiεhing and controlling by the operationε εupport εyεtem via said representation the rules for that applicable to carry through the process.

17. A method according to claim 16, in which said rules include instructions regarding what basic data containing resources that shall be uεed, how the transformation shall be designed, and what rules that are applicable for communication with the user.

18. A method according to any of claims 14-17, comprising fetching said basic data from a log and performing said trans¬ formation before or after logging.

19. A method according to any of claims 14-17, comprising obtaining said basic data from a notification.

20. A method according to any of claims 12-19, comprising performing said transformation by the tranεformation function by meanε of a number of tranεformation components intended for each its kind of transformation.

21. A method according to claim 20, comprising using one or more transformation components for performing any or some of the following transformations: opening an incoming information packet containing said basic data, translating tags to market specific tags, formatting, performing data record delimitation, sorting records according to a desired order, aggregating tables, compiling records from instrument readings, encrypting, transforming to code optimized for a specific market and application.