[go: up one dir, main page]

WO1997036439A1 - Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications - Google Patents

Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications Download PDF

Info

Publication number
WO1997036439A1
WO1997036439A1 PCT/IE1996/000014 IE9600014W WO9736439A1 WO 1997036439 A1 WO1997036439 A1 WO 1997036439A1 IE 9600014 W IE9600014 W IE 9600014W WO 9736439 A1 WO9736439 A1 WO 9736439A1
Authority
WO
WIPO (PCT)
Prior art keywords
service provider
core
interface
messages
signalling system
Prior art date
Application number
PCT/IE1996/000014
Other languages
English (en)
Inventor
Joseph Cunningham
Augustine Collins
Neillus O'shea
Original Assignee
Markport Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Markport Limited filed Critical Markport Limited
Priority to AU52863/96A priority Critical patent/AU5286396A/en
Priority to IE960257A priority patent/IES960257A2/en
Priority to PCT/IE1996/000014 priority patent/WO1997036439A1/fr
Publication of WO1997036439A1 publication Critical patent/WO1997036439A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q3/00—Selecting arrangements
    • H04Q3/0016—Arrangements providing connection between exchanges
    • H04Q3/0025—Provisions for signalling

Definitions

  • the invention relates to a service provider for interaction with the signalling system of a telecommunications network.
  • 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.
  • HLRs home location registers
  • MAP- User Mobile Application Part User
  • GSM Global System for Mobile communications
  • Another object is that the service provider is easy to upgrade.
  • 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 .
  • a service provider for interaction with a telecommunication network signalling system comprising:-
  • a core comprising means for processing messages
  • 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.
  • 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.
  • 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.
  • 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.
  • the main section comprises means for activating an upper or lower interface portable element upon detection of a message
  • the portable elements each comprise means for handling message transfer to the associated inner element when activated by the main section.
  • 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.
  • 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.
  • 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.
  • 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.
  • the lower interface inner element comprises, means for ending a signalling system transaction when the count value equals the pre-set threshold.
  • 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 .
  • the core comprises a list routine for directing storage of list structures indicating relationships between instances of state machines.
  • the core and the upper and lower interfaces comprise means for automatically calling a write function for logging of diagnostic tracing information during processing.
  • 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 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;
  • an upper interface for interaction with a service user via an external interface comprising:
  • an inner element having means for initiating processing of messages by the core
  • 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.
  • the lower interface inner element comprises:-
  • 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 G 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.
  • 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.
  • TCAP Transaction CAPability
  • the MAP-P 1 is also connected to a number of service users 4 by MAP APIs 5 which form part of the MAP- P 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 MAP- Users 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.
  • the MAP-P 1 comprises a core which is a finite state machine 10 and which performs protocol- implementation 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.
  • a lower interface 13 interfaces with the TCAP API 3, the latter not forming part of the MAP-P 1.
  • the MAP- P 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:-
  • 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.
  • 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.
  • IPC Inter-process communication
  • 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 data management
  • RSM requesting state machine
  • PSM performing state machine
  • 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.
  • 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 RSM 21 has the following states:-
  • the PSM 22 has the following states:-
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 non- blocking mode for two reasons. Firstly, it prevents the core 10 from blocking and secondly, it enables the upper interface 14 to detect congestion.
  • 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.
  • 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
  • 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.
  • the upper interface portable element 14(b) 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.
  • 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.
  • 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.
  • the core 10 attempts to initialise the event logging A PI 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:-
  • 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 of such a condition is a memory leak.
  • a termination request can either specify an immediate shutdown or a "graceful" shutdown. In an immediate shutdown, all existing dialogues are aborted. In a graceful shutdown, the core 10 will honor all existing dialogues but will abort new dialogues. During shutdown, the following action is taken:-
  • a configuration message is sent to an external process management system
  • 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:-
  • the statistics management function operates by generating periodic reports of the counter values and resetting the counters.
  • 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.
  • 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;
  • 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.
  • 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:-
  • 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
  • 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.
  • 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.
  • the communication channels established with the APIs may be monitored directly by the upper and lower interfaces.
  • 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.
  • 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Cette invention se rapporte à un fournisseur de services (1) qui comprend un noyau (10) d'automate fini (FSM), ce noyau étant isolé de l'environnement par des interfaces supérieure (14) et inférieure (13). Chaque interface possède un élément interne (13(a), 14(a)) qui entre en interaction avec le noyau (10), par exemple en créant une instance FSM pour une nouvelle transaction. Les interfaces comportent également des éléments portables (13(b), 14(b)) qui sont modulaires et compatibles avec l'interface externe particulière (API) et qui ne traitent pas de données de message.
PCT/IE1996/000014 1996-03-28 1996-03-28 Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications WO1997036439A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
AU52863/96A AU5286396A (en) 1996-03-28 1996-03-28 A service provider for interaction with a telecommunications network signalling system
IE960257A IES960257A2 (en) 1996-03-28 1996-03-28 A service provider for interaction with a¹telecommunications network signalling system
PCT/IE1996/000014 WO1997036439A1 (fr) 1996-03-28 1996-03-28 Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
IE960257A IES960257A2 (en) 1996-03-28 1996-03-28 A service provider for interaction with a¹telecommunications network signalling system
PCT/IE1996/000014 WO1997036439A1 (fr) 1996-03-28 1996-03-28 Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications

Publications (1)

Publication Number Publication Date
WO1997036439A1 true WO1997036439A1 (fr) 1997-10-02

Family

ID=26319907

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IE1996/000014 WO1997036439A1 (fr) 1996-03-28 1996-03-28 Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications

Country Status (2)

Country Link
IE (1) IES960257A2 (fr)
WO (1) WO1997036439A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999016272A1 (fr) * 1997-09-26 1999-04-01 Alcatel Usa Sourcing Lp Fournisseur d'applications et procede de communication
WO1999027727A1 (fr) * 1997-11-21 1999-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Interface d'interrogation entre systeme administratif client et elements de base de donnees d'un systeme de telecommunications
WO2002067602A1 (fr) * 2001-02-19 2002-08-29 Sensible Group Limited Systeme ameliore de messagerie base sur du texte

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992014329A1 (fr) * 1991-02-12 1992-08-20 Telenokia Oy Procede de transmission d'informations dans un reseau multiservice

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992014329A1 (fr) * 1991-02-12 1992-08-20 Telenokia Oy Procede de transmission d'informations dans un reseau multiservice

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
JANSSEN U ET AL: "The Mobile Application Part for GSM phase 2", MRC MOBILE RADIO CONFERENCE 1991, NICE, FRANCE, 13-15 NOV. 1991, 13 November 1991 (1991-11-13) - 15 November 1996 (1996-11-15), 1991, VALBONNE, FRANCE, SEE, FRANCE, pages 65 - 72, XP000444215 *
LI V O K ET AL: "PERSONAL COMMUNICATION SYSTEMS (PCS)", PROCEEDINGS OF THE IEEE, vol. 83, no. 9, 1 September 1995 (1995-09-01), pages 1210 - 1243, XP000526000 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999016272A1 (fr) * 1997-09-26 1999-04-01 Alcatel Usa Sourcing Lp Fournisseur d'applications et procede de communication
WO1999027727A1 (fr) * 1997-11-21 1999-06-03 Telefonaktiebolaget Lm Ericsson (Publ) Interface d'interrogation entre systeme administratif client et elements de base de donnees d'un systeme de telecommunications
US6134544A (en) * 1997-11-21 2000-10-17 Telefonaktiebolaget Lm Ericsson (Publ) Query supporting interface between a customer administrative system and database network elements in a telecommunications system
WO2002067602A1 (fr) * 2001-02-19 2002-08-29 Sensible Group Limited Systeme ameliore de messagerie base sur du texte

Also Published As

Publication number Publication date
IES68867B2 (en) 1996-07-24
IES960257A2 (en) 1996-07-24

Similar Documents

Publication Publication Date Title
JP3317405B2 (ja) プログラム可能なネットワーク・プロトコルと通信サービスを備えた電気通信スイッチ
JP3507510B2 (ja) 電話サービスフィーチャのやりとりを管理するシステムおよび方法
US5768352A (en) Generalized statistics engine for telephone network
US8014507B2 (en) Providing features to a subscriber in a telecommunications network
US7529269B1 (en) Communicating messages in a multiple communication protocol network
US7194078B2 (en) Network redirection control routing
JP2001521325A (ja) 高性能インテリジェント・ネットワーク・ゲートウェイ
US6847639B2 (en) Managing feature interaction among a plurality of independent feature servers in telecommunications servers
US6119173A (en) System and method for communications and process management in a distributed telecommunications switch
US5687223A (en) Method for acquiring statistics in a telephone network employing flexibly changeable rules
US7042995B1 (en) Providing features to a subscriber in a telecommunications network
WO1998032291A1 (fr) Reseau intelligent dote d'une fonction de commande de service repartie
WO1997036439A1 (fr) Fournisseur de services entrant en interaction avec un systeme de signalisation de reseau de telecommunications
EP0873029A1 (fr) Interface de point de commande de service
IE80765B1 (en) A service provider for interaction with a telecommunication network signalling system
US20020021774A1 (en) Dispatcher configurable linking of software elements
JP2002505045A (ja) サービス制御ポイント（ｓｃｐ）におけるオーバーロード防止
Marples et al. A Platform for Modelling Feature Interaction Detection and Resolution Techniques.
KR19990052903A (ko) 교환기에 있어서 지능망 호 추적방법
JP2025522131A (ja) 通信ネットワークデバイス、合法的傍受システム及び合法的傍受方法
KR0168939B1 (ko) 고도 지능망 서비스 교환기에서 서비스 상호작용 관리부와 감지점 처리부간의 인터페이스 방법
JP3564514B2 (ja) 分散不可視化方法
KR100277703B1 (ko) 지능형 정보제공 시스템에서의 그래픽 운용자 단말기에 대한 정합 방법
KR100617816B1 (ko) 지능망에서 호 제어 기능 블럭의 객체 지향 설계 방법
KR19980047753A (ko) 폴트의 수집 및 관리방법

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DE DK DK EE ES FI GB GE HU IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: JP

Ref document number: 97534196

Format of ref document f/p: F

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase