IE970240A1 - A service user for a mobile telecommunications system - Google Patents

Abstract

A service user such as a MAP-User (1) has a core (10) which is isolated from low-level signalling and protocols of external entities such as a database server and an authentication centre. The core (10) interfaces with such external entities via signal interfaces (17,19,21) and handlers (18, 20,22). The core (10) also interfaces with a MAP-Provider (4) which connects it to a signalling system. This connection is via an API. The core (10) has a distributor (11) which creates a finite state machine instance when a transaction begins. Responder instances (13) receive requests from the signalling system and initiator instances (14) transmits signals to the signalling system. A threshold controller instance (12) monitors the general state. <Fig. 3>.

Description

A service user for a mobile telecommunications system The invention relates to a service user, often referred to in the standards as a Mobile Application Part-User (MAPUser) for a mobile telecommunications system. In such a system, the MAP-User is the equivalent of an application program in a data processing system in that it provides the top-level processing for a particular function. More often than not, it will interact with a signalling system of a mobile system via a MAP-Provider and a signalling system stack. It may, for example, form part of a network access processor (NAP) of a home location register (HLR). However, the applications are many and it may perform short message service centre (SMSC), visitor location register (VLR), or authentication centre (AuC) processing.

Heretofore, MAP-Users have been implemented as integrated code within a larger system, for example, a HLR as described in WO 95/28812 (L. M. Ericsson). While such a MAP-User generally operates quite effectively, they sometimes suffer from the problems of being difficult to modify or upgrade, and secondly there is a long lead time in development.

It is therefore an object of the invention to provide a MAP-User which is of simpler construction than heretofore, may be more easily modified or upgraded, and which has a relatively short development time.

According to the invention, there is provided a service user for a mobile telecommunications system, the service user comprising:a core comprising means for processing transaction messages; and a plurality of handlers connected to the core for communication with external entities.

This allows the service user to be easily and quickly modified for use in different applications. Provision of short lead times is an extremely important aspect for development in this technology.

In one embodiment, the service user further comprises a signal interface connected between the core and each handler.

Preferably, said handlers include an API comprising means for connecting the core to a service provider which is in turn connected to a signalling system.

In one embodiment, the service user further comprises a management handler connected to the core for communication with a management system entity of the system, and preferably also comprises a database handler for connecting the core to a database system, and preferably further comprises an authentication centre handler for connecting the core to an authentication centre entity.

In another embodiment, the user comprises means for creating Inter-Process Communication binding the core to the handlers during operation of the service user.

Ideally, the core comprises means for creating a finite state machine instance for each transaction.

Preferably, the core comprises a finite state machine distributor instance which remains active throughout operation of the service user and comprises means for initiating a transaction. In one embodiment, the distributor comprises means for activating a responder instance for receiving signals from a signalling system, and an initiator instance comprising means for transmitting signals to the signalling system.

In a further embodiment, the service user further comprises a threshold controller finite state machine instance which is created at start-up and remains active during operation of the service user and which comprises means for monitoring operation of the core.

In another embodiment, the distributor, the initiators, and the responders comprise means for updating the threshold controller with status information indicating operation of the core.

Preferably, the management handler comprises means for start-up and shut-down of the database and authentication centre handlers.

Ideally, the management handler comprises means for connecting and disconnecting the core from a service provider external entity.

Preferably, the management handler comprises means for initialisation and on-line configuration of the service user global parameters.

The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only, with reference to the accompanying drawings, in which:Fig. 1 is a diagrammatic representation of a service user of the invention and the environment in which it is connected; Fig. 2 is a diagram illustrating construction of the service user; and Fig. 3 is a more detailed diagram illustrating construction of the service user.

Referring to Fig. 1, a service user hereinafter referred to as a MAP-User 1 is shown in a GSM environment. The GSM system comprises an SS7 signalling system 2 connected to various system entities including a VLR, an MSC and an SMSC. The system comprises an SS7 stack 3 which interfaces between the signalling system 2 and a MAPProvider 4. The MAP-User 1 is connected to the MAPProvider 4 and comprises a database 5. The MAP-User 1 is connected to user systems including an AuC 7 and a management system 6.

This configuration is given for illustration purposes as the MAP-User of the invention may be connected in a variety of different contexts, including providing some of the core control programs for a HLR.

Referring now to Fig. 2, construction of the MAP-User 1 is shown at a high level. The MAP-User 1 comprises a core 10 connected on one side via a MAP-Provider signal interface 15 and a MAP-Provider API 16 to the MAP-Provider 4. On the other side, the core 10 is connected via a management signal interface 21 to a management handler 22, via a database signal interface 19 with a database handler 20, and via an AUC signal interface 17 with an AuC handler 18. The handlers 18, 20 and 22 are connected to an AuC system, a database system, and a management system, respectively.

An important aspect of the invention is the fact that the functions are separated in this manner. This achieves a high level of modularity and provides for ease of modification and also efficiency and reliability in operation. The core 10 does not store data or code relating to operation of the external entities - it simply interacts with the handlers so that operation of the external entities is transparent to it.

In more detail and referring to Fig. 3, construction of the core 10 is illustrated. The core 10 comprises a distributor 11, a threshold handler 12, a plurality of responders 13, and a plurality of initiators 14.

The core 10 operates according to a finite state machine mechanism, whereby there is one instance of the finite state machine (FSM) for each transaction. The distributor 11 manages creation of an instance, whereas the threshold controller 12 manages the operational state of the core 10 and reports events regarding thresholds to the management handler 22. The responders 13 handle requests from the network, while the initiators 14 issue requests to the network.

The distributor 11 is effectively the manager of the other handlers within the core 10 and it is an FSM instance which is created on start-up and remains in place throughout operation of the core 10. The distributor in effect creates the responder and initiator instances when a particular signal is received. For example, when the distributor 11 receives a request from the MAP-Provider, it creates an instance of a responder 13, which in turn sends a response to the MAP-Provider. All subsequent messages from the MAP-Provider 4 are then directed to that responder 13. The instances are implemented by SDL code routines . - 6 Operations initiated by the management handler 22 cause the creation of an initiator 14, which issues requests to the network.

As stated above, once a responder or initiator 13 or 14 is created, it is responsible for a whole transaction or dialogue. They are programmed to receive, process, lock or shut down signals at any waiting state. A responder 13 can invoke one of the following routines or macros :NetworkLocUpd - handles location updating and data restoration operations; LocInfoRetrieval - handles requests for location information; ImsiRetrieval - handles IMSI lookup; InfoRetrieval - handles requests for authentication/subscriber details; VLRReset - handles receipt of resets from a VLR; NetworkFunctionalSs- handles receipt of signalling system (SS) operations; NetworkUnstructuredSs- handles receipt of unstructured SS operations; ShortMsgGateway - handles SMS routing requests; MwdMgt - handles requests for message waiting data operations .

The initiator 14 is programmed to invoke one of the following routines or macros:IE 970240 LocationCancellation - handles issuing of cancel Locations; HLRReset - handles the issuing of resets to VLRs at startup; SubscriberDataMngt - handles issuing of standalone ISDs/DSDs; SubTracing - handles issuing of standalone tracing activation/deactivation; ShortMsgAlert- handles issuing of SMS alerts.

Like the distributor 11, there is only one instance of the threshold controller 12 and this is created at start up. The threshold controller 12 keeps track of the number of transactions or dialogues and each time one is created or halts, an appropriate signal is sent to the threshold controller 22. If there are too many the dialogue is not allowed to be started.

Regarding the MAP-Provider signal interface 15, this operates to mark routines for receiving incoming messages with either ind or cnf, representing an indication (received request) or a confirmation (received response) respectively. Conversely, routines for sending outgoing messages are postfixed with either req. or rsp., representing request or response respectively. A system services function 23 handles the IPC sockets and ensures that they are not blocked.

Regarding operation of the management handler 22, the implementation is dependent on the management entity but it is capable of interfacing with the core 10 using a - 8 protocol defined by the management signal interface 21. The management handler 22 provides the following functionality:Startup and shutdown of Database and AuC Handlers and of Core MAP User; Connection to and disconnection from the MAP Provider; Initialisation and on-line configuration of parameters global to the whole of the service user (e.g. transactions limits, debugging flags, etc.); Statistics reporting; Forwarding of alarms/events to Management Entity.

The signal interface 21 is defined using SDT signals and all signals sent by the handler 22 to the core 10 are handled by the distributor.

The database handler 20 provides the core 10 and the other external handlers 18 and 22 with a means to access the database 5 shown in Fig. 1. The implementation is dependent on the nature of the database 5, but it must be capable of interfacing with the core 10 using the protocol defined in the database signal interface 19. An important aspect is the fact that the core 10 does not make specific decisions regarding locking of objects in the database 5 it will simply request whatever data it needs for a particular operation. Accordingly, the core 10 is separated from the low-level database operations.

Due to the size of some of the objects retrieved from the database (using db_access, the average subscriber occupies - 9 about 2K), it would be expensive to pass these structures in SDL signals. This is because when the core receives a DB_DATA signal from the database handler, its contents would generally be copied to a local variable (in order that it can be accessed for the remainder of the process, even though the signal is freed upon completion of the immediate transition). Therefore the DB_DATA signal contains a pointer to an area of memory containing the information. This memory is maintained by the database handler. The core may access this as it pleases (but not change it). When the core has finished with the memory, it uses the DB_FINISH signal to indicate this to the database handler. In order to implement this, the database handler creates a separate process to handle each database request. This new process declares a local variable which will hold the retrieved data. It is the address of this local variable which is passed to the Core MAP User in the DB_DATA signal.

Regarding the AuC handler 18, this provides the core 10 with the ability to request authentication triplets from an authentication centre. The core 10 will request a set of five triplets each time it receives an authentication request.

It will thus be appreciated that the invention provides a service user which is configured largely independently of external entities at a low level. The handlers and signal interfaces isolate the core from the external entity lowlevel operation. Thus, the MAP-User may be easily ported and quickly re-configured for different uses or for similar uses interacting with different external entities. For example, if the MAP-User is to be changed for use with a different AuC entity, it is only necessary to modify the AuC handler 18. - 10 The invention is not limited to the embodiments hereinbefore described, but may be varied within the scope of the claims in construction and detail.

Claims (16)

1. A service user for a mobile telecommunications system, the service user comprising:a core comprising means for processing transaction messages; and a plurality of handlers connected to the core for communication with external entities.

2. A service user as claimed in claim 1, further comprising a signal interface connected between the core and each handler.

3. A service user as claimed in claim 1 or 2, wherein said handlers include an API comprising means for connecting the core to a service provider which is in turn connected to a signalling system.

4. A service user as claimed in any preceding claim comprising a management handler connected to the core for communication with a management system entity of the system.

5. A service user as claimed in any preceding claim, comprising a database handler for connecting the core to a database system.

6. A service user as claimed in any preceding claim, comprising an authentication centre handler for connecting the core to an authentication centre entity.

7. A service user as claimed in any preceding claim, comprising means for creating Inter-Process - 12 Communication binding the core to the handlers during operation of the service user.

8. A service user as claimed in any preceding claim, wherein the core comprises means for creating a finite state machine instance for each transaction.

9. A service user as claimed in claim 8, wherein the core comprises a finite state machine distributor instance which remains active throughout operation of the service user and comprises means for initiating a transaction.

10. A service user as claimed in claim 9, wherein the distributor comprises means for activating a responder instance for receiving signals from a signalling system, and an initiator instance comprising means for transmitting signals to the signalling system.

11. A service user as claimed in claim 10, further comprising a threshold controller finite state machine instance which is created at start-up and remains active during operation of the service user and which comprises means for monitoring operation of the core.

12. A service user as claimed in claim 11, wherein the distributor, the initiators, and the responders comprise means for updating the threshold controller with status information indicating operation of the core.

13. A service user as claimed in any of claims 4 to 12, wherein the management handler comprises means for - 13 start-up and shut-down of the database and authentication centre handlers.

14. A service user as claimed in claim 13, wherein the management handler comprises means for connecting and disconnecting the core from a service provider external entity.

15. A service user as claimed in claims 13 or 14, wherein the management handler comprises means for initialisation and on-line configuration of the service user global parameters.

16. A service user substantially as hereinbefore described with reference to and as illustrated in the accompanying drawings .