KR100326322B1 - Efficient routing method in isup interworking in atm exchange - Google Patents

Abstract

The technical field to which the invention described in the claims belongs.

Asynchronous transfer mode switching system.

B. Technical problem to be solved

It provides an efficient routing method in ISUP interworking of Asynchronous Transfer Mode Switch.

C. Summary of the Solution

The present invention provides an efficient routing method in ISUP interworking of an asynchronous transmission mode switch, comprising the steps of requesting a translation of a trunk station number for the setup call when a call setup request is made from a subscriber; Requesting a routing corresponding to the translated station number; searching for an outgoing call processing processor equipped with an available trunk to the corresponding route by referring to the route table when receiving the routing request; Transmitting a call processing processor having an available trunk to the call setup requested subscriber call processing processor as a result of the routing; and performing call setup by occupying a specific available trunk of the outgoing call processing processor; It is characterized by the configuration.

D. Significant Uses of the Invention

Used when routing in an asynchronous transfer mode exchange.

Description

Efficient Routing Method in I / O Interworking with Asynchronous Transfer Mode Switch {EFFICIENT ROUTING METHOD IN ISUP INTERWORKING IN ATM EXCHANGE}

The present invention relates to an asynchronous transfer mode (hereinafter referred to as "ATM") switching system, and more particularly to an efficient routing method in the ISUP (ISDN User Part) interworking of the ATM switch.

In general, the routing of an exchange means a logical routing operation from an ISDN network to a subscriber exchange node and a destination exchange node.

1 is a diagram illustrating call processing processors (Access Switching Processors) (hereinafter referred to as ASPs) and operation maintaining processors (hereinafter referred to as OMPs) for routing according to a call setup request from a subscriber in each switch in the ISDN network. The TDX-10A switch is illustrated as an example. In particular, referring to FIG. 1, a routing operation of a conventional switch is described. The processing block (Usage Parameter Control: UPC) 108 transmits a trunk station number translation request signal to the OMP Number Translation Processor (NTP) 116 when the call requested from the subscriber is not a native call. PfxTranTrk RQ) 10 is transmitted to request translation of the station number. The number translation block (NTR) 118 of the NTP 116 then translates the trunk station number of the call requested from the subscriber and routes it to the routing control block (RCO) 120. A request signal (Routing RQ) 20 is transmitted to request routing to the destination exchange node corresponding to the translated station number. The RCO 120 then retrieves a root table and extracts ASPs that implement the trunk of the root. The root table includes a root number (D_RT_NO), a root class (D_RT_CLS), It consists of information such as the ASP implementation status (D_ASP_EQUIP_STS). The route number means a number assigned to a route to each destination node, and the route class indicates whether the route number is a route for incoming or outgoing route. The ASP implementation states represent ASPs that implement a trunk for connection to the corresponding route. For example, since the root class rt_ogt displays the outgoing route, route number 1 indicates that the route is for outgoing through the root class rt_ogt. Referring to the ASP implementation status, a trunk for connecting to the corresponding route is mounted. The ASPs are identified by three ASPs: ASP01 102, ASP02 104, and ASP03 106. That is, the RCO 120 of the NTP 116, which has been requested to route, first sends a trunk occupancy request signal (IsupSzRQ) 30 to the first ASP01 102 with reference to the route table provided as shown in FIG. Send through Communication. The UPC 110 of the ASP01 102 then checks whether there is an available trunk through a resource management block (not shown). At this time, if there is no trunk available in ASP01 102, ASP01 102 transmits trunk occupancy request signal (IsupSzRQ) 40 back to ASP02 104, and in ASP02 104 that receives the trunk occupancy request. Again, as in ASP01 102, the resource management block checks whether there is an available trunk. At this time, if ASP02 104 does not have an available trunk, ASP02 104 returns to ASP03 106 using IPC. The trunk occupancy request signal (IsupSzRQ) 50 is transmitted, and the ASP03 106 that receives the trunk occupancy request checks whether there is an available trunk as in the ASP01 102 and ASP02 104 and checks the corresponding route. If there is an available trunk, the outgoing occupancy response signal (OgtSzRP) 60 is transmitted to the ASP00 100 to inform that the trunk to the corresponding route according to the call setup request from the subscriber is occupied.

However, in the conventional routing method as described above, since the NTP routing processing block RCO only stores the positions of the ASPs that implement the available trunks to the corresponding route, it is not known whether the ASPs have the available trunks. It was not possible to determine exactly whether the call was accepted. In other words, the RCO stores only the ASP information on which the available trunk is mounted, and whether or not the actual call is accepted can be known only through the CLS library of each ASP. Therefore, the use of IPC between ASPs is increased to find an ASP in which an available trunk is mounted, which increases the time taken to establish a call when the traffic is congested, and also increases the call volume.

As described above, in the conventional routing method, since the routing processing block RCO of NTP in the OMP stores only the locations of the ASPs that have available trunks to the corresponding route, it is not known whether the ASPs have available trunks. The subscriber could not accurately determine whether to accept the requested call. That is, the RCO stores only ASP information in which the available trunk is mounted, and whether or not the actual call is accepted can be known only through the CLS library of each ASP. Therefore, the use of IPC between ASPs is increased to find an ASP in which an available trunk is mounted, which increases the time taken to establish a call when the traffic is congested, and also increases the call volume.

Accordingly, an object of the present invention is to provide an efficient routing method in ISUP interworking of an ATM switch which reduces call setup time by reducing IPC usage between ASPs to occupy a trunk to a corresponding route according to a call setup request.

1 is a block diagram for routing processing of a conventional TDX-10a switch;

2 is a configuration diagram of a route table of a conventional routing block;

3 is a block diagram for routing processing of an asynchronous transfer mode switch according to an embodiment of the present invention;

4 is a configuration diagram of a route table of a routing block according to an embodiment of the present invention;

5 is a flowchart of a routing process in an asynchronous transmission mode switch according to an embodiment of the present invention.

6 is a flowchart illustrating an available trunk count value update process when a call is released according to an embodiment of the present invention.

In order to achieve the above object, the present invention provides an efficient routing method in ISUP interworking of an asynchronous transmission mode switch, wherein when a call is requested from a subscriber, a trunk station number translation for the call is requested. Requesting a route; requesting routing corresponding to the translated station number; searching for an outgoing call processing processor equipped with an available trunk to a corresponding route by referring to a route table when receiving the routing request; Transmitting a call processing processor having the retrieved available trunk to the corresponding route to the call setup requested subscriber call processing processor as a result of the routing; and establishing a call by occupying a specific available trunk of the outgoing call processing processor. Characterized in that the configuration, including the process of performing.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. Many specific details are set forth in the following description and in the accompanying drawings, in order to provide a more thorough understanding of the present invention. It will be apparent to those skilled in the art that the present invention may be practiced without these specific details. And a detailed description of known functions and configurations that may unnecessarily obscure the subject matter of the present invention will be omitted.

3 is a diagram illustrating a connection relationship between ASPs and OMPs for routing according to a call setup request from a subscriber in each switch in an ISDN network according to an embodiment of the present invention. In particular, FIG. . Referring to FIG. 3, the NTR 318 in the NTP 316 translates the station number required for call setup from the subscriber in response to the trunk station translation request signal (PfxTranTrkRQ) 70 from the ASP00 300 as in the prior art. . The RCO 320 searches the route table in response to the routing request signal (RoutingRQ) 72 from the UPC 308 of the ASP00 300 and extracts the ASPs that carry the trunk of the route. In this case, as shown in FIG. 4, the root table provided in the RCO 320 is implemented to have an index structure. That is, referring to FIG. 4, the root table further includes information of an external PCM pointer (D_ExtRcmRtr), wherein the external PCM pointer index number is an ASP information table 400 in which detailed information of ASPs incorporating trunks of a corresponding route is recorded. ) Is linked. Unlike the related art, the ASP information table 400 not only records ASPs in which the trunk of the corresponding root is mounted but also records the current trunk count value (D_IdleCnt) of each ASP in detail, and the available trunk counts at each call establishment and call release. The value is updated to keep the current ASP's trunk information available correctly.

In addition, the ASP details table 400 records the previous PCM pointer information (D_PreExtPcmPtr) and the next PCM pointer information (D_NextExtPcmPtr) so that the linked ASPs are linked until the ASPs with the available trunks are found. All will be searched. That is, as shown in FIG. 4, when there is no available trunk in ASP01 302, an ASP with an available trunk is searched continuously for ASP02 304 and ASP03 306.

5 is an operation control flowchart for routing processing according to a call establishment request from a subscription at NTP 316 of an ATM switch OMP according to an embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 3, 4, and 5. In particular, in the description of the present invention, a case where there is a request for setting an external trunk line call from a subscriber of the ASP00 300 will be described as an example.

First, if the telephone number inputted when a call setup request is generated from the subscriber is a local line rather than a local call, the ASP00 300 transmits a trunk station number translation request signal (PfxTranTrRQ) 70 to the NTP 316 of the OMP to request the translation of the trunk line number. Done. NTP 316 then receives it at step 500 to perform translation of the requested CO line number through NTR 318, and proceeds to step 502 to inform ASP00 300 of the translated CO line number. . Accordingly, the ASP00 300 recognizes the trunk line number of the input call and transmits a routing request signal (RoutingRQ) 72 to the NTP 316 to request routing for the call setup of the trunk line call. Then, the NTP 316 receives the routing request from the ASP00 300 in step 504, and proceeds to step 506, where the RCO 320 is newly provided according to an embodiment of the present invention. Refers to the root table to search for an ASP that has an available trunk for that route. That is, for example, if the set request call is an outgoing call corresponding to route number 1, the available trunk counts of ASP01 302, ASP02 304, and ASP03 306 linked to external PCM pointer 0 corresponding to route number 1. The values are retrieved in turn. Then, the NTP 316 proceeds to step 508 and notifies the ASP00 300, which has requested a call setup from the subscriber, to the ASP having the available trunk of the corresponding route found in the step 506, and proceeds to step 510. Thus, the available trunk count value of the ASP is reduced by '1'. That is, in the embodiment of the present invention, as shown in FIG. 4, only the ASP03 306 has an available trunk count value of 32, so that the ASP03 306 has an available trunk to the corresponding route as a routing result. As a result it is retrieved and notified to the ASP00 (300).

Therefore, the ASP00 300 requests the incoming call 76 directly to the ASP03 306 which mounts the available trunk to the corresponding route, and the ASP03 306 that has received the incoming call 76 requests the resource management block. By occupying and occupying the available trunk through and giving outgoing relay occupancy response to the ASP00 (300) is a call setup is made. Therefore, unlike the related art, the use of IPC between the ASPs 300, 302, 304, and 306 is much reduced, and call setup time can be shortened.

6 illustrates a process flow for updating the available trunk count value of the ASP03 306 by the NTP 316 upon release of the call established through the process of FIG. 5 in the ASP03 306. Referring to FIG. 6, when the call is first released, the ASP03 306 notifies the NTP 316 of the OMP through the IPC. At this time, the ASP03 306 notifies that the call is released and simultaneously notifies the available trunk count value of the ASP03 306 when the call is released according to the embodiment of the present invention. This means that when the RCO 320 of the NTP 316 managing only the available trunk count value of the corresponding route is notified from the corresponding ASP, the available trunk count value reduced when the call is set is available, as in the call setup. Is updated by increasing the value of '1', and when the call release signal is not transmitted due to IPC loss when only the call release is notified, the RCO 320 of the NTP 316 has difficulty in accurately managing resource available for the available trunk of the corresponding ASP. To solve. That is, even if an IPC loss occurs by transmitting a call release signal and its current available trunk value together, when a call release signal transmitted later is received, an available trunk of the corresponding ASP in the root table is referred to by referring to the current available trunk value of the corresponding ASP. This will keep the value accurate. The NTP 316 then proceeds to step 602 in response to the call release notification in step 600 and then decrements the available trunk count value of the ASP03 306 recorded in the root table of the RCO 320 by '1. Decrease by ' The NTP 316 then proceeds to step 604 to route the current available trunk value of the ASP03 306 sent with the call release notification from the ASP03 306 to the root of the RCO 320 in step 602. It is compared with the available trunk count value of the ASP03 306 which is updated and recorded in the table. At this time, if the available trunk count value recorded in the route table and the current available trunk value transmitted from the ASP03 306 do not coincide with each other, the NTP 316 proceeds to step 608 and the RCO 320. The available trunk count value of the ASP03 306 recorded in the root table is updated and stored with the available trunk value transmitted from the ASP03 306 together with the call release signal. Therefore, accurate resource management can be achieved even if IPC loss occurs.

As described above, the present invention provides not only the information on the ASPs in which the trunk of the corresponding route is installed in the routing processing block but also the available trunk values of the ASPs so that the routing processing block can accurately determine whether to accept the call. In addition, there is an advantage in that IPC usage between ASPs for finding ASPs with conventionally available trunks is much reduced, so that call setup time can be shortened.

Claims (7)

In an efficient routing method in ISUP interworking of an asynchronous transfer mode switch, Requesting the translation of the trunk station number for the set-up requested call when the call is requested from the subscriber; Requesting routing corresponding to the translated station number; Receiving the routing request, searching for an outgoing call processing processor equipped with an available trunk to a corresponding route by referring to a route table; Transmitting a call processing processor having the retrieved available trunk to the corresponding route to the call establishment requested subscriber call processing processor as a result of the routing; E. S. U. interworking efficient routing method of the asynchronous transmission mode switch, characterized in that the process of performing a call setup by occupying a specific available trunk of the outgoing call processing processor. The method of claim 1, wherein the root table, Efficient routing method in the A / S WP interworking of an asynchronous transfer mode exchange, comprising a root number, a root class, and an external PCM pointer index number. The method of claim 2, wherein the external P. C. M pointer index number, Efficient routing method in the I. S. U. P interworking of the asynchronous transmission mode switch, characterized in that the link to the table recorded the available trunk count value of the call processing processors equipped with the trunk of the route. The method of claim 3, And subtracting and updating the available trunk count value of the outgoing call processing processor of the route table by '1' when the call is set. Efficient Routing Method in. The method of claim 4, wherein And receiving a call release signal from the outgoing call processing processor upon release of the call. The method of claim 5, wherein the call release signal, Efficient routing method in the I. S. U. interworking of the non-transmission mode switch, characterized in that it comprises the information of the current available trunk value of the outgoing call processing processor. The method of claim 6, Updating the available trunk count value of the outgoing call processing processor of the route table to the current available trunk value of the outgoing call processing processor included in the call release signal when the call release signal is received. Efficient routing method in I / S interworking of asynchronous transfer mode exchange to be done.