EP0856217A1 - A support function for a network element - Google Patents

A support function for a network element

Info

Publication number
EP0856217A1
EP0856217A1 EP96935725A EP96935725A EP0856217A1 EP 0856217 A1 EP0856217 A1 EP 0856217A1 EP 96935725 A EP96935725 A EP 96935725A EP 96935725 A EP96935725 A EP 96935725A EP 0856217 A1 EP0856217 A1 EP 0856217A1
Authority
EP
European Patent Office
Prior art keywords
network element
data
function
transformation
software
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP96935725A
Other languages
German (de)
English (en)
French (fr)
Inventor
Kurt Davies Jonsson
Carina Marie Runefjord
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of EP0856217A1 publication Critical patent/EP0856217A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units

Definitions

  • a support function for a network element is a support function for a network element.
  • the present invention generally relates to generic support for feeding out and post managing data in a data system.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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 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.
  • 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.
  • 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) .
  • its characteristic interface is identical to that of the transformation component.
  • 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.
  • 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 in the form of hardware and software in a resource layer 106.
  • network element functions which each provides a service in the network, as well as other resources used for performing the network element operations.
  • 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.
  • 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.
  • FTAM File Transfer, Access and Management
  • 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 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.
  • the communication function 122 is represented by VSF 120.
  • 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.
  • 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.
  • GPP 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.
  • transformation component is thus here meant a function that transforms data.
  • 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.
  • 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.
  • FIG. 2 schematically illustrates the structure of the GPP function.
  • a block 202 designated R_GPP R: Resource
  • R_GPP Resource
  • 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.
  • a block 302 designated FMA_GOPS FMA: FileManage- ment Adaption
  • FMA_GOPS FileManage- ment Adaption
  • 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.
  • the GOPS function 302 is represented by a managed object MO_GOPS (MO: Managed Object) designated 304.
  • MO_GOPS Managed Object
  • 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.
  • 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.
  • a responder is a "file service user” that accepts "FTAM regime establishment", that is asked for by an initiator.
  • 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”.
  • 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.
  • Annex A in the same part some examples of use of FTAM are included, in the form of sequence diagrams.
  • 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.
  • a software component 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.
  • 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.
  • obligatory software components 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • "getting" means getting information from a log.
  • 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.
  • EFD Event Forwarding Discriminator
  • 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.
  • 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.
  • 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) .
  • the representation 120 (Fig. l) of the GOPS function 122 as well as FTAM_Responder 308 (Fig. 3) are included.
  • 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) .
  • 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.
  • FIG. 7 an example of a scenario according to Figs. 5 and
  • a billing center subscribes to traffic data, so-called TT records (Toll Ticketing) , which are stored in logs in an internal format.
  • TT records Toll Ticketing
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 ⁇ Obd, 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.
  • Fig. 9 is essentially identical to Fig. 5, and therefore the same reference characters as in Fig. 5 are used in cases where appropriate.
  • 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.
  • FIG. 9 such an oval 904 is thus present in the information generating object 502 and the GPP function 902.
  • 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.
  • 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
  • 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.
  • 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.
  • the log record 1205 is fetched by a GOPS function 1208.
  • 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.
  • Fig. 13 i ⁇ intended to show, as an example, a pos ⁇ ible debiting management ⁇ cenario.
  • a notification 1304 is sent for logging as a log record in a log 1306.
  • the log record is fetched by a GOPS function 1308.
  • a GPP function 1310 is included in the GOPS function 1308 .
  • trans ⁇ formation component 1312 included in the GPP function 13 10 transformation is performed to a code optimized for a specific market and application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
EP96935725A 1995-10-19 1996-10-18 A support function for a network element Withdrawn EP0856217A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
SE9503675 1995-10-19
SE9503675A SE515343C2 (sv) 1995-10-19 1995-10-19 Stödfunktion för nätelement
PCT/SE1996/001327 WO1997015133A1 (en) 1995-10-19 1996-10-18 A support function for a network element

Publications (1)

Publication Number Publication Date
EP0856217A1 true EP0856217A1 (en) 1998-08-05

Family

ID=20399889

Family Applications (1)

Application Number Title Priority Date Filing Date
EP96935725A Withdrawn EP0856217A1 (en) 1995-10-19 1996-10-18 A support function for a network element

Country Status (8)

Country Link
EP (1) EP0856217A1 (sv)
JP (1) JPH11513824A (sv)
KR (1) KR19990064317A (sv)
AU (1) AU705857B2 (sv)
CA (1) CA2235403A1 (sv)
NO (1) NO981714L (sv)
SE (1) SE515343C2 (sv)
WO (1) WO1997015133A1 (sv)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6134544A (en) * 1997-11-21 2000-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Query supporting interface between a customer administrative system and database network elements in a telecommunications system
JP2001084183A (ja) 1999-09-17 2001-03-30 Nec Corp データ変換システム
WO2014201085A1 (en) * 2013-06-14 2014-12-18 Zte (Usa) Inc. Method and system for virtualized network entity (vne) based network operations support systems (noss)

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA1312959C (en) * 1987-11-06 1993-01-19 Kiritkumar Talati Virtual interface system and method for enabling software applications to be environment-independent
US5049873A (en) * 1988-01-29 1991-09-17 Network Equipment Technologies, Inc. Communications network state and topology monitor
US5075847A (en) * 1989-05-26 1991-12-24 Hewlett-Packard Company Method and apparatus for computer program encapsulation
NL8901827A (nl) * 1989-07-14 1991-02-01 Oce Nederland Bv Systeem voor het verwerken van in bestanden georganiseerde gegevens, alsmede beheersmodule ten gebruike daarin en opslagmedium, voorzien van de programmatuur van deze beheersmodule.
US5367635A (en) * 1991-08-29 1994-11-22 Hewlett-Packard Company Network management agent with user created objects providing additional functionality
FI106418B (sv) * 1992-03-10 2001-01-31 Nokia Networks Oy Nätkontrollsystem
ES2126656T3 (es) * 1992-08-28 1999-04-01 Ericsson Telefon Ab L M Gestion de sistemas de telecomunicacion y de sistemas abiertos.
US5375241A (en) * 1992-12-21 1994-12-20 Microsoft Corporation Method and system for dynamic-link library

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9715133A1 *

Also Published As

Publication number Publication date
AU705857B2 (en) 1999-06-03
WO1997015133A1 (en) 1997-04-24
KR19990064317A (ko) 1999-07-26
NO981714L (no) 1998-06-19
AU7354196A (en) 1997-05-07
NO981714D0 (no) 1998-04-16
SE9503675L (sv) 1997-04-20
JPH11513824A (ja) 1999-11-24
SE9503675D0 (sv) 1995-10-19
SE515343C2 (sv) 2001-07-16
CA2235403A1 (en) 1997-04-24

Similar Documents

Publication Publication Date Title
US9742614B2 (en) Data-type definition driven dynamic business component instantiation and execution framework
CN101065947B (zh) Web服务注册和操作方法和系统
CN102394875B (zh) 由第一网络的成员访问第二网络上可用业务的方法及系统
US5579384A (en) Telecommunications network service central management system interfacing with protocol specific regional stations providing services to subscribers
AU684912B2 (en) System for managing networked computer applications
US20070036315A1 (en) Platform for rapid development of telecommunication services
CN1285120A (zh) 结构独立应用程序在一个电话网络上的调用
WO2002086679A2 (en) Service provision system and method
EP1175753A1 (en) Telecommunications network resource handling arrangement and method
US20090259510A1 (en) Operational Support System for Telecommunication Services
CN1125435C (zh) 话音处理系统
JPH08274814A (ja) ネットワーク通信カスタマイズのための方法とシステム
AU705857B2 (en) A support function for a network element
CN100586203C (zh) 用于集成网络服务提供者的服务应用程序构架
EP0873029A1 (en) An SCP interface
US6151317A (en) Control type or service independent building block
Thimm et al. A mail-based teleservice architecture for archiving and retrieving dynamically composable multimedia documents
US7376748B1 (en) Data delivering system
EP1715653A1 (en) A system and method for mediating within a network
US7039612B1 (en) Intranet platform system
Baseline Service Architecture
AU691667B2 (en) A method to structure call processing and a call processing switching system for telephony
CN117729262A (zh) 一种网关服务编排方法、装置、设备及存储介质
MXPA00005961A (en) Architecture independent application invocation over a telephony network

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19980406

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT CH DE DK ES FI FR GB IT LI NL

17Q First examination report despatched

Effective date: 20020513

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030924