WO1992015161A1 - Methode et appareil de regulation de la communication de messages intermodule - Google Patents

Methode et appareil de regulation de la communication de messages intermodule Download PDF

Info

Publication number
WO1992015161A1
WO1992015161A1 PCT/US1992/001586 US9201586W WO9215161A1 WO 1992015161 A1 WO1992015161 A1 WO 1992015161A1 US 9201586 W US9201586 W US 9201586W WO 9215161 A1 WO9215161 A1 WO 9215161A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
messages
module
interface unit
alarm
Prior art date
Application number
PCT/US1992/001586
Other languages
English (en)
Inventor
Herbert L. Steierman
Garland David Turner
Tam Thu Tran
Larry Chung-Ying Chiang
Dinesh C. Khurana
Original Assignee
Raynet Corporation
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 Raynet Corporation filed Critical Raynet Corporation
Publication of WO1992015161A1 publication Critical patent/WO1992015161A1/fr

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
    • H04L41/06Management of faults, events, alarms or notifications
    • 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
    • H04L41/24Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using dedicated network management hardware
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks

Definitions

  • the present invention relates to communications systems, which include interface units receiving messages from a communications network, and to apparatus and methods for controlling communication of such messages within the interface unit, the invention being particularly useful when the messages are related to an event where status changes l o rapidly over time, as often occurs for events which generate alarms.
  • embedded intelligence such as 15 a computer to control the operations of its parts. It is further common that the parts making up this telecommunications system also use embedded intelligence to take commands from a centralized point such as a central processing unit (CPU) module, and to alert this centralized point of important events.
  • CPU central processing unit
  • each module has its own processing unit so that it can receive instructions from the CPU and can report events to the CPU.
  • a means of communication is provided between the modules or cards through an inter-module communication bus.
  • the procedure to communicate among modules can be one of many protocols. 5
  • SUBSTITUTE SHEET include signal coding error detection, out-of-frame detection, loss-of-signal detection, and/or message oriented signals from the central office terminal (COT) system such as major alarm, minor alarm, shelf alarms, loop back alarms, maintenance alarms, and protection switch alarms. 5
  • COT central office terminal
  • Tl lines are embodied into a single interface system, a feature which increases the likelihood of a flood of events to be reported to the CPU.
  • contention among the CPU and the modules l o for the communications path can further aggravate the times when floods of events need to be conveyed to the CPU.
  • the nature of Tl lines is that although alarm events are rare, when they occur, many events may occur simultaneously often over several Tl lines.
  • Stale information may accumulate in a receiving module. Stale information may be message data that is old or out-dated and should be deleted or it may be message data that would be more meaningful if combined with newly acquired information.
  • the conventional solution for a telecommunications system can comprise hardware and software components as illustrated in Fig. 1. These components include: External events 1 such as Tl performance events delivered by hardware to the software control block 2 for performance monitoring.
  • This block 2 comprises software algorithms used to pass only significant events in the form of messages to a first-in-first-out queue FIFO-Q 4 0 through path 3.
  • the inter-module communication block 5 periodically queries the FIFO-Q 4 through path 6 of messages in the FIFO-Q and when messages are present, it extracts them so as to send them to the CPU via path 7. It is likely that additional information, in the form of other messages 8, needs to be conveyed to the CPU and is also placed in the FIFO-Q via path 9.
  • the FIFO-Q can fill at a rate faster than the messages can be delivered to the CPU. Because of this, it is likely that some of the messages in the FIFO-Q will become stale as more current information is fed into it.
  • a typical Tl situation is the detection of an out-of-frame condition and then a short time thereafter the detection of excessive line coding errors and then a short time thereafter the detection of loss of signal, each event generating a message for the CPU. Under normal circumstances, each of these events would be delivered to the CPU via the inter-module communications bus because the capacity of the communications bus had not been exceeded.
  • the present invention provides an improved method and apparatus for controlling delivery of messages to a central processing module to make sure that only relevant messages are delivered to the central processing module.
  • information that is stale may be deleted or it may be combined with other information related to the messages being received by the interface unit.
  • inter-module communication is reduced, and the CPU makes decisions based on only relevant messages.
  • the invention can be characterized as a method for communicating relevant messages from a second module in an interface station of a data communications system to a first module within the interface module.
  • the method includes the steps of:
  • SUBSTITUTE SHEET 1 storing information concerning messages in a store in the second module
  • a step of building a message packet according to one aspect of the present invention 15 includes:
  • the present invention can be characterized as a communication interface unit for interfacing between a long range communications network, including high capacity lines, such as Tl lines, and a local communications network, such as a fiber optic loop including subscriber interfaces.
  • the interface unit 0 includes a first processing module under program control providing interface unit control and processing alarm messages.
  • a second processing module on the interface unit receives the alarm messages from the high capacity communications lines and includes a first store for storing alarm-type indicators for received alarm messages in a first-in-first-out queue, and a second store for storing information concerning received alarm messages.
  • a relevant 5 message handling unit includes means for determining an alarm message type from the first-in-first-out queue and for building a message packet in response to the alarm message type and the information concerning received alarm messages in the second store.
  • the second module further includes an inter-module communications port through which the
  • SUBSTITUTE SHEET package is delivered to the first module when inter-module communications resources are available.
  • the unit for building message packets includes, according to one aspect of the 5 invention, a processing unit for performing a plurality of relevancy tests for determining whether relevant information exists in the second store for respective message alarm types and a unit for selecting a relevancy test from the plurality of relevancy tests in response to the determined alarm message type retrieved from the first-in-first-out queue.
  • the selected relevancy test is then executed and an appropriate message packet is composed if relevant l o information exists. If no relevant information exists, then no message packet is composed.
  • the relevant messages so identified are erased from the second 15 store.
  • the invention is most advantageous for messages whose status dynamically changes rapidly with time and at least one such status is superseded by a later status, such as occurs when an out-of-frame condition of a telephone transmission system arises.
  • equal weight is not always given to all communication. It is this feature which allows stale information to be deleted or combined with other information when needed. By providing this feature, inter-module communication is reduced and CPU decisions based on relevant information are improved.
  • the system operates in much the same way as an expert system might operate. That is, 5 special rules are executed based upon what is cm ⁇ ently known about the system so as to better handle a complex situation.
  • Fig. 1 is a block diagram of a prior art alarm message handling module in a communications interface unit. 5
  • Fig. 2 is a block diagram of a communications interface unit for a fiber optic loop carrier, in which a preferred embodiment of the present invention is implemented.
  • SUBSTITUTE SHEET Fig.3 is a block diagram of the alarm message handling unit according to the present invention.
  • Fig.4 is a flow chart illustrating the relevant message handling routine according to the present invention.
  • Fig.5 is a diagram of computer software architecture for implementation of a preferred embodiment of the present invention.
  • the present invention is particularly suitable for use in interface units in high capacity tele ⁇ mmunications networks, such as the North American Tl, T2, or T3 lines in the public telephone network, and providing an interface to individual telephone subscribers using fiber optic loops.
  • high capacity tele ⁇ mmunications networks such as the North American Tl, T2, or T3 lines in the public telephone network, and providing an interface to individual telephone subscribers using fiber optic loops.
  • FIG.2 A block diagram of one such system which may be used for communicating with North American Tl lines over the public telephone network to individual telephone subscribers using fiber optics is illustrated in Fig.2. Although this system is representative of the use of the invention claimed herein, other communications system architectures may also apply.
  • the public network central office terminal (COT) 10 provides high capacity telephone service (via North American Tl lines 11 ) to loop optical carrier equipment 12 which, in turn, provides individual telephone service to subscribers 13.
  • the hardware equipment making up the loop optical carrier (LOC) equipment 12 is likely to comprise several special purpose modules so as to satisfy system needs and is often divided into common and subscriber equipment
  • the modules in a preferred system comprise: (A) a central office feeder interface unit (OFT) 14 to meet the interface needs of the Tl lines (e.g. second module), the OFT performing some alarm functions, (B) a feeder distribution interface (FDI) 15 to cross connect high capacity telephone circuits to individual subscriber circuits, the FDI performing some alarm functions, (C) a distribution fiber module (DFM) 16 to convert electrical subscriber signals into optical signals, (D) a local loop transmission facility of fiber optic cable 17, (E) a subscriber interface unit (SIU) 18 to convert optical subscriber signals into electrical signals, (F) subscriber telephones 13, (G) a timing generator module
  • SUBS ⁇ E (TGM) 19 to synchronize the signals within the LOC equipment 12 to that of the COT 10, and (H) a central processing unit (CPU) 20 (e.g. first module) to control system setup and to report system anomalies. It is further likely that multiple modules of common equipment may be used to increase system capacity or to improve system reliability. According to 5 another preferred embodiment, all alarm functions can be performed at a single location, e.g. at the OFT, rather than divided between the OFT and the FDI.
  • FIG. 3 A block diagram of the primary components of the message handler is illustrated in Fig. 3, while a detailed flow diagram of the improvement is illustrated in Fig. 4.
  • External l o events 30 such as Tl performance events are delivered by hardware to the software control block 31 for performance monitoring.
  • FIFO-Q 32 Rather than place an entire message into a first-in- first-out queue, FIFO-Q 32, only the message type is entered and the remaining data making up the message is placed in a local software data base 33.
  • This data base 33 contains a set of indicators describing what is relevant about the messages placed in the
  • a relevant message handler 34 communicates with an inter-module communication block 35, the FIFO-Q 32 and the data base 33 so as to convey only relevant information to the CPU via the inter-module communication bus 36.
  • additional information in the form of other messages 37 is placed in the FIFO-Q 32. 0
  • Trie information in the FIFO-Q is placed there so as to communicate important events to the CPU.
  • Two paths are provided.
  • the path 38 is provided to allow a large class of information to be conveyed to the CPU which does n exhibit features of going stale.
  • the entire message is placed in the FIFO-Q.
  • the path 5 39 from performance monitoring allows information to be conveyed to the CPU which may become stale by virtue of more current information.
  • the relevant message handler uses these blocks to ultimately construct a message for delivery to the CPU via inter-module 0 communication 35.
  • Fig. 4 The operation of the relevant message handler 34 is illustrated by the flow diagram of Fig. 4.
  • This handler 34 is queried periodically by the inter-module Communication Module 35.
  • handler 34 looks into the FIFO-Q for any messages (block 5 51 ). If any are present, then a message type indicator is retrieved in order from the FIFO-Q (block 52).
  • Retrieved message types can be of one of at least two categories, as determined in block 53. The first category is for completely composed messages (which are always relevant), while the second category is for messages whose relevancy may change with
  • each message has a type to identify it, a feature used by the multi-way decision to route control.
  • a typical Tl situation is the detection of an out-of-frame 0 condition and then a short time thereafter the detection of excessive line coding errors and then a short time thereafter the detection of loss of signal.
  • This scenario is used to illustrate the value added by the improved method.
  • Each of these three events generates an entry (as a subsequent message) in the FIFO-Q. If these messages are slow to be delivered to the CPU because of high inter-module communication, then the relevant message handler 5 would group each of these similar events into a single message after the first event is queried from the FIFO-Q. The CPU would then be able to make reliable decisions based on the current system state.
  • the second event would be queried some time after the first message was sent to the CPU. To this, the relevant message handler would determine that no new 0 information needs to be conveyed to the CPU and thus disposes of the message. The third message would be handled in a similar manner.
  • Fig. 5 is a block diagram illustrating a preferred ordering of preferred routines.
  • the software operating system receives inputs from handle Tl events 5 modules 105, and in response to those inputs the software operating system detects messages in the FIFO-Q (block 100). Next, the message in the FIFO-Q must be handled. To do this, an inter-module communication block retrieves the message from the FIFO Q and calls get next rel msg() to determine the relevancy (block 101). Relevancy is then checked and handled in the get next rel msg() routine (block 102). This routine passes control to the routine process next rel msg() if relevancy applies.
  • the process next rel msg() routine is executed (block 103). This routine checks the data base for current relevancy of the message and fills in a message if relevant information exists. Finally, the f ⁇ ll_dsl_.alarm_event() routine (block 104) is called to fill in a message body or message packet for transmission to the CPU module. Control is then returned to the inter-modules communications block 101 to send the message to the CPU module and finally control is returned to the software operating system.
  • the first module 100 of the software architecture is the software operating system in general.
  • the module 105 includes:
  • handle_dsl.alarm_event() handle_dsl_felp_event() handle.dsl.maint.eventO handle.dsl_switch_event()
  • the appropriate performance monitoring routine When an event needs to be conveyed to the CPU, the appropriate performance monitoring routine first saves the pertinent data in the local data base and then calls one of these routines. In this implementation, the information passed to one of these routines is done via a message conveying which of the eight digroups (of DSl lines) has new data to be sent to the CPU.
  • a header of the message is built conveying the type of message this is. This action serves two purposes. First it will convey to the relevant message handler how to
  • SUBSTITUTE SHEET complete the message and second it reduces the time which might be spent in the relevant message handler by composing all static information into the ultimate message (i.e., the message header comprising message source, destination, message command type, etc.).
  • the pointer to the message buffer is placed in the queue so that delivery can be made to the CPU.
  • Pointers are placed in the queues rather than entire messages since this provides a more efficient means for routing messages within the same software platform.
  • the message buffers are known to always fall on 128 byte boundaries. This information is taken advantage of so as to flag i o the message which goes into the queue as either conventional or relevant.
  • a macro forces the least significant bit of the message pointer to 1, a detectable violation in the buffer boundary location, which identifies that this message requires relevant handling.
  • the third module 102 of the software architecture includes:
  • This short assembly routine is called from the inter-module communication block whenever this block finds information in the FLFO_Q.
  • the routine is a filter in the true 0 sense. That is, a pointer to a message is passed to it and a pointer to a message is returned. In between, the message may be operated on.
  • This routine takes advantage of the procedure used in the first module routine above to determine if the message is conventional or relevant If it is conventional, then the pointer to the message is retumed unaltered. If it is relevant by virtue that the pointer to the message is not on a 128 byte 5 boundary, men the message is operated on by the routine process_.nextrel_.msg().
  • This routine will return either a pointer to a message (on a valid 128 byte boundary) or it will return a NULL pointer indicating that no message need be sent to the CPU.
  • the condition indicated by the NULL pointer is handled by the routine which originally called get_next_rel_msg(), that is the inter-module communications block. 0
  • the fourth module 103 of the software architecture includes:
  • This routine is the relevant message handler. It is called because a message requires relevant handling. That is, in this application the appropriate message body needs to be filled in with current information so that it can be sent to the CPU. This routine handles the case when stale information is found whereby either another message from the FlFO Q is
  • a continuous loop is entered which is terminated when a message is completely composed for delivery to the CPU or when stale information is found for the message and no other messages need to be sent to the CPU.
  • the message type (or command) is extracted from the message and is used to switch to all possible relevant message types.
  • each of the cases for relevant message types is handled in a similar manner. That is, the routine fill_dsl_alarm_events() is called so as to fill in the body of the message with relevant information.
  • This routine returns the disposition of its action, that is it returns S AVE_PKT when a message is composed and returns DISPOSE.PKT when only stale information is available and thus no message is composed.
  • the other common operation for each case is that the events (indicating which digroups have information for the CPU) in the local base is cleared. The switch command is then exited.
  • the pointer to the (now determined) stale message is disposed of so as to allow the buffer to be reused.
  • SUBSTITUTE SHEET (8) The same actions occur during this and potential other passes as was done before. However, this time, the default case from the switch can be entered. This case provides for the situation when a dequeued message from the previous step (7) contains a completely composed message not subject to relevancy requirements. Thus a break out ' from this routine occurs, allowing the message to be sent to the CPU.
  • the last module 104 of the software architecture includes:
  • This routine fills in the body of a relevant message with current information from the local data base.
  • Two parameters are passed, one being the pointer to the buffer where the information is to be placed that also contains its static "header" information.
  • the other being a bit mask of up to eight relevant events corresponding to the eight digroups. The operation is as follows:
  • the command for the message type to be filled is queried from the partially composed buffer so as to switch to one of the relevant event types.
  • This switch sets up some local variables describing where the data for the message is in the local data base and how large that data is. If the command is not part of the set of relevant messages, then the routine is exited with DISPOSE.PKT as the return value so as to inform the calling party that no message need be sent. This latter condition is an error path that should normally not be reached but is included to ensure sanity of the program.
  • a loop is entered and is executed as many times as necessary to fill the body of the message for all digroups which have relevant information for the CPU.
  • a preferred technique applied in this application takes advantage of bit manipulation features of the C programming language. That is, for each pass through the "while" loop, the least significant bit of the events is tested. A positive test indicates that relevant data for this digroup (from the data base) is transferred to the message body, while a negative test transfers nothing to the message body. In either case, the pointer used to locate the relevant data in the local data base is incremented to correspond to the data for the next digroup.
  • the event flags are shifted down by one bit so as to place the bit 5 corresponding to the next digroup in the pertinent least significant bit position and also to dispose of the bit corresponding to the just serviced digroup. This technique of shifting the event flags reduces the average time in the "while” loop since once all relevant events have been operated on, the "while" loop will terminate.
  • the software presented with reference to Fig. 5 is a representative approach for 15 implementing the present invention. These functions can also be implemented in hardware, or a combination of hardware with software as suits the needs of a particular design.
  • the relevant message handler provides more timely information to the CPU, reduces inter-module communication traffic, removes stale information before the 20 CPU has the opportunity to act on it combines similar information into a more relevant message, reduces CPU load, and simplifies the decision process at the CPU.

Landscapes

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

Abstract

Jonction entre un réseau de communication longue distance, comportant des lignes haute capacité, telles que les lignes de l'industrie des télécommunications, et un réseau de communications locales, tel qu'un circuit à fibre optique comportant des jonctions d'abonnés, comprenant un module d'UC de traitement des messages d'alarme. Un second module de traitement sur l'unité de jonction reçoit les messages d'alarme des lignes de communication de haute capacité et inclut des indicateurs d'enregistrement en file d'attente de type FIFO (premier entré, premier sorti) aux messages d'alarme reçus, et une deuxième mémoire enregistre les informations concernant les messages d'alarme reçus. Un paquet de messages est élaboré en fonction du type de message d'alarme et de l'information concernant les messages d'alarme reçus dans la seconde mémoire. Le paquet est ensuite transmis au module d'UC lorsque les moyens de communication intermodule sont disponibles. Les paquets de messages sont élaborés après l'accomplissement d'un test de pertinence sélectionné parmi une multiplicité de tels tests, afin de déterminer s'il existe dans la seconde mémoire des informations pertinentes pour les types de messages d'alarme correspondants. Un paquet de messages adéquat est composé si les informations pertinentes existent. A défaut, il n'est pas constitué de paquet de messages.
PCT/US1992/001586 1991-02-26 1992-02-26 Methode et appareil de regulation de la communication de messages intermodule WO1992015161A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US66157491A 1991-02-26 1991-02-26
US661,574 1991-02-26

Publications (1)

Publication Number Publication Date
WO1992015161A1 true WO1992015161A1 (fr) 1992-09-03

Family

ID=24654173

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1992/001586 WO1992015161A1 (fr) 1991-02-26 1992-02-26 Methode et appareil de regulation de la communication de messages intermodule

Country Status (2)

Country Link
AU (1) AU1455892A (fr)
WO (1) WO1992015161A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0295426A2 (fr) * 1987-06-15 1988-12-21 International Business Machines Corporation Procédé et dispositif pour produire des messages d'alertes dans un réseau de communication
EP0336585A2 (fr) * 1988-04-08 1989-10-11 International Business Machines Corporation Génération d'affichage de message d'erreur

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0295426A2 (fr) * 1987-06-15 1988-12-21 International Business Machines Corporation Procédé et dispositif pour produire des messages d'alertes dans un réseau de communication
EP0336585A2 (fr) * 1988-04-08 1989-10-11 International Business Machines Corporation Génération d'affichage de message d'erreur

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATION. vol. 6, no. 5, June 1988, NEW YORK US pages 784 - 787; L.BERNSTEIN ET AL: 'EXPERT SYSTEMS IN NETWORK MANAGEMENT - THE SECOND REVOLUTION' *

Also Published As

Publication number Publication date
AU1455892A (en) 1992-09-15

Similar Documents

Publication Publication Date Title
US6411599B1 (en) Fault tolerant switching architecture
US5838915A (en) System for buffering data in the network having a linked list for each of said plurality of queues
US6519226B1 (en) Packet network interface
US7352695B2 (en) Switch and a switching method
US4942569A (en) Congestion control method for packet switching apparatus
US5042027A (en) Communication network system and method of controlling a communication network
US4421955A (en) Distributed switching system
EP0792075A2 (fr) Dispositif pour la modification d'un message applicable au réseau de signalisation de télécommunication
US5729530A (en) ATM switch
EP0683949B1 (fr) Procede de traitement de plans de commutation de redondance dans des commutateurs de paquets et commutateur permettant d'appliquer ce procede
US5084863A (en) System for interchanging messages in real time between stations interconnected by a loop link, in particular between stations in a telecommunications exchange
US6580688B1 (en) Switching transmission units to an equivalent circuit for the purposes of bidirectional asynchronous cell transfer
CN100466591C (zh) 主从设备系统
US6058120A (en) System and apparatus for controlling telecommunications components
US7061870B2 (en) Method and system of transmitting loopback cells through a switching node of an asynchronous transfer mode (ATM) network
WO1992015161A1 (fr) Methode et appareil de regulation de la communication de messages intermodule
US5822298A (en) Ring transmission system for providing efficient transmission of management data
US6456623B1 (en) Line switching method and asynchronous transfer mode (ATM) system using the same
US6982958B2 (en) Method for transmitting loopback cells through a switching node of an asynchronous transfer mode (ATM) network
US6839354B1 (en) Scheduling circuit and scheduling method for dealing with service classes with differing priorities
JPH08331137A (ja) Smds交換装置
US6732169B1 (en) Network transmission circuit control method and system
KR100483546B1 (ko) 에이티엠 입력 셀 복제에 의한 멀티캐스트 스위칭 장치 및방법
JP2522233B2 (ja) 入力トラヒック制御方法
JP3090308B2 (ja) Atm交換機

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU CA JP KR

AL Designated countries for regional patents

Kind code of ref document: A1

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

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
NENP Non-entry into the national phase

Ref country code: CA