Browse Prior Art Database

A State Machine Algorithm

IP.com Disclosure Number: IPCOM000126648D
Original Publication Date: 2005-Jul-25
Included in the Prior Art Database: 2005-Jul-25
Document File: 4 page(s) / 70K

Publishing Venue

Motorola

Abstract

This article describes a mechanism for implementing a state machine within a network element and the management mechanisms for preventing conflicting requests from operating on it. The state machine is implemented as a discrete entity, and may be paired with another state machine in another network element which it must remain synchronised with. The mechanism for synchronizing is via signalling messages, which may take a non-zero time to travel between the two state machines.

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 41% of the total text.

Page 1 of 4

A State Machine Algorithm

By Peter Randall, Stephen Hill Motorola, Inc.
Networks Business

ABSTRACT

  This article describes a mechanism for implementing a state machine within a network element and the management mechanisms for preventing conflicting requests from operating on it.

  The state machine is implemented as a discrete entity, and may be paired with another state machine in another network element which it must remain synchronised with. The mechanism for synchronizing is via signalling messages, which may take a non-zero time to travel between the two state machines.

PROBLEM

  Within the signalling framework of a mobile phone network, state machines are maintained and the signalling serves to synchronise them. Due to the nature of the network, delays are incurred in transmitting the signalling between peer entities, and so it is possible to result in overlap of signalling messages that results in conflicting behaviours in the state machines, hence resulting in potential lock-out or state machine crashes.

SOLUTION

  This document describes an instantiation of a signalling management algorithm that can be used to oversee the responsiveness of a network element or state machine. This can improve the availability and performance of the overall network by dealing with conflicting signalling procedures arising

from the many different independent factors that can generate signalling procedures originating from different points within the network (e.g. mobile originated or terminated call setups).

  The essence of the algorithm is to provide a decision mechanism to evaluate whether a newly requested procedure should be accepted, queued or rejected, depending on current activities within the state machine or network element and the permissions needed to perform the procedure.

  It is envisaged that this algorithm would be used at each end of intercommunicating peer entities - e.g. at the mobile and RNC instantiations of the RRC state machines, or in neighbouring network elements.

OPERATION

  The following three diagrams show flow charts for the major operations within this process. The first diagram (

© 2005 Motorola, Inc.

Page 2 of 4

 Receive Signalling

Message

Entity Busy?

Yes

Create New Procedure

No

 Existing Procedure?

Yes

Procedure Active?

Yes

No

 Handle message (inc any response)

Place in input queue

No

Exit

Figure 1) details the events when a message is received by the entity. In this flow, when a message is received, the entity first checks if there are any procedures currently running. If there are none, then the message may trigger a new process (see Figure 2). Otherwise, the entity checks if the message belongs to an existing process. If it does not belong to a process, then the message is queued. If it does belong to a process, then it checks if the process is active. If the process is not active, then the message is queued. Otherwise, the message is handled by the process that it pertains to.

  The second diagram (Figure 2) illustrates...