KR100290680B1 - Load sharing method of local ssp(service switching point) exchange on advanced intelligent network - Google Patents

Abstract

The present invention relates to a Local Service Switching Point (SSP) exchange having a next generation intelligent network (AIN: ADVANCED INTELLIGENT NETWORK) structure, and in particular, an efficient load sharing between an SSP (Service Switching System) and a plurality of SCPs (Service Control System) ) Method. In order to solve this problem, the present invention adds a domain (D_SSN_AIN) that can specify an SSN for each service to the internal data for load sharing to R_SERVICE_SCP_GROUP, separates D_SCP_GR_LOAD into two by providing a point for R_SCP_GROUP, and corresponding information in each SCP. In order to be configured as a combination of SPC / SSN / GTS / TT to move the GTS and TT to R_SCP, characterized in that the load sharing when the call incoming.

Description

LOAD SHARING METHOD OF LOCAL SSP (SERVICE SWITCHING POINT) EXCHANGE ON ADVANCED INTELLIGENT NETWORK}

The present invention relates to a Local Service Switching Point (SSP) exchange having a next generation intelligent network (AIN: ADVANCED INTELLIGENT NETWORK) structure, and in particular, an efficient load sharing between an SSP (Service Switching System) and a plurality of SCPs (Service Control System) ) Method.

The conventional TOLL SSP switch basically has a load sharing function between each signaling point of SCP, basically having the same service key and having different SCP groups. Here, the SCP group has a signal point and SSN (subsystem number) of up to two physical SCPs.

A load sharing operation method in the conventional TOLL SSP exchange will be described with reference to FIGS. 1 and 2. In this case, it is assumed that there are three SCPs having the same subsystem number (SSN, hereinafter referred to as SSN) but having different signaling points, and one physical SCP is configured in the SCP group.

The operator registers each signaling point and SSN for each SCP. The operator then assigns SCPs to each SCP group. When the SCP is designated, the operator creates up to three services having the same service key (or SSN), and assigns a load sharing ratio to each service. After completing the basic procedure, in step 11 of FIG. 1, the related call is referred to as a SSF (Service Switching Function) in the Call Control Function (CCF) (100). At the time point of entering the 110 and processing the intelligent network request, the SSF 110 performs a DP (Detection Point: detection point, hereinafter referred to as DP) processing to provide a service of a corresponding trigger. Obtain a point and obtain a service key associated with the service point. Through the obtained service key, the SSF 110 finds an SCP group associated with the corresponding service key, and sends a message as a load sharing ratio between the SCP groups preset to the corresponding SCP 120 in the SCP group determined in step 13. Root and get the result in step 15. In this way, the SSP 110 shares the load and transmits the instructions of the SCP to the CCF 100 in step 17.

2 illustrates a data structure according to load sharing in a conventional TOLL SSP exchange. In FIG. 2, R_XX is a relation name referring to a DBMS (database management system), D_YY is a domain of the relation, SVC is a service, GR is a group, TT is a Translation Type, and GTS is Global Title Series, TMR is timer. That is, when a related call flows in, the SSP 110 retrieves a service name from the R_TRIGGER relation of the DBMS. After searching the service key for the service name in the R_SERVICE_SCP_GROUP relation, searching for the SCP group associated with the service key in the R_SCP_GROUP relation and the R_SCP relaxation, and sharing the load with the set load sharing ratio between the searched SCP groups. .

The load sharing method of the conventional TOLL SSP switch was limited in that it had only the same service key and different SCP groups. There was a problem in that it was recognized as if two different services existed.

Therefore, an object of the present invention is to overcome the limitations of the conventional TOLL SSP switch in applying the load sharing function to the next-generation intelligent network LOCAL SSP switch to solve the above problems, and to ensure the maximum functionality and ease of operation of the next-generation intelligent network. It is to provide a load sharing method in a local SSP exchange.

In order to achieve the above object, the present invention provides a load sharing method of a next generation intelligent network local service exchange system (LOCAL SSP) switch, wherein a domain (D_SSN_AIN) for assigning an SSN for each service to internal data for the load sharing is added to R_SERVICE_SCP_GROUP. And the D_SCP_GR_LOAD is separated into two by giving a point for R_SCP_GROUP, and the GTS and TT are moved to R_SCP so that the information can be composed of SPC / SSN / GTS / TT in each SCP, and then the service exchange Registering service control system (SCP) information for processing intelligent network services in the system, assigning each weight to each service control system for load sharing, and assigning the service control system group to the service exchange system. Registering the intelligent network service to be processed in the service switching system; Registering a trigger information of an intelligent network service that can be provided by the service switching system; searching for trigger name registered in the service switching system when a call flows from a call control function block (CCF); Searching for the service control system group using the service name, searching for an actual service control system to perform load sharing within the service control system group, and packing and transmitting a message to the corresponding service control system. It is characterized by consisting of a process.

1 is a block diagram and signal flow diagram for performing the load sharing in the conventional TOLL SSP switch

Figure 2 is a data structure diagram according to the load sharing performed in the SSP in the conventional TOLL SSP exchange

3 is a block diagram and signal flow diagram for performing load sharing in a LOCAL SSP switch according to the present invention.

4 is a data structure diagram according to load sharing performed in an SSP in a LOCAL SSP switch according to the present invention;

5 is a flowchart illustrating a service configuration method for load sharing application according to a preferred embodiment of the present invention.

6 is a flowchart illustrating a load sharing method according to a preferred embodiment of the present invention.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in detail. First of all, in adding reference numerals to the components of each drawing, it should be noted that the same components have the same reference numerals as much as possible even if they are displayed on different drawings. In addition, in the following description, numerous specific details, such as specific process flows, are set forth 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. Detailed descriptions of well-known functions and configurations that are determined to unnecessarily obscure the subject matter of the present invention will be omitted.

3 is a block diagram and signal flow diagram for performing load sharing in a LOCAL SSP switch according to the present invention;

The CCF 300 is a function block that provides call / service processing and control. The CCF 300 operates or releases a call / service instance requested by a CCAF (call control agent function), which is not shown, and is specified by the request of the SSF 310. It provides the ability to associate or associate a call or service with the CCAF entity contained in the instance. It also manages the relationship between CCAF entities involved in the call and detects and sends a trigger event to the SSF 310.

The SSF 310 is a service exchange function block connected to the CCF 300, and provides functions for interaction between the CCF 300 and the SCF 320, recognizes a service control trigger, and recognizes a service control trigger. Extend the logic of the CCF 300 to interact. It manages the signaling between the CCF 300 and the SCF 320, and controls the load sharing according to the present invention.

SCF 320 is a functional block that directs intelligent network call control in the processing of supplementary services or user requests, and has an intelligent network service logic program and interacts with other entities to access additional logic or to handle intelligent network call / service instances. .

FIG. 3 illustrates a block configuration and signal flow sharing loads by SCP groups in order to express a load sharing process in a LOCAL SSP switch according to the present invention. In FIG. 3, signals 201 to 207 represent signal flows according to a load sharing process applied to the present invention. First, when a call flows into the SSP 310 with a 201 signal, the SSP 310 registers information of the SCP 320 and gives weights to each SCP 321 ˜ 325 for load sharing purposes. Register SCP groups, register services, and register trigger information. In addition, D_SSN_AIN is added to the relation of the database configured in the SSP 310 to specify the SSN (subsystem number) for each service to the 203 signal, and a message is sent to the actual SCP to perform load sharing, and the result is signaled 205. After receiving the SSP (310) transmits the instructions of the SCP to the CCF 300 as a signal 207.

In order to perform the load sharing according to the present invention, first, the load sharing is applied to go through a registration procedure for configuring a service in the SSP 310, which is illustrated in FIG. A service configuration method for load sharing application according to a preferred embodiment of the present invention will be described with reference to the flowchart of FIG. 5.

1) Step 501: Register the SCP information for processing the intelligent network service in the service switching system (SSP).

ADD-SCP: NAME = a, SCP = b, SSN = c, GTS = XX, TT = YY, CMDLBASE = d, SCFID = e, COMMEND = f;

Here, SSN is a subsystem number, GTS is a Gloval Title Series, and TT is a Translation Type.

2) Step 503: Assign each weight to each SCP for load sharing purposes. Three steps are required to set load weighting for up to 30 SCPs.

ADD-SCPG-LOAD: NAME = a, LOAD = 10 & 20 & 30 & ... & 10, COMMENT = f;

3) Step 505: Register the SCP group in the service switching system (SSP).

ADD-SCP-GRP: NAME = a, SCPS = SCP10 & SCP20 & ... & SCP10, SCPGLOAD = xx, COMMENT = f;

Here, SCPS is used to register multiple SCPs in one group. Three inputs are required to set up to 30 SCPs in a group. The SCPGLOAD provides information for associating loads in separate relations.

4) Step 507: Register the intelligent network service to be processed in the system. At this time, the operator registers the corresponding intelligent network service key information when registering the intelligent network service.

ADD-SVC: NAME = a, SK = b, SCPG = c, LOAD = d, INFOREQ = e, COMMENT = f;

Where a is the service name, b is the service key number, c is the name of the SCP group performing the service processing, and d is the load sharing ratio of the SCPs that make up the SCP group.

5) Step 509: Register trigger information of an intelligent network service that can be provided by the system.

ADD-TRIG: NAME = a, ROUTEID = b, BNUMPRE = c, ANUMPRE = d, CPC = e, TMR = f, CAUSE = g, PRE = h, ALEN = i, BLEN = j, ARMED = k, COMMENT = l, DP = m, TYPE = n, SERVICE = o;

The item for the trigger changes, but is structurally identical. The domain D_SSN_AIN is added to R_SERVICE_SCP_GROUP so that the SSN can be designated for each service. In addition, the relation R_SCP_GROUP separates the domain D_SCP_GR_LOAD into two due to the domain limitation of the duplicate relation. Here, each SCP moves GTS and TT from R_SCP_GROUP to R_SCP so that the information can be composed of a combination of SCP (signal point code) / SSN / GTS / TT. This is possible by constructing a data structure diagram according to load sharing in the LOCAL SSP switch of FIG. 4 as a database in the SSP.

When the load flow is applied as shown in FIG. 5 and the registration procedure constituting the service in the SSP 310 is performed, load sharing may be performed when the call flows, which is shown in the preferred embodiment of the present invention shown in FIG. The load sharing method according to the present invention will be described in detail with reference to a flowchart.

When the call flows into the SSF from the CCF 300, the SSP 310 searches for trigger information from the DBMS in step 601 to find a service name. It searches for the R_TRIGGER relation to find D_SVC_NAME to find trigger information as shown in FIG. Using the service name retrieved in step 601, the SSP 310 searches for the SCP group in step 603, which searches for the R_SERVICE_SCP_GROUP relation using the D_SVC_NAME of FIG. Thereafter, in step 605, the SSP 310 searches for a real SCP to perform load sharing within the SCP group. If DPC / SSN is used, availability should be considered. In R_SERVICE_SCP_GROUP of FIG. 4, R_SCP_GROUP is searched using D_SCP_GR_NAME. In this case, R_SCP is searched using D_SCP_NAME. In the R_SCP, each SCP allows the information to be composed of a combination of SPC / SSN / GTS / TT. The GTS / TT of the existing SCP_GRP is moved here. If all steps up to step 605 have been completed, the process proceeds to step 607 and the SSP 310 wraps and sends a message to the corresponding SCP 320.

On the other hand, in the detailed description of the present invention has been described with reference to specific embodiments, of course, various modifications are possible within the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined not only by the scope of the following claims, but also by the equivalents of the claims.

As described above, the present invention has the effect of allocating the same single service to several signaling points of the SCP by performing load sharing of the next-generation intelligent network LOCAL SSP switch.

In addition, the present invention has an effect that can be divided loads for each SCP of the SCP group assigned to the same service.

In addition, in the present invention, since the structure of the relation is applied to the internal data as it is, the SSF can simplify the processing.

In addition, when the SSN is allocated to each service, only the signaling point information may be present in the R_SCP, and thus, various combinations may be configured for each service.

Claims (2)

In the load sharing method of next generation intelligent network local service exchange system (LOCAL SSP) switch, Registering service control system (SCP) information for processing an intelligent network service in the service switching system; Assigning each weight to each service control system for load sharing purposes, Registering the service control system group with the service switching system; Registering the intelligent network service to be processed in the service exchange system; Registering trigger information of an intelligent network service that can be provided by the service switching system; When a call flows from a call control function block (CCF), searching for trigger information registered in the service switching system to find a service name; Searching for the service control system group using the service name; Searching for an actual service control system to perform load sharing within the service control system group; A method of load sharing in a next-generation intelligent network local SSP switch, comprising a process of packaging and transmitting a message to a corresponding service control system. The method of claim 1, The service switching system adds a domain D_SSN_AIN to the service-service control system-group relation (R_SERVICE_SCP_GROUP) that can specify a subsystem number (SSN) for each service in the internal data for the load sharing, and the service control system-group Point the relation (R_SCP_GROUP) to separate the service control system-group-load domain (D_SCP_GR_LOAD) into two, and separate the corresponding information from each service control system in signal point code / subsystem number / global title series / transfer type (SPC). / SSN / GTS / TT) in the next-generation intelligent network local SSP exchanger to move the global title series (GTS) and transmission type (TT) to the service control system relation (R_SCP) so that it can be composed of a combination of Load sharing method.