WO1999018739A1 - Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface - Google Patents

Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface Download PDF

Info

Publication number
WO1999018739A1
WO1999018739A1 PCT/FI1998/000620 FI9800620W WO9918739A1 WO 1999018739 A1 WO1999018739 A1 WO 1999018739A1 FI 9800620 W FI9800620 W FI 9800620W WO 9918739 A1 WO9918739 A1 WO 9918739A1
Authority
WO
WIPO (PCT)
Prior art keywords
interface
message
protocol
restart
subscriber
Prior art date
Application number
PCT/FI1998/000620
Other languages
French (fr)
Inventor
Timo Juntunen
Pekka Lehto
Tiina Lehikoinen
Jaakko Rautiainen
Arto RUKAJÄRVI
Jyrki Suutari
Jouni Pohjolainen
Kirsi Maansaari
Toivo Lallukka
Jaakko Saarela
Original Assignee
Nokia Networks Oy
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 Nokia Networks Oy filed Critical Nokia Networks Oy
Priority to AU86332/98A priority Critical patent/AU8633298A/en
Priority to EP98937590A priority patent/EP1025713A1/en
Publication of WO1999018739A1 publication Critical patent/WO1999018739A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q11/00—Selecting arrangements for multiplex systems
    • H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/1309—Apparatus individually associated with a subscriber line, line circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13176—Common channel signaling, CCS7
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13203—Exchange termination [ET]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13204—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13209—ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13292—Time division multiplexing, TDM

Definitions

  • 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.
  • 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 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) .
  • a second V5 interface see Fig. 1
  • 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.
  • 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.
  • 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.
  • 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.
  • PSTN protocol signalling consistent with the ETS 300 324-1 standard is achieved in the V5 interfaces .
  • 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 .
  • the restart of the PSTN protocol is controlled and synchronised by means responsible for V5 interface 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • Fig. 4 presents a signalling diagram for a third embodiment of the procedure of the invention for restart of the PSTN protocol.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • signalling consistent with the PSTN protocol according to the specification (ETS 300 324-1) is obtained in the V5.2 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

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.
PCT/FI1998/000620 1997-10-08 1998-08-07 Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface WO1999018739A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU86332/98A AU8633298A (en) 1997-10-08 1998-08-07 Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface
EP98937590A EP1025713A1 (en) 1997-10-08 1998-08-07 Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FI973911 1997-10-08
FI973911A FI973911A (en) 1997-10-08 1997-10-08 Method for Controlled Call Release in the V5 PSTN Protocol Restart

Publications (1)

Publication Number Publication Date
WO1999018739A1 true WO1999018739A1 (en) 1999-04-15

Family

ID=8549688

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI1998/000620 WO1999018739A1 (en) 1997-10-08 1998-08-07 Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface

Country Status (4)

Country Link
EP (1) EP1025713A1 (en)
AU (1) AU8633298A (en)
FI (1) FI973911A (en)
WO (1) WO1999018739A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999048307A1 (en) * 1998-03-13 1999-09-23 Nokia Networks Oy Method and system for ensuring a pstn protocol restart procedure as defined by the v5 standard
EP1061765A2 (en) * 1999-06-18 2000-12-20 Fujitsu Limited Access network management system

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FREQUENZ, 1994, (BERLIN), KARIM KHAKZAR, "V5 Interfaces Between Digital Local Exchanges and Access Networks", pages 44-50. *
IEEE GLOBAL TELECOMMUNICATION CONFERENCE, Volume 3, December 1992, (USA), ALEX GILLESPIE, "Interfacing Access Networks to Exchances the Etsi V5 Approach", pages 1754-1758. *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999048307A1 (en) * 1998-03-13 1999-09-23 Nokia Networks Oy Method and system for ensuring a pstn protocol restart procedure as defined by the v5 standard
US6738471B1 (en) 1998-03-13 2004-05-18 Nokia Corporation Method and system for ensuring a PSTN protocol restart procedure as defined by the V5 standard
EP1061765A2 (en) * 1999-06-18 2000-12-20 Fujitsu Limited Access network management system
EP1061765A3 (en) * 1999-06-18 2006-08-09 Fujitsu Limited Access network management system

Also Published As

Publication number Publication date
FI973911A0 (en) 1997-10-08
FI973911A (en) 1999-04-09
EP1025713A1 (en) 2000-08-09
AU8633298A (en) 1999-04-27

Similar Documents

Publication Publication Date Title
US5781623A (en) Method of controlling an access network as well as exchange and access network
JP3338288B2 (en) Method and apparatus for providing inter-switch delegation in a personal communication service system
CA1237804A (en) Trunk call processing services for host computers interconnections
JPH05260045A (en) Communication method for data terminal equipment
US4985887A (en) Systems for selecting a transmission control procedure in communications using integrated services digital networks
EP0497000B1 (en) A maintenance communication control system in an ISDN service
EP1025713A1 (en) Procedure for controlled disconnection of calls in conjunction with pstn protocol restart in a v5 interface
US6711175B1 (en) Procedure for scanning or disconnecting a module line in a V5.2 access node
US5841780A (en) ISDN BRI link restoration without loss of calls
JP3027483B2 (en) Line switching control method and device
KR100302868B1 (en) method for switch over communication path of V5.2 ISDN call
JP3165081B2 (en) Duplexing method for a D-channel packet processor operating in a single mode in an ISDN exchange having a centralized packet processor
JP3149262B2 (en) Communication method for ISDN terminal device
JP3008720B2 (en) ISDN signal switching equipment
JP2812767B2 (en) Packet terminal device and communication system
JP2970215B2 (en) Line controller
JPH0779376B2 (en) Communication terminal
KR19990048229A (en) V5.2 Subscriber Information Management Device using External Host in Electronic Switching System
JP2001028627A (en) Line exchange and terminal equipment
JP3624851B2 (en) Remote switching system switching method and switching system
KR100219224B1 (en) Method for processing primitives in layer 3 of isdn uni
JP2783270B2 (en) ISDN terminal adapter device
JP2972239B2 (en) Message signaling system
JP3243267B2 (en) ISDN data terminal equipment
JP3216898B2 (en) Subscriber line controller

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW SD SZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

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

Ref document number: 1998937590

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09542764

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: KR

WWP Wipo information: published in national office

Ref document number: 1998937590

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 1998937590

Country of ref document: EP