PROCEDURE FOR CONTROLLED DISCONNECTION OF CALLS IN CONJUNCTION WITH PSTN PROTOCOL RESTART IN A V5 INTERFACE

Abstract: Procedure for controlled disconnection of calls in conjunction with restart of the PSTN protocol in a V interface in a data communication system in which a number of subscriber terminals (TE) are connected to an access node (AN) and from the access node to a local exchange (LE) via a standard first V5 interface (V5). A number of subscriber terminals (TE) are connected to a concentrator (MUX) and the concentrator is connected to the access node (AN) via a second V5 interface (V5'). In conjunction with a restart of the PSTN protocol in the first or second V5 interface, information giving the status of all subscriber ports is sent to the local exchange (LE).

Description: PROCEDURE FOR CONTROLLED DISCONNECTION OF CALLS IN CONJUNCTION WITH PSTN PROTOCOL RESTART IN A V5 INTERFACE The present invention relates to a procedure as defined in the preamble of claim 1. Previously known is a data communication system in which a number of subscriber terminals are connected to an access node and from the access node to a local exchange using a standard V5 interface. In a prior-art system like this, the access node is always informed about the status of the calls. The object of the present invention is to present a new type of procedure for controlled disconnection of calls in conjunction with a restart of the PSTN protocol in a V5 interface when in said data communication system the subscriber terminals (TE) are connected to a concentrator (MUX) and the concentrator is connected to an access node (AN) via a second V5 interface (see Fig. 1) . The above-mentioned second V5 interface (V5.1') is a static multiplexer interface which is not located between an access node (AN) and a local exchange (LE) like a normal V5 interface. Instead, the second V5 interface is an interface internal to the access network and it serves to connect subscribers (TE) , usually connected to a physically separate concentrator, to the access node. The signalling in the second V5 interface is consistent with the ETS 300 324-1 standard and it supports analogue subscriber li- nes, basic ISDN lines and semi-fixed connections. V5 interface standards ETS 300 324 (V5.1 interface) and ETS 300 347 (V5.2 interface) describe the interface between a local exchange (LE) and an access node (AN) and the functionality in the access node. The V5 interface standards do not support cascading of V5 interfaces, nor do they forbid it. In the access node (AN), a V5.2/V5.1 conversion is performed when the first V5 interface is a V5.2 interface and the second V5 interface is a V5.1 interface (V5.1'). The V5.1' interface between the concentrator (MUX) and the access node (AN) must not affect the V5.2 interface between the local exchange (LE) and the access node (AN) . The signalling conversion between the V5.2 interface and the V5.1' interface is carried out in such a way that the local exchan- ge will perceive the subscriber as being directly connected to the V5.2 interface and that the V5.1' subscriber concentrator will perceive the V5.1' interface as being directly connected to the local exchange. The network element transmitting messages between the V5.2 and V5.1' interfaces does not know the status of the calls, which is why in such a system a problematic issue is how to disconnect calls in the cascaded V5 interfaces in conjunction with a restart of the PSTN protocol in either one of the V5 interfaces in a controlled manner and so that no subscriber ports/channels remain reserved. The procedure of the invention is characterised by what is presented in claim 1. According to the invention, a number of sub- scriber terminals are connected to a concentrator, and the concentrator is connected to an access node via a second V5 interface; and in conjunction with a restart of the PSTN protocol of the first or second V5 interface, information giving the status of all subscriber ports is sent to the local exchange. The invention has the advantage that any calls that may be going on can be disconnected in a controlled manner in conjunction with a restart of the PSTN protocol and no subscriber ports/channels remain busy. In addition, PSTN protocol signalling consistent with the ETS 300 324-1 standard is achieved in the V5 interfaces . In an embodiment of the procedure, notification regarding restart of the PSTN protocol is given; a disconnect message consistent with the PSTN protocol is sent to each subscriber port in the second V5 in- terface; and an acknowledgement of the disconnect message is sent by the subscriber ports of the second V5 interface to the local exchange, thus informing the local exchange about the status of the subscriber ports . In an embodiment of the procedure, the restart of the PSTN protocol is controlled and synchronised by means responsible for V5 interface system management . In an embodiment of the procedure, using me- ans responsible for system management, the means responsible for the PSTN protocol are informed about the restart; using the means responsible for the PSTN protocol, a disconnect message consistent with the PSTN protocol is sent to each PSTN subscriber port in the second V5 interface; the disconnect message is acknowledged by the subscriber ports of the second V5 interface by sending a disconnect complete message to the local exchange; and, using means responsible for system management in the first V5 interface, means res- ponsible for the BCC protocol are requested to release the connections by means of a V5 interface-specific or subscriber port-specific signal. In an embodiment of the procedure, the disconnect message is acknowledged by the subscriber ports of the second V5 interface by sending a disconnect complete message both to the first V5 interface and to the second V5 interface. In an embodiment of the procedure, temporary status engines are created for the subscriber ports of the second V5 interface for use during restart of the PSTN protocol, and the status engines are deleted af- ter the local exchange has received the subscriber port status data via the status engines. In an embodiment of the procedure, temporary status engines are created for the subscriber ports of the second V5 interface by the means responsible for system management in the second V5 interface and a restart request message is sent to the subscriber ports; the disconnect message is sent further by means responsible for the status engines to each subscriber port involved in the failure situation; the disconnect message is acknowledged by the subscriber ports by sending an acknowledgement message to the status engines; the disconnect message is acknowledged by the status engines by sending an acknowledgement message to the local exchange; completion of restart of the PSTN protocol is acknowledged by the status engines by sending an acknowledgement message to the means responsible for system management in the V5 interface; the status engines are deleted by the means responsi- ble for system management in the V5 interface; and the means responsible for the BCC protocol are requested by the means responsible for system management in the first V5 interface to release the connections by means of a V5 interface-specific or subscriber port-specific signal. In an embodiment of the procedure, all PSTN subscriber ports are blocked, causing a disconnection acknowledgement message to be sent to the local exchange; and the subscriber ports are unblocked. Res- tart of the PSTN protocol can now be performed in the second V5 interface in accordance with the control protocol . In an embodiment of the procedure, using the means responsible for system management in the second V5 interface, all subscriber ports in the second V5 interface that are involved in the failure situation are blocked by means of the control protocol, causing a message acknowledging the disconnect message to be sent to the local exchange, so the local exchange will assume that the restart of the PSTN protocol has been completed; acknowledgement of the blocking of all subscriber ports in the second V5 interface is sent by the control protocol to the means responsible for system management in the V5 interface; using the means responsible for system management in the second V5 interface, a request to unblock the subscriber ports of the second V5 interface is sent to the control protocol; using the control protocol, an acknowledgement of the unblocking of the subscriber ports of the second V5 interface is sent to the means responsible for system management in the second V5 interface; a message acknowledging the restart of the PSTN protocol is sent by the means responsible for system management in the second V5 interface to the means responsible for system management in the first V5 interface; and, using the means responsible for system management in the first V5 interface, the means responsible for the BCC protocol are requested to release the connections by means of a V5 interface-specific or subscriber port- specific signal. In an embodiment of the procedure, the first V5 interface is V5.2 interface consistent with the ETS 300 347 standard and the second V5 interface is a V5.1 interface consistent with the ETS 300 324 standard. In the following, the invention will be described in detail by the aid of a few examples of its embodiments by referring to the attached drawings, wherein Fig. 1 presents a diagram representing a data communication system in which the procedure of the invention is implemented, Fig. 2 presents a signalling diagram for a first embodiment of the procedure of the invention for restart of the PSTN protocol, Fig. 3 presents a signalling diagram for a second embodiment of the procedure of the invention for restart of the PSTN protocol, and Fig. 4 presents a signalling diagram for a third embodiment of the procedure of the invention for restart of the PSTN protocol. In Fig. 2, the restarting of the PSTN protocol in the V5 interface is controlled by program blocks responsible for system management in the V5 in- terfaces. The program block V.52 System Management responsible for system management in the first V5 interface V5.2 sends a RESTART message to the control protocol CTRL, which further sends a COMMON CONTROL (restart) message to the local exchange LE. The local exchange LE acknowledges the message by sending a COMMON CONTROL ACK message to the control protocol CTRL. The program block V.52 System Management responsible for V5.2 system management sends a Disconnect_B- channels (V5.2) command to the Cross-connection proto- col, which acknowledges the command by sending a B- channels_disconnected message to V5.2 System Management . V5.2 System Management then sends a restart request in a restart_request message to the program block V5.1 System Management responsible for system management in the second V5 interface V5.1 . Its program block responsible for the PSTN protocol sends a DISCONNECT message consistent with the PSTN protocol (ETS 300 324-1) to each V5.1' subscriber port (V5.1 mux in the figures) in the concentrator (MUX) in the first V5 interface V5.1'. The subscriber ports respond with a DISCONNECT COMPLETE message directly to the local exchange LE. The figure also presents an embodiment, outlined with broken lines, in which the DISCONNECT_COMPLETE message is also sent to the first V5.2 interface and the second V5.1' interface. The lo- cal exchange acknowledges the DISCONNECT_COMPLETE message by sending it back. Next, the local exchange LE sends a COMMON_CONTROL (restart_complete) message to the cont- rol protocol CTRL of the V5.2 interface, which further sends the restart_complete message to V5.2 System Management. The control protocol CTRL acknowledges the message by sending a COMMON CONTROL ACK message to the local exchange LE. V5.2 System Management sends a res- tart_complete message to the control protocol CTRL, which sends it via the C-channel as a COMMON_CONTROL (restart_complete) message to the local exchange LE, which acknowledges it by sending a COMMON CONTROL ACK message to the control protocol CTRL. Finally, V5.2 interface System Management requests the protocol responsible for the BCC protocol to release the connections by means of a V5 interface- specific or subscriber port-specific signal. The function of the BCC (Bearer Channel Connection) proto- col is to allocate and release time slots, i.e. user channels for user ports in the V5.2 interface. Any ongoing calls can be disconnected in a controlled manner and, in conjunction with a restart of the PSTN protocol in a V5 interface, no channels remain allocated. In this embodiment, it is not necessary to implement independent status engines for the V5.1' interface. Such an embodiment is described in conjunction with Fig. 3. In both V5 interfaces, signalling consistent with the PSTN protocol according to the specification (ETS 300 324-1) is achieved. In Fig. 3, restart of the PSTN protocol in the V5 interface is controlled by program blocks responsible for system management in the V5 interfaces. The program block V5.2 System Management responsible for system management in the first V5 interface V5.2 sends a RESTART message to the control protocol CTRL, which further sends a COMMON_CONTROL (restart) message to the local exchange LE. The local exchange LE acknowledges the message by sending a COMMON_CONTROL ACK message to the control protocol CTRL. The program block V5.2 System Management responsible for V5.2 sys- tem management sends a Disconnect_B-channels (V5.2) command to the Cross-connection protocol, which acknowledges it by sending a B-channels_disconnected message to V5.2 System Management. V.51 System Management is responsible for system management in the V5.1' interface. In conjunction with the restart of the PSTN protocol, V.51 System Management creates temporary PSTN status engines for the subscriber ports in the V5.1' interface and sends the subscriber ports a Restart message via the PSTN status engines. The PSTN status engines send a DISCONNECT message consistent with the PSTN protocol (ETS 300 324-1) to each subscriber port (V5.1-mux in the figure) in the concentrator (MUX) in the V5.1' interface. The V5.1' subscriber ports send a DISCONNECT_COMPLETE message to the PSTN status engines, which further send the DISCONNECT_COMPLETE message to the local exchange LE. 'After sending the DISCONNECT_COMPLETE message to the local exchange LE, the PSTN status engines acknowledge completion of the restart of the PSTN protocol, i.e. the PSTN Restart procedure, by sending a Restart_ack message to V.51 System Management. Having received this message from the PSTN status engines, V.51 System Management deletes the status engines. After this, V.51 System Management informs V5.2 System Management about the completion of the restart procedure by sending a restart_complete message to V5.2 System Management, which further sends a restart_complete message to the control protocol CTRL, which sends it further to the local exchange LE with a COMMON_CONTROL (restart_complete) message. The local exchange LE sends the control protocol an ack- nowledgement with a CTRL COMMON_CONTROL ACK message. The local exchange LE further sends a COMMON_CONTROL (restart_complete) acknowledgement message to the control protocol and the control protocol CTRL sends a restart_complete message to V5.2 System Management. The control protocol CTRL sends a COMMON_CONTROL_ACK acknowledgement message to the local exchange LE. Finally, V5.2 interface System Management requests the protocol responsible for the BCC protocol to release the connections by means of a V5 interface- specific or subscriber port-specific signal. Any calls that may be going on can be disconnected in a controlled manner and no channels remain allocated in conjunction with the restart of the PSTN protocol of the V5 interface. Independent PSTN status engines are created in the V5.1 interface only for the time of the PSTN protocol restart procedure. Signalling consistent with the PSTN protocol according to the specification (ETS 300 324-1) is obtained in both V5 interfaces. In Fig. 4, V5.2 System Management, which is responsible for system management in the first V5 interface V5.2, sends a RESTART message to the control protocol CTRL. The control protocol CTRL further sends a COMMON_CONTROL (restart) message to the local exchange LE. The local exchange LE acknowledges the message by sending a COMMON_CONTROL ACK message to the control protocol CTRL. The program block V5.2 System Management responsible for V5.2 system management sends a Disconnect_B-channels (V5.2) command to the Cross-connection protocol, which acknowledges it by sending a B-channels_disconnected message to V5.2 System Management. Next, V5.2 System Management sends a restart request in a restart_request message to the program block V.51 System Management responsible for system management in the second V5 interface, i.e. the V5.1' interface. V.51 System Management sends a block request to the control protocol CTRL. The control protocol CTRL sends a BLOCKING_INDICATION message to each subscriber port (V5.1-mux) in the concentrator (MUX) in the V5.1' interface. The subscriber ports in the V5.1' interface acknowledge the message with a BLOCKING_ACK message to the control protocol CTRL, which further sends a block_ack message to V.51 System Management. Thus, all subscriber ports in the V5.1' interface are blocked. The blocking of the subscriber ports causes a DISCONNECT_COMPLETE message to be sent to the local exchange LE. The local exchange LE assumes that the PSTN protocol restart procedure has been completed. The local exchange LE sends an acknowledge- ment with a DISCONNECT_COMPLETE message to the subscriber ports. V.51 System Management then sends an unblock request to the control protocol CTRL, which further sends an UNBLOCK REQUEST to the subscriber ports. The subscriber ports acknowledge the request by sending an UNBLOCK_ACK message to the control protocol CTRL, which further sends an unblock message to V.51 System Management. Having thus learned that the subscriber ports have been unblocked, V.51 System Management sends a Restart_complete message to V5.2 Sys- tem Management, which sends the Restart_complete message further to the control protocol CTRL, which sends it further to the local exchange LE with a COMMONJCONTROL (restart_complete) message. The local exchange LE sends a COMMON_CONTROL ACK message to the control protocol CTRL. The local exchange LE further sends an acknowledgement to the control protocol CTRL with a COMMON_CONTROL (restart_complete) message and the control protocol CTRL sends a Restart_complete message to V5.2 System Management. The control proto- col CTRL sends an acknowledgement with a COMMON_CONTROL ACK message to the local exchange LE . Finally, V5.2 interface System Management requests the protocol responsible for the BCC protocol to release the connections by means of a V5 interface- specific or subscriber port-specific signal. Any calls that may be going on can be disconnected in a controlled manner and no channels remain allocated in conjunction with the restart of the PSTN protocol in the V5 interface. The PSTN protocol restart procedure can be carried out in the V5.1 interfa- ce by using the control protocol, without having to execute the PSTN protocol. Thus, signalling consistent with the PSTN protocol according to the specification (ETS 300 324-1) is obtained in the V5.2 interface. The invention is not restricted to the examples of its embodiments described above, but many variations are possible within the scope of the inventive idea defined by the claims.

Claims: CLAIMS 1. Procedure for controlled disconnection of calls in conjunction with a restart of the PSTN protocol in a V5 interface in a data communication system, in which a number of subscriber terminals (TE) are connected to an access node (AN) and from the access node to a local exchange (LE) via a standard first V5 interface (V5) , cha ract e r i s ed in that a number of subscriber terminals (TE) are connected to a concentrator (MUX) and the concentrator is connected to the access node (AN) via a second V5 interface (V5' ) ; and in conjunction with a restart of the PSTN protocol in the first or second V5 interface, information giving the status of all subscriber ports is sent to the local exchange (LE) . 2. Procedure as defined in claim 1, cha ra ct e r i s e d in that - notification regarding restart of the PSTN protocol is given; - a disconnect message consistent with the PSTN protocol is sent to each subscriber port in the second V5 interface, and - acknowledgement of the disconnect message is sent by the subscriber ports of the second V5 interfa- ce to the local exchange (LE) , the local exchange thus receiving information regarding the status of the subscriber ports. 3. Procedure as defined in claim 1 or 2, cha ract e r i s e d in that the restart of the PSTN protocol is controlled and synchronised using means responsible for system management in the V5 interface. 4. Procedure as defined in any one of claims 1 - 3, chara ct e r i s ed in that - using means responsible for system management, means responsible for the PSTN protocol are informed about the restart, - using the means responsible for the PSTN protocol, a disconnect message consistent with the PSTN protocol is sent to each PSTN subscriber port in the second V5 interface, - the disconnect message is acknowledged by the subscriber ports of the second V5 interface by sending a disconnect complete message to the local exchange, and - using means responsible for system management in the first V5 interface, means responsible for the BCC protocol are requested to release the connections by means of a V5 interface-specific or subscriber port-specific signal. 5. Procedure as defined in any one of claims 1 - 3, cha r a ct e r i s e d in that the disconnect message is acknowledged by the subscriber ports of the second V5 interface by sending a disconnect complete message both to the first V5 interface and to the second V5 interface. 6. Procedure as defined claim 1, cha ra ct e ri s ed in that - temporary status engines are created for the subscriber ports of the second V5 interface for use during restart of the PSTN protocol , and - the status engines are deleted after the local exchange has received the subscriber port status data via the status engines. 7. Procedure as defined in claim 6, cha ra ct e r i s e d in that - the temporary status engines for the subscriber ports of the second V5 interface are created using the means responsible for system management in the second V5 interface and a restart request message is sent to the subscriber ports, - using means responsible for the status engines, the disconnect message is sent further to each subscriber port involved in the failure situation, - the disconnect message is acknowledged by the subscriber ports by sending an acknowledgement message to the status engines, - the disconnect message is acknowledged by the status engines by sending an acknowledgement message to the local exchange, - completion of restart of the PSTN protocol is acknowledged by the status engines by sending an acknowledgement message to the means responsible for sys- tem management in the V5 interface, - the status engines are deleted by the means responsible for system management in the V5 interface, and - the means responsible for the BCC protocol are requested by the means responsible for system management in the first V5 interface to release the connections by means of a V5 interface-specific or subscriber port-specific signal. 8. Procedure as defined in claim 1, c h a - ra ct e r i s ed in that - all PSTN subscriber ports are blocked, causing a disconnection acknowledgement message to be sent to the local exchange, and - the subscriber ports are unblocked. 9. Procedure as defined in claim 8, cha ra ct e r i s ed in that - using the means responsible for system management in the second V5 interface, all subscriber ports in the second V5 interface that are involved in the failure situation are blocked by means of the control protocol, causing a message acknowledging the disconnect message to be sent to the local exchange, so the local exchange will assume that the restart of the PSTN protocol has been completed, - an acknowledgement of the blocking of all subscriber ports in the second V5 interface is sent by the control protocol to the means responsible for system management in the V5 interface, - using the means responsible for system management in the second V5 interface, a request to unblock the subscriber ports of the second V5 interface is sent to the control protocol, - an acknowledgement of the unblocking of the subscriber ports of the second V5 interface is sent by the control protocol to the means responsible for sys- tem management in the second V5 interface, - a message acknowledging the restart of the PSTN protocol is sent by the means responsible for system management in the second V5 interface to the means responsible for system management in the first V5 in- terface, and - the means responsible for the BCC protocol are requested by the means responsible for system management in the first V5 interface to release the connections by means of a V5 interface-specific or sub- scriber port-specific signal. 10. Procedure as defined in any one of claims 1 - 9, cha ra ct e r i s e d in that the first V5 interface is V5.2 interface consistent with the ETS 300 347 standard and the second V5 interface is a V5.1 interface consistent with the ETS 300 324 standard.

Inventors: JUNTUNEN TIMO, LALLUKKA TOIVO, LEHIKOINEN TIINA, LEHTO PEKKA, MAANSAARI KIRSI, POHJOLAINEN JOUNI, RAUTIAINEN JAAKKO, RUKAJAERVI ARTO, SAARELA JAAKKO, SUUTARI JYRKI, JUNTUNEN, TIMO, LALLUKKA, TOIVO, LEHIKOINEN, TIINA, LEHTO, PEKKA, MAANSAARI, KIRSI, POHJOLAINEN, JOUNI, RAUTIAINEN, JAAKKO, RUKAJAERVI, ARTO, SAARELA, JAAKKO, SUUTARI, JYRKI
Applicants: JUNTUNEN TIMO, LALLUKKA TOIVO, LEHIKOINEN TIINA, LEHTO PEKKA, MAANSAARI KIRSI, NOKIA TELECOMMUNICATIONS OY, POHJOLAINEN JOUNI, RAUTIAINEN JAAKKO, RUKAJAERVI ARTO, SAARELA JAAKKO, SUUTARI JYRKI, JUNTUNEN, TIMO, LALLUKKA, TOIVO, LEHIKOINEN, TIINA, LEHTO, PEKKA, MAANSAARI, KIRSI, POHJOLAINEN, JOUNI, RAUTIAINEN, JAAKKO, RUKAJAERVI, ARTO, SAARELA, JAAKKO, SUUTARI, JYRKI
Application year: 1998
Main classification: H04Q3
IPC codes: H04Q11