Synchronization and information exchange between communication components using a network management operations and control paradigm

Information

  • Patent Grant
  • 6170005
  • Patent Number
    6,170,005
  • Date Filed
    Friday, June 12, 1998
    26 years ago
  • Date Issued
    Tuesday, January 2, 2001
    23 years ago
Abstract
A system for providing synchronization and information exchange in a network such as a digital television broadcast network using a network management operations and control paradigm. A management entity component, such as a computer workstation operated at a control center, coordinates the actions of different agent components, such as hardware used at the headend or uplink site of a television network. The agent components are used to provide conditional access to a television signal by inserting conditional access data into the transmitted programming. Management information bases (MIBs) are provided for the agent components and the management component. The agent components update their MIBs with information of the communication network, such as changes in a television event schedule. The management component periodically reads the agents' MIBs to obtain the updated information and store it in its own MIB. The management component provides information to the agents' MIBs according to the updated information obtained from the agents to synchronize the insertion of data into the digital broadcast data stream by the agents.
Description




BACKGROUND OF THE INVENTION




The present invention relates to a method and apparatus for providing synchronization and information exchange in a network. The invention is particularly suitable for use with satellite uplink or headend components in a conditional access television communication network.




The following acronyms are used in this application:





















SNMP




Simple network management protocol







CA




Conditional Access







CCITT




International Telegraph And Telephone








Consultative Committee (Translation)







CMIP




Common Management Information Protocol







CORBA




Common Object Request Broker Architecture







C(P)SI




Custom and/or Program Specific Information







CPSIM




Custom Program Specific Information Manager







CSI




Custom Service Information







CWG




Control Word Generator







DVB




Digital Video Broadcast







ECMG




Entitlement Control Message Generator







EFD




Event Forwarding Discriminator







EIS




Event Information Scheduler







EIT




Event Information Table







EMM




Entitlement Management Message







IIOP




Internet Inter ORB Protocol (a CORBA








protocol)







IP




Internet Protocol







ITU




International Telecommunications Union







LAN




Local Area Network







MIB




Management Information Base







NIT




Network Information Table







OO




Object Oriented







ORB




Object Request Broker







OSI




Open Systems Interconnection







PAT




Program Association Table







PDG




Private Data Generator







PMT




Program Map Table







PSI




Program Specific Information







PSIG




PSI Generator







RMI




Remote Method Invocation







RST




Running Status Table







SDT




Service Description Table







SI




Service Information







SMI




Structure of Management Information







SNMP




Simple Network Management Protocol







TCP




Transaction Control Protocol







TDT




Time Date Table







TLI




Transport Layer Interface







TMN




Telecommunications Management Network







TP




Transport Protocol







UDP




User Datagram Protocol







WAN




Wide Area Network















The synchronization and information exchange between headend and uplink components in broadband multimedia distribution networks is conventionally realized through a variety of custom communications protocols. Examples include protocols between generators of Entitlement Management Messages (EMMs) for Conditional Access (CA) Systems and other uplink/headend equipment which multiplexes those messages into the transport streams. Other examples include headends/uplinks with multiple Conditional Access Systems.




However, there is a need to enable information flow and synchronization between components within CA Systems and the headend/uplink. An example is the protocol between CA MPEG Program Specific Information (PSI) components (these are typically named Custom PSI-CPSI) and headend PSI components. For example, a headend of a cable television (CATV) network may receive video data from different programming services, e.g., ABC, CBS, CNN, HBO, NBC and the like, where the PSI components are specific to each programming service. Another example is the protocols between CA DVB Service Information (SI) components and headend SI components. These interfaces are typically referred to as Custom SI-CSI-SI interfaces.




Custom communications protocols using any of the standard data transport protocols such as OSI TP 0-4 or the standard Internet UDP or TCP protocols and Socket or TLI abstractions are rather complex. They take a long time to implement and integrate into systems (e.g., one to two years) and remain proprietary and therefore are difficult to maintain and upgrade.




The present invention avoids the need to define and implement new communications protocols through a combination of techniques from the so-called “network management” operations and control paradigm. In particular, already implemented management protocols are used, such as the Internet Simple Network Management protocol (SNMP), in combination with ITU-T X.700 event reporting and logging functions to solve problems with component synchronization and information exchange. More particularly, X.731 (state management), X.733 (alarm management), X.734 (event management), and X.735 (log management) are used within the non ITU-T framework to synchronize and exchange information between headend/uplink components or between headend/uplink and CA System components.




This approach advantageously combines the benefits of the sophisticated X.700 techniques with the simplicity of management frameworks such as SNMP while avoiding the high implementation cost of X.700 and the limited functionality of SNMP style frameworks.




SUMMARY OF THE INVENTION




The present invention relates to a method and apparatus for providing synchronization and information exchange in a network. The method allows a management entity component, such as a computer workstation operated at a control center, to coordinate the actions of different agent components, such as hardware used at the headend or uplink site of a television network. In particular, the agent components may be hardware (e.g., including firmware and software) used to provide conditional access to a television signal.




The invention is particularly suited for use in a broadband communication network, such as a CATV network or satellite broadcast network, that provides a digital broadcast data stream to a decoder population.




This hardware provides various forms of data that controls an end user's ability to access the television or other data. For example, with a tiered marketing scheme, only users who pay an additional fee can access specific premium programs. To implement such a scheme, it is necessary to provide conditional access data such as private data, entitlement management messages, program-specific information, and entitlement control messages with the transmitted programming.




While the use of such conditional access data is known, the present invention provides a system for managing and coordinating the insertion of the conditional access data into the transmitted programming stream using a network management operations and control paradigm.




A method for providing communication between first and second headend, uplink and/or conditional access agent components (e.g., agents) and a management component (e.g., manager) thereof in a communication network includes the step of providing respective management information bases (MIBs) for the first and second agent components and the management component. The MIB includes managed objects that represent managed resources. The first and second agent components update the respective MIBs with information of the communication network. For example, an agent may receive information regarding a new television program that requires conditional access data, in which case the agent makes a data entry in its MIB that corresponds to the new program.




The management component periodically reads the MIBs of the first and second agent components to obtain the updated information therefrom, and store the updated information in its respective MIB. Furthermore, the management component provides information to the MIBs of the first and second agent components to synchronize an insertion of data into a digital broadcast data stream by the first and second agent components. For example, a component may create and insert Conditional Access Systems specific information into an MPEG transport stream. Essentially, the management component and the first and second agent components are synchronized with one another.




The first agent component may advertise event schedule information of the communication network by making the event schedule information available to the management component and the second agent component via the first agent component's respective MIB.




The method may include the further step of transmitting event reporting information from the management component to at least the first agent component to allow the first agent component to implement an event reporting procedure. The event reporting information defines pre-conditions for the first agent component to declare an event. The pre-conditions may relate to a value or state change of a parameter that is monitored by the agent. For example, a pre-condition for generating an event may be that a MIB variable has crossed a specified threshold, or a state of the agent has been changed.




The agent has the ability to asynchronously notify the management component of an event when the pre-conditions have been met.




When a plurality of management components are provided in the communication network, the method may include the further step of transmitting information from at least a particular one of the management components to the first and second agent components to register the particular management component as a recipient of the asynchronous event notifications thereof. That is, the managers instruct the agents to send event notifications to them.




The method may include the further step of transmitting event logging information from the management component to at least the first agent component to allow the first agent component to implement an event logging procedure according to the event reporting procedure. The event logging information defines pre-conditions for the first agent component to log an event. For example, some events may be generated but not logged, e.g., recorded, if they are not sufficiently important. Or, a particular event may not be logged unless it occurs a number of times.




The method may include the further step of transmitting event forwarding discriminator information from the management component to at least the first agent component to allow the first agent component to implement an event forwarding discriminator procedure according to the event reporting procedure. The event forwarding discriminator information defines pre-conditions for the first agent to forward an event to the component to the management component. The manager is not necessarily notified of all events that are generated at the agent. The EFD pre-conditions thus define which events should be communicated to the manager by filtering all generated events.




At least one of the first and second agent components may be a conditional access agent component for inserting conditional access data, such as EMMs and ECMs, into the digital broadcast stream. Furthermore, the management component may provide the conditional access information to the MIB of the conditional access agent component.




A corresponding apparatus is also presented.




An apparatus is also present for providing communication between first and second headend, uplink and/or conditional access agent components and a management component thereof in a communication network. The apparatus includes at least one memory associated with the first and second agent components providing respective management information bases (MIBs) thereof. That is, the agents may have their own memories, or share a common memory. A memory associated with the management component provides a MIB thereof.




Transceivers and processors are also associated with the first and second agent components, and with the management component. The agents' processor(s) are responsive to their transceiver(s) for updating their MIBs with information of the communication network. The manager's transceiver is responsive its processor for periodically (e.g., intermittently) transmitting control signals to the agent's processor(s). The agents' transceiver is responsive to their processor(s) and the control signals from the manager for transmitting the updated information from their MIBs to the manager's transceiver for storage at the manager's MIB.




The manager's transceiver is responsive to its processor for periodically transmitting information to the agents' processor(s) for storage at the agents' MIBs to synchronize insertion of data into the digital broadcast data stream by the first and second agent components.




Generally, the manager has its own memory and processor, but it is possible for the manager and agents to share common hardware, e.g., when they are co-located.











BRIEF DESCRIPTION OF THE DRAWINGS





FIG. 1

illustrates a network with management entity components and agent components in accordance with the present invention.





FIG. 2

illustrates a broadcast headend with conditional access components as agents, and a network management system as a management entity component, in accordance with the present invention.





FIG. 3

illustrates an agent component and a management entity component in accordance with the present invention.











DETAILED DESCRIPTION OF THE INVENTION




The present invention relates to a method and apparatus for providing synchronization and information exchange in a network using a network management operations and control paradigm.





FIG. 1

illustrates a network with management entity components and agent components in accordance with the present invention. The network, shown generally at


100


, includes one or more management entity components (e.g., managers), such as management entity components


120


and


140


, and one or more agent components (e.g., agents), such as agent components


110


and


130


. The management entity components


120


and


140


may be headend, satellite uplink, or conditional access system management entities that act in a manager's role. The management entity components


120


and


140


may also act in an agent's role with respect to another manager.




The agent components


110


and


130


may be headend, satellite uplink, or conditional access system agent entities that act in an agent's role.




Each component includes a management information base (MIB). Specifically, MIBs


115


,


125


,


135


and


145


are associated with components


110


,


120


,


130


and


140


, respectively. A MIB identifies the network elements (e.g., managed objects) that are to be managed, and contains a name that is associated with each managed object. Network management protocols use the MIB to define the managed objects in the network. The MIB defines the contents of the information carried with the network management protocols, as well as information describing each network management user's ability to access elements of the MIB, e.g., read or write access.




Note that while

FIG. 1

illustrates two agent components and two management entity components, it is possible to have one or more of either type of component. Moreover, each component may be implemented in common or different hardware, and be co-located or remote from one another.




Bi-directional communication paths


150


,


155


,


160


,


165


and


170


allow the different components to communicate with one another. First, the management entity components configure CA/headend/uplink events and EFDs at the component agents. Second, the management entity components get CA/headend/uplink MIB information from the agent components. The management entities update their local MIBs with this information. Third, the agent components send asynchronous notifications to the management entity components. An asynchronous notification means that the time of sending the notification by the agent is random from the manager's perspective, and is not in response to an immediately preceding request. Fourth, the management entity components provide CA/headend/uplink MIB updates to the agent components.




In particular, the interaction between the CA/headend/uplink system components is accomplished though the network management system as follows. The component advertises information such as DVB/MPEG SI/PSI information including event schedules through the MIB. For example, the MIB can comprise SNMPv2 SMI MIB. This is accomplished through a software agent (e.g., SNMPv2 agent) or through an object server (e.g., CORBA object server or Java™ RMI object server).




For example, a component may advertise event schedules for television programming. The status of the program/event information may change due to a change in scheduled programs. An EIS, discussed in connection with

FIG. 2

, may be used to change this status. A certain amount of time before the start of the new program, the EIS changes a data entry in an agent's MIB that corresponds to the new program. This MIB information is made accessible to all managers. Additionally, the change in the data entry causes a MIB value-change event to be generated, which is then processed by an EFD to determine if a management entity should be notified. If so, notifications are generated and distributed to every management entity that is registered to receive the information. Advertising thus refers to making the new MIB data available to managers and distributing notifications if warranted.




However, advertising of event scheduling is only one of the things that can be accomplished by the ORPs. An ORP may also be used to distribute EMMs to multiplexers, distribute ECMs to ECM generators, and synchronize ECMGs with synchronizers.




The agent components implement X.733, X.734, and X.735 event reporting and logging by using the asynchronous notification capability of the management system. These capabilities include SNMP event notifications and special SNMP MIBs implementing event definitions, event forwarding definitions, and event logging.




The CA System Manager (e.g., management entities


120


and/or


140


) reads the headend/uplink MIBs on a fixed or varying periodic basis, updates its custom information and registers itself as a recipient of events caused by updates in the uplink MIB. The manager needs to periodically read the agent MIBs since the information at the agent can change as a result of a change in a component that is represented by an agent, and as a result of a change initiated by the manager.




The CA System Manager updates the headend/uplink with CA information on a periodic basis or upon receiving an event from the headend/uplink or another CA System component by setting the uplink MIBs through the network management protocol, or by updating its own MIBs which cause events that result in notifications to be sent to the headend/uplink manager.





FIG. 1

illustrates this synchronization and information exchange mechanism within the uplink/headend.




In accordance with the present invention, an Operation Reference Point (ORP) defines the interface between two headend/uplink components. It replaces a custom communications protocol which would need to be designed for the particular interface by a generic information exchange and event notification mechanism.




The four basic ingredients which enable ORP-based information exchange and synchronization are:




1. Information access through a standardized management protocol such as SNMP or CMIP, an enhanced SNMP protocol such as described in commonly assigned, co-pending U.S. patent application Ser. No. 09/075,605 to B. Meandzija, filed May 11, 1998, and incorporated herein by reference, or through a standardized OO protocol such as CORBA IIOP or Java™ RMI;




2. Information advertisement through a management information base or an object broker;




3. Event trigger configuration, event forwarding configuration, and event notifications; and




4. Event logging.




In the following sections, an implementation of ORPs for C(P)SI/(P)SI interaction is conceptualized using the following technologies:




1. SNMPv2 as the management protocol;




2. SNMPV2 SMI MIBs for information advertisement;




3. SNMPv2 event and EFD MIBs and event notifications implementing a variant of the ITU-T X.731, X.733, and X.734 based state and event management; and




4. SNMPv2 logging and logging control MIBs implementing a variant of the ITU-T X.731 and X.735 based log management.




Event Mechanism




The event mechanism enables managers to configure the types of events that can be generated by an agent, and when those events should be transformed into asynchronous notifications (e.g., SNMP Traps) to be sent to different managers. The mechanism and information model used are based on the ITU-T TMN X.733 and X.734 standards defining event management and alarm reporting. The following object groups are defined:




Events Group—This group comprises event configuration information defining the types of events that the agent shall generate.




Event Forwarding Discriminator (EFD) Group—This group comprises EFD configuration information defining what types of events an EFD will transform into notifications, at what times of day it will do so, and to which managers it will send the notifications.




Event Notifications—This group defines three types of notifications which an agent can send to a manager, namely an alarm, a state change notification, and a value change notification. Each EFD specifies what type of notification is to be sent for an event that has occurred in the agent. The EFD also specifies the conditions under which such a notification is to be sent, and the IP address of the manager to which the notification is to be sent. All standard SNMP traps are sent to the managers UDP port


162


. All management platforms like HP OpenView™, Sun DomainManager™, and so forth support this mechanism.




The Events Group stores event descriptions in a table. Each row in the table corresponds to an event that the agent is to generate. The event description in that table specifies when the agent is to generate the event, e.g., because a MIB variable has crossed a specified threshold, because a state has been changed, etc.




Once the agent generates an event as specified in the Event table, it checks the EFD Table to find an EFD that matches that event and specifies what kind of notification is to be generated, and to which manager that notification is to be sent. The match is performed based on event characteristics such as event type, etc.




The EFDs in the EFD Table are controlled by three state/status variables, namely the administrative state, the operational state, and the availability status of the agent. If the administrative state is not unlocked, or the operational state is not enabled, or the availability status is not available, the EFD is inactive, which means it is ignored by the agent. The manager sets the administrative and operational states. The availability status is set as a result of an automatic scheduling function that is also associated with the EFD and specified in the EFD table. This scheduling function includes specifications of a daily start and stop time, and a weekly mask specifying when the EFD changes availability status from off-duty to available.




Event Group




This group, set forth in Table 1, comprises event configuration information defining the types of events that the agent shall generate.














TABLE 1









Common Information Model - CIM





Maximum






Simulcrypt Events Module - EM Events




Object




Access






Group - Event Configuration Table




Justification




Right











emEventName, the unique name of the




provides a unique




read






target event, EntryName (SNMP)




identification







of an event






emEventAdminiState, administrative




enables concur-




read-write






state of a table row, enumerated




rency control






type (ITU-T X.731)




between multi-







ple management







entities






emEventType, indicates the type of event,




enables differen-




read-write






enumerated type (ITU-T X.734)




tiation between







distinct event







types






emEventText, a description of an event's




enables textual




read-write






function and use, ASCII string of




description of






maximum 256 characters




an event for







human readers






emEventChangedObjectId, the object




enables associa-




read-write






identifier of the MIB object to check




tion of MIB






and see if the event should fire (groups




objects with






of objects are identified by specifying




events






an intermediate node), OBJECT






IDENTIFIER (SNMP)






emEventToStateChange, if




enables associa-




read-write






emEventChangedObjectId is a state/status




tion of events






variable this variable identifies the state




with state/






that causes the event to be generated,




status






32 bit unsigned integer




variables






emEventRisingThreshold, if




enables associa-




read-write






emEventChangedObjectId is a threshold




tion of events






variable this variable indicates the




with threshold






threshold value to check against; if




variables






the value of emEventChangedObjectId is






greater than or equal an event is






generated; 32 bit unsigned integer






emEventFallingThreshold, if




enables associa-




read-write






emEventChangedObjectId is a threshold




tion of events






variable this variable indicates the




with threshold






threshold value to check against; if the




variables






value of emEventChangedObjectId is less






than or equal an event is generated;






32 bit unsigned integer






emEventProbableCause, defines further




enables differen-




read






probable cause for the last event of




tiation between






this type, enumerated type (ITU-T X.734)




event causes






emEventPerceivedSeverity, defines the




enables differen-




read






perceived severity of the last event of




tiation of event






this type, enumerated type (ITU-T X.734)




severity level






EmEventTrendIndication, indicates




enables the




read






the trend of the last event




indication of






of this type, enumerated type




the event






(ITU-T X.734)




trend, i.e. more/







less severe






emEventBackedUpStatus, indicates




enables identifica-




read-write






the backed up status of the object




tion of backed






causing the event, enumerated type




up objects






(ITU-T X.731)






emEventBackedUpObject, if the backed




enables specifica-




read-write






up status is backedUp this variable




tion of back






contains the object identifier of the back




up objects






up object, OBJECT IDENTIFIER (SNMP)






emEventSpecificProblems, identifies the




enables specifica-




read-write






object responsible for the problem,




ton of specific






OBJECT IDENTIFIER (SNMP)




problems






emEventFrequency, identifies the number




enables event




read-write






of seconds to wait between event




throttling






frequency checks, 32 bit unsigned






integer






emEventPersistence, identifies whether




enables reliable




read-write






the event is generated only once or




event delivery






whether it is repeated in emEvent-






Frequency intervals, TruthValue (SNMP)






emEventStatus, status variable for




enables synchro-




read-write






synchronizing row creation/deletion




nization of row






between management entities,




creation/deletion






RowStatus (SNMP)














Event Forwarding Discriminator (EFD) Group




This group, set forth in Table 2, comprises EFD configuration information defining what types of events an EFD will transform into notifications, at what times of day it will do so, and to which managers it will send the notifications. An EFD generates a notification if it is unlocked (administrative state), enabled (operational state) and available (availability status), and if all of the specified discriminators are true, e.g., if emEfdDiscriminatedTypes is specified, then the type indicated has to match the type of the event for a notification to be generated. If multiple discriminators are specified by a single EFD, then all have to be matched (e.g., using a logical AND) before a notification is generated. A discriminator that is not specified in an EFD is always TRUE. A single event can match multiple EFDs and generate multiple notifications if so specified by the emEfdOr variable of Table 2.














TABLE 2









Common Information Model - CIM








Simulcrypt Events Module - EM Event





Maximum






Forwarding Discriminator (EFD) Group -




Object




Access






EFD Table




Justification




Right











emEfdName, the unique name of the EFD,




provides a unique




read






EntryName (SNMP)




identification







of an EFD






emEfdAdminState, administrative state




enables concur-




read-write






of a table row, enumerated type




rency control






(ITU-T X.731)




between multi-







ple management







entities






emEfdOperState, operational state of




enables the




read-write






an EFD, enumerated type (ITU-T X.731)




indication of







the current oper-







ation state






emdEfdAvailStatus, reflects the




enables




read






scheduling of the EFD, enumerated




scheduling






type (ITU-T X.731)






emEfdStartTime, defines the date and




enables the




read-write






time at which an unlocked and enabled




scheduling of






EFD starts functioning, i.e. changes




EFDs






the availability status from offDuty






to available, DateAndTime (SNMP)






emEfdStopTime, defines the date and




same




read-write






time at which an unlocked and enabled






EFD stops functioning, i.e. changes






its availability status from available






to offDuty, DateAndTime (SNMP)






emEfdDailyStartTime, defines the




enables daily




read-write






daily start time at which an unlocked




scheduling of






and enabled EFD starts functioning,




EFDs






i.e. changes its availability status from






offDuty to available, TimeTicks (SNMP)






emEfdDailyStopTime, defines the daily




same




read-write






stop time at which an unlocked and






enabled EFD stops functioning, i.e.






changes its availability status from






available to offDuty, TimeTicks (SNMP)






emEfdWeeklyMask, defines the weekly




enables weekly




read-write






schedule at which an unlocked and




scheduling






enabled EFD starts functioning, an






octet string of 1 octet






emEfdTypes, the event type that this




enables an EFD




read-write






EFD may generate notifications for,




to be specialized






enumerated type (ITU-T X.734)




for a particular







event type






emEfdCause, the probable cause that




enables an EFD




read-write






this EFD may generate notifications




to be specialized






for, enumerated type (ITU-T X.734)




by probable







cause






emEfdPerceivedSeverity, the perceived




enables an EFD




read-write






severity that this EFD may generate




to be specialized






notifications for, enumerated type




by severity






(ITU-T X.734)






emEfdSpecificProblems, the identifier




enables an EFD




read-write






of the object that may cause the




to be specialized






generation of a notification by this




by event causing






EFD, OBJECT IDENTIFIER (SNMP)




Object






emEfdTrendIndication, identifies the




enables an EFD




read-write






event trend that will cause a




to be specialized






notification to be generated, enumerated




by event






type (ITU-T X.734)




trend






emEfdChangedObjectId, identifies the




enables an EFD




read-write






object whose value change shall cause




to be specialized






the generation of a notification,




by value change






OBJECT IDENTIFIER (SNMP)




of an object






emEfdToStateChange, the to state of




enables an EFD




read-write






the object that may cause the generation




to be specialized






of a notification by this EFD, 32 bit




by a state






unsigned integer




value






emEfdNotification, identifies the




enables the




read-write






notification object identifier to be




association of a






generated if conditions are met,




notification type






OBJECT IDENTIFIER (SNMP)




with an EFD






emEfdOr, identifies whether the EFD table




enables multiple




read-write






shall be searched further for other




notifications to be






possible matches and further possible




generated by






notification generation, enumerated




an event






emEfdTarget, the IP address of the




enables the




read-write






management entity to receive the




specification of






notification if generated, IpAddress




the target man-






(SNMP)




agement entity







for the notifica-







tions generated







by the EFD






emEfdText, a description of an event's




enables textual




read-write






function and use, ASCII string




description of an






of maximum 256 characters




EFD for







human readers






emEfdStatus, status variable for




enables synchro-




read-write






synchronizing row creation/deletion




nization of row






between management entities, RowStatus




creation/deletion






(SNMP)














Event Notification Group




This group defines three types of notifications which an agent can send to a manager. These are an alarm, a state change notification, and a value change notification. Each EFD specifies what type of notification is to be sent for an event that has occurred in the agent. The EFD also specifies the conditions under which such a notification is to be sent and the IP address of the manager to which the notification is to be sent. All standard SNMP traps are sent to the manager's UDP port


162


. All management platforms like HP OpenView, Sun DomainManager, etc. support this mechanism.




The first notification type that can be generated is an emEventAlarm, which carries, in addition to the standard SNMPv2 notification parameters, the following objects from the events table:




emEventName




emEventType




emEventProbableCause




emEventSpecificProblems




emEventPereceivedSeverity




emEventTrendIndication




emEventText




The second notification type that can be generated is an emEventStateChange which carries, in addition to the standard SNMPv2 notification parameters, the following objects from the events table:




emEventName




emEVentStateChange




emEventChangedObjectId




The third notification type that can be generated is an emEventobjectValueChange which carries, in addition to the standard SNMPv2 notification parameters, the following objects from the events table:




emEventName




emEventChangedObjectId




Logging Mechanism




The logging mechanism enables managers to configure the types of logs that can be generated by an agent. The mechanism and information model used are based on the ITU-T TMN X.735 Log Model.




The log, in addition to conceptually storing the logged information, determines which information is to be logged. Each log contains a discriminator construct which specifies the characteristics an event must have in order to be selected for logging. Thus, the generated events are filtered by the discriminator construct to determine which events are to be logged. The logging mechanism comprises the following object groups:




Log Control Group—This group defines the types of log tables the agent is maintaining, their discriminators, the log scheduling, etc; and




The Logs Group—This group defines three logs: the alarm logs, the state change logs, and the object value change logs.




Logs are controlled by the Log Control Table as specified in the ITU-T TMN X.735. Each entry in that table associates events with logs, and specifies when the event is to be logged in that log. The event is logged if the log discriminator holds. That is, if the event is of a certain type, if it has been generated by a certain object, if it exceeds a certain threshold, etc. The log control entries themselves are controlled by state/status variables, the administrative state, the operational state, and the availability status of the agent. The manager can set the administrative and operational states. The availability status is set by the agent itself based on an automatic log control scheduling mechanism which specifies the times during which the logs are to be made.




Log Control Table entries also specify log control information and log statistics. The three logs defined are defined as tables in which each event is stored as a row. The logs in the alarm log table are logs of alarm events that have passed the log control discriminator in the Log Control Table. Similarly the logs in the state change log table are logs of state changes. And, logs in the object value change table are logs of object value changes.




Log Control Group




This group, set forth in Table 3, defines the types of log tables the agent is maintaining, their discriminators, the log scheduling, etc.














TABLE 3









Common Information Model - CIM





Maximum






Simulcrypt Logs Module - LM Log




Object




Access






Control Group - Log Control Table




Justification




Right











ImLogControlName, the unique name




provides a unique




read






of the Log Control Entry, EntryName




identification






(SNMP)




of a Log







Control Entry






ImLogControlId, the unique log table




provides a unique




read-write






identifier, OBJECT IDENTIFIER (SNMP)




identification







of Log Tables






ImLogControlAdminiState, administrative




enables concur-




read-write






state of a table row, enumerated




rency control






(ITU-T X.731)




between multi-







ple management







entities






ImLogControlOperState, operational state




enables the




read-write






of an EFD, enumerated (ITU-T X.731)




indication of the







current oper-







ation state






ImLogControlAvailStatus, reflects the




enables




read






scheduling of the Log Control entry,




scheduling






enumerated (ITU-T X.731)






ImLogControlFullAction, defines what




enables control




read-write






action to take when the maximum log




of log full






table size has been reached, enumerated




action






(ITU-T X.735)






ImLogControlMaxLogSize, defines the




enables control




read-write






maximum size of a log table in number




of the maximum






of octets, 32 bit unsigned integer




log table size






ImLogControlCurrentLogSize, defines the




enables monitor-




read






current log table size, 32 bit unsigned




ing of log table






interger




size






ImLogControlNumberOfRecords,




enables monitor-




read






specifies the number of log records in




ing of the log






the log table, 32 bit unsigned integer




table size






ImLogControlStartTime, defines the




enables the




read-write






date and time at which an unlocked and




scheduling of






enabled Log Control entry starts




Log Controls






functioning, i.e. changes the availability






status from offDuty to available,






DateAndTime (SNMP)






ImLogControlStopTime, defines the date




same




read-write






and time at which an unlocked and






enabled Log Control entry stops






functioning, i.e. changes its






availability status from available to






offDuty DateAndTime (SNMP)






ImLogControlDailyStartTime, defines the




enables daily




read-write






daily start time at which an unlocked




scheduling of






and enabled Log Control entry starts




log control






functioning, i.e. changes its availability




entries






status from offDuty to available,






TimeTicks (SNMP)






ImLogControlDailyStopTime, defines




same




read-write






the daily stop time at which an






unlocked and enabled Log Control entry






stops functioning, i.e. changes its






availability status from available to






offDuty, TimeTicks (SNMP)






ImLogControlWeeklyMask, defines the




enables weekly




read-write






weekly schedule at which an unlocked




scheduling






and enabled Log Control entry starts






functioning, octal string of length 1






ImLogControlTypes, the event type that




enables a Log




read-write






this Log Control entry may generate logs




Control entry






for, enumerated (ITU-T X.734)




to be specialized







for a particular







event type






ImLogControlCause, the probable cause




enables an Log




read-write






that this Log Control entry may generate




Control entry to






logs for, enumerated (ITU-T X.734)




be specialized







by probable







cause






ImLogControlSeverity, the perceived




enables an Log




read-write






severity that this Log Control entry




Control entry to






may generate logs for, enumerated




be specialized






(ITU-T X.734)




by severity






ImLogControlSpecificProblems, the




enables an Log




read-write






identifier of the object that may cause




Control entry to






the generation of a log entry by




be specialized






this Log Control entry, OBJECT




by Object






IDENTIFIER (SNMP)






ImLogControlToStateChange, the to




enables an Log




read-write






state of the object that may




Control entry to






cause the generation of a log entry




be specialized by






by this Log Control entry, 32




a state value






bit unsigned integer







ImLogControlTrendIndication, identifies




enables special-




read-write






the trend that will cause a log entry




ization of log






to be made, enumerated (ITU-T X.734)




control based on







event trends






ImLogControlChangedObjectId, identifies




enables special-




read-write






the object that changed value and




ization of log






should be logged, OBJECT IDENTIFIER




control based on






(SNMP)




objects causing







the event






ImLogControlStatus, status variable for




enables synchro-




read-write






synchronizing row creation/deletion




nization of row






between management entities,




creation/deletion






RowStatus (SNMP)














Logs Group




The three logs defined are defined as tables in which each event is stored as a row. The logs in the alarm log table, Table 4, are logs of alarm events that have passed the log control discriminator in the Log Control Table. Similarly, the logs in the state change log table, Table 5, are logs of state change events. And, logs in the object value change table, Table 6, are logs of object value change events.














TABLE 4









Common Information Model - CIM





Maximum






Simulcrypt Logs Module - LM Logs




Object




Access






Group - Alarm Logs Table




Justification




Right











ImAlarmLogName, the unique name of




provides a unique




read






the Log Control Entry, EntryName




identification






(SNMP)




of the alarm







log entry; it is







identical to the







event name






ImAlarmLogTime, the time at which




provides a unique




read






the alarm has been logged, TimeTicks




identification






(SNMP)




of Log Tables






ImAlarmLogText, a textual description of




records the event




read






the event being logged, ASCII string of




description






maximum 256 characters






ImAlarmLogType, the event type of this




records alarm




read






log entry, enumerated (ITU-T X.734)




type






ImAlarmLogCause, the event cause of this




records event




read






log entry, enumerated (ITU-T X.734)




cause






ImAlarmLogSeverity, the alarm severity




records event




read






of the logged event, enumerated




severity






(ITU-T X.734)






ImAlarmLogSpecificProblems, the




records the id




read






identifier of the object that




of objects






caused the logged event, OBJECT




causing the






IDENTIFIER (SNMP)




event






ImAlarmLogTrendIndication, the trend




records event




read






of the event that has been logged,




trend






enumerated (ITU-T X.734)






ImAlarmLogChangedObjectId, identifies




records the id




read






the object that changed value and




of the object






caused the logged event, OBJECT




causing the






IDENTIFIER (SNMP)




event
























TABLE 5









Common Information Model CIM





Maximum






Simulcrypt Logs Module - LM Logs




Object




Access






Group - State Change Log Table




Justification




Right











ImStateChangeLogName, the unique name




provides a unique




read






of the Log Control Entry, EntryName




identification






(SNMP)




of the log entry;







it is identical







to the







event name






ImStateChangeLogTime, the time at




provides a unique




read






which the alarm has been logged,




identification






TimeTicks (SNMP)




of Log Tables






ImStateChangeLogTime, a textual descrip-




records the




read






tion of the event being logged, ASCII




event






string of maximum 256 characters




description






ImStateChangeLogToState, the to state




records event




read






change of the event being logged,




to state






enumerated (ITU-T X.734)




change






ImStateChangeLogChangedObjectId,




records the id




read






identifies the object that changed value




of the object






and caused the logged event, OBJECT




causing the event






IDENTIFIER (SNMP)
























TABLE 6









Common Information Model - CIM





Maximum






Simulcrypt Logs Module - LM Logs




Object




Access






Group - Value Change Logs Table




Justification




Right











ImValueChangeLogName, the unique




provides a unique




read






name of the Log Control Entry,




identification






EntryName (SNMP)




of the log entry;







it is identical







to the event







name






ImValueChangeLogTime, the time at




provides a unique




read






which the alarm has been logged,




identification






TimeTicks (SNMP)




of Log Tables






ImValueChangeLogText, a textual




records the event




read






description of the event being logged,




description






ASCII string of maximum 256 characters






ImValueChangeLogChangedObjectId,




records the id






identifies the object that changed




of the object






value and caused the logged event,




causing the






OBJECT IDENTIFIER (SNMP)




event














(P)SI Information Advertisement




(P)SI information is advertised in SNMPv2 SMI tables. Each table maintains the row status through an EntryStatus type object and the administrative state in the same manner as the tables in the previous sections. All MPEG/DVB data types are mapped to SNMPv2 SMI types. Each MPEG/DVB section is represented by SNMPv2 SMI tables as follows:




1. MPEG program_association_section in PAT;




2. MPEG CA_section in CAT;




3. MPEG TS_program_map_section in PMT;




4. DVB network_information_section in NIT-O and NIT-A;




5. DVB service_description_section in SDT in SDT-O and SDT-A;




6. DVB event_information_section in EIT-A-PF, EIT-O-PF, EIT-A-ES, and EIT-O-ES;




7. DVB bouquet_association_section in BAT;




8. DVB time_date_section in TDT;




9. DVB running_status_section in RST; and




10. DVB stuffing_section in ST.




Operations Reference Points (ORPs)




Information exchange and synchronization between C(P)SI and (P)SI generators is accomplished as follows using ORPs:




The (P)SI generator (PSIG) implements three SNMPv2 SMI modules, namely (1) events module as specified in the section entitled “Event Mechanism”, (2) logs module as specified in the section entitled “Logging Mechanism”, and (3) (P)SI information as specified in the section entitled “(P)SI Information Advertisement”.




The manager maintaining the C(P)SI-CPSIM-reads the (P)SI tables by using SNMPv2 get, getNext, or getBulk commands.




CPSIM configures an event in PSIGs events module that will generate an event whenever an object or a group of objects in the EIT changes value. The EIT may include additional event scheduling status information with each one of the objects. The value change in that status may be configured as the event trigger by the CPSIM.




CPSIM configures the EFD in PSIG and, through the EFD, schedules what objects are to be forwarded to what destinations.




PSIG generates the event and consults the EFD table. If scheduled, event notifications are generated and sent to the CPSIM and possibly other destinations.




The PSIG continues generating and forwarding events until reconfigured by the CPSIM. This ensures that the event is received by the intended recipient.




If necessary, the CPSIM updates (P)SI tables in the PSIG such as the CAT.




To save networking bandwidth, it is possible to only transmit basic event information using event notifications. Additional information can be logged through the logging mechanism described in the section entitled “Logging Mechanisms”. In this event, the log control table in the PSIG is configured by the CPSIM to define exactly which events and which associated objects are logged.





FIG. 2

illustrates a broadcast headend with conditional access components as agents, and a network management system as a manager, in accordance with the present invention. A headend, shown generally at


200


, includes an Event Information Scheduler (EIS)


205


which provides event scheduling information to a Program Specific Information (PSI) generator


250


, a mux configuration component


265


, and a sychronizer


270


. The EIS


205


is an agent that receives data from a management entity component regarding the scheduling of events. For example, the events may be television programs which are scheduled by channel, programming source, e.g., CNN and HBO, and time.




The PSI generator


250


also receives custom and/or program specific information, i.e., C(P)SI, from a C(P)SI generator component


215


, and provides corresponding PSI tables to the mux


280


. PSI is defined in the MPEG standard.




An Entitlement Control Message Generator (ECMG)


220


provides entitlement control messages (ECMs) to the synchronizer


270


, which provides the ECMs at the proper time to the mux


280


. The synchronizer also provides control words (CW) and access criteria (AC) data to the ECMG


220


.




An Entitlement Management Message (EMM) generator


240


provides EMMs to the mux


280


, while a private data generator


230


provides private data to the mux


280


. An EMM may include cryptographic keys such as group keys which are used by a decoder to decoder an encrypted television signal, for example. The EMMs are appended to the various programming services to authorize the decoders to receive particular programming services, for example, according to a tiered marketing scheme. Possession of the group key or keys along with the appropriate entitlement control data allows the decoders to recover program keys from the program data sent by the service provider in the ECMs. ECMs and EMMs are well-known in the art, for example, as discussed in commonly-assigned U.S. Pat. No. 5,627,892 to Kauffman.




Under the control of the synchronizer


270


, the mux multiplexes the input data and provides it to a scrambler


285


for scrambling (e.g., encryption), also under the control of the synchronizer. The output of the mux


280


may be an MPEG transport stream which includes various other types of data, including audio and video, not shown. The output of the scrambler


285


comprises CA data that is subsequently transmitted to an end user, e.g., via CATV network or digital satellite broadcast network. The synchronizer


270


times the multiplexing of the private data from component


230


, EMMs from component


240


, ECMs from component


220


, and control words from component


275


.




Note that components


215


,


220


,


230


,


240


are used for providing conditional access, while components


205


,


250


,


265


,


270


,


275


and


285


, are host headend components.




The CA components of the headend


200


act as agents which communicate with a management entity component such as the network management system


295


. The network management system


295


may be local to the headend


200


, or at a remote location. The network management system


295


may use a communication path such as a telephone line, LAN, ATM network, or other computer network link, for example, to provide monitoring and control data to the agent components, and to receive the asynchronous notifications from the agent components.




In

FIG. 2

, one or more different types of private data, EMMs, PSI tables and ECMs may be provided according to the specific format of the television or other signal in which the CA data will be used. Furthermore, while the components are logically separate, they may reside within the same physical component, in which case there is only one agent for the merged components.




The different components in

FIG. 2

are synchronized with one another through the use of ORPs, i.e., message exchanges using the transaction mechanism as defined by the procedure and information to be exchanged.





FIG. 3

illustrates an agent component and a management entity component in accordance with the present invention. The agent component (e.g., agent)


300


communicates with a management entity component (e.g., manager)


370


via a network


350


, such as a LAN, computer network, Internet, or telephone network. The agent component


300


includes a memory


302


, processor


304


, and transceiver


306


, while the management entity component similarly includes a memory


372


, processor


374


, and transceiver


376


. Typically, several agent components, and one or more management entity components are provided, but only one of each is shown here for simplicity.




Moreover, one or more agents may share a memory, processor, and/or transceiver, or each agent may have its own separate hardware. Generally, the manager has its own hardware but can possibly also share hardware with the agents.




The manager


370


may communicate with an operator interface


380


, such as a keyboard, to receive information such as the administrative and operational states of the agent components. The manager


380


may be implemented as a workstation, personal computer or other type of computer, or as a computer board or as a computer chip set. The memory


372


may comprise RAM, for example, and the processor


374


may be a microprocessor. The transceiver


376


; or transmitter/receiver is a conventional circuit such as a modem used for transmitting and receiving data.




A computer code to be used by the manager


370


may be stored in the memory


372


and operated on by the processor


374


. Information received from the operator interface


380


may also be stored in the memory


372


. Additionally, the MIB of the manager


370


may be provided as part of the general purpose memory


372


.




The processor


374


may be used to execute the computer code to communicate information to specific agents, and to process information received from the agents.




As will be appreciated by those skilled in the art, the processors


304


,


374


may read and write data from the associated memories


302


,


372


, and send data to, and receive data from the respective transceivers


306


,


376


. In this manner, the management component


370


and agent component


300


may communicate data, control signals, polling signals, and other information between themselves. Moreover, the respective processors


304


,


374


may include timing circuits that indicate particular times for a specific data transmission to occur.




In particular, the processor


304


may be responsive to the transceiver


306


for updating the MIB (in memory


306


) with information of the communication network that is received by the transceiver. The transceiver


376


may be responsive to the processor


374


for periodically (e.g., intermittently) transmitting control signals to the processor


304


, e.g., via the transceiver


306


. The transceiver


306


is responsive to the processor


304


and the control signals from the manager for transmitting the updated information from the MIB to the manager's transceiver


376


for storage at the manager's MIB in memory


372


.




The manager's transceiver


376


is responsive to its processor


374


for periodically transmitting information to the agent's processor


304


for storage at the agent's MIB to synchronize insertion of data into the digital broadcast data stream by one or more agent components.




The agent


300


may represent one or more resources or other agents, e.g., sub-agents. The MIB of the agent


300


may be provided as part of the general purpose memory


302


.




Information, such as administrative state information and event information may be communicated from the manager


370


to the agent


300


and stored in the memory


302


. Event table data, EFD table data, and log control table data may also be stored in the memory


302


for use by the agent component


300


. Alarm, state change, and value change log data may also be stored in the memory


302


.




The processor


304


may be used to communicate information to, and receive information from, the manager


370


and any other resource or sub-agent.




The manager


370


may be a standalone device (e.g., computer), or may be a capability implemented on a shared system. The manager


370


serves as an interface for a human operator/manager into the management system and includes:




Management applications for data analysis, fault recovery, etc.;




A monitoring/control interface of the network for the manager;




The capability to translate a network manager's commands into actual monitoring and control of remote elements; and




A database of information extracted from the MIBs of all the managed entities in the network.




The agent components respond to requests for actions from the manager


370


. The manager


370


may also provide the agent


300


with important unsolicited information. Each agent supports access to a collection of managed resources, which are represented by managed objects referred to as the MIB. Managed objects are standardized across systems of a particular class; for example, all EMM generators support a standard set of objects, in addition to some objects that are specific to a particular manufacturer's EMM generator model.




The manager performs a monitoring function by retrieving the value of MIB objects from the agents. A manager can cause an action to take place at an agent, or change the configuration settings of an agent by modifying the value of specific variables. For example, a manager can request an MPEG table insertion into an MPEG transport stream by making a table entry into the corresponding table in a MIB.




As can be seen, the present invention provides a method and apparatus for providing synchronization and information exchange in a network. The method allows a management entity component, such as a computer workstation operated at a control center, to coordinate the actions of different agent components, such as hardware used at the headend or uplink site of a television network. In particular, the agent components may provide conditional access data for a television signal.




Although the invention has been described in connection with various specific embodiments, those skilled in the art will appreciate that numerous adaptations and modifications may be made thereto without departing from the spirit and scope of the invention as set forth in the claims.



Claims
  • 1. A method for providing communication between first and second headend, uplink and/or conditional access agent components and a management component thereof in a communication network, comprising the steps of:providing respective management information bases (MIBs) for said first and second agent components and said management component; said first and second agent components updating their respective MIBs with information of said communication network; said management component periodically reading said MIBs of said first and second agent components to obtain the updated information therefrom, and storing the updated information in its respective MIB; wherein said management component provides information to said MIBs of said first and second agent components to synchronize an insertion of data into a digital broadcast data stream by said first and second agent components.
  • 2. The method of claim 1, wherein:said first agent component advertises event schedule information of said communication network by making said event schedule information available to said management component and said second agent component via said first agent component's respective MIB.
  • 3. The method of claim 1, comprising the further step of:transmitting event reporting information from said management component to at least said first agent component to allow said first agent component to implement an event reporting procedure; said event reporting information defining pre-conditions for said first agent component to declare an event; said first agent component asynchronously notifying said management component of an event when said pre-conditions have been met.
  • 4. The method of claim 3, wherein a plurality of management components are provided in said communication network, comprising the further step of:transmitting information from at least a particular one of said management components to said first and second agent components to register said particular management component as a recipient of the asynchronous event notifications thereof.
  • 5. The method of claim 3, comprising the further step of:transmitting event logging information from said management component to at least said first agent component to allow said first agent component to implement an event logging procedure according to said event reporting procedure; said event logging information defining pre-conditions for said first agent component to log an event.
  • 6. The method of claim 3, comprising the further step of:transmitting event forwarding discriminator information from said management component to at least said first agent component to allow said first agent component to implement an event forwarding discriminator procedure according to said event reporting procedure; said event forwarding discriminator information defining pre-conditions for said first agent component to forward an event to said management component.
  • 7. The method of claim 1, wherein:at least one of said first and second agent components is a conditional access agent component for inserting conditional access data into said digital broadcast data stream.
  • 8. The method of claim 7, wherein:said management component provides conditional access information to said MIB of said conditional access agent component.
  • 9. The method of claim 1, wherein:said management component and said first and second agent components are synchronized with one another.
  • 10. An apparatus for providing communication between first and second headend, uplink and/or conditional access agent components and a management component thereof in a communication network, comprising:respective management information bases (MIBs) for said first and second agent components and said management component; means associated with said first and second agent components for updating their respective MIBs with information of said communication network; means associated with said management component for periodically reading said MIBs of said first and second agent components to obtain the updated information therefrom; means for storing the updated information in said MIB of said management component; and means associated with said management component for providing information to said MIBs of said first and second agent components to synchronize an insertion of data into a digital broadcast data stream by said first and second agent components.
  • 11. The apparatus of claim 10, further comprising:means associated with said first agent component for advertising event schedule information of said communication network by making said event schedule information available to said management component and said second agent component via said first agent component's respective MIB.
  • 12. The apparatus of claim 10, further comprising:means for transmitting event reporting information from said management component to at least said first agent component to allow said first agent component to implement an event reporting procedure; said event reporting information defining pre-conditions for said first agent component to declare an event; and means associated with said first agent component for asynchronously notifying said management component of an event when said pre-conditions have been met.
  • 13. The apparatus of claim 12, wherein a plurality of management components are provided in said communication network, further comprising:means for transmitting information from at least a particular one of said management components to said first and second agent components to register said particular management component as a recipient of the asynchronous event notifications thereof.
  • 14. The apparatus of claim 12, further comprising:means for transmitting event logging information from said management component to at least said first agent component to allow said first agent component to implement an event logging procedure according to said event reporting procedure; said event logging information defining pre-conditions for said first agent component to log an event.
  • 15. The apparatus of claim 12, further comprising:means for transmitting event forwarding discriminator information from said management component to at least said first agent component to allow said first agent component to implement an event forwarding discriminator procedure according to said event reporting procedure; said event forwarding discriminator information defining pre-conditions for said first agent component to forward an event to said management component.
  • 16. The apparatus of claim 10, wherein at least one of said first and second agent components is a conditional access agent component, further comprising:means associated with said conditional access agent component for inserting conditional access data into said digital broadcast data stream.
  • 17. The apparatus of claim 16, further comprising:means associated with said management component for providing conditional access information to said MIB of said conditional access agent component.
  • 18. The apparatus of claim 10, wherein:said management component and said first and second agent components are synchronized with one another.
  • 19. The apparatus of claim 10, wherein:said communication network comprises a broadband network for providing said digital broadcast data stream to a decoder population.
  • 20. An apparatus for providing communication between first and second headend, uplink and/or conditional access agent components and a management component thereof in a communication network, comprising:at least one memory associated with said first and second agent components providing respective management information bases (MIBs) thereof; a memory associated with said management component providing a MIB thereof; at least one transceiver associated with said first and second agent components; a transceiver associated with said management component; at least one processor associated with said first and second agent components; a processor associated with said management component; said at least one processor responsive to said at least one transceiver for updating said MIBs of said first and second agent components with information of said communication network; said transceiver of said management component responsive to said processor thereof for periodically transmitting control signals to said at least one processor; said at least one transceiver responsive to said at least one processor and said control signals for transmitting the updated information from said MIBs of said first and second agent components to said transceiver of said management component for storage at the MIB thereof; said transceiver of said management component responsive to said processor thereof for periodically transmitting information to said at least one processor for storage at the MIBs of said first and second agent components to synchronize an insertion of data into a digital broadcast data stream by said first and second agent components.
Parent Case Info

This application claims the benefit of U.S. Provisional Application No. 60/064,178, filed Nov. 4, 1997.

US Referenced Citations (7)
Number Name Date Kind
5317568 Bixby et al. May 1994
5519863 Allen et al. May 1996
5627892 Kauffman May 1997
5794018 Vrvilo et al. Aug 1998
5968135 Teramato et al. Oct 1999
6014706 Cannon et al. Jan 2000
6041342 Yamaguchi Mar 2000
Foreign Referenced Citations (1)
Number Date Country
WO 9533309 Dec 1995 WO
Non-Patent Literature Citations (1)
Entry
Agoulmine, Nazim et al., “Intelligent Model Updating System in Heterogeneous Networks,” Conference on Communication Technology, 16 Sep. 1992, XP 000671596, pp. 19.07.1-19.07.4.
Provisional Applications (1)
Number Date Country
60/064178 Nov 1997 US