KR20050088840A - Method for managing call resource in intelligent network system and system thereof - Google Patents

Abstract

The present invention relates to an intelligent network system management method and apparatus therefor. More specifically, the present invention relates to a method and apparatus for intelligent call management system for managing an intelligent network system for intensively managing call resources, and for organically handling a call with an interworking system (SCP / IP / SSP).

Description

Method for managing call resource in intelligent network system and system therefor {Method for managing call resource in Intelligent Network System and system}

The present invention relates to an intelligent network system management method and apparatus therefor. More specifically, in the present invention, an intelligent network management system (Service Management System, hereinafter referred to as "SMS") that manages an intelligent network system intensively manages call resources, and organically communicates with a linked system (SCP / IP / SSP). It relates to a method and a device for processing the.

1A shows the configuration of an intelligent network system in a communication network.

Referring to FIG. 1A, an intelligent network system in a communication network includes an SMS 100, a service control point (“SCP”) 110-1, 110-2,. Collectively referred to as "110"), Intelligent Peripheral (hereinafter referred to as "IP") (120a, 120b, collectively referred to as "120"), Service Switching Point (hereinafter referred to as "SSP") ( 130-1, 130-2, ... 130-n, collectively referred to as "130"), and the organic connection structure between each system is shown in FIG. 1A. Hereinafter, after briefly explaining the main functions of each component, the overall operation of the intelligent network system will be described.

The SMS 100 performs subscriber information (subscriber information database) management and backup (Back-Up) function and system management function. The subscriber information management and backup function of the SMS 100 manages the intelligent network service subscriber information in association with the SCP 110 and backs up the subscriber information for use in the event of a failure of the SCP 110. The system management function of the SMS 100 manages and reports the status of the intelligent network components SCP 110, IP 120, and SSP 130. Here, the subscriber information may be any one of a phone number of a subscriber station, a mobile identification number (MIN), a prepaid card number, and prepaid card balance information.

SCP 110 is a system for managing intelligent network service subscribers and performing service logic. SCP 110 manages profiles and related DBs of intelligent network service subscribers for call processing and service logic execution. Perform logic Service logic execution function is the main function of SCP (110).

IP 120 is a system for providing a convenience to the subscriber interface to interface with the subscriber in conjunction with the SSP 130 under the control of the SCP (110). As the interface method, voice (ARS), voice recognition, text-to-speech, and the like are possible.

SSP 130 provides basic call processing and service switching functions. In more detail, the basic call processing function is a function of providing a bearer channel to an intelligent subscriber, and the service switching function determines the type of the intelligent network service and connects the call with the corresponding call control system (SCP 110). This is a function to perform processing.

Hereinafter, a basic call processing procedure of the above-described intelligent network system will be described with reference to FIG. 1B. Call processing procedure of intelligent network service can be generated in various forms according to the service type, and the procedure is described based on the most commonly developed prepaid card service. In addition, when defining the detailed procedure, the standard protocol is described based on the CDMA ?? WIN standard. SCP 110 is classified by the calling number to accommodate the subscriber to the intelligent network service, subscriber information (including prepaid card information) is managed in the same manner by SMS (100), SCP (110). If the prepaid card is produced / distributed through the SMS (100) will be transmitted to all SCP (110) linked to the SMS (100).

In step S100, when the prepaid card customer dials a called number including a service access code (hereinafter referred to as "SAC"), the call is introduced into the SSP 130, and the SSP 130 translates the calling number. To perform an analysis information (AnalyzedInformation, hereinafter referred to as "ANLYZD") message including the SAC to the SCP (110).

In step S105, upon receiving the ANLYZD message, SCP 110 first determines that the requested call is a prepaid card service call by translating the SAC included in the received message. Thereafter, a channel setting is performed between the IP 120 and the SSP 130 to perform a subscriber prepaid card number authentication procedure through the IP 120 based on service logic. That is, a resource allocation message (SeizeResource, hereinafter referred to as "SEIZERES") that requests IP resource allocation from the SCP 110 to the IP 120 to establish a voice channel between the IP 120 and the SSP 130 is transmitted.

In step S110, upon receiving the SEIZERES message, the IP 120 determines whether there is an idle channel resource, and if there is an idle channel resource, in response to the corresponding SEIZERES message, the channel number (Temporary Local Directory Number, hereinafter " Send a seizeres message to the SCP (110).

In step S115, upon receiving the seizeres message including the TLDN, the SCP 110 transmits the TLDN to the SSP 130 by using a resource connection (hereinafter referred to as "CONNRES") message with the IP 120. Request channel setting.

In step S120, upon receiving the CONNERS message, the SSP 130 transmits a channel setup message (hereinafter referred to as "IAM") to the IP 120, and in step S125, the IP 120 receives an IAM. A CONnect message is sent to the SSP 130 in response to the request, and a channel setup completion notification message (hereinafter referred to as an "INSTREQ message") is transmitted to the SCP 110. By the steps S120 to S130, a voice channel between the IP 120 and the subscriber is secured (step S140).

In step S145, SCP 110 transmits the necessary announcement to the subscriber via IP 120 (ie, via SRFDIR message) in accordance with the service logic. If necessary, the subscriber responds using DTMF (subscriber's dial pad input). This response is delivered to SCP 110 via an srfdir message (step S150). Steps S145 and S150 may be repeatedly performed based on the service logic.

In step S155, when the service logic between the IP (120) ?? User is completed, the SCP 110 transmits an anlyzd message to the SSP 130 to request an incoming call. The anlyzd message contains the SCP call resource ID, call time, and called number. SCP call resource ID is transmitted to SCP 110 after the call is completed by SSP 130 in the call log (CallResultReport, hereinafter referred to as "CRRPT") message, and SCP 110 uses SCP call resource ID. To ensure consistency of call resources.

In steps S160 and S165, the SSP 130 releases the established channel with the IP 120 (REL / RLC) and performs the incoming call processing of step S170. The incoming call process may vary depending on the network type (wired network, wireless network, IMT-2000, etc.). When the incoming call process is completed, the call between subscribers starts, and when the call is completed, the call ends.

In step S180, the SSP 130 sends a call history (typically including a call start time and a call end time) to the SCP 110 at the end of the call through a CRRPT message. The CRRPT message contains the call history and the SCP call resource ID obtained when the anlyzd message was received. SCP 110 uses the SCP call resource ID as a parameter to confirm the correspondence of the call. SCP 110 also checks talk time, calculates the prepaid charges, and deducts the balance from the card account.

In step S185, the deducted information is also transmitted to the SMS 100 so that the SMS 100 can manage card information in real time.

The intelligent network system described with reference to FIGS. 1A and 1B has the following problems. First, upon registration of a new prepaid card, the SMS 100 has a problem of transmitting new prepaid card information to all SCP 110. Because the SSP 130 selects the SCP 110 accommodated by the subscriber by the calling number, all prepaid card information must be registered in all the SCP 110 associated with the SMS 100 to provide the service. Second, since the calling party number of each subscriber is designated for each SCP 110, and all prepaid card information is stored in all SCP 110, the prepaid card information is not exchanged between the SCP (110) have. Therefore, if the SCP 110 does not originally accept the subscriber's call number, the service information of the prepaid card changed after the termination of the call processing in the SCP 110 is sent to the SCP 110 originally accepting the subscriber. It is not reflected in the registered prepaid card information.

The present invention has been made to solve the above problems, and an object of the present invention is to provide an intelligent network that centralizes and manages subscriber information individually managed by a plurality of SCPs, and performs call processing and call resource management in SCPs and SSPs. This paper presents a management system (SMS), a call resource management method applicable to it, and an organic call processing method with a related system (SCP / IP / SSP).

In order to achieve the above object, according to a preferred embodiment of the present invention, in a call processing method executed in a service control point (SCP) and an intelligent network management system (SMS), Sends to the SMS the prepaid card information received from the subscriber terminal through the SCP resource ID and the channel set by the assigned call resource identifying the call resource allocated in response to the call request from the subscriber terminal, and from the SCP Upon receiving the prepaid card information and the SCP resource ID, it is determined whether the prepaid card is in service using the prepaid card information, and if the prepaid card is not in service, the prepaid card information and the prepaid card Send balance information to the SCP, and receive the prepaid card information and the balance information from the SMS If so, the temporary management information including the prepaid card information, the balance information and the SCP resource ID is recorded in the temporary management information DB for managing during the call processing period, and the incoming call processing for the prepaid card service request is performed. When the call is terminated by the incoming call processing, the call charge corresponding to the call time is calculated and transmitted to the SMS together with the prepaid card information. When the call charge and the prepaid card information are received from the SCP, the balance of the prepaid card is received. A call processing method is provided in an intelligent network system including updating, transmitting a prepaid card update response message to the SCP, and deleting the temporary management information when receiving the prepaid card update response message from the SMS.

According to another aspect of the present invention, in a call resource management method executed in an intelligent network management system (SMS), from a service control point (SCP) to subscriber identification information and a call request from a subscriber terminal Receive and register a call request including a SCP resource ID identifying a call resource assigned to the subscriber terminal as a progress call, run a timer for the progress call, and proceed from the SCP before the timer expires. Receiving call history for a call, releases the timer, releases the call resource assigned to the ongoing call, requests the SCP to confirm the call status for the ongoing call when the timer expires, and receives from the SCP. When the call status is abnormally terminated as a result of a call status check, the allocated call resource is released and the call is released from the SCP. A call resource management method in an intelligent network system including resetting the timer when the call is normally in progress as a result of the received call state check is provided.

According to another aspect of the present invention, in a call resource management method executed in an intelligent network management system (SMS), subscriber identification information and subscribers from any one of a plurality of service control points (SCPs) In response to a call request from a terminal, a call request including an SCP resource ID for identifying a call resource allocated to the subscriber terminal is received, and it is determined by determining whether a progress call corresponding to the received subscriber identification information is registered. If not, the requested call is registered as a forwarding call, and if a forwarding call corresponding to the received subscriber identification information is already registered, it is determined whether the SCP transmitting the call request is an SCP that is receiving the forwarding call, If it is determined that the SCP that sent the call request is the SCP that is receiving the progress call, the proceeding call is Removes the requested call as a forwarding call, and if the SCP which sent the call request is not an SCP that is receiving the forwarding call, requests the call status confirmation to the SCP that is receiving the forwarding call. If the call is in progress as a result of the call status check from the SCP requesting the call status check, the requested call is rejected; if the call is abnormally terminated as a result of the call status check from the SCP requesting the call status check, the proceeding call is deleted. And a call resource management method in an intelligent network system comprising the step of registering the requested call as a progress call.

According to another aspect of the present invention, an intelligent network management system (SMS) for managing call resources of an intelligent network system including a service switching point (SSP) and a service control point (SCP) A subscriber information database storing subscriber information, an ongoing call database storing call information being processed by the SSP and the SCP, a message transmitting / receiving unit performing message transmission and reception with the SCP, and subscriber identification information received from the SCP. And determining whether a progress call corresponding to the subscriber identification information is registered in the progress call database according to the call request message including the SCP resource ID and the SCP resource ID, thereby generating one of the progress call registration signal and the call status confirmation signal. And the subscriber identification information and S corresponding to the progress call registration signal. A progress call manager that registers a CP resource ID in the progress call database and deletes the subscriber identification information and the SCP resource ID corresponding to the progress call deletion signal from the progress call database; And confirming that if the determination result is the same, generating the progress call deletion signal, and if the determination result is not the same, confirming the state of the progress call from the SCP receiving the progress call and generating the progress call deletion signal; Subscriber information for transmitting the subscriber identification information to the SCP in response to the progress call registration signal, and updating the subscriber information corresponding to the subscriber identification information in response to the call history message received from the SCP and the progress call deletion signal. An intelligent network management system including a management unit is provided.

Hereinafter, with reference to the accompanying drawings will be described in detail an embodiment of the present invention applied to the prepaid card service. However, the present invention will be described with reference to the exemplary embodiments in order to enable those skilled in the art to easily understand the present invention, and the present invention is not limited to the prepaid card service.

In the communication network, the intelligent network system is composed of SMS (100), SCP (110), IP (120) and SSP 130, the call resource management related to call processing is performed by SCP (110) and SSP (130). The SMS 100 handles subscriber distribution, backup, and external interworking, and manages SCP / SSP / IP (system state management). In the intelligent network system, the system is extended to the structure of SMS (100): SCP (110) = 1: N, accordingly, there is a need to centralize and manage call resources generated from different SCP (110). In the present invention, as a method for centralizing call resources generated from a plurality of different SCPs 110, a method for managing call resources in the SMS 100 is provided. The technical implementation of the present invention presents an embodiment based on an intelligent network prepaid card service.

According to a preferred embodiment of the present invention, the SMS 100 and the SCP 110 manage subscriber information (or prepaid card information) as follows. That is, the balance information of the prepaid card that changes in real time when using the service is managed by the SMS 100, and the SCP 110 generates this information at the call processing request and deletes it at the end of the call processing.

The SMS 100 stores and manages prepaid card information and information managed by all SCPs. Prepaid card information is information provided upon request to SCP 110 upon call processing, and is information about a prepaid card number and balance. In addition, the SMS 100 stores and manages all data managed by the SCP 110 in order to back up the SCP 110.

Information managed by SCP 110 is divided into temporary management information and permanent management information. Each piece of information is managed by a database.

Temporary management information is created temporarily during the call processing phase and deleted after the call processing ends, including the prepaid card number, SCP-call resource ID, and the prepaid card balance. In addition, the rate table, call number / called number and card generation time may be managed temporarily.

The prepaid card number is received from the SMS 100 upon service request. SCP-call resource ID is a unique ID generated by SCP 110 upon service request. The prepaid card balance is received from the SMS 100 upon service request. Rate tables are managed directly by SCP 110. Calling number / called number is the information included in the request message of the SSP (130). The card generation time is a time when the prepaid card number is received from the SMS 100 after the service request.

Permanent management information is continuously managed regardless of call processing, and includes a rate table for rate calculation and data for service call processing.

2 is a flowchart illustrating a detailed call processing method between SSP-SMS-SCP according to a preferred embodiment of the present invention, and shows a normal call processing procedure. Here, the DTMF collection process of the subscriber by setting the voice channel between the SSP (130) and the IP (120) is the same as the step S105 to step S150 of FIG. 1B, SSP (130) -SCP (110) -SMS (100) below Only the interworking procedure will be described.

In step S200, when the subscriber requests the service, the SSP 130 translates the calling party's calling number and selects SCP 110, which accepts the subscriber, from among the plurality of SCPs 110, and selects the ANLYZD message which is a service request message. Transmit to 110.

In step S205, the SCP 110 receiving the ANLYZD message determines that the requested service is a prepaid card service through the SAC included in the called number of the ANLYZD message, and transmits a make-card message to the SMS 100. do. The card generation message includes the prepaid card number, password, and SCP call resource ID. Here, the prepaid card number is a prepaid card number received from the subscriber, the password is a password for the prepaid card number received from the subscriber, SCP call resource ID is the call resource ID of SCP (110).

In step S210, after receiving the card generation message, the SMS 100 determines whether the prepaid card number is in service, and then sends a SCP make-card message including balance information corresponding to the prepaid card number. Transmit to 110. At the same time, the SMS 100 manages the prepaid card number in service by managing the SCP call resource ID for the prepaid card number.

In step S215, the SCP 110 receiving the card generation response message records the temporary management information in the temporary management information DB in order to use the included balance information during the call processing period. As a result, call resource management by SCP 110 is started, and after calculating the available call time with reference to the rate table, it transmits to SSP 130 through an anlyzd message.

In step S220, when the SSP 130 receives the anlyzd message, the subscriber initiates the call. In step S225, when the call is terminated, the SSP 130 transmits the call history (ie, talk time) to the SCP 110 through the CRRPT message.

In step S230, the SCP 110 receives the CRRPT message, calculates the call charge using the talk time in the CRRPT message, and notifies the SMS 100 of the update-card message. Here, the Update-Card message includes a prepaid card number and a call charge.

In step S235, the SMS 100 receiving the card update message subtracts the call charge from the remaining balance of the prepaid card number and transmits a card update response message to the SCP 110. In step S240, upon receiving the normal card update response message, SCP 110 transmits a crrpt response message to SSP 130 and deletes the corresponding temporary card DB. Even when an abnormal response is received, SCP 110 deletes the corresponding temporary card DB and logs the call processing (service) history including the reason.

3 is a flowchart schematically illustrating a process of checking call status between SMS and SCPs for call resource management according to an exemplary embodiment of the present invention. The call status checking process is performed together with the call processing method of FIG. 2 and the call resource management method of FIGS. 4 and 5, but will be described below for convenience of description. An embodiment in which the call processing method and the call resource management method are simultaneously applied will be described after the call resource management method is described in detail.

The parameter used by SMS 100 for call resource management, including call status check, is any one or combination of SCP call resource IDs, prepaid card numbers, and originating numbers received from SCP 110. Possible combinations include SCP call resource ID-prepaid card number, SCP call resource ID-call number and SCP call resource ID-prepaid card number-call number. Whether dual management of prepaid card number and calling number or only prepaid card number is managed may be determined according to reliability of call resource management. SCP call resource ID is an ID uniquely assigned by SCP 110 when a call is generated, and is composed of a corresponding SCP 110 number (SCP #) and a unique serial number. The prepaid card number may use a prepaid card number managed by the SMS 100 or a prepaid card number received when a call is generated from the SCP 110. The caller ID is the caller ID received from SCP 110 upon call request.

Referring to FIG. 3, the call status checking process in the SMS 100 is a method of confirming by querying a corresponding SCP 110 that has requested a call processing, and the procedure is as follows.

In step S300, when the call resource needs to check the status of the call resource, the SMS 100 checks the SCP 110 requesting the call resource and transmits a call status check message to the corresponding SCP 110.

In step S310, the SCP 110 receives the call status check message, checks the call progress status for the call requested to check the status, and transmits a call status check (call-check) message to the SMS (100). Steps S300 and S310 may also be affected by the call progress state in the SSP 130. In response to the call status response message, the SMS 100 operates according to the corresponding call resource management logic (or service logic).

The call state checking process of the SMS 100 described above includes a periodic method and an event method, and both methods may be independently applied. In the periodic method, the SMS 100 starts a call resource management timer (Timer) after receiving the call, and requests the call status confirmation message to the SCP (110) for each period pre-registered by the subscriber (system operator).

In the event method, the SMS 100 requests a call state confirmation message to the SCP 110 when a call state confirmation event occurs. The type of event depends on the service scenario and status management reliability, but representative cases include: (1) A call is in progress in the SMS 100, a new call setup request is received from SCP 110, and (2) by the system operator. There is a case where call status check is requested.

4 and 5 are flowcharts illustrating a call resource management method between SSP-SCP-SMS. Systems that receive call processing and call resource management in an intelligent network system are SSPs 130 and SCP 110, and systems that perform call processing and call resource management are SMS 100. The call resource management method between the SSP 130, the SCP 110, and the SMS 100 may be divided into an SMS control method and an independent control method according to a call state confirmation message processing method of the SCP 110. The difference between the SMS control method and the independent control method is whether the call status confirmation message of the SMS 100 is transmitted to the SSP 130. In addition, the subjects releasing abnormally terminated call resources may vary. Both methods may apply the periodic method and the event method described with reference to FIG. 3.

The SMS control method is a method in which the call status confirmation message of the SMS 100 is transmitted to the SSP 130 as shown in FIG. 4. In step S400, when the SMS 100 transmits a call-check message to the corresponding SCP 110 according to a predetermined condition, the SCP 110 that receives the call status check message in step S410 corresponds to the corresponding message. The call state check (Call-State) message is sent to the SSP (130). After receiving the call state confirmation message in step S420, the SSP 130 checks the call state for which confirmation is requested, and then transmits a call state confirmation response (call-state) message to SCP 110, in step S420 SCP (110). ) Sends a call-check message to the SMS 100. According to the SMS control method, since the SMS 100 can directly control a call currently in progress, when the call is abnormally terminated as a result of receiving a call-check message, the SMS 100 releases the call resource. Logging may be performed for the call.

The independent control method responds to the call status confirmation message of the SMS 100 based on the call status of the SCP 110, and the SCP 110 responds to the SSP 130 by the control of the SMS 100 or independently. Call management can be performed. In step S500, when the SMS 100 transmits a call check message to the corresponding SCP 110 according to a predetermined condition, the SCP 110, which has received the call status check message in step S510, is currently SSP. Answer the call state of 130. That is, SCP 110 independently checks the call status, and the call status performed on the SSP 130 immediately before receiving the call status confirmation message from the SMS 100 to the SMS 100 through the call status confirmation response message. send. In step S520, the SSP 130 transmits a call state confirmation message to the SSP 130 by a periodic method or an event method, and sends a call state check response (call-state) message in response thereto. Receive. Steps S520 and S530 are executed independently of steps S500 and S510. According to the independent control method, the SMS 100 can confirm this only when the call status confirmation message is sent after the SCP 110 confirms the abnormally terminated call. Therefore, call resource management between SCP-SSP is performed according to the call resource management logic of SCP 110 previously set. That is, SCP 110 updates only (1) call state information and does not release call resources when confirming abnormal call termination, releases call resources after receiving call resource release message from SMS 100, or (2) Release the call resource and report the release of the call resource to the SMS 100 (period or immediately upon release), or (3) release the call resource and receive the call status confirmation message from the SMS 100 in response to the call resource. Release can be reported.

Hereinafter, when an abnormally terminated call is identified, call processing and call management procedures will be described by dividing the periodic method and the event method. As described above, the periodic method and the event method may be executed independently, and both methods may be applied to call processing and call management procedures.

-Abnormally terminated call in a periodic manner

In a periodic manner, the occurrence of the call status confirmation message may be caused by a message loss between each system (a message loss can also be interpreted as a time ?? out from the point of view of the message receiving system) or a timeout. In other words, if the SMS 100 does not receive the message during the set period, the SMS 100 transmits a call status confirmation message to the SCP 110. Based on the system analysis, there are two cases of message loss.

(1) Loss of CRRPT message between SSP and SCP

(2) Successfully received CRRPT message between SSP-SCP but lost card update message between SCP-SMS

In both cases, the SMS 100 transmits a call status confirmation message to the SCP 110, and the SCP 110 responds to the requested call status confirmation message according to the SMS control method or the independent control method. According to the content of the call status confirmation response message, the SMS 100 may operate as follows.

If the current call is normally in progress (In-Call), the SMS 100 maintains the call resources and resets the timer for periodic confirmation. If the current call is abnormally terminated (Non-Call), the SMS 100 releases the call resource and performs logging on the call.

If the call ends abnormally in the event mode

A typical abnormal case in the event method is a case in which the SMS 100 manages a progress call and receives a new call for a prepaid card (or subscriber). The processing method in the SMS 100 differs depending on whether the SCP 110 requesting the call managed by the SMS 100 is the same as the SCP 110 requesting the new call.

(1) SCP (110) is the same

As a specific example, a call managed by the SMS 100 is requested from SCP 110-1, and a new call is also requested from SCP 110-1. In this case, the SMS 100 deletes the call currently being managed (SCP 110-1) and accepts a new call (SCP 110-1). Since SCP 110-1 manages call resources on a prepaid card (or subscriber) basis, it means that existing calls are already terminated abnormally when a new call occurs.

(2) SCP (110) is not the same

As a specific example, a call managed by the SMS 100 is requested from SCP 110-1, and a new call is requested from SCP 110-2. In this case, the SMS 100 requests the call state confirmation to the SCP 110-1, and the SMS 100 may operate as follows according to the contents of the call state confirmation response message.

If the call is currently in progress in the SPC 110-1 (In-Call), the SMS 100 maintains the call resource of the SPC 110-1 and the call requested by the SCP 110-2 is treated as an illegal call. Refuse to accept the call. If the call is abnormally terminated in the current SPC 110-1 (Non-Call), the SMS 100 releases the call resource of the SPC 110-1 and receives a new call requested from the SCP 110-2. Accept. That is, the call currently being managed by the SPC 110-1 is abnormally terminated. Therefore, the SMS 100 performs logging on the call managed by the SPC 110-1.

6 is a block diagram illustrating a call resource management function of the SMS according to an embodiment of the present invention. The functional configuration of the SMS will be described with reference to the aforementioned call processing and call resource management method. The SCP backup function of SMS is a function of backing up data managed by SCP, which can be easily understood by those skilled in the art to which the present invention pertains, and thus a detailed description thereof will be omitted.

Referring to FIG. 6, the SMS includes a subscriber information database, a progress call database, a progress call determination unit, a progress call manager, a status checker, and a subscriber information manager.

The subscriber information database 670 stores subscriber information. The subscriber information may be any one or a combination of a phone number, a mobile identification number (MIN), a prepaid card number, a prepaid card password, a prepaid card balance information, and a service identification information requested by the subscriber. When the call request message is received from the SCP 110, the prepaid card balance information stored in the subscriber information database 670 is read and transmitted. When the CRRPT message is received, the included call charge is deducted from the prepaid card balance information.

The progress call database 660 stores the call information that the SSP 130 and the SCP 110 are receiving. The progress call database 660 may include at least one of subscriber identification information and SCP resource ID.

The message transmitting and receiving unit 610 transmits and receives a message with the SCP (110). Messages received from SCP 110 are call request messages (e.g., card creation messages), call history messages (e.g., card update messages), call status response messages, and messages sent to SCP 11 are: Call approval message (e.g., card generation response message), call status confirmation message. In addition, various messages are transmitted / received between the SCP 11 and the SMS 100 through the message transmission / reception unit 610 in the form of a request message-response message. The received message is input by the message transceiver 610 to a corresponding processor.

When the progress call determination unit 620 receives the call request message including the subscriber identification information and the SCP resource ID received from the SCP 110, it determines the type of the requested service and requests the request through the subscriber information database 670. It is determined whether the provided service can be provided to the subscriber. As a representative determination method, duplicate call check may be applied. That is, it is determined whether the progress call corresponding to the subscriber identification information included in the call request message is already registered in the progress call database 660. If it is determined that the call request is not registered (that is, not a duplicate call), the progress call registration signal is transmitted to the progress call manager 630 and the subscriber identification information and the SCP resource ID to store the call request in the progress call database 660. And print it out together. As a result of the determination, if the call is already registered (that is, a duplicate call), the call status check signal is output to the status check unit 640 to check the status of the progress call.

The progress call manager 630 registers the subscriber identification information and the SCP resource ID input together with the progress call registration signal in the progress call database 660, and proceeds with the subscriber identification information and the SCP resource ID input together with the progress call deletion signal. Delete from call database 660. Here, the progress call deletion signal is input by the progress call determination unit 620, the status confirmation unit 640, and the subscriber information management unit 650.

The status checker 640 checks whether the SCP requesting the duplicated call is the same as the SCP that has already received the registered call by the call status check signal input from the progress call determiner 620. If the determination result is the same, the progress call deletion signal is output to the progress call manager 630 to delete the progress call already registered, and finally, the requested call is registered as the progress call. If the determination result is not the same, the status of the progress call is confirmed by the SCP that is receiving the progress call. SCP identification is performed by sending a call status confirmation message and receiving a response to the SCP that is receiving the registered progress call. As a result of confirmation, if the registered progress call is still validly in progress, the finally requested call is illegal and rejects the lake. As a result of the check, if the registered progress call ends abnormally, the previously registered progress call is deleted (i.e., generating the progress call deletion signal), and finally the requested call is registered as the progress call (i.e., the progress call registration signal is generated). )do.

The subscriber information management unit 650 transmits subscriber identification information to the SCP 110 in response to the progress call registration signal input from the progress call determination unit 620 and the status check unit 640, and received from the SCP 110. The subscriber information corresponding to the call history message and the progress call deletion signal inputted from the progress call determination unit 620 and the status check unit 640 is updated.

As described above, in the present specification, a method and apparatus for call processing and call management in an intelligent network system of a communication network have been described with reference to embodiments. However, the present invention is not limited to the above embodiments, and many variations are possible by those skilled in the art within the spirit of the present invention. In addition, the scope of the present invention can be interpreted only by the claims described below.

As described above, the call processing and call resource management method and apparatus of the present invention have expanded the range of services that can be implemented in an intelligent network system. That is, in the intelligent network system according to the present invention, since subscriber information and call processing / call resources are centrally managed in SMS, the flexibility of the intelligent network system structure is increased (that is, the structure of SMS-SCP), and the flexibility of intelligent network service development is also increased.

1A shows the configuration of an intelligent network system in a communication network.

1B is a flowchart illustrating a basic call processing procedure of an intelligent network system.

2 is a flowchart illustrating a detailed call processing method between SSP ?? SMS ?? SCP according to a preferred embodiment of the present invention, and illustrates a normal call processing procedure.

3 is a flowchart schematically illustrating a call status checking process between SMS ?? SCPs for call resource management according to an exemplary embodiment of the present invention.

4 is a flowchart illustrating an SMS control method which is one of call resource management methods according to an exemplary embodiment of the present invention.

5 is a flowchart illustrating an independent control method which is one of call resource management methods according to an exemplary embodiment of the present invention.

6 is a block diagram illustrating a call resource management function of the SMS according to an embodiment of the present invention.

Claims (15)

In the call processing method executed in a service control point (SCP) and an intelligent network management system (SMS), Transmitting the prepaid card information received from the subscriber station to the SMS through an SCP resource ID identifying an assigned call resource in response to a call request from the subscriber station and a channel established by the assigned call resource; Upon receiving the prepaid card information and the SCP resource ID from the SCP, it is determined whether the prepaid card is in service using the prepaid card information, and if the prepaid card is not in service, the prepaid card information and the Transmitting balance information of a prepaid card to the SCP; Upon receiving the prepaid card information and the balance information from the SMS, temporary management information including the prepaid card information, the balance information and the SCP resource ID is recorded in a temporary management information DB for managing during a call processing period, Performing an incoming call processing for the prepaid card service request, calculating a call charge corresponding to a call time when the call is terminated by the incoming call processing, and transmitting the call charge to the SMS together with the prepaid card information; Upon receiving the call charge and the prepaid card information from the SCP, updating the balance of the prepaid card and transmitting a prepaid card update response message to the SCP; And And upon receiving the prepaid card update response message from the SMS, deleting the temporary management information. The method of claim 1, wherein the transmitting of the SCP resource ID and the prepaid card information received from the subscriber terminal to the intelligent network management system identify the call resource allocated to the prepaid card service request from the subscriber terminal. Determining the requested service type by translating a service access code (SAC) included in a service request message corresponding to a service request from a subscriber station transmitted from a service switching point (SSP); ; If the service type is a prepaid card service, establishing a channel between the subscriber station and an intelligent network device (IP) and generating the SCP resource ID for identifying a call resource allocated for the channel setting; And And transmitting the prepaid card information received from the subscriber station and the generated SCP resource ID to the intelligent network management system through the established channel. The method of claim 1, wherein the prepaid card information comprises at least one of a prepaid card number and a password. The method of claim 1, wherein the temporary management information further comprises at least one of a rate table, a calling number, a called number, and a card generation time. The method of claim 1, Receiving a call request including the prepaid card information and the SCP resource ID from the SCP, registering the call as an ongoing call and periodically requesting call status confirmation to the SCP by running a call resource management timer; And And releasing the allocated call resource if the call state is abnormally terminated as a result of the call state check received from the SCP. The method of claim 1, Registering the call as an ongoing call when receiving the call request including the prepaid card information and the SCP resource ID from the first SCP when the SCP is composed of a first SCP and a second SCP; Determining whether the SCP transmitting the same prepaid card information is the first SCP when receiving the same prepaid card information received from the first SCP from any one of the plurality of SCPs; If it is determined that the SCP transmitting the same prepaid card information is the first SCP, deleting the ongoing call and registering the last requested call as the advanced call; Requesting a call status check to the first SCP if the SCP transmitting the same prepaid card information is not the first SCP; If the call is in progress as a result of the call state check received from the first SCP, rejecting the last requested call; And If the call is abnormally terminated as a result of the call state check received from the first SCP, deleting the ongoing call and registering the last requested call as the advanced call. In the call resource management method running in an intelligent network management system (SMS), Receiving a call request including an SCP resource ID for identifying a call resource allocated to the subscriber terminal in response to a call request from the subscriber terminal from the service control point (SCP) and registering the call request as an ongoing call step; Driving a timer for the progress call; Releasing the timer and releasing the call resource allocated to the progress call if receiving the call history of the progress call from the SCP before the timer expires; Requesting call status confirmation for the ongoing call to the SCP when the timer expires; Releasing the allocated call resource if the ongoing call is abnormally terminated as a result of the call state check received from the SCP; And And resetting the timer when the call is normally in progress as a result of the call state check received from the SCP. The method of claim 7, wherein the SCP receiving the call status check request requests a call status check to a service switching point (SSP) that is processing the ongoing call, and receives a response from the SSP. Call resource management method in intelligent network system transmitted to SCP. The method according to claim 7, wherein the SCP requests the call status check to the service switching point (SSP) which is processing the incoming call and stores the received response as the current state of the proceeding call, And receiving the call state confirmation request from the SMS, transmitting the current state of the stored call to the SMS. In the call resource management method running in an intelligent network management system (SMS), Receives a call request from the service control point (SCP) from among a plurality of service control points (SCPs) including an SCP resource ID identifying a call resource assigned to the subscriber terminal in response to a call request from the subscriber terminal. Making; Determining whether a progress call corresponding to the received subscriber identification information is registered, and if not, registering the requested call as a progress call; If the progress call corresponding to the received subscriber identification information is already registered, determining whether the SCP sending the call request is the SCP that is receiving the progress call; If the SCP that transmits the call request is an SCP that is receiving the progress call, deleting the progress call and registering the requested call as a progress call; Requesting a call status check to the SCP receiving the ongoing call if the SCP that has sent the call request is not the SCP that is receiving the ongoing call; Rejecting the requested call if it is an ongoing call as a result of the call status check from the SCP requesting the call status check; And And deleting the progress call and registering the requested call as a progress call if the call status is abnormally terminated as a result of the call status check from the SCP requesting the call status check. The method of claim 10, wherein the SCP receiving the call status check request requests a call status check to a service switching point (SSP) that is in progress of processing the incoming call, receives a response from the SSP, and Call resource management method in intelligent network system transmitted to SCP. The method according to claim 10, wherein the SCP requests the call status check to the service switching point (SSP) which is processing the incoming call, and stores the received response as the current state of the proceeding call, And receiving the call state confirmation request from the SMS, transmitting the current state of the stored call to the SMS. The method of claim 10, wherein the subscriber identification information is any one of a terminal telephone number, a terminal identification number (MIN), and a prepaid card number. In an intelligent network management system (SMS) that manages call resources of an intelligent network system including a service switching point (SSP) and a service control point (SCP), A subscriber information database storing subscriber information; An ongoing call database storing call information being processed by the SSP and the SCP; A message transmitting / receiving unit which transmits and receives a message with the SCP; In response to the call request message including the subscriber identification information and the SCP resource ID received from the SCP, it is determined whether a progress call corresponding to the subscriber identification information is registered in the progress call database. Progress call determination unit for generating any one; Registering the subscriber identification information and the SCP resource ID in the progress call database corresponding to the progress call registration signal, and deleting the subscriber identification information and the SCP resource ID corresponding to the progress call deletion signal from the progress call database; Call manager; Confirm whether the SCP is the same by the call status check signal, if the determination result is the same, generate the progress call delete signal; if the determination is not the same, the status of the progress call is confirmed from the SCP that is receiving the progress call, the progress A state checking unit generating a call deletion signal; And Subscriber information for transmitting the subscriber identification information to the SCP in response to the progress call registration signal, and updating the subscriber information corresponding to the subscriber identification information in response to the call history message received from the SCP and the progress call deletion signal. Intelligent network management system including a management unit. The call state of claim 1, wherein the status confirmation unit drives a timer in response to the progress call registration signal, and when the set time expires without receiving a call history message from the SCP. Intelligent network management system to generate a call clearing signal received confirmation.