WO1998027785A1

WO1998027785A1 - Call reference handling

Info

Publication number: WO1998027785A1
Application number: PCT/SE1997/001991
Authority: WO
Inventors: Bo Bergström
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 1996-12-19
Filing date: 1997-11-27
Publication date: 1998-06-25
Also published as: AU5420998A; SE9604681D0; SE9604681L; SE515692C2

Abstract

The present invention discloses a method for handling a large amount of calls that executes messages in parallel by for each signalling channel creating a permanent static process where said permanent static process includes its own Call Reference table and for each new call creating at least one distinct new dynamic process with a unique Call Reference which communicate with other dynamic processes or with static processes and that when said call is finished all said dynamic processes are terminated.

Description

CALL REFERENCE HANDLING

TECHNICAL FIELD OF INVENTION

The present invention regards telecommunication in general and effective and secure call reference handling in particular.

DESCRIPTION OF RELATED ART

The recent development within telecommunications with increased tele^' and data traffic together with requirements on improved efficiency and reduced cost has put hard requirements on telecommunication equipment. The rapid development in the business also put forward requirements on quick, and secure, implementation of new features.

With the impending standardisation of B-ISDN (Broadband Integrated Services Digital Network) , new services will be offered by carriers and third party vendors. These services include for example high bandwidth multimedia applications, multipoint application and interactive applications. These new services and with the services associated protocols are switching, connection and signalling requirements which is substantially more complex than today's requirements.

To be able to deal with these requirements as well as to be able to support a vast number of increasingly complex protocols the telecommunication industry needs supportive design tools and methods .

EP 0 631 456 discloses a distributed, server-based communications network architecture. In the architecture is various traditional call processing functions separated into distinct application processes .

SUMMARY OF THE INVENTION The present invention discloses a method, a node and a network on how to handle, in a secure and fast way, a large amount of calls that execute messages in parallel.

The purpose of the present invention is thus to effectively and easily^' handle a large amount of calls in a node in a network.

The problem, described above, regarding how to handle a large amount of calls that executes messages in parallel is addressed by for each signalling channel creating a permanent static process where said permanent static process includes its own Call Reference table and for each new call creating at least one distinct new dynamic process with a unique Call Reference which communicate with other dynamic processes or with static processes and that when said call is finished all said dynamic processes is terminated.

The advantages with the present invention is that a large number of calls and messages can be handled simultaneously.

Another advantage is that the software is easily maintainable.

Another advantage is that call data is isolated.

Yet another advantage is that a smaller and more maintainable Call Reference table is accomplished.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a process layout of a preferred embodiment.

Figure 2 shows a signal diagram for configuring a PUA process.

Figure 3 shows a signal diagram for unconfiguring a PUA process.

Figure 4 shows a process layout of another traffic situation.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS A process is a computer program including data which executes in its own environment with its own stack. When a process terminates the memory which was associated with said process is completely cleared.

In this description processes comes in two flavours, dynamic processes which is created by other processes and will only live throughout its predetermined task execution, e.g. processes representing a call will only exist through the duration of the call. The other flavour is the static processes which will exist over a longer time and will create or serve the dynamic processes. The static processes will only be terminated in case of a major fault.

The messages names used herein can be regarded as a sort of meta messages. They do not match messages specified in the ITU-T Q.2931 B-ISDN Specification although some of the messages herein corresponds to messages in Q.2931 while other messages are invented only for sake of clarity.

In the following description a message is used as meaning receiving and treating information in broad terms. It can be reception and treatment of a standardised Q.2931 message as well as a internal function call.

PERMANENT USER ACCESS

In figure 1 is a first static PUA (Permanent User Access) process denoted 101. A static PUA process 101 is created for each signalling link. The PUA process 101 interacts with a dynamic UA

(User Access) process 102 and the logical node SAAL (Signalling

ATM Adaption Layer) 103 performing signalling link handling. A PUA process 101 is created via a start function which is called from the PUA_SERVER 104. In the initialisation phase the PUA process 101 configure the link against the SAAL 103.

When PUA_SERVER 104 wants to delete the link it sends a kill message to the PUA process 101. The PUA process 101 will then directly execute the shutdown function which will delete the SAAL link 103 and exit.

There exists one permanent PUA process 101 per signalling link.

The PUA process 101 will keep two lists, CRNetList and CRUserList, with the elements CR (Call Reference) and UAPid (User Access Process identity) .

The first list, CRNetlist, contains call references owned by the network and the second list, CRUserList, contains call references owned by the user.

When a message arrives to a PUA process 101 it must pass the following checks:

• Protocol discriminator error - If a message is received with a protocol discriminator coded other than Q.2931 user-network call control message, that message shall be ignored. "Ignore" means to do nothing as if the message had never been received. The only allowed value of the protocol discriminator is 0000 1001' .

• Message too short - When a message is received that is too short to contain a complete Message length IE, that message shall be ignored. A message is too short if it is less than 9 octets .

• Call reference error - If the Call Reference information element octet 1, bits 5 through 8 do not equal 0000' , then the message shall be ignored. If the Call Reference information element octet 1, bits 1 through 4 indicate a length other than 3 octets, then the message shall be ignored.

• Dummy Call Reference - If a message is received containing the dummy call reference (all bits of the call reference is set to

1) , the message shall be ignored.

• Global Call Reference - If a message with a global call reference is received the following action must be taken:

1) If the call reference flag = 0, the message shall be sent to the Reset-Respond-N process. Necessary checks are made in the Reset-Respond-N process.

2) If the call reference flag = 1, the message shall be sent to the Reset-Start-N process. Necessary checks are made in the Reset-Start-N process

PERMANENT USER ACCESS SERVER

The PUA_SERVER process 104 is a permanent process which supervises all the PUA processes 101. The PUA_SERVER process 104 is also an interface to services for configuration and deletion of a SVC (SAAL) .

The PUA_SERVER process 104 also supports the UA processes 102 with data.

While referring to figure 2 the following flow describes how the PUA process is configured.

• A request is made from the operator to create a SVC. The message CREATE_SVC 201 is sent from Services 108, said message

201 includes necessary data as for example Subscriber Number and VCI. Services 108 waits for an ACK (ACKNOWLEDGEMENT) message on the outcome of the order. • The PUA_SERVER 104 sends a START message 202 to start a PUA process 101. The PUA_SERVER process 104 waits for an acknowledgement from the PUA process 101, i.e. if the signalling link was configured or not, and if the PUA process 101 could be created.

• A CONFIG_LINK message 203 to SAAL 103 is sent to order SAAL 103 to configure a link. The result of the configuration is sent back in an ACK message 204. If the result of the configuration is OK, the PUA 101 PID is sent back to the PUA_SERVER process 104 in a ACK message 205. If the result of the configuration in SAAL 103 did not went well, then said PUA process 101 will terminate with exit (normal) .

• If the result of the configuration is OK, the PUA 101 pid and the Subscriber Number for said SVC will be stored in two lists "SubKeyList" and "PuaKeyList" in the PUA_SERVER process 104, and an ACK message 206 is sent to Services 108 to indicate the fact that the signalling link was successfully configured.

While referring to figure 3 the following flow describes how the PUA process is deleted.

• A request is made from the operator to the Services 108 to delete a SVC. It is assumed that this request only can be performed when all resources connected to the subscriber are marked as free, i.e. no calls exist to nor from this subscriber. A DELETE_SVC message 301 is sent from Services 108 to the PUA_SERVER process 104. Said DELETE_SVC message 301 includes necessary data such as for instance Subscriber Number. Services waits for acknowledgement on the outcome of the order.

• The PUA 101 PID, corresponding to the Subscriber Number is found in the PUA_SERVER process 104 data "SubKeyList" . The

PUA_SERVER 104 will send an UNCONFIGURE message 302 to SAAL 103 and also a KILL message 303 to the PUA process 101 connected to SAAL 103. The PUA 101 data will also be deleted from "SubKeyList" and "PuaKeyList" in PUA_SERVER 104.

• Said PUA process 101 will terminate and send an EXIT message 304 to said PUA_SERVER process 104. The data in said "PuaKeyList" and "SubKeyList" in the PUA_SERVER process 104 corresponding to the deleted PUA process 101 will be erased. When the PUA_SERVER process 104 receives an EXIT message said PUA_SERVER process 104 will look in the "PuaKeyList" to see if the PID exists. If the PUA process 101 PID exists said PUA process 101 will be restarted.

• When the signalling link in SAAL 103 is unconfigured and confirmed, with an ACK message 305 and the PUA process 101 is terminated the PUA_SERVER process 104 will send an ACK message 306 to the Services 108.

USER ACCESS

The UA process 102 is a dynamic process, only "alive" during a call.

It shall be noticed that the UA process might be implemented as a state-machine. If the UA process is implemented as a state- machine the states can be implemented according to Q.2931.

The UA process 102 is responsible for:

• Receiving incoming DSS2 (Digital Subscriber Signalling System No. 2 ) messages, outgoing HCP (Half Call Protocol) messages and timer expiration. • Check that a received message is received in an allowed state.

• Check if the content of incoming DSS2 messages is correct.

• Convert incoming DSS2 messages to HCP messages and pass them on to USOrig and USTerm

• Convert outgoing HCP messages to DSS2 messages and pass them on to the PUA process. • Start Timers .

• Stop Timers .

• Perform appropriate state transitions.

The UA process 102 is started from PUA 101 or USTerm 106.

The UA process 102 can exit normally due to:

• RELEASE COMPLETE is received from USOrig 105 or US Term 106. The process will send RELEASE COMPLETE to PUA 101 and then exit .

• RELEASE COMPLETE is received from the PUA 101. The process will send RELEASE COMPLETE to USOrig 105 and then exit.

• RELEASE COMPLETE/ RELEASE is received unexpectedly.

The process can exit abnormally due to:

• Unexpected message from USOrig 105 or USTerm 106.

USER SERVICE ORIGINATING

The USOrig process 105 extracts relevant parameters from incoming messages and requests the following checks and analysis from Services :

• BCOB-subscription check

• Subscriber-blocking check • CPNV

• B-number analysis

• Routing analysis

• Reservation of resources (via CM)

The process also changes parameters, initiates the terminating Half-Call and creates the CM-process. The USOrig process 105 is dynamic.

In the preferred embodiment the USOrig process 105 is started by the UA process 102, which also links itself to USOrig 105. There is one USOrig process 105 for each originating call. After receiving a release-message from the originating or terminating side the USOrig process 105 orders disconnection and resource releasing and then exits.

USER SERVICE TERMINATING

The USTerm process 106 extracts relevant parameters from incoming messages and requests the following checks and analysis from Services :

• BCOB-subscription check • Subscriber-blocking check

• CLIP-subscription check

• SUB-subscription check

• Reservation of resources (via CM)

The USTerm process 106 also adds information in IE:s and creates a UA process 107. The USTerm process 106 is dynamic.

The USTerm 106 process is started by the originating Half-Call, which also links itself to USTerm 106. There is one USTerm 106 process for each terminating call. After receiving a release- message from the originating or terminating side the USTerm process 106 orders disconnection and resource releasing and then terminates .

In figure 4 a PUA_SERVER is denoted 401. A first PUA process is called 402 and said PUA process has two UA processes associated 405 and 406. Both of these UA processes 405 and 406 represents an originating call which can be seen by the connection to the two US_Orig processes 410 and 411. The UA processes have thus been created by the PUA process 402 on order from the USER 415. Each of the UA processes has a unique CR. The different CR for the different UA processes 405 and 406 has been taken from the CRUserList in the PUA process 402. The PUA process 402 holds a list associating the CR value with the corresponding UA process 405, 406 identity. A second PUA process 403 also comprises a CRUserList which has been used to get a CR for the UA process 408. The UA process 408 has thus been created by the PUA process 403 on order from the USER 416 and the UA process 408 represents an originating call. The CR value for the UA process 408 can be the same as the CR value for any of the UA processes 405 or 406 since they relate to different PUA processes. However the CR value for the UA processes 405 and 406 can never be the same. The UA processes 407 and 409 have been created by the US_Term processes 412 and 414. The CR values used for these UA processes 407 and 407 have been chosen by the network and is transfered to the PUA process 403 and stored in the CRNetList. The UA processes 407 and 409 are representing terminating calls. Also in figure 4 is SAAL denoted with 404.

The invention being thus described, it will be obvious that the same may be varied in many ways . Such variations are not to be regarded as a departure from the spirit and scope of the invention, and all such modifications as would be obvious to one skilled in the art are intended to be included within the scope of the following claims.

Claims

1. Method for handling a large number of calls and connections in a node where said node being a part of an integrated data and telecommunication -network, CHARACTERISED in that for each signalling link one permanent, static PUA process is created, that said PUA process comprises a Call Reference table, that for each new call attempt at least a first dynamic UA process is created, and that said UA process is assigned one unique Call Reference value from said Call Reference table.

2. Method according to claim 1, CHARACTERISED in that said first dynamic UA process is connected to at least said PUA process where said PUA process is connected to one signalling link, that at least one dynamic USOrig process is created, that said first dynamic UA process is connected to said dynamic USOrig process, and that all dynamic processes is ended when said call is completed.

3. Method according to claim 2, CHARACTERISED in that, in dependence of if said call is terminated in said node,- a second dynamic UA process and at least one dynamic USTerm process is created, that said second dynamic UA process is connected to said dynamic USTerm process, that said second dynamic UA process is connected to at least a second static PUA process, and that said second static PUA process is connected to a second signalling link.

4. Method according to claim 2, CHARACTERISED in that said first PUA process receives messages on said signalling link, that said PUA process performs checks on said messages, and in dependence of the result of said checks forwards said messages to said first UA process.

5. Method according to claim 3, CHARACTERISED in that said second PUA process receives messages on said second signalling link, that said second PUA process performs checks on said messages from said signalling link, and in dependence of the result of said checks forwards said messages to said second UA process.

6. Method according to claim 2, CHARACTERISED in that said PUA process receives messages from said first UA process, and that said PUA process forwards said message to said signalling link.

7. Method according to claim 3, CHARACTERISED in that said second PUA process receives messages from said second UA process, and that said second PUA process forwards said message to said signalling link.

8. Method according to claim 4 or 5, CHARACTERISED in that in dependence of if a message is received with a protocol discrimination error, if a too short message is received, if a message is received with a call reference error or if a message is received with a^{' '} dummy call reference, said checks results in that said message is ignored.

9. Method according to claim 1, CHARACTERISED in that all PUA processes are connected to a static PUA server process.

10.Method according to claim 1, CHARACTERISED in that said UA process comprises a state machine according to Q.2931, that said UA process receives incoming DSS2 messages and outgoing HCP messages, that said UA process performs checks on said messages, that said UA process converts allowed incoming DSS2 messages to HCP messages and forwards said messages to a USOrig process or a USTerm process, that said UA process converts allowed HCP messages to DSS2 messages and forwards said messages to said PUA process.

11.Method according to claim 1, CHARACTERISED in that said network is a B-ISDN network.

12.A node in an integrated data and telecommunication network, CHARACTERISED in that said node comprises at least one signalling link, and at least one permanent, static PUA process associated with said signalling link, that said PUA process comprises a Call Reference table, that said PUA process comprises means for creating at least one dynamic UA process for each new call attempt, and that said PUA process comprises means for assigning one unique Call Reference value from said Call Reference table to said UA process.

13.An integrated data and telecommunication network, CHARACTERISED in that said network comprises at least on node, that said node comprises at least one signalling link, and at least one permanent, static PUA process associated with said signalling link, that said PUA process comprises a Call Reference table, that said PUA process comprises means for creating at least one dynamic UA process for each new call attempt, and that said PUA process comprises means for assigning one unique Call Reference value from said Call Reference table to said UA process.