WO1998027786A1

WO1998027786A1 - Protocol restart

Info

Publication number: WO1998027786A1
Application number: PCT/SE1997/002140
Authority: WO
Inventors: Ulf Richard Wennman; Johan Harald Appelbom
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 1996-12-19
Filing date: 1997-12-17
Publication date: 1998-06-25
Also published as: SE9604680D0; SE511946C2; AU5503798A; SE9604680L

Abstract

A first static process related to a signalling link receives a restart message from a user. Said static process will create at least a first dynamic process and forward the restart message to said first dynamic process. Said dynamic process will send a restart message to all dynamic processes related to said first static process in parallel. The dynamic processes which are involved in the restart will release their associated resources and send a message to said first dynamic process indicating the fact. The dynamic processes not involved in the restart will send a message to said first dynamic process indicating this.

Description

PROTOCOL RESTART

TECHNICAL FIELD OF INVENTION

The present invention regards telecommunication in general and effective and secure restart 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 equiptment . The rapid development in the business also puts 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 are substantially more complex than today's requirements.

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

The Problem Area

The ITU-T Q.2931 B-ISDN requirements shortly means that the network or the subscriber have the possibility to originate

(initiate) a new half-call (connection) between the network and the user. This is done via a signalling channel between the subscriber and the network. Two half-calls can connect two subscribers to each other. This will be a local call. The half- call is the logical view of the physical resource (connection) to the subscriber.

When some of the interfaces (The network or the subscriber) do not respond to call control messages a RESTART procedure is usually invoked. This means that either the user or the network has the possibility to reset (delete) the call/connection. The message that will perform this is called RESTART. Restart is the last resort to reset a call which has a failure.

The following points summarize some of the requirements in this area .

• In the case that both sides of the interface initiate simultaneous RESTART requests they shall be handled independently . • It shall be possible to receive a RESTART on subscriber, VP or VC level. This means that a RESTART message might have to reset hundreds of connections at a time.

• The RESTART should not impact on call connect/disconnect times . • In the case when some VP channels are specified, they shall not be considered free for reuse until all the relevant RESTART procedures are completed.

• It shall not be possible to set-up new calls during the RESTART procedure on the concerned resources.

A problem with Protocol Restart is that it is very unspecified in the ITU-T Q.2931 specifications.

Another problem has also been the bad performance on the known ATM switches which concerns the time to disconnect a call. EP 0 631 456 disclose a distributed, server-based communications network architecture. In the architecture is various traditional call processing functions separated into distinct application entities .

SUMMARY OF THE INVENTION

The present invention discloses a method, a node and a network to be able to handle restart in an integrated data and telecommunication network in an efficient and secure way.

The purpose of the present invention is thus to describe a method and apparatus for handling a restart in an integrated data and telecommunication network in a secure and efficient way.

The problem, described above, regarding how to achive a secure and efficient restart handling is solved by for each signalling link which have received a restart message creating a dynamic process and that said dynamic process sends a message in parallell to all processes related to said signalling link.

In .more detail will a first static process related to a signalling link receive a restart message from a user. Said static process will create at least a first dynamic process and forward the restart message to said first dynamic process. Said dynamic process will send a restart message to all dynamic processes related to said first static process in parallel. The dynamic processes which are involved in the restart will release their associated resources and send a message to said first dynamic process indicating the fact. The dynamic processes not involved in the restart will send a message to said first dynamic process indicating this.

An advantage with the present invention is that a secure and fast restart is achieved. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows a process allocation of a user initiated restart of a preferred embodiment.

^• Figure 2 shows a message flow of a user initiated restart.

Figure 3 shows a different case of events of a message flow of a user initiated restart.

Figure 4 shows a process allocation of a network initiated restart of a preferred embodiment.

Figure 5 shows a message flow of a network initiated restart.

Figure 6 shows a different case of events of a message flow of a network initiated restart.

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 come in two flavours, dynamic processes which are created by other processes and will only live throughout their 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 Q.2931 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.

The present invention will now be disclosed in a preferred embodiment while referring to figure 1 to figure 6.

The following terminology is repeated here for sake of clarity.

• VP - Virtual Path, is a type of connection within ATM.

• VC - Virtual Channel is a type of connection within ATM.

• PUA - Permanent User Access, is the static process within the BISDN application corresponding to a subscriber.

• UA - User Access is a dynamic process in the BISDN application modelling the state machine functionality within ITU-T,

Q.2931.

• ^■ LN Services - is a service node which have all services for the BISDN application. The database, connection handling etc.

• OMGR - Object Manager is the management interface for the operator of the switch.

The restart functionality implements the treatment of all DSS2 (Digital Subscriber Signalling System No. 2 ) messages with global call reference. This includes RESTART, RESTART ACKNOWLEDGE and STATUS .

To be able to handle RESTART collision (i.e. when user and network issue a restart request simultaneously) , a PUA process 101 creates two independent dynamic processes: • one for restart requests received from the user. The process is referred to as RR (Reset-Respond) 102 in figure 1. The RR process 102 will take care of all messages with global call reference and call reference flag = 0.

• one for restart requests issued by the network. The process is referred to as RS (Reset-Start) 103 in figure 1. The RS process also needs a queue for network initiated restart requests, since the DSS2 protocol does not allow overlapping restart procedures in the same direction. The RS process will take care of all messages with global call reference and call reference flag = 1.

When a message arrives to the RR process 102, it shall check what type of message that was received.

RESET RESPOND

The RR process 102 includes a first list, Affectedlist 104. Said list 104 keeps track of all the UAPid (User Access Process Identities) to the half calls that are concerned about the restart. The UAPid is mapped together with the affected resource.

Said RR process 102 also includes a second and a third list, CRUserList 105 and CRNetlist 106. They are used to keep track of whether all calls have responded back or not. Every time the RR process 102 receives a message with response from the UA the UAPid is deleted in both lists. When both lists are empty the Restart is continued.

RESET START

The RS process 103 handles restart from the network to a user. The allowed messages is RESTART_ACK and STATUS, but other messages may also appear. The RS process 103 is created when the network wants to perform restart against the user. There are two times when the network initiate restart:

1. When a half-call calls the method restart_request in PUA 101. (Vc restart)

2. When PUA 101 have been in state connection_released and is coming up again. (SVC restart)

The PUA process 101 will gateway all messages with global call reference and call reference flag =1 to the RS process 103. If there is no RS process created, the RS process will be created first.

USER INITIATED RESTART

While refering to figure 1 and figure 2 the sequence of events in case of the reception of a RESTART message from the user will be described.

1 The RESTART message 201 arrives to the PUA 101.

2 The PUA does the elementary checks on said RESTART message 201, recognizes that it has the global call reference with call reference flag = 0 and forwards the RESTART message to the RR process 102. If the RR process 102 is not created the process will be created first. It also checks if the RS process 103 exists and if it exists, a RESTART message will be sent to the RS process 103 as well.

3 The RR process 102 performs the checks on the RESTART message 201 as described in the Q.2931 specification.

4 If said RESTART message 201 is correct and the resource which shall be restarted is not the signalling channel a BLOCK message 202 is sent to LN services so that the resource will not be allocated during the restart procedure.

As the PUA process 101 cannot associate the Connection identifier IE, if any, with a specific call, the RR process 102 forwards the RESTART message to all dynamic UA processes 107, 108 indicating the type of reset. The RR process 102 starts timer T317.

Each UA process 107, 108 checks if it is affected by the restart. The UA processes can send two kinds of answer: - The call is affected and the UA process sends a RELEASE_ACK message back when the physical resource is disconnected or the call is not affected and the UA process will respond immediately with a NOT_AFFECTED message to indicate that. In this embodiment the UA process 107 responds with a NOT_AFFECTED message 203. In another embodiment the affected UA processes immediately responds with an AFFECTED message.

If the call is affected the UA process 108 will send a RELEASE message 204 towards the ^• USorig processes 109 and normal shutdown procedure is performed. When the RESTART message arrives to the UA process 107, 108, said UA processes can be in any state. The UA will enter a restart state where the shutdown procedure is performed.

The RR process 102 waits until all UA processes 107, 108 that are concerned about the restart have replied with either a NOT_AFFECTED message 203 or a RELEASE_ACK message 205. If this happens before timer T317 expires: it stops T317 and sends an UNBLOCK message 206 to the LN services 110.

Said RR process 102 assembles and sends a RESTART_ACKNOWLEDGE message 207 to said PUA process 101. Said PUA process 101 forwards said RESTART ACKNOWLEDGE message 207 to said USER. Then the dynamic RR process will terminate.

The following set of events will describe the case when the timer T317 expires before all results has been received by said RR process 102 from said UA processes 107, 108 while referring to figure 1 and figure 3. All messages in figure 3 are identical to the messages in figure 2 except for a NOTIFICATION message 304 to the OMGR 111.

1. If T317 expires before a result has been received from all UA processes 107, 108 concerned about the restart the RR process 102 sends a notification to the OMGR 111 indicating the resources that still are not disconnected by the Restart procedure. After this the RR process 102 will terminate. Any results arriving later are ignored.

Network Initiated Restart

While refering to figure 4 and figure 5 the sequence of events in case the network needs to request a restart procedure from the user is described. Following ITU Q.2931, the only case where this can happen is when the SAAL (Signalling Adaption ATM Layer) connection is available but the user does not reply to any call- related DSS2 messages any more, i.e. timer T308 has expired twice after sending RELEASE.

1 The dynamic UA process 401 sends a RESTART_REQUEST message 501 towards the static PUA process 402. The dynamic UA process will not terminate before it has received a message from the RS process 403 order it to terminate. This is because the resources shall not be free for use until a RESTART_ACK is received from the USER. The PUA process 402 creates a RS process 403 and forwards the RESTART_REQUEST 502 to said RS process 403. If the RS process 403 is already created the RESTARTJREQUEST message 502 is queued in the RS process 403. The RESTART_REQUEST message will be executed as soon as the previously executed message is finished. The RS process 403 will also get a RESTART message from the PUA process 402 when said PUA process 402 receives a RESTART message from the USER (as mentioned above) . The RESTART message contains the resource of the incoming restart. The RS process 403 will delete this resource from said RS process restart queue.

If there exist no RESTART_REQUEST in the queue the RS process 403 will terminate.

The RS process 403 assembles a RESTART message 503 for the restart of a single VC, adds the Connection identifier IE and sends it to said PUA process 402. The PUA process 402 forwards the RESTART message 504 to the USER. Then said RS process 403 starts timer T316.

5 The USER answers with a RESTART_ACKNOWLEDGE message 505 to the PUA process 402 which forwards said RESTART_ACKNOWLEDGE message 506 to the RS process 403 since it contains a global call reference with call reference flag = 1.

6 The RS process 403 sends a RESTART_ACKNOWLEDGE message 507 to the concerned UA process 401 so that it can free its resources.

7 The RS process 403 stops timer T316 and if no queue exists said RS process 403 will terminate.

While refering to figure 5 and figure 6 the set of events that will take place if said PUA process 402 does not respond to said RESTART message 503 will be described. The messages 501 to 503 in figure 5 corresponds to messages 601 to 603 in figure 6.

1. If timer T316 expires 604 before the RESTART_ACKNOWLEDGE message is received, the RS process 403 sends the RESTART message 605 again and restarts the timer T316.

2. After the second expiry of T316 606, the RS process 403 sends a NOTIFICATION message 607 towards the OMGR, put the virtual channel into out-of-service condition, by sending a BLOCK message 608 to SERVICES. If no queue exists said RS process 403 will terminate

Restart After SAAL Release

The following set of events briefly describes the restart procedure after a SAAL release while referring to figure 4.

1 In case the PUA process 402 receives a RELEASE_IND from SAAL, the PUA process immediately forwards the RELEASE_IND to all UA processes registered.

2 Each UA process 401, 404 which is not in the Active call state

(N10), shall be released upon reception of the RELEASE_IND message .

3 The PUA starts timer T309 (10s) and waits for the signalling connection to be re-established. If T309 expires before a RELEASE_CONF is received, all active half-calls must be released to the remote party. This is achieved by a second RELEASE_IND to said UA processes 401, 404. The PUA process 402 will delete all call references to the calls.

4 A complete restart of the SVC will be performed.

5 The PUA process 402 will create a RS process 403 to assemble a RESTART message for the complete SVC and send it to the user. In this case all existing RESET_REQUEST messages should be deleted, as the global RESTART message covers them. A restart after SAAL release always means that there exist no calls at the network side .

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. A method for performing a restart procedure in an integrated data and telecommunication network, CHARACTERISED in that a static PUA process receives a message indicating a restart, that said PUA process creates a dynamic process, and that said dynamic process sends messages to processes which might be affected by said restart.

2. A method according to claim 1, CHARACTERISED in that said static PUA process receives a RESTART message from a USER, that said PUA process creates said dynamic RR (reset-respond) process, that said PUA process forwards said RESTART message to said RR process, that said RR process sends a RESTART message to all dynamic UA processes related to said PUA process in parallell, and that each of said UA processes sends a NOT_AFFECTED message to said RR process or a RELEASE message to a USOrig process in dependence of if said UA process is affected by said restart.

3. A method according to claim 2, CHARACTERISED in that if a RR process already exists said PUA process sends said RESTART message to the already existing RR process.

4. A method according to claim 2, CHARACTERISED in that said RR process sends a BLOCK message to a LN service function for the concerned resources.

5. A method according to claim 4, CHARACTERISED in that said RR process sends an UNBLOCK message to said LN service function for the concerned resources in dependance of if all of said UA processes have responded within a first time limit.

6. A method according to claim 5, CHARACTERISED in that said RR process sends a RESTART_ACKNOWLEDGE message to said PUA process, and that said RR process terminates in dependance of if all of said UA processes have responded within said first time limit.

7. A method according to claim 2, CHARACTERISED in that said RR process sends a NOTIFICATION message to an OMGR function indicating the concerned resources, and that said RR process terminates in dependance on if all of said UA processes have not responded within a first time limit.

8. A method according to claim 1, CHARACTERISED in that said static PUA process receives a RESTART_REQUEST message from a dynamic UA process, that said PUA process creates said dynamic RS (reset-start) process, that said PUA process forwards said RESTART_REQUEST message to said RS process, that said RS process sends a RESTART message to said PUA process, that said PUA process sends said RESTART message to a USER, that said USER sends a RESTART_ACKNOWLEDGE to said PUA process, that said PUA process sends a RESTART_ACKNOWLEDGE to said RS process, that said RS process sends a RESTART_ACKNOWLEDGE to said'UA process, and that said UA process- releases associated resources and terminates.

9. A node in an integrated data and telecommunication network, CHARACTERISED in that said node comprises a static PUA process, that said PUA process comprises means for receiving a message indicating a restart, that said PUA process comprises means for creating a dynamic process, . and that said dynamic process comprises means for sending messages to processes which might be affected by said restart.

10.An integrated data and telecommunication network, CHARACTERISED in that said network comprises a node, that said node comprises a static PUA process, that said PUA process comprises means for receiving a message indicating a restart, that said PUA process comprises means for creating a dynamic process, and that said dynamic process comprises means for sending messages to processes which might be affected by said restart .