WO1995016318A1 - Information transmission system and telecommunications equipment intended to be used in such a system - Google Patents

Information transmission system and telecommunications equipment intended to be used in such a system Download PDF

Info

Publication number
WO1995016318A1
WO1995016318A1 PCT/IB1994/000400 IB9400400W WO9516318A1 WO 1995016318 A1 WO1995016318 A1 WO 1995016318A1 IB 9400400 W IB9400400 W IB 9400400W WO 9516318 A1 WO9516318 A1 WO 9516318A1
Authority
WO
WIPO (PCT)
Prior art keywords
die
equipment
module
objects
management
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.)
Ceased
Application number
PCT/IB1994/000400
Other languages
French (fr)
Inventor
Daniel Goumillou
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.)
Telecommunications Radioelectriques et Telephoniques SA TRT
Koninklijke Philips NV
Philips Norden AB
Original Assignee
Telecommunications Radioelectriques et Telephoniques SA TRT
Philips Electronics NV
Philips Norden 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 Telecommunications Radioelectriques et Telephoniques SA TRT, Philips Electronics NV, Philips Norden AB filed Critical Telecommunications Radioelectriques et Telephoniques SA TRT
Priority to EP95901560A priority Critical patent/EP0685131A1/en
Priority to US08/500,841 priority patent/US5836008A/en
Priority to JP7516078A priority patent/JPH08509342A/en
Publication of WO1995016318A1 publication Critical patent/WO1995016318A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to a transmission system for transmitting information between a source and a receiver via a network, to which network is connected telecommunications equipment comprising a bus dedicated to the exchange of management messages between a plurality of interface modules for various communication services and at least a supervisory module used as an interface between said equipment and external administration equipment.
  • the invention likewise relates to telecommunications equipment as described above and, particularly, to a service multiplexer for an ATM network.
  • an information transmission system is characterized in that for internally transmitting said management messages said telecommunications equipment comprises communication means based on a similar communication protocol to that used between the external administration equipment and the supervisory module.
  • Telecommunication equipments of such a system comprise interfaces for varied, real-time telecommunications services, and are therefore naturally evolutive.
  • the introduction of a new interface module for a new service implies considerable modifications with respect to the supervisory module.
  • a further aim of the present invention is therefore to propose an information transmission system whose telecommunications equipment is designed to facilitate such evolution by minimizing its impacts on the developments realised in the past. Therefore, an information transmission system according to the inventio and as described in the opening paragraph is characterized in that with respect to their management the telecommunications resources of each module are structured as objects which correspond as regards software to an encapsulation of management information generated by said resources and of operations that can be applied to this information.
  • said telecommunications equipment thus comprises for the internal transmission of said management messages communication means based upon die Common Management Information Protocol (CMIP) recommended by the CCITT while said objects have the following properties which form part of the Common Management Information Service Element (CMISE):
  • CMIP Common Management Information Protocol
  • CMISE Common Management Information Service Element
  • CMIP protocol which is based upon die common service element CMISE actually provides the advantage of being largely distributed in die field of network administration.
  • each of said objects is advantageously: - eidier an instance of a class defined in the Management Information Base (MIB) recommended by me CCITT,
  • MIB Management Information Base
  • each module advantageously supports the objects which determine its own telecommunications resources and, to handle said objects, comprises hardware means and software means and, more specifically, communication means associated thereto, while the number of centralized functions in the supervisory module are minimized.
  • FIG. 1 shows an example of a service multiplexer for an ATM networ according to the invention
  • Fig. 2 is a diagram representing an example of me operational fabric o an interface module of telecommunications equipment according to the invention
  • - Fig. 3 is a diagram giving a symbolic representation of a class of an object
  • - Fig. 4 is a diagram representing an example of me information transmission system according to the invention
  • FIG. 5 is a diagram representing an example of how objects of a video conference module of an ATM service multiplexer according to d e invention are arranged;
  • Fig. 6 is a diagram giving a symbolic representation of an object of the video conference module called "pam G703" object;
  • Fig. 7 is a diagram representing an example of the architecture of the software of a local operation subassembly of a video conference module of a service multiplexer for me ATM network according to me invention.
  • Fig. 8 is a diagrammatic representation of an example of the communication service object.
  • the telecommunications equipment to be described by way of example in the following is a service multiplexer for an ATM network.
  • Such an ATM service multiplexer is shown in Fig. 1. Its role is to multiplex various services (X25, local network and video conference network in this embodiment) on a high-rate ATM link. Therefore the multiplexer comprises a supervisory module 2 and five interface modules: two network modules 3 and 4 connected via hardware accesses 15 to d e ATM network, and tiiree service modules 5, 6 and 7 connected via hardware accesses 15 to a codec (coder-decoder) for video conference, to a local area network LAN and to a network X25, respectively. These six modules are interconnected by a bus 8 dedicated to me internal management of the equipment.
  • codec coder-decoder
  • the five interface modules are furthermore interconnected by a data bus 9 dedicated to transporting ATM cells and as described, for example, in French Patent Application no. 9303775 filed 31/03/1993 by die Applicants.
  • m supervisory module 2 is connected to an external local administration station 10.
  • each module has its associated processing capacity, data capacity and memory capacity and die software is distributed as much as possible in die various modules of me equipment so as to process nearly all me management information generated by me hardware functions. Moreover, each module is autonomous, so that it can be witiidrawn from or used in a piece of equipment without interference with die operation of d e odier modules. Thus, die supervisory module primarily ensures a bridging function towards die external administration system and it handles various centralized applicative functions.
  • Fig. 2 shows the functional structure of a module of telecommunications equipment according to d e invention. It comprises four functional subsets:
  • a subset 13 which is used as a management interface between the subsets 11 and 12, on die one hand, and, on die odier hand, a subset 14 charged widi the internal management of the equipment.
  • This management interface gathers the management information generated by die hardware functions and/or by die subset 12 which manages the access to die data bus 9, in the form of counter alarms, counter states, and it transmits mem to the subset 14.
  • the subset 14 which comprises a microprocessor unit 16 based upon, for example, M68302 manufactured by Motorola, receives management information either from die interface subse 13 or me management bus 8, and it executes die following operations:
  • the microprocessor unit 16 in fact comprises a microprocessor 17, a read-only memory 18 in which is stored all d e software that permits the realisation of various processes, and a read/ write memory 19.
  • a certain number of hardware functions thus corresponds to each module, and management information (performance, defaults, rate making, configuration) which are processed by die internal management subset 14 are associated to each of these functions.
  • each module (module, physical access, communication layer 7) are structured as regards dieir management in the form of objects which correspond from die point of view of software to an encapsulation of management information and of processes diat can be applied to diis information.
  • each type of resource is thus associated a type of object called "class" which is in fact a generic model diat gathers the information and includes processes which are characteristic of this type of resource.
  • Each class has, for example in die form of a programmed function, a "constructor” whose role it is to create the new objects of the class called instance of the class.
  • Each class is thus “instanced” in as many real elements as are necessary.
  • This process is accompanied by a memory allocation.
  • me data of each object are gadiered in a block of the read/write memory 19 under die control of a memory allocation service.
  • diis service allocates a reference to die number of the empty memory block to the object. This number is then used as a local instance number to refer to the object at module level.
  • the memory allocation service produces die address of die memory block which contains me object data on me basis of this local instance number.
  • diis equipment allocates an aggregate instance number to me object, which number makes it possible to refer to same at equipment level.
  • This aggregate instance number is formed by: - die number of the plug of the module supporting me object on the management bus, - the class of the object,
  • each class has a "destroyer" whose role it is to destroy d e objects of a previously created class and diis operation is accompanied by die restoration of the memory that had been assigned to each of diese objects.
  • Fig. 3 gives a symbolic representation of the classes on die basis of which the objects are created diat determine the telecommunications resources of each module.
  • the objects accessible to die external administration are instances of classes defined in d e Management Information Base (MIB) recommended by die CCITT.
  • MIB Management Information Base
  • attributes ATTR 1, ATTR 2 and ATTR 3 which form me data of the object and which hav a value that can be consulted and/or modified on request addressed to die object.
  • attributes ATTR 1 that can be consulted by die administration
  • attributes ATTR 2 that can be consulted and modified by die administration
  • internal attributes ATTR 3 inaccessible to me administration
  • an object transmits a notification at each occurrence of an event it detects when a notification of such an event is requested in the definition of its class.
  • diis object structuring uses the formalism required by die service element CMISE (Common Management Information Service Element) which has been defined by d e CCITT to permit, more specifically, exchanges between pieces of telecommunications equipment and administration systems in me form of requests and/or responses to requests so as to realise, on the one hand, management operations such as a consultation, an updating, a creation or a deletion of management information and, on die odier hand, notifications of events.
  • CMISE Common Management Information Service Element
  • Fig. 4 shows, amongst other things, an embodiment for the information transmission system according to the invention, which allows of the interconnection of two codecs CODEC 1 and CODEC2 across an ATM network.
  • said ATM network comprises two ATM service multiplexers la and lb which are connected to die network via respective network modules 4a and 4b which are connected each to an external local administration station 10a and 10b respectively, by a supervisory module 2a and 2b, and which multiplexers comprise a video conference module 5a, 5b, respectively.
  • information signals coming from data sources Da and Db respectively, from channels Va and Vb or images Ia and lb are multiplexed in a frame in accordance widi Recommendation H221 of the CCITT and transmitted to eidier video conference module 5a, 5b respectively, at a rate equal to n.384 kb/s (where n is an integer between 1 and 5) which rate is liable to change during die communication.
  • Each video conference module is capable of managing a plurality of separate services: this is the case, for example, with module 5a which is also connected to a third codec CODEC3.
  • the interface between the codecs and d e service multiplexers is in accordance with Recommendation G703 (physical adaptation of transmitted data) and G704 (definition of the frame) of the CCITT for the physical layer and widi Recommendation H221 for the higher layers.
  • Fig. 5 is a diagram representing the setting up of objects of a video conference module.
  • Three types of objects are used: - centralized objects which are situated on die supervisory module, - decentralized objects which are situated on d e interface modules (diis is die case diat occurs most, because me software is spread most in me various modules of die equipment so that the management information generated by d e hardware is processed as accurately as possible), - and spread objects which are situated both on d e supervisory module and on die interface modules.
  • a particular object called centralized "root” object is defined. It is introduced at a predefined memory address and allows of direct access to d e highest level of dependence in the fadier-son hierarchy established between the objects.
  • a spread object called “module” object allows of ensuring the connection between the root object and die odier objects of die module. This "module" object is the first object created during die start.
  • die "root” object 100 introduced in the supervisory module includes a son object 101: die “module” object which is spread over die supervisory module and over die video conference module.
  • This module object itself includes at least d ree son objects introduced in the video conference module:
  • an object 102 (via video conference service managed by die module) representing die physical access in accordance wid Recommendation G703 of die CCITT called "G703 access" object
  • an object 103 representing the applicative software of the module so as to be able to identify die module (by its type number, its size ... ) and also to audiorize certain operations with die software (for example, a remote loading, a start, a stop, a deletion .... ),
  • the "G703 access” object includes a son object 105 called “channel G704", which represents the channel to the interface between the service multiplexer and die codec, in accordance widi Recommendation G704 of the CCITT.
  • the "channel G704" object includes two son objects:
  • n.384 kb/s transmit connection which represents the connection from the codec to die service multiplexer, which connection has a bit rate equal to n.384 kb/s.
  • n.384 kb/s receive connection which represents the connection from the service multiplexer to the codec, which connection has a bit rate equal to n.384 kb/s.
  • the object called "n.384 kb/s transmit connection” includes a son object 108 called “transmit AAL layer” which represents an asynchronous transfer mode adaptation layer (called AAL layer) in the transmit direction, diat is to say, from the codec to d e service multiplexer. This layer converts any specific service into a stream of undifferentiate cells.
  • die object called “n.384 kb/s receive connection” includes a son object 109 called “receive AAL layer” which represents this AAL layer in the receive direction, diat is to say from the service multiplexer to the codec.
  • the object called “transmit AAL layer” has a son object 110 called “virtual transmit channel” which represents the ending of a virtual channel from the module to d e transmit ATM network.
  • die object called “receive AAL layer” has a son object
  • virtual receive channel which represents the ending of d e virtual channel from the module to me receive ATM network.
  • the object called "virtual transmit channel” includes an object
  • intermediate transmit point which is set up in the network module diat handles diis virtual channel and which makes it possible to connect the output of the video conferenc module to die input of die corresponding network module.
  • object called “virtual receive channel” includes an object 113 called “intermediate receive point” set up in the network module diat handles diis virtual channel.
  • Fig. 6 symbolically represents one of the objects of video conference module: die object called "G703 access”.
  • This object represents the physical access in accordance wid Recommendation G703 of die CCITT for the video conference service. It is automatically created by its father object, die "module” object, when die module is inserted into the servic multiplexer, and destroyed when it is wid drawn therefrom.
  • the administration can neidier create nor destroy diis object which explains the absence of die “DELETE” operation, but it can consult and/or modify me values of certain of these attributes by the operations "GET" and "SET".
  • the attributes that may be consulted by d e administration are die following:
  • This state may be "in service” or “out of service”, the "out of service” state being attained when the object or a resource on which it depends is in an alarmed state,
  • AdministrativeState which contains the administrative state of die resource. This state may be "open” or "closed”,
  • the clock is provided, for example, either by d e coder or die service multiplexer, the latter utilizing then eidier its own local clock or a clock adjusted to die reception of d e ATM network, or a clock coming from an external network dedicated to clock distribution,
  • the "G703 access” object further includes two internal attributes; the first called “Num.Conduit.G704" contains die aggregate instance number of the "pad G704" object which is situated under d is "G703 access” object; and d e second called " Perfect_operationnel” indicates d e operational state (active or inactive) of the object.
  • the linking of objects that has been chosen in this example consists of making the father object point towards die son object, each son object itself pointing towards die two brodier objects around it and to dieir father object.
  • Two actions “GetFirst” and “GetNext” are thus defined to be able to access various interlinked objects: the action “GetFirst” makes it possible to access the first son object after which the action "GetNext” makes it possible to access subsequent son objects. These two actions make it possible to obtain information about die object "G704 channel" contained in an instance "G703 access”.
  • two notifications are defined.
  • the first notification called “ObjectCreation” is a notification which follows the creation of die "G703 access” object when die module is inserted.
  • die attribute an integer of 16 or 32 bits, a Boolean value or a list
  • die previously initialized attribute * the type of the value of die attribute (an integer of 16 or 32 bits, a Boolean value or a list), * the value of die previously initialized attribute.
  • die request comes either from inside the object, or from the external administration, from the supervisory module or from the video conference module which supports the object.
  • action function calls the applicative defence task.
  • die "action” function calls die applicative defence task.
  • the local instance number of the object is obtained based upon its aggregate instance number.
  • the address of die beginning of the memory block in which the data of the object are written is recovered based upon die local instance number of the object.
  • Fig. 7 The architecture of die software of such a subset is shown in Fig. 7.
  • a subset has two types of tasks: on the one hand, real-time and/or immediate tasks 40 (that is to say, triggered by an interruption) formed by a processing task 26 for processing the time and a reading task 42 for reading die counters, and, on die odier hand, tasks 50 differentiated under die control of a multitask core (for example of the VRTX type).
  • the tasks 50 include:
  • configuration task which includes d e functions of configuration, reconfiguration, alarm handling and post counting, to manage the objects of the module which objects represent the telecommunications resources of the module
  • intertask communication means 22 - and a monitoring task 52 cyclically triggered by d e time processing task 26, to read die statuses of the microprocessor unit 16 (more particularly the alarm statuses) and to trigger the necessary actions (reconfigurations, as required) in die case of a default.
  • the intertask communication means 22 uses at the applicative level the Common Management Information Protocol (CMIP) defmed by the CCITT as a Common Management Information Service Element CMISE.
  • CMIP Common Management Information Protocol
  • CMISE Common Management Information Service Element
  • the possible exchanges are eidier a transmission of a message towards a object denoted by a transport address, or a transmission of a message sent to all the objects of all the modules which determine telecommunications resources.
  • Each of these messages comprises a first header called transport header, a second header called object header and a data field which comprises a list of attributes, actions or events which correspond to a request, to a response to an operation or to a notification.
  • transport header allows die definition of:
  • a transport address of die destination object (diis address is, for example, formed by die number of the plug of die module in which the object is situated followed by die local instance number of the object),
  • the object header similarly allows the definition of: - die aggregate instance number of the destination object,
  • each module has a Communication Object Service SCO as is represented in Fig. 8, which is utilized by each task that uses an object representation to ensure:
  • the request messages MD1 are delivered to a first queue FAD in which the task T is awaiting a message most of the time.
  • the communication mechanism between two objects of a like task utilizes directly die internal call functions FD and response functions FR without passing through the messaging.
  • the task 24 for starting the system transmits an action request message (creation of various objects, configuration or reconfiguration of the hardware and/or software, possibly reinitialization of the alarm attributes) to the configuration task. Then diis message is converted and switched to die object "module" by die communication object service of the configuration task.
  • action request message creation of various objects, configuration or reconfiguration of the hardware and/or software, possibly reinitialization of the alarm attributes
  • the applicative software defence task 27 makes it possible to handle internal irregularities of the software. As this has been indicated during die description of die "constructor", "GET" and “action” functions, error detection points are provided in the software which, in the case of error, calls this defence task of the system, so that it evaluates the probable type of error and activates die process provided dierefore.
  • the tasks 40 include d e time processing task 26 which is an immediate task, and d e real-time task 42 for reading die counters (performance and rate making) of the module.
  • d e time processing task 26 which is an immediate task
  • d e real-time task 42 for reading die counters (performance and rate making) of the module.
  • Each module further comprises, facultatively, one or various tasks called historical tasks (not represented in Fig. 7), of less priority than the configuration task 32 described above for managing objects called historical objects (various tasks are used when is necessary to assign different priorities to them).
  • These objects are either recorders or recordings, each recorder ensuring the storing for a certain period of time in the form of recordings of events of die same type.
  • the recorder object is d en the fadier of a sequence of recording objects of the same type.
  • various types of recording objects are defmed as, for example, recordings of events of:
  • the external administration can selectively access these recordings to read or delete diem.
  • the invention has been described for a service multiplexer for ATM networks, it applies to a wide range of telecommunications equipment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

The invention relates to a system for transmitting information between a source and a receiver via a network to which is connected telecommunications equipment (1) comprising a plurality of interfaces (3, 4, 5, 6, 7) for various communication services (ATM, CODEC, LAN, X25) as well as an interface (2) between said equipment (1) and external administration equipment (10). In a preferred embodiment of the invention the various telecommunications resources of each module are structured in the form of objects whose properties are in conformity with those defined in the CMISE service recommended by the CCITT; the communication protocol CMIP is extended to within the equipment; and the objects accessible to the external administration are instances of classes defined in the information base MIB. Moreover, the hardware and logic processing means are spread over the various modules. Applications: particularly ATM network and service multiplexer for ATM networks.

Description

Information transmission system and telecommunications equipment intended to be used in such a system.
The present invention relates to a transmission system for transmitting information between a source and a receiver via a network, to which network is connected telecommunications equipment comprising a bus dedicated to the exchange of management messages between a plurality of interface modules for various communication services and at least a supervisory module used as an interface between said equipment and external administration equipment.
The invention likewise relates to telecommunications equipment as described above and, particularly, to a service multiplexer for an ATM network.
Such a system is described, for example in the article entitled "BREHAT, premier reseau a haut debit realise en technologie ATM" by J. Legras, G. Onno and M. Lemonier, published in the journal of "Commutation & Transmission" no. 3, 1991. Its telecommunications equipment are generally managed by external administration equipments, a dedicated communication protocol being used at the interface between these two types of equipments to transmit varied information signals which relate to the operation of said telecommunications equipment.
It is a first aim of the invention to provide maximum simplification of this interface.
Therefore, an information transmission system according to the invention and as described in the opening paragraph is characterized in that for internally transmitting said management messages said telecommunications equipment comprises communication means based on a similar communication protocol to that used between the external administration equipment and the supervisory module.
It is thus possible to avoid any conversion at the OSI application level in the supervisory module of such equipment. Telecommunication equipments of such a system comprise interfaces for varied, real-time telecommunications services, and are therefore naturally evolutive. The introduction of a new interface module for a new service implies considerable modifications with respect to the supervisory module.
A further aim of the present invention is therefore to propose an information transmission system whose telecommunications equipment is designed to facilitate such evolution by minimizing its impacts on the developments realised in the past. Therefore, an information transmission system according to the inventio and as described in the opening paragraph is characterized in that with respect to their management the telecommunications resources of each module are structured as objects which correspond as regards software to an encapsulation of management information generated by said resources and of operations that can be applied to this information. In a particularly advantageous embodiment of an information transmission system according to the invention said telecommunications equipment thus comprises for the internal transmission of said management messages communication means based upon die Common Management Information Protocol (CMIP) recommended by the CCITT while said objects have the following properties which form part of the Common Management Information Service Element (CMISE):
- attributes,
- operations with respect to these attributes and to the object itself,
- and notifications.
The CMIP protocol which is based upon die common service element CMISE actually provides the advantage of being largely distributed in die field of network administration.
In diis case, in order to avoid any conversion of data structure between me external administration and me internal management of the telecommunications equipment, each of said objects is advantageously: - eidier an instance of a class defined in the Management Information Base (MIB) recommended by me CCITT,
- or a specific object for internal needs in each module.
Finally, each module advantageously supports the objects which determine its own telecommunications resources and, to handle said objects, comprises hardware means and software means and, more specifically, communication means associated thereto, while the number of centralized functions in the supervisory module are minimized.
A systematic return of the data towards die supervisory module is thus avoided, which minimizes the processing time, and me future evolutions are made easier because the various modules are tiien mutually autonomous. Other particularities, details and advantages of die invention will be clarified by d e following description made with reference to the appended drawings which are given by way of examples which are not exhaustive, and in which:
- Fig. 1 shows an example of a service multiplexer for an ATM networ according to the invention;
- Fig. 2 is a diagram representing an example of me operational fabric o an interface module of telecommunications equipment according to the invention;
- Fig. 3 is a diagram giving a symbolic representation of a class of an object; - Fig. 4 is a diagram representing an example of me information transmission system according to the invention;
- Fig. 5 is a diagram representing an example of how objects of a video conference module of an ATM service multiplexer according to d e invention are arranged;
Fig. 6 is a diagram giving a symbolic representation of an object of the video conference module called "pam G703" object;
- Fig. 7 is a diagram representing an example of the architecture of the software of a local operation subassembly of a video conference module of a service multiplexer for me ATM network according to me invention; and
- Fig. 8 is a diagrammatic representation of an example of the communication service object.
Prior to the description of an information transmission system according to die invention, telecommunications equipment of such a system will be described first.
The telecommunications equipment to be described by way of example in the following is a service multiplexer for an ATM network. Such an ATM service multiplexer is shown in Fig. 1. Its role is to multiplex various services (X25, local network and video conference network in this embodiment) on a high-rate ATM link. Therefore the multiplexer comprises a supervisory module 2 and five interface modules: two network modules 3 and 4 connected via hardware accesses 15 to d e ATM network, and tiiree service modules 5, 6 and 7 connected via hardware accesses 15 to a codec (coder-decoder) for video conference, to a local area network LAN and to a network X25, respectively. These six modules are interconnected by a bus 8 dedicated to me internal management of the equipment. The five interface modules are furthermore interconnected by a data bus 9 dedicated to transporting ATM cells and as described, for example, in French Patent Application no. 9303775 filed 31/03/1993 by die Applicants. Finally, in this embodiment m supervisory module 2 is connected to an external local administration station 10.
The functions of such equipment can be subdivided as follows: - hardware functions, which comprise: * the conversion of protocols of die various services into an ATM protocol, and vic versa,
* die very high rate multiplexing and demultiplexing of various services processed simultaneously,
* the physical adaptation to various types of interfaces. - internal management functions, which comprise:
* the configuration and reconfiguration of die hardware,
* the survey of performance and loading,
* the management of errors,
* the management of the security - the communication with me external administration system constituted by station 10.
In the embodiment to be described below each module has its associated processing capacity, data capacity and memory capacity and die software is distributed as much as possible in die various modules of me equipment so as to process nearly all me management information generated by me hardware functions. Moreover, each module is autonomous, so that it can be witiidrawn from or used in a piece of equipment without interference with die operation of d e odier modules. Thus, die supervisory module primarily ensures a bridging function towards die external administration system and it handles various centralized applicative functions.
Fig. 2 shows the functional structure of a module of telecommunications equipment according to d e invention. It comprises four functional subsets:
- a subset 11 for handling hardware functions (services or network) of die module based upon data available on its hardware access 15 (service access or network access),
- a subset 12 which manages the access to d e data bus 9,
- a subset 13 which is used as a management interface between the subsets 11 and 12, on die one hand, and, on die odier hand, a subset 14 charged widi the internal management of the equipment. This management interface gathers the management information generated by die hardware functions and/or by die subset 12 which manages the access to die data bus 9, in the form of counter alarms, counter states, and it transmits mem to the subset 14.
- the subset 14, which comprises a microprocessor unit 16 based upon, for example, M68302 manufactured by Motorola, receives management information either from die interface subse 13 or me management bus 8, and it executes die following operations:
* it provides hardware configuration based upon received management information,
* it collects the information signals generated by the hardware, * it evaluates performance criterions,
* it returns information signals to me supervisory module on request via the management bus 8. The microprocessor unit 16 in fact comprises a microprocessor 17, a read-only memory 18 in which is stored all d e software that permits the realisation of various processes, and a read/ write memory 19. A certain number of hardware functions thus corresponds to each module, and management information (performance, defaults, rate making, configuration) which are processed by die internal management subset 14 are associated to each of these functions.
The logical or physical telecommunications resources of each module (module, physical access, communication layer ...) are structured as regards dieir management in the form of objects which correspond from die point of view of software to an encapsulation of management information and of processes diat can be applied to diis information.
To each type of resource is thus associated a type of object called "class" which is in fact a generic model diat gathers the information and includes processes which are characteristic of this type of resource. Each class has, for example in die form of a programmed function, a "constructor" whose role it is to create the new objects of the class called instance of the class. Each class is thus "instanced" in as many real elements as are necessary. This process is accompanied by a memory allocation. In fact, me data of each object are gadiered in a block of the read/write memory 19 under die control of a memory allocation service. When the object is created, diis service allocates a reference to die number of the empty memory block to the object. This number is then used as a local instance number to refer to the object at module level. Thus, each time it is necessary to have access to this object, the memory allocation service produces die address of die memory block which contains me object data on me basis of this local instance number. On the other hand, when die object is created, diis equipment allocates an aggregate instance number to me object, which number makes it possible to refer to same at equipment level. This aggregate instance number is formed by: - die number of the plug of the module supporting me object on the management bus, - the class of the object,
- d e local instance number,
- and a binary element mat indicates whetiier me external administration either or not has access to diis object. Similarly, each class has a "destroyer" whose role it is to destroy d e objects of a previously created class and diis operation is accompanied by die restoration of the memory that had been assigned to each of diese objects.
Fig. 3 gives a symbolic representation of the classes on die basis of which the objects are created diat determine the telecommunications resources of each module. In a particularly advantageous manner the objects accessible to die external administration are instances of classes defined in d e Management Information Base (MIB) recommended by die CCITT.
The characterizing properties of these object classes are d e following:
- attributes ATTR 1, ATTR 2 and ATTR 3 which form me data of the object and which hav a value that can be consulted and/or modified on request addressed to die object. Three types of attributes are defined: attributes ATTR 1 that can be consulted by die administration, attributes ATTR 2 that can be consulted and modified by die administration, and internal attributes ATTR 3 inaccessible to me administration,
- operations with respect to attributes: a consultation operation called "GET" and a modifyin operation called "SET",
- operations with respect to objects: a create operation called "CREATE" relating to the sons of die object, a destroy operation called "DELETE" and action operations called "ACTION" which are defined from one case to me next for each object. Two types of actions are defined: the actions ACT 1 which can be used by d e administration and die actions ACT 2 which cannot.
- notifications of events NOTIF: an object transmits a notification at each occurrence of an event it detects when a notification of such an event is requested in the definition of its class.
Examples of these properties will be given in the following description. Thus, diis object structuring uses the formalism required by die service element CMISE (Common Management Information Service Element) which has been defined by d e CCITT to permit, more specifically, exchanges between pieces of telecommunications equipment and administration systems in me form of requests and/or responses to requests so as to realise, on the one hand, management operations such as a consultation, an updating, a creation or a deletion of management information and, on die odier hand, notifications of events.
The base MIB, the service element CMISE and die principle of the object representation are described in me publication "Les normes de gestion de reseau a 1TSO" by C. Lecerf and D. Chomel, published in 1993 by MASSON in "Collection technique et scientifique des telecommunications".
In the following description an example will be given of die object structure of a service module: d e video conference module. However, it seems necessary though to present first the main characteristics of a video conference service while an ATM network is used.
Fig. 4 shows, amongst other things, an embodiment for the information transmission system according to the invention, which allows of the interconnection of two codecs CODEC 1 and CODEC2 across an ATM network. To this end, said ATM network comprises two ATM service multiplexers la and lb which are connected to die network via respective network modules 4a and 4b which are connected each to an external local administration station 10a and 10b respectively, by a supervisory module 2a and 2b, and which multiplexers comprise a video conference module 5a, 5b, respectively. Thus, information signals coming from data sources Da and Db respectively, from channels Va and Vb or images Ia and lb are multiplexed in a frame in accordance widi Recommendation H221 of the CCITT and transmitted to eidier video conference module 5a, 5b respectively, at a rate equal to n.384 kb/s (where n is an integer between 1 and 5) which rate is liable to change during die communication. Each video conference module is capable of managing a plurality of separate services: this is the case, for example, with module 5a which is also connected to a third codec CODEC3. The interface between the codecs and d e service multiplexers is in accordance with Recommendation G703 (physical adaptation of transmitted data) and G704 (definition of the frame) of the CCITT for the physical layer and widi Recommendation H221 for the higher layers.
The ATM transfer network and die interfaces it has with die service multiplexers are described in said article entided "BREHAT, premier reseau a haut debit realise en technologie ATM".
Fig. 5 is a diagram representing the setting up of objects of a video conference module. Three types of objects are used: - centralized objects which are situated on die supervisory module, - decentralized objects which are situated on d e interface modules (diis is die case diat occurs most, because me software is spread most in me various modules of die equipment so that the management information generated by d e hardware is processed as accurately as possible), - and spread objects which are situated both on d e supervisory module and on die interface modules.
A particular object called centralized "root" object is defined. It is introduced at a predefined memory address and allows of direct access to d e highest level of dependence in the fadier-son hierarchy established between the objects. For each interface module, a spread object called "module" object allows of ensuring the connection between the root object and die odier objects of die module. This "module" object is the first object created during die start.
According to Fig. 5 die "root" object 100 introduced in the supervisory module includes a son object 101: die "module" object which is spread over die supervisory module and over die video conference module. This module object itself includes at least d ree son objects introduced in the video conference module:
- an object 102 (via video conference service managed by die module) representing die physical access in accordance wid Recommendation G703 of die CCITT called "G703 access" object, - an object 103 representing the applicative software of the module so as to be able to identify die module (by its type number, its size ... ) and also to audiorize certain operations with die software (for example, a remote loading, a start, a stop, a deletion .... ),
- an object 104 for similarly representing the start software of the module.
The "G703 access" object includes a son object 105 called "channel G704", which represents the channel to the interface between the service multiplexer and die codec, in accordance widi Recommendation G704 of the CCITT. Similarly, the "channel G704" object includes two son objects:
- an object 106 called "n.384 kb/s transmit connection" which represents the connection from the codec to die service multiplexer, which connection has a bit rate equal to n.384 kb/s. - and an object 107 called "n.384 kb/s receive connection" which represents the connection from the service multiplexer to the codec, which connection has a bit rate equal to n.384 kb/s.
The object called "n.384 kb/s transmit connection" includes a son object 108 called "transmit AAL layer" which represents an asynchronous transfer mode adaptation layer (called AAL layer) in the transmit direction, diat is to say, from the codec to d e service multiplexer. This layer converts any specific service into a stream of undifferentiate cells. And die object called "n.384 kb/s receive connection" includes a son object 109 called "receive AAL layer" which represents this AAL layer in the receive direction, diat is to say from the service multiplexer to the codec.
The object called "transmit AAL layer" has a son object 110 called "virtual transmit channel" which represents the ending of a virtual channel from the module to d e transmit ATM network. And die object called "receive AAL layer" has a son object
111 called "virtual receive channel" which represents the ending of d e virtual channel from the module to me receive ATM network.
Finally, the object called "virtual transmit channel" includes an object
112 called "intermediate transmit point" which is set up in the network module diat handles diis virtual channel and which makes it possible to connect the output of the video conferenc module to die input of die corresponding network module. Similarly, the object called "virtual receive channel" includes an object 113 called "intermediate receive point" set up in the network module diat handles diis virtual channel.
By way of example Fig. 6 symbolically represents one of the objects of video conference module: die object called "G703 access".
This object represents the physical access in accordance wid Recommendation G703 of die CCITT for the video conference service. It is automatically created by its father object, die "module" object, when die module is inserted into the servic multiplexer, and destroyed when it is wid drawn therefrom. The administration can neidier create nor destroy diis object which explains the absence of die "DELETE" operation, but it can consult and/or modify me values of certain of these attributes by the operations "GET" and "SET". The attributes that may be consulted by d e administration are die following:
- an attribute "Id" which contains the aggregate instance number of the object and is used as a reference for the operations on the latter,
- an attribute "Parent" which contains the identifier of die fadier object of the "G703 access" object, diat is to say, of d e "module" object, - an attribute "Classe" which contains the identifier of die class to which the object belongs. It is to be noted d at diese tiiree first attributes are present in all the objects and make it possible to indicate the inter-object relations,
- an attribute "SupportedByObjectList", normalized by the CCITT, which represents die list of objects of which the state can affect the state of the object under consideration. It makes it possible to join physical resources and logical objects,
- an attribute "PlugNumber" which contains the number of the plug of d e module supportin die object to die management bus 8,
- an attribute "OperationalState" which contains the operational state of the resource. This state may be "in service" or "out of service", the "out of service" state being attained when the object or a resource on which it depends is in an alarmed state,
- an attribute "AlarmStatus" which contains the alarm status of the object (most serious current alarm),
- an attribute "CurrentPbList" which contains the list of die current alarms in the object. The attributes diat can be consulted and modified by me administration are the following:
- an attribute " AdministrativeState" which contains the administrative state of die resource. This state may be "open" or "closed",
- an attribute "EmissionSystemTiming" which contains the choice of die transmit clock. In fact, the video conference service being a real-time service, the two ends of a link have to be in synchronism (in sync). Thereto, various choices are possible under die control of die administration: the clock is provided, for example, either by d e coder or die service multiplexer, the latter utilizing then eidier its own local clock or a clock adjusted to die reception of d e ATM network, or a clock coming from an external network dedicated to clock distribution,
- an attribute called "ReceptionSystemTiming" which contains die choice of d e receive clock. As die decoder is adjusted to die service multiplexer, various choices (similar to those mentioned before) remain possible under d e control of d e administration.
The "G703 access" object further includes two internal attributes; the first called "Num.Conduit.G704" contains die aggregate instance number of the "pad G704" object which is situated under d is "G703 access" object; and d e second called "Etat_operationnel" indicates d e operational state (active or inactive) of the object.
The linking of objects that has been chosen in this example consists of making the father object point towards die son object, each son object itself pointing towards die two brodier objects around it and to dieir father object. Two actions "GetFirst" and "GetNext" are thus defined to be able to access various interlinked objects: the action "GetFirst" makes it possible to access the first son object after which the action "GetNext" makes it possible to access subsequent son objects. These two actions make it possible to obtain information about die object "G704 channel" contained in an instance "G703 access". Similarly, two notifications are defined. The first notification called "ObjectCreation" is a notification which follows the creation of die "G703 access" object when die module is inserted. The second notification called "AlarmCommunication" is transmitted in case there is a clock problem and in die case of transmit signal loss. Summarizing, this object structure of die physical access resource G703 of a video conference module makes it possible to manage managing information assigned d ereto, that is to say:
- the defaults of loss of clock and signal loss on transmission,
- the configuration of die transmit clock, of the receive clock and of die administrative state of the resource.
There will now be described an example of me "constructor" function of ie class called "G703 access" which makes it possible to create such a "G703 access" object. This function carries out the following operations:
- Verification of die number of the plug of the video conference module which is associated to die video conference service for which the "G703 access" object is to be created. In diis embodiment each video conference module supports two connections to the video conference services. This number of the plug can thus only assume the value 1 or 2. For any other valu d e constructor function calls an applicative defence task which will be described hereinbelow and which permits to handle d e errors. - Initialization of the values of die attributes "OperationalState", "AlarmStatus", "PlugNumber" , "AdminstrativeState", "EπussionSystemTiming" and "ReceptionSystemTiming" with dieir value defined by default.
- Initialization, as required, of the values of the three attributes "AdministrativeState", "EmissionSystemTiming" and "ReceptionSystemTiming" (which are the only ones that can be modified by die external administration) with the values that have become parameters of the constructor function, after having verified diat, on the one hand, die values of the attributes that have become parameters are valid and, on me other hand, dieir number does not exceed diree. In die opposite case, the constructor calls die applicative defence task.
- Allocation to me object of a temporary storage block by calling a memory allocation task which assigns thereto in exchange a reference number of a free memory block used as a local instance number of the object.
- Initialization of the list of attributes to be returned by die constructor function, each of these attributes being defined by diree magnitudes:
* die type of attribute Id, Parent, Class, SupportedByObjectList, OperationalState, AdministrativeState, AlarmStatus, CurrentProblemList, PlugNumber, EmissionSystemTiming and ReceptionSystemTiming,
* the type of the value of die attribute (an integer of 16 or 32 bits, a Boolean value or a list), * the value of die previously initialized attribute.
- Initialization of the internal attribute containing the aggregate instance number of the son object "G704 path" of die object "G703 access".
- Writing in a memory of the object "G703 access" and calling die applicative defence task die case of failure. - Notification of die creation of die object.
By way of example there will be described a first function called "GET" which makes it possible to realise a "GET" operation with die attributes of an object of the class "G703 access", followed by a second function called "action" which makes it possible to realise either action "GetFirst" or "GetNext" with an object of die same class. The steps of said "GET" function are die following:
- Obtaining the local instance number of the object based upon its aggregate instance numbe
- Recuperation of die address of me beginning of me memory block in which the data of die object are written based upon die local instance number of the object. - Test of die type of attribute to be read which has become a parameter of the function and, if it relates to one of die autiiorized types, initialization based upon die data read from the memory of the return variable which has two fields which indicate die type of value and die value as such, respectively.
- Call of die applicative defence task in the case where die type of the attribute that has become a parameter is not identified.
The steps of said "action" function are die following:
- Test of die origin of the request for action: die request comes either from inside the object, or from the external administration, from the supervisory module or from the video conference module which supports the object. In all odier cases die "action" function calls the applicative defence task.
- Test of the nature of die requested action. If it does not relate eidier to a "GetFirst" action or to a "GetNext" action, die "action" function calls die applicative defence task.
- The local instance number of the object is obtained based upon its aggregate instance number. - The address of die beginning of the memory block in which the data of the object are written is recovered based upon die local instance number of the object.
- Handling the action "GetFirst":
* verify whether die son object whose aggregate instance number is to be returned by d e action is actually an instance of the class "G704 path", and call d e applicativ defence task in the opposite case;
* initialize the variable response which has five fields: die type of the response (here it is about a response to an operation "GET"), the type of the returned variable by the action (here it is about a aggregate instance number of the object), die number of son objects (which is equal to one when the object "G703 access" actually has a son, and to zero in the opposite case), the class of the son object and me aggregate instance number of the son object (which is equal to zero when the object "G703 access" does not have a son).
- Handling die action "GetNext": if the object "G703 access" has only a single son, the action "GetNext" does not affect this object. The "action" function thus calls die applicative defence task.
As the principle of the structure in the form of objects of the telecommunications resources of the various modules has been explained hereinbefore, mere will now be described in detail die processing of these objects by the local management subset 14 of each module.
The architecture of die software of such a subset is shown in Fig. 7. According to Fig. 7 such a subset has two types of tasks: on the one hand, real-time and/or immediate tasks 40 (that is to say, triggered by an interruption) formed by a processing task 26 for processing the time and a reading task 42 for reading die counters, and, on die odier hand, tasks 50 differentiated under die control of a multitask core (for example of the VRTX type).
The tasks 50 include:
- at least a task 32 called configuration task which includes d e functions of configuration, reconfiguration, alarm handling and post counting, to manage the objects of the module which objects represent the telecommunications resources of the module,
- a task 24 for starting the system,
- an applicative defence task 27 of the software,
- a bottom task 28,
- intertask communication means 22, - and a monitoring task 52 cyclically triggered by d e time processing task 26, to read die statuses of the microprocessor unit 16 (more particularly the alarm statuses) and to trigger the necessary actions (reconfigurations, as required) in die case of a default.
The intertask communication means 22 uses at the applicative level the Common Management Information Protocol (CMIP) defmed by the CCITT as a Common Management Information Service Element CMISE. Thus, the service of messaging between the external administration system and me telecommunications equipment is extended to wid in this equipment between the various modules. This makes it possible to avoid any superfluous conversion at the supervisory module which, because of diis, has only the role adapting low layers.
The possible exchanges are eidier a transmission of a message towards a object denoted by a transport address, or a transmission of a message sent to all the objects of all the modules which determine telecommunications resources.
Each of these messages comprises a first header called transport header, a second header called object header and a data field which comprises a list of attributes, actions or events which correspond to a request, to a response to an operation or to a notification. The transport header allows die definition of:
- a transport address of die destination object (diis address is, for example, formed by die number of the plug of die module in which the object is situated followed by die local instance number of the object),
- die transport address of die dispatching object,
- the type of transport message (broadcast or not),
- die lengtii of the data field.
The object header similarly allows the definition of: - die aggregate instance number of the destination object,
- die aggregate instance number of the dispatching object,
- die code of die requested operation (consultation, modification, creation, destruction and action, request or respond mode, notification),
- the use of d e confirmation mode or not, - an identification number of the request,
- me number of attributes to which the request or the notification refers.
Between two tasks located eidier or not on die same module, d e commumcation object proceeds via this message service via a request message after which comes, as required, a return message for die confirmation mode. Therefore, each module has a Communication Object Service SCO as is represented in Fig. 8, which is utilized by each task that uses an object representation to ensure:
- the translation of a message MD1 having an external request for task T into the calling of an internal request function FD1 which corresponds to one of d e audiorized operations to die destination object ObjDest, followed by die translation of an internal response function FRl transmitted via the destination object ObjDest into a transport response message MR1. The request messages MD1 are delivered to a first queue FAD in which the task T is awaiting a message most of the time.
- the translation of an internal request FD2 into an external request message MD2, followed by die waiting in a second queue FAR of an external response message MR2 and, finally, the translation of this external response message MR2 into an internal response function FR2 applied directly to the transmitting object ObjEm.
The communication mechanism between two objects of a like task utilizes directly die internal call functions FD and response functions FR without passing through the messaging.
The task 24 for starting the system transmits an action request message (creation of various objects, configuration or reconfiguration of the hardware and/or software, possibly reinitialization of the alarm attributes) to the configuration task. Then diis message is converted and switched to die object "module" by die communication object service of the configuration task.
The applicative software defence task 27 makes it possible to handle internal irregularities of the software. As this has been indicated during die description of die "constructor", "GET" and "action" functions, error detection points are provided in the software which, in the case of error, calls this defence task of the system, so that it evaluates the probable type of error and activates die process provided dierefore.
Finally, the tasks 40 include d e time processing task 26 which is an immediate task, and d e real-time task 42 for reading die counters (performance and rate making) of the module. These countings are realised of sixteen binary elements at the microprocessor unit 60 and die results are cyclically returned to die management subset 14 in order to have d em accumulated in thirty-two binary elements, and dius for a much longer period of time. These software counters can be consulted by die configuration task 32 which can then update die various attributes of its objects.
Each module further comprises, facultatively, one or various tasks called historical tasks (not represented in Fig. 7), of less priority than the configuration task 32 described above for managing objects called historical objects (various tasks are used when is necessary to assign different priorities to them). These objects are either recorders or recordings, each recorder ensuring the storing for a certain period of time in the form of recordings of events of die same type. Concretely, the recorder object is d en the fadier of a sequence of recording objects of the same type. Thus, various types of recording objects are defmed as, for example, recordings of events of:
- alarm,
- change of attributes,
- change of the state of an object, - creation of an object,
- destruction of an object.
The external administration can selectively access these recordings to read or delete diem.
Any person skilled in the art working in the field of telecommunications and having common knowledge of the C-language is capable of implementing die invention. Obviously, modifications may be made wid respect to die embodiment which has been described, more specifically by substituting equivalent technical means, widiout leaving die scope of die present invention.
More particularly, and aldiough the invention has been described for a service multiplexer for ATM networks, it applies to a wide range of telecommunications equipment.

Claims

CLAIMS:
1. Information transmission system for transmitting information between a source and a receiver via a network, to which network is connected telecommunications equipment (1) comprising a bus (8) dedicated to die exchange of management messages between a plurality of interface modules (3, 4, 5, 6, 7) for various communication services (ATM, CODEC, LAN, X25) and at least a supervisory module (2) used as an interface between said equipment (1) and external administration equipment (10), characterized in that for internally transmitting said management messages said telecommunications equipment (1) comprises communication means based on a similar communication protocol to that used between die external administration equipment (10) and die supervisory module (2).
2. Information transmission system as claimed in Claim 1, in which each of the modules of said telecommunication equipment (1) comprises a plurality of telecommunications resources, characterized in that with respect to dieir management the telecommunications resources of each module are structured as objects which correspond as regards software to an encapsulation of management information generated by said resources and of operations that can be applied to diis information.
3. Transmission system for transmitting information between a source and a receiver via a network which is connected a telecommunication equipment (1) which comprises a bus (8) dedicated to die exchange of management messages between a plurality of interface modules (3, 4, 5, 6, 7) for various communication services (ATM, CODEC, LAN, X25) and at least a supervisory module (2) used as an interface between said equipment (1) and external administration equipment (10), each of these modules comprising a plurality of telecommunications resources, characterized in that the telecommunications resources of each module are structured as regards dieir management in me form of objects which correspond from the point of view of software to an encapsulation of management information generated by said resources and of operations that can be applied to diis information.
4. Information transmission system as claimed in one of me Claims 2 or 3, characterized in that said telecommunications equipment (1) thus comprises for the internal transmission of said management messages communication means based upon die Common Management Information Protocol (CMIP) recommended by d e CCITT while said objects have the following properties which form part of die Common Management Information Service Element (CMISE):
- attributes (ATTRl, ATTR2, ATTR3), - operations with respect to die attributes ("GET", "SET") and to die object itself ("CREATE", "DELETE", "ACTION"),
- and notifications (NOTlF).
5. Information transmission system as claimed in Claim 4, characterized in that each of die objects is: - either an instance of a class defined in die Management Information Base (MIB) recommended by die CCITT,
- or a specific object for internal needs in each module.
6. Information transmission system as claimed in one of die Claims 4 or 5, characterized in diat said communication means further comprise an object communication server (SCO) ensuring the translation of said management messages (MD, MR) into a function request (FD, FR) which realises one of said operations ("GET", "SET", "CREATE", "DELETE", "ACTION").
7. Information transmission system as claimed in one of the Claims 2 to 6, characterized in that each module supports die objects which determine its own telecommunications resources and, to handle said objects, comprises hardware means and logical means (14) and, more specifically, communication means (22) associated diereto, while the number of centralized functions in the supervisory module are minimized.
8. Information transmission system as claimed in Claim 7, characterized in that an aggregate instance number is allocated to each object when created, so as to refer said object at equipment level.
9. Telecommunications equipment (1) comprising a bus (8) dedicated to die exchange of management messages between a plurality of interface modules (3, 4, 5, 6, 7) for various communication services (ATM, CODEC, LAN, X25) and at least a supervisory module (2) used as an interface between said equipment (1) and external administration equipment (10), characterized in that it comprises means which make it possible for the equipment to be used in an information transmission system as claimed in one of d e Claims 1 to 8.
10. Service multiplexer for an ATM network as claimed in Claim 9.
PCT/IB1994/000400 1993-12-08 1994-12-08 Information transmission system and telecommunications equipment intended to be used in such a system Ceased WO1995016318A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP95901560A EP0685131A1 (en) 1993-12-08 1994-12-08 Information transmission system and telecommunications equipment intended to be used in such a system
US08/500,841 US5836008A (en) 1993-12-08 1994-12-08 Communications interface for connection between telecommunications equipment and interface modules
JP7516078A JPH08509342A (en) 1993-12-08 1994-12-08 Information transmission system and communication device used for such device

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR93/14706 1993-12-08
FR9314706 1993-12-08

Publications (1)

Publication Number Publication Date
WO1995016318A1 true WO1995016318A1 (en) 1995-06-15

Family

ID=9453686

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB1994/000400 Ceased WO1995016318A1 (en) 1993-12-08 1994-12-08 Information transmission system and telecommunications equipment intended to be used in such a system

Country Status (4)

Country Link
US (1) US5836008A (en)
EP (1) EP0685131A1 (en)
JP (1) JPH08509342A (en)
WO (1) WO1995016318A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997036268A3 (en) * 1996-03-25 1997-11-27 Michael Coveley Wireless electronic funds transfer/point-of-sale packet assembler-disassembler
EP0798894A3 (en) * 1996-03-29 1998-07-22 Compaq Computer Corporation Management communication bus for networking devices
WO1998033305A1 (en) * 1997-01-28 1998-07-30 Sextant Avionique Method and device for generic routing of messages in different formats and according to different protocols

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19717948C2 (en) * 1997-04-29 2003-07-31 Deutsche Telekom Ag Procedure for the transmission of information
US6700890B1 (en) 1997-12-22 2004-03-02 Cisco Technology, Inc. Method and apparatus for configuring permanent virtual connection (PVC) information stored on network devices in an ATM network logically configured with subnetworks
US6810040B1 (en) 1997-12-22 2004-10-26 Cisco Technology, Inc. Method and apparatus for configuring network devices
JP2000076150A (en) * 1998-08-31 2000-03-14 Fujitsu Ltd System management method and system management device
US20030106042A1 (en) * 2001-12-05 2003-06-05 Steve Lynch System and method for animating state diagram through debug connection
KR100428765B1 (en) * 2001-12-12 2004-04-28 삼성전자주식회사 Management information transmitting system and method in asynchronous transfer mode
FR3096859A1 (en) * 2019-05-28 2020-12-04 Orange A method of managing telecommunications resources dynamically allocated to a plurality of telecommunications operators, a computer program product and corresponding devices.

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991016679A1 (en) * 1990-04-23 1991-10-31 Chipcom, Corp. Multichannel backplane bus system architecture
EP0463764A2 (en) * 1990-06-28 1992-01-02 Digital Equipment Corporation Common agent computer management system and method
EP0529787A2 (en) * 1991-08-29 1993-03-03 Hewlett-Packard Company Network management agent with user created objects
EP0599706A2 (en) * 1992-11-23 1994-06-01 Bull S.A. Information processing apparatus allowing information resource management by a management system

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4903258A (en) * 1987-08-21 1990-02-20 Klaus Kuhlmann Modularly structured digital communications system
US5047923A (en) * 1987-08-21 1991-09-10 Siemens Aktiengesellschaft Modularly structured digital communication system for interconnecting terminal equipment and public networks
US5434863A (en) * 1991-08-30 1995-07-18 Hitachi, Ltd. Internetworking apparatus for connecting plural network systems and communication network system composed of plural network systems mutually connected

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1991016679A1 (en) * 1990-04-23 1991-10-31 Chipcom, Corp. Multichannel backplane bus system architecture
EP0463764A2 (en) * 1990-06-28 1992-01-02 Digital Equipment Corporation Common agent computer management system and method
EP0529787A2 (en) * 1991-08-29 1993-03-03 Hewlett-Packard Company Network management agent with user created objects
EP0599706A2 (en) * 1992-11-23 1994-06-01 Bull S.A. Information processing apparatus allowing information resource management by a management system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AT & Technical Journal, Volume 67, No. 4, July 1988, (New York, US), J. COPLIEN et al., "C++: Evolving Toward a More Powerfull Language", page 27, line 1 - page 32, line 9. *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1997036268A3 (en) * 1996-03-25 1997-11-27 Michael Coveley Wireless electronic funds transfer/point-of-sale packet assembler-disassembler
EP0798894A3 (en) * 1996-03-29 1998-07-22 Compaq Computer Corporation Management communication bus for networking devices
US6199133B1 (en) 1996-03-29 2001-03-06 Compaq Computer Corporation Management communication bus for networking devices
WO1998033305A1 (en) * 1997-01-28 1998-07-30 Sextant Avionique Method and device for generic routing of messages in different formats and according to different protocols
FR2758925A1 (en) * 1997-01-28 1998-07-31 Sextant Avionique METHOD AND DEVICE FOR GENERALLY ROUTING MESSAGES TRANSMITTED IN FORMATS AND ACCORDING TO DIFFERENT PROTOCOLS

Also Published As

Publication number Publication date
JPH08509342A (en) 1996-10-01
US5836008A (en) 1998-11-10
EP0685131A1 (en) 1995-12-06

Similar Documents

Publication Publication Date Title
US4720850A (en) Communication system control arrangement
US4713806A (en) Communication system control arrangement
US4930123A (en) Method for controlling address parameters for interconnecting lan and ISDN
US6209039B1 (en) Method and apparatus for providing an interface between a plurality of frame relay networks
US7733789B1 (en) Remote monitoring of switch network
US6223219B1 (en) Trail management across transport functionality of large and complex telecommunications networks
US6018625A (en) Management system architecture and design method to support reuse
US6070188A (en) Telecommunications network management system
US5949759A (en) Fault correlation system and method in packet switching networks
JPH10501909A (en) Network elements in telecommunications networks
GB2332335A (en) Network management system
US5836008A (en) Communications interface for connection between telecommunications equipment and interface modules
US6944657B1 (en) Automatic network synchronization of the network configuration with the management information database
Imai et al. ATMR: ring architecture for broadband networks
EP0923269B1 (en) Capability modeling using templates in network management system
CA2331899C (en) Method and communications system for processing state information in a management network having a number of management levels
WO1995020297A1 (en) An element manager for a communications network
CA2254607C (en) State machine for trail management system
EP0968587B1 (en) Telecommunications switching system with readily configurable supervisor control
US6836802B1 (en) Network management system uses proxy agent for communicating control information and event notifications between network management apparatus and agents not directly connected to a network
Seshake et al. Data communication platform in distributed operations system based on TMN
JP2586573B2 (en) Line switching device
KR950001512B1 (en) Network management system and communication method in the communication process
Pokam et al. Integrate multimedia in manufacturing networks using ATM
US6256316B1 (en) Communication method in centralized supervisory system

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): JP RU US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1995901560

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 08500841

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1995901560

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1995901560

Country of ref document: EP