Browse Prior Art Database

Hierarchical Cascading of State/Event Machines

IP.com Disclosure Number: IPCOM000019964D
Original Publication Date: 2003-Nov-25
Included in the Prior Art Database: 2003-Nov-25
Document File: 3 page(s) / 159K

Publishing Venue

Siemens

Related People

Juergen Carstens: CONTACT

Abstract

In every communication session, session related data needs to be controlled and maintained. If one of the communication partners requires supplementary internal session data, and if this internal data is again related to the global session data, then complex relations arise, which become more and more difficult to handle as communication partners are added or removed. Often session related data is stored on different places in parallel. Sometimes very chaotic and thus error sensitive constructions occur, or else, restrictions are defined in order to prevent too complex data linkages to built up. Therefore, a generic way of establishing session related data is needed. To avoid these problems, a method for cascading State/Event Machines (SEMs) is described below. A State/Event Machine Controller instantiates a task and its assigned SEM. Depending on the kind of application, it can be necessary to instantiate further, subordinate SEMs, which maintain and process their own session related data. No data is stored double, though changes in one SEM can cause changes of data in another. This is initiated by internal events sent to the Event Distributor (ED), which is distributing any message, internal or external, to the appropriate SEM.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 3

S

© SIEMENS AG 2003 file: 2003J13432.doc page: 1

Hierarchical Cascading of State/Event Machines

Idea: Bart Reynaert, BE-Gent; Jan Vrolix, BE-Gent

In every communication session, session related data needs to be controlled and maintained. If one of the communication partners requires supplementary internal session data, and if this internal data is again related to the global session data, then complex relations arise, which become more and more difficult to handle as communication partners are added or removed. Often session related data is stored on different places in parallel. Sometimes very chaotic and thus error sensitive constructions occur, or else, restrictions are defined in order to prevent too complex data linkages to built up. Therefore, a generic way of establishing session related data is needed.

To avoid these problems, a method for cascading State/Event Machines (SEMs) is described below. A State/Event Machine Controller instantiates a task and its assigned SEM. Depending on the kind of application, it can be necessary to instantiate further, subordinate SEMs, which maintain and process their own session related data. No data is stored double, though changes in one SEM can cause changes of data in another. This is initiated by internal events sent to the Event Distributor (ED), which is distributing any message, internal or external, to the appropriate SEM.

The architecture of the above-named mechanism is depicted in Figure 1. The SEM Controller creates and deletes SEMs. This is a dynamic process and can be triggered by different sources. If e.g. the user creates or deletes a subscriber or a group, SEMs are created or deleted accordingly. Similarly, if the subscriber goes off-hook, a SEM ,Call Leg' is created. Also, the SEMs itself can trigger new ,child' SEMs, which in turn can start their own child SEMs. This can e.g. occur when the subscriber goes off- hook and a SEM ,Call Leg' is created as above, which in turn starts two child SEMs of which one is handling the A-side call leg, whereas the other takes over the B-side call leg. Furthermore, all SEMs of created subscribers, groups, etc. can be started at the system start-up.

The Event Distributor allocates the events to the appropriate SEM(s). There are two types of events. External events, which are originating from an external source, are typically signaling information like
e.g. the subscriber being off-hook. Internal events are originating from (child) SEM(s). If a SEM has information that has to be provided to another SEM, it emits an internal event, which is forwarded by the ED. For example an internal event is generated for the ,Subscriber Status' SEM of the called party, when the event ,Dialing Digits' is processed and a called party is selected. Several criteria can be used by the ED to select the destination SEM for an event. An important one is the source of the event. If e.g. a subscriber is off-hook, it will be routed to the according ,Subscriber' SEM...