IE80765B1 - A service provider for interaction with a telecommunication network signalling system - Google Patents

Abstract

A service provider (1) has a finite state machine (FSM) core (10) which is isolated from the environment by upper (14) and lower (13) interfaces. Each interface has an inner element (13(a), 14(a)) which interacts with the core (10) by, for example, creating an FSM instance for a new transaction. The interfaces also have portable elements (13(b), 14(b)) which are modular and compatible with the particular external interface API and do not process message data.

Description

A service provider for interaction with a telecommunications network signalling system ' The invention relates to a service provider for i interaction with the signalling system of a telecommunications network. Such a service provider may be used for providing signals in the protocol necessary for access to subscriber data for signalling in a mobile telecommunications network. A service provider may alternatively be used for short message handling in a mobile telecommunications network. The invention relates to a service provider for any desired use which interacts with a telecommunications network signalling system.

Heretofore, service providers have been included in home location registers (HLRs) as an integral unit with a user interface such as a Mobile Application Part User (MAPUser) in a GSM network. Indeed, the combination of a MAPProvider service provider, together with a MAP-User is specified in the GSM standard. Such a service provider is quite difficult to modify with growth of the network.

Further, there is little versatility as it may not be used for a variety of different purposes. This necessitates a large degree of further programming as additional components are added to the network and existing ones are upgraded.

It is therefore an object of the invention to provide a service provider which is versatile whereby it may be used in a number of different environments with little modification. e Another object is that the service provider is easy to * upgrade.

GC A still further object is that the service provider should be capable of handling a number of different transactions simultaneously in real time while providing controlled access to system resources.

According to the invention, there is provided a service provider for interaction with a telecommunication network signalling system, the service provider comprising:a core comprising means for processing messages; an upper interface for interaction with a service user 10 via an external interface; and a lower interface for interaction with a signalling system via an external interface, wherein each interface comprises an inner element comprising means for initiating processing of messages by the core, and a modular portable element compatible with the external interface to which it is to be connected and comprising means for transferring messages without processing message data.

This architecture in a very simple manner allows versatility because it is only necessary to change the interface portable elements to change the environment in which the service provider is to operate. This is achieved more specifically by the separation of the interfaces from the core, and further, by breakdown of each interface as described. The fact that the portable elements do not process data helps to achieve both portability and fast message transfer.

In one embodiment, each portable element comprises means for calling external interface routines in response to a request from the core. This is a very effective way of separating core functionality from the external environment - it will always address a portable element routine in the same manner, even if the portable element is changed for a new environment.

In one embodiment, the service provider comprises means for establishing permanent communication channels with the external interfaces and for continuously monitoring the channels to detect messages. This allows very fast message transfer, in a simple way. The communication channels may be inter-process communication sockets bound between the external interfaces and the core. Further, the service provider may comprise a main section comprising means for establishing the sockets with all external interfaces and continuously monitoring them to detect messages .

In a further embodiment, the main section comprises means for activating an upper or lower interface portable element upon detection of a message, and the portable elements each comprise means for handling message transfer to the associated inner element when activated by the main section. This is a very efficient mechanism for achieving message transfer because the listening function is left to the main section and the transfer function to the portable element.

In another embodiment, the core comprises a finite state machine, each instance of which processes a single transaction involving one or more messages. This is a very effective way of processing messages, particularly because of the one-to-one link between instances and transactions. This link provides a basis for simple transaction control and monitoring. In this latter embodiment, the core may comprise means for allocating a unique memory area at the start of a transaction for storage of a transaction state, and means for inputting data of a received message as an event into a dispatcher together with the current state to identify a transaction routine to be executed.

Preferably, the lower interface inner element comprises means for activating an FSM routine to create a new instance, if one does not already exist, for a message received from the signalling system. This is an important feature because the inner element acts as a single channel for creating instances . The lower interface inner element may comprise means for maintaining a count value of current instances and comparing the count value with a pre-set threshold. Preferably, the lower interface inner element comprises means for ending a signalling system transaction when the count value equals the pre-set threshold. These features are very important because they prevent overload of the core and provide traffic control generally.

In another embodiment, the service provider further comprises a utility section which comprises means for creating buffer pools within the core for storage of state machine memory structures .

In a further embodiment, the core comprises a list routine for directing storage of list structures indicating relationships between instances of state machines.

Preferably, the core and the upper and lower interfaces comprise means for automatically calling a write function for logging of diagnostic tracing information during processing.

According to another aspect, the invention provides a service provider for interaction with a telecommunication network signalling system, the service provider comprising:a core comprising a finite state machine, each instance of which processes a single transaction involving one or more messages; a lower interface for interaction with a signalling system via an external interface, the lower interface comprising: an inner element having means for activating a finite state machine routine to create a new instance, if one does not already exist, for messages received from the signalling system, and a modular portable element compatible with the external interface to which it is connected and comprising means for transferring messages without processing message data and for calling external interface routines in response to a request from the core; and an upper interface for interaction with a service user via an external interface, the upper interface comprising:an inner element having means for initiating processing of messages by the core, and a modular portable element compatible with the external interface to which it is connected and comprising means for transferring messages without processing message data and for calling external interface routines in response to a request from the core.

Preferably, the lower interface inner element comprises :means for maintaining a count value of current 5 instances and comparing the count value with a pre-set threshold, and means for ending a signalling system transaction when the count value equals the pre-set threshold.

The invention will be more clearly understood from the 10 following description of some embodiments thereof, given by way of example only, with reference to the accompanying drawings in which:Fig. 1 is a schematic representation of a service provider of the invention connected to a signalling system and to a number of service users; Fig. 2 is a diagram showing a typical distributed environment in which the service provider may be used; Fig. 3 is a more detailed diagram illustrating construction of the service provider; Figs. 4 to 6 are flow charts illustrating operation of a core of the service provider; Figs. 7 to 10 inclusive are diagrams illustrating utility functions of the service provider.

Referring to Fig. 1, a service provider, namely, a Mobile Application Part-Provider (MAP-P) 1 is shown. The MAP-P 1 is connected to an SS7 signalling system 2 via an external interface, namely a Transaction CAPability (TCAP) API 3. The MAP-P 1 is also connected to a number of service users 4 by MAP APIs 5 which form part of the MAPP 1. While the MAP APIs 5 are part of the service provider 1, they are external interfaces to allow user access and need not necessarily be incorporated in the service provider 1. The other parts of the MAP-P 1 are indicated generally by the numeral 6 in Fig. 1. The service users 4 may be of any desired type such as MAPUsers in a home location register (HLR), or alternatively sections of a short messaging system. A number of different service users 4 may be serviced by the MAP-P 1. The service users 4 may run on the same host system as the MAP-P 1 or on a remote system. A typical example of the context of the MAP-P 1 is shown in Fig. 2 where it is part of each of a number of GSM network access processor nodes 8.

Referring now to Fig. 3, the MAP-P 1 is now described in more detail. The MAP-P 1 comprises a core which is a finite state machine 10 and which performs protocolimplementation functions. Each transaction is handled as a single instance of a dialogue handler. The MAP-P 1 also comprises a main section 11 which includes routines for such things as initialisation, management, and distribution of messaging through the MAP-P 1. There is also a utility section 12 to perform utility functions. A lower interface 13 interfaces with the TCAP API 3, the latter not forming part of the MAP-P 1. Finally, the MAPP 1 comprises an upper interface 14 which interfaces with the MAP APIs 5, both forming part of the MAP-P 1. In practice, there will often be several MAP APIs 5.

The finite state machine (FSM) 10 implements dialogue (transaction) handling, invocation requesting, and invocation performing operations. These operations are performed by receipt of an input event from either the upper interface 14 or the lower interface 13 and using the classic finite state machine mechanism of :input event + current state = next state + resulting transition.

The upper and lower interfaces 14 and 13 isolate the finite state machine 10 from the environment, namely, the signalling system API and the service users. Accordingly, the MAP-P 1 of the invention may be used in different environments with relatively little modification. The upper interface 14 comprises an inner element 14(a) and a portable element 14(b), whereas the lower interface 13 comprises an inner element 13(a) and a portable element 13(b).

Each separate instance that is created has an associated unique data memory area assigned to it and this area stores private information only relevant to the related transaction. Whenever an input event is about to be passed to the state machine, the private area to which the event is related is retrieved and both are passed into the state machine.

Referring to Fig. 5, the steps 15 to 24 performed for an instance of the FSM 10 are illustrated. Inter-process communication (IPC) sockets for message transfer are used to bind the API 3 to the FSM 10 via the lower interface 13, and to bind the MAP APIs 5 to FSM 10 via the upper interface 14. How this is achieved is described in more detail below.

In step 15, a first message at a socket binding the FSM 10 to the API 3 is detected and, upon receipt by the FSM 10, a transaction identifier (ID) is determined in step 16. This is used to create an area of memory and store in it an initial transaction state. The state is retrieved in step 17. The data in the received message is identified as an event. The state and the event are inputted in step 18 to a dispatcher 30, shown in Fig. 5. This comprises a table of routine identifiers addressable by the state and event coordinates. The routine retrieved in step 19 may be an action routine 32, or an error routine 33 if the event is disallowed. If an action routine 32, in step 20 it is executed to perform either a protocol implementation function such as to begin a MAP transaction with a user or cause the message to be passed on to the next part of the provider 1. The routine updates the memory with a new state and this is retrieved in step 21. If the state indicates that the transaction is complete, as indicated by step 22 the resources are released and the instance exits. If further messages are to be processed for the transaction, in step 24 the main section 11 monitors the socket until the next message is ready, upon which steps 16 to 22 are repeated.

The core 10 comprises three distinct state machines as shown in Fig. 6, namely, a dialogue handling state machine (DSM) 40, a requesting state machine (RSM) 41 and a performing state machine (PSM) 42. The DSM 40 receives all input events and executes the relevant action routines. If the event is a service invocation request or a service invocation response, it may result in the DSM 40 passing the event to either the RSM 41 or the PSM 42. In the embodiment illustrated, requests are received from the service users and passed to the network to be processed, whereas responses apply to operations received from the network and passed to the user to be performed.

If the action routine returns an error, the dispatcher then runs the accompanying error routine.

The following are the states for the DSM 20:idle state; incoming dialogue pending; incoming dialogue accepted; forward 2-way dialogue established; outgoing dialogue pending; outgoing dialogue initiated.

The RSM 21 has the following states :idle state; waiting for acknowledgement.

The PSM 22 has the following states :idle state; waiting for MAP-open response; waiting for response to operation.

Referring again to Fig. 3, the manner in which messages are handled is now described. As the provider 1 interacts with a mobile telecommunications signalling system, it must be capable of handling many transactions at one time - in the order of hundreds, for example. Accordingly, the passing of messages to and from the FSM 10 is a very important task. This is achieved primarily by use of the main section 11 in conjunction with the portable elements 13(b) and 14(b) of the lower and upper interfaces respectively. The control signal flows are indicated by the full-line arrows of Fig. 3, whereas the message flows are indicated by interrupted-line arrows.

The main section 11 establishes IPC sockets binding each user API 5 and the TCAP API 3 to the FSM 10. Once the sockets are established, it permanently listens and is ready to accept messages as they arise in an API.

The portable element 14(b) has routines which call routines in the MAP APIs 5 in response to a request from the core. This isolates the core from the environment as it simply makes the same requests irrespective of the portable element being used and the environment. Thus, the inner element 14(a) provides the necessary intelligence for interaction with the FSM 10, to for example, determine if an instance of the FSM 10 exists for the current message. The portable element 14(b) on the other hand is simpler and acts merely to pass messages back and forth without processing message data. The element 14(b) is termed portable because it is modular and provides compatibility with the particular MAP API 5, thus isolating the FSM 10. This results in very simple design and installation.

The lower interface 13 is constructed in the same general manner. The portable element 13(b) can call routines in the API 5 in response to requests from the core 10.

As indicated by the control signal arrows of Fig. 3, the main section 11 detects a message at a socket which has been established and calls an IPC routine in a portable element 13(b) or 14(b). This then directs transfer of the message to the inner element 13(a) or 14(a) as appropriate, which in turn interacts with the FSM 10.

The high traffic is handled because there is only a single IPC socket for each API, because they are permanently monitored by the main section 11, and because simple routines in the portable elements 13(b) and 14(b) control message transfer. Further, the inner elements 13(a) and 14(a) provide the necessary intelligence for interaction with the FSM 10. Additionally, the content or data parts of the messages are read only when they reach the inner elements and the FSM 10. Therefore, outside of the FSM 10 and the inner elements, the messages are all regarded as the same.

The inner elements 13(a) and 14(a) interact with the core by determining if an instance exists for a received message. This is achieved by referring to instance tables within the core. If an instance does not exist, the inner element activates an FSM routine to create a new instance. In this way, all new instances are created at the instigation of an inner element. This allows the possibility of monitoring this activity by reference to the inner elements .

It is the nature of a service provider environment that much more transaction requests originate on the signalling system side than on the user side. In order to avoid overload of the core 10, the lower interface inner element 13(a) maintains a count value of current instances and compares this value with a pre-set threshold. This provides an indicator of core activity at any point in time. Core overload is prevented by the inner element 13(a) automatically ending a signalling system transaction when the current instance count value equals the threshold. This prevents corruption of data and other faults which could be caused by overload, in a very simple manner.

The following sets out the different types of control signals passed between the various parts of the provider, and the APIs 3 and 5.

Bind/Unbind Request: A service user 4 must first bind to the core 10 by establishing a socket connection before it can send any other request or receive any messages from the core 10. A bind API function sets up an access point between the user and the core 10 using a bind table with an entry for each user 4 which has bound and necessary buffer resources allocated. An unbind API terminates the bind association and in so doing, it closes the interprocess communication connection to the socket.

MAP Main Service Requests/Responses: The API function is passed a message as a call argument. The message is encoded (for example into XDR) and is then sent over the bind connection or socket to the core 10.

MAP Specific Service Requests/Responses: The API function is passed a message as a call argument. The full message is encoded and is then sent over the bind connection to the core 10.

MAP Management Requests: Again, such a request is passed as a call argument in a message which is encoded and sent over the bind connection. The MAP API 5 also provides functions to receive the following types of indications/confirmations from the core 10. The receive API functions are used to receive the following.

MAP Main Service Indications/Confirmations: A MAP main service primitive is received as a message. The message is fully decoded into a local data structure and returned to the caller over the functional call interface.

MAP Specific Service Indications/Confirmations A MAP specific service primitive is also received in a message which contains the original ASN 1 encoded MAP data unit received over TCAP. This is an encoded message. The API function does not decode the MAP data unit, and thus the service user receives an ASN.l encoded data unit within the message.

MAP Management Indications/Confirmations: Management primitives are received as encoded messages. The API 5 decodes the message into a local data format and passes the local format to the user 4 over a functional call interface.

The core 10 is configured as a server in an IPC configuration file of the portable elements 13(b) and 14(b) to accept connections from the service users 4. The end-point reference of the new connection is used as the access-point reference. This end-point is set to nonblocking mode for two reasons. Firstly, it prevents the core 10 from blocking and secondly, it enables the upper interface 14 to detect congestion.

For message encoding/decoding, messages destined to a service user 4 are encoded and messages received from a user 4 are decoded into a local format before further handling. This is achieved by using an encoding/decoding technique such as XDR or ASN.l, both of which are well known in the art.

For handling messages from the core 10 to the user 4, a functional call interface is provided by the upper interface 14 for sending such messages. New incoming dialogues require special handling. The upper interface inner element 14(b) must select an appropriate user 4 (that has already bound to the core 10) for the dialogue. The upper interface 14 selects a user 4 that is configured for the requested application context and that has bound with the incoming dialogues parameter. In the case that more than one user 4 satisfies these criteria, the upper interface 14 uses a round robin algorithm to distribute such incoming dialogues .

For congestion control of outgoing messages to the user, in addition to the socket send buffers managed by the IPC components, the upper interface portable element 14(b) also provides its own buffers for queuing MAP service primitives. These buffers are used once the IPC interface indicates a would block error. Congestion is deemed to be onset when a certain percentage of the overflow buffers have been allocated to MAP user messages. As the IPC communication buffer is free, the overflow buffers will empty. As the number of allocated buffers drops below a threshold level, the interface to the MAP user is no longer deemed to be congested.

As stated above, the lower interface 13 provides an interface to the TCAP layer, namely the TCAP API 3 of the signalling system. On the upstream side, the lower interface receives TCAP primitives (messages) via the API 3 and each primitive received is translated into a DSM 20 event by the inner element 13(a). The inner element 13(a) and the core 10 then create a new finite state machine instance or, through the reference provided by the portable element 13(b) function call, retrieve an existing finite state machine instance. Both the finite state machine instance and the event structure are passed to the DSM dispatcher 30, shown in Fig. 5.

Regarding the utility section 12, this performs event management, trace management, process management, and statistics management functions.

The event management function is responsible for logging MAP-P events to an external event logging system acting in the role of a MAP management user. Events are classified as either informational, alarms, or exceptions.

Informational events provide information about routine or background events which are happening in the core 10 such as system start-up or configuration updates. An alarm event may indicate an overload. An exception event indicates internal software errors or any events which have an unexpected nature. Events are logged by sending a message to the external management system. Alarm events are assigned a minor, major or critical level.

There are two mechanisms for enabling the event logging function, the mechanism chosen depending on the external event handling system that is present. At process startup, the core 10 attempts to initialise the event logging API of the external event handling system. As each event handling system has its own API, a generic macro is defined for this initialisation function. If initialisation succeeds, posting of events is now active. If the initialisation fails, the core 10 does not regard this as an error - it continues without any event having been active. The second mechanism for enabling event logging is to be initialised by the receipt of an external request from a user.

The trace management function is responsible for diagnostic tracing in the core 10. It is possible to dynamically turn trace ON and OFF by issuing appropriate requests to the main section 11. Unix signals are used, if the platform is Unix-based.

The process management function is responsible for core 10 initialisation, process termination and process sanity checks. At process initialisation, the following actions are carried out :attempt to initialise event logging; initialise trace if appropriate; initialise IPC; read in a configuration file and pass the contents into RAM configuration tables; allocate buffer resources and initialise buffer pools; initialise statistic counters; initialise a timer module.

Process termination can occur as a result of an external management request or as a result of a critical error condition for which no recovery is possible. An example A termination shutdown or a shutdown, all of such a condition is a memory leak, request can either specify an immediate graceful shutdown. In an immediate existing dialogues are aborted. In a graceful shutdown, the core 10 will honour all existing dialogues but will abort new dialogues. During shutdown, the following action is taken:all dialogues are aborted; an alarm event is transmitted to an external event system; a notification is sent to an external event system; tracing is terminated; a configuration message is sent to an external process management system; IPC is terminated; and the process is exited.

The statistics management function is responsible for collection of measurements in the core 10. This can be started and halted dynamically and it reports the current settings of measurement counters when requested to do so by a management user. Statistic reports can also be sent asynchronously to a management user. The following four statistic counters are maintained within the core 10:general statistics; user statistics; TCAP event statistics; and resource statistics.

The statistics management function operates by generating periodic reports of the counter values and resetting the counters .

Regarding the main section 11 shown in Fig. 3, in addition to monitoring the IPC sockets, this provides a list utility, buffer pools, hash lists, ASN encoding/decoding, and timers. Referring to Fig. 7, the list utility provides a doubly linked list which consists of a head and a set of zero or more elements. The head points at the first and last element on the list, or to itself if there are no elements. The elements on the list point to the previous and next element on the list.

Referring to Fig. 8, a hash list 50 is illustrated. It comprises a complex list data type which uses a simple hashing algorithm to speed up the searching of items on a list. The data type is intended to better the results of the serial brute force search of a list by introducing a simple hash of the element used to order the list. The element is considered as an integer. The hash list shown in Fig. 8 consists of a hash list head which stores all information pertaining to the list. The hashing function uses the criteria to index into an array of normal linked lists .

The pool function of the main section 11 creates various buffer pools used within the core 10. This module also provides a number of routines to manipulate the elements in the pools. The following pools are created:user information pool? result pool; dialogue state machine pool; performing state machine pool; requesting state machine pool.

The user information buffer pool is used to store user information received from the user that is not yet ready to be sent to the network until another input event has arrived at the FSM. The result buffer pool is used to store partial buffers. The state machine pool holds state machine structures that are used to hold the private data for each of the active instances of the particular state machine. Each of the pools has functionality for initialising a pool, destroying a pool, retrieving a buffer from the pool and initialising any important value within the structure within the buffer, and returning a buffer to the pool for re-use. The DSM, RSM and PSM pools have ordering functions which will order the buffers or hash lists according to the criteria that suits the particular buffer. They also have searching routines that attempt to find a buffer stored on the list by the order function using whatever key is applicable to the buffer.

When the various pools are in use, they are collected in a dynamic structure that allows the core 10 to find the structure with a reference. Each entity that interfaces to the core 10 has a mechanism for passing references that are used to decide which thread of the FSM the incoming event is related to. A DSM buffer or structure is allocated or created for each new dialogue. Dialogues can be initiated with three different characteristics : a network initiated dialogue; a user initiated dialogue; a dialogues initiated as a direct result of one of the above methods that has a parent/child relationship with the original dialogue.

DSM structures are stored in various list structures or are stored as a child of another DSM structure. The location where the structure is stored depends on the initiation characteristic and the current state of operation of the entity whose information is stored within the DSM structure.

DSM structures created as a result of a dialogue initiation are placed on a lower or upper hash list. These elements are ordered by TCAP provider reference and user reference respectively. A third list, namely a main list, is used to store the DSM structures once the doublet (TCAP user reference, TCAP provider reference, or MAP user reference, MAP provider reference) has been completed. Once this doublet is filled in, every party has instant access to the relevant structure and the lists do not have to be searched. The main list is used as a holding list to ensure no dynamic resources are lost until the resource is returned to the buffer pool. Fig. 9 illustrates DSM lists and an allocation and disposal path and Fig. 10 illustrates DSM structures in a parent-child relationship. The parent DSM structure is connected to one of either the upper, lower or main lists. It then has links to the child structure. To reference the child structure, a doublet will contain the MAP provider reference of the parent and the MAP user reference of the child.

It will be appreciated that the invention provides for handling of large volumes of transactions in a very simple manner. It also provides portability across different APIs with little modification.

The invention is not limited to the embodiments described. For example, the communication channels established with the APIs may be monitored directly by the upper and lower interfaces. Further, the management functions could alternatively be carried out by the core 10 instead of by the utility section 12. The provider need not necessarily include the service user APIs and may interface between the signalling system and third party service user APIs.

Further, the upper interface inner element 14(a) may be programmed to prevent core overload in a manner similar to the lower interface inner element 13(a).

Claims (17)

1. A service provider for interaction with a telecommunication network signalling system, the service provider comprising:a core comprising means for processing messages; an upper interface for interaction with a service user via an external interface; and a lower interface for interaction with a signalling system via an external interface; wherein each interface comprises an inner element comprising means for initiating processing of messages by the core, and a modular portable element compatible with the external interface to which it is to be connected and comprising means for transferring messages without processing message data.

2. A service provider as claimed in claim 1, wherein each portable element comprises means for calling external interface routines in response to a request from the core.

3. A service provider as claimed in claim 1 or 2, wherein the service provider comprises means for establishing permanent communication channels with the external interfaces and for continuously monitoring the channels to detect message .

4. A service provider as claimed in claim 3, wherein the communication channels are inter-process communication sockets bound between the external interfaces and the core.

5. A service provider as claimed in claim 4, wherein the service provider comprises a main section comprising means for establishing the sockets with all external interfaces and continuously monitoring them to detect messages .

6. A service provider as claimed in claim 5, wherein the main section comprises means for activating an upper or lower interface portable element upon detection of a message, and the portable elements each comprise means for handling message transfer to the associated inner element when activated by the main section.

7. A service provider as claimed in any preceding claim, wherein the core comprises a finite state machine, each instance of which processes a single transaction involving one or more messages.

8. A service provider as claimed in claim 7, wherein the core comprises means for allocating a unique memory area at the start of a transaction for storage of a transaction state, and means for inputting data of a received message as an event into a dispatcher together with the current state to identify a transaction routine to be executed.

9. A service provider as claimed in claims 7 or 8, wherein the lower interface inner element comprises means for activating an FSM routine to create a new instance, if one does not already exist, for a message received from the signalling system.

10. A service provider as claimed in claim 9 wherein the lower interface inner element comprises means for maintaining a count value of current instances and comparing the count value with a pre-set threshold.

11. A service provider as claimed in claim 10, wherein the lower interface inner element comprises means for ending a signalling system transaction when the count value equals the pre-set threshold.

12. A service provider as claimed in any of claims 7 to 11 further comprising a utility section which comprises means for creating buffer pools within the core for storage of state machine memory structures.

13. A service provider as claimed in claim 12, wherein the core comprises a list routine for directing storage of list structures indicating relationships between instances of state machines.

14. A service provider as claimed in any preceding claim, wherein the core and the upper and lower interfaces comprise means for automatically calling a write function for logging of diagnostic tracing information during processing.

15. A service provider for interaction with a telecommunication network signalling system, the service provider comprising:a core comprising a finite state machine, each instance of which processes a single transaction involving one or more messages; a lower interface for interaction with a signalling system via an external interface, the lower interface comprising:t. - 26 an inner element having means for activating a finite state machine routine to create a new instance, if one does not already exist, for messages received from 5 the signalling system, and a modular portable element compatible with the external interface to which it is connected and comprising means for transferring messages without processing 10 message data and for calling external interface routines in response to a request from the core; and an upper interface for interaction with a service user via an external interface, the 15 upper interface comprising:an inner element having means for initiating processing of messages by the core, and a modular portable element compatible with 20 the external interface to which it is connected and comprising means for transferring messages without processing message data and for calling external interface routines in response to a request 25 from the core.

16. A service provider as claimed in claim 15, wherein the lower interface inner element comprises:means for maintaining a count value of current instances and comparing the count value with a 30 pre-set threshold, and - 27 means for ending a signalling system transaction when the count value equals the pre-set threshold.

17. A service provider substantially as described with 5 reference to and as illustrated in the drawings.