KR100452073B1 - Short message service system - Google Patents

Abstract

MobilePOST Short Message Service Center (SMSC) applied in the present invention is a text-based text format in a limited size between a mobile station (Mobile Station) and a mobile terminal, a mobile terminal and an ESME (External Short Message Entity) or ESME and ESME in a mobile network. It is a system that exchanges and delivers between SMEs (Short Message Entity).

In the present invention, when processing a short message submitted from a Short Message Service Center (SMSC) based on CDMA (Code Division Multiple Access), access to a relational database for storing and charging a message for short message transmission and message scheduling The present invention relates to a short message storage technique that can minimize the problem of delay caused by the system and have the best performance.

The configuration of the present invention is a shared memory application technique for storing short messages linked by linked-list, and stored in a file system for reliability of short messages that may be lost due to unstable operation of the system and initialization of the operator. It is implemented as a technique to save and to a relational database to provide the billing processing of the user's convenient short message. Accordingly, the present invention is a storage scheme of an optimal SMSC system capable of high-speed transmission and reliable message transmission in short message processing in a CDMA-based SMSC.

Description

Short message service system {SHORT MESSAGE SERVICE SYSTEM}

The present invention relates to a Code Division Multiple Access (CDMA) based Short Message Service Center (SMSC) having a message storage technique for high-speed transmission of short messages and reliable message transmission. The present invention relates to an SMSC capable of ensuring high-speed transmission and reliability in message transmission by providing an effective storage method for a message, a storage method for providing reliability of message transmission, and a relational database storage method for billing processing.

1 shows a schematic configuration of an SMS. An object for requesting a short message service (SMS), the mobile station (MS) such as a PCS terminal or a cellular terminal 310a-310d and an external short message entity such as an E-Mail Server or a Voice Mail Server ESME (External Short Message Entity); 210a-210c, SMSC 100 as a short message service entity, and data network 200 and signaling network 300 as network means between the above components. Under such a system, a short message service can be provided between the MS and the MS, between the MS and the ESME, or between the ESME and the ESME.

2 shows a configuration of a conventional SMSC.

The SMSC 100 processes the short message as a whole and includes processor means 110 for managing all components in the device, shared memory 120 for storing all received short messages and information, unstable operation of the system and initialization of the operator. File system 130 additionally stores short messages and information in preparation for the possibility of being lost, and a relational database 140 that stores charging processing information of the short messages.

According to the memory utilization method of the conventional SMSC, when one short message is received by the SMSC 100, the processor means 110 accesses the shared memory 120, performs a procedure for storing it, After that, a procedure of accessing the file system 130 to move and restore the necessary information is performed, and finally, the access to the relational database 140 is performed in order for the billing process. Only after performing all of these message storage procedures will the processor means 110 operate to perform processing steps for the next short message.

That is, under the method in which the processor means 110 sequentially accesses each data storage means and performs a data storage procedure, since the other means cannot be processed at all during a specific process of processing one short message, This can cause unnecessary delays in processing short messages. In addition, in the case of Busy Hour Short Message (BHSM), since the traffic of the system transmits an average of 300-400 messages per second, the message storage method of this structure effectively processes all short messages entered into the SMSC 100. Sometimes problems arise.

In view of the above problems, an object of the present invention is to provide a mobilePOST SMSC to which a storage technique for minimizing time delay of a message storage process occurring in short message processing and a storage technique for improving reliability in message transmission.

In order to achieve the above object, the present invention provides a short message processing structure using a connection list of a shared memory for storing and changing a short message submitted to a mobilePOST SMSC. In order to provide reliability, it includes a storage method to a file system and a storage method to a relational database for message management of an operator operating an SMSC.

1 is a schematic diagram showing the overall configuration of a short message service (SMS) system to which the present invention is applied;

2 is a block diagram showing the configuration of the SMSC 100 according to the prior art.

3 is a block diagram showing a characteristic configuration of the SMSC 100 according to the present invention.

4 is a diagram showing a detailed configuration of the mobilePOST SMSC core 150 of FIG.

5 is a diagram illustrating a detailed configuration of the shared memory 120 of FIG. 3.

6 is a diagram showing a detailed configuration of BATH 501 of FIG.

7 is a diagram showing the detailed configuration of the NOTE 502 of FIG.

8 is a diagram illustrating a transmission relationship of signals transmitted to each other to perform a short message service between detailed components of an SMSC according to the present invention.

9 is a flowchart for SMS transmission in accordance with the present invention.

10 is a flowchart illustrating a procedure inside a POST for generating SUBMIT_ACK and transmitting it to SMPP.

11 is a flowchart illustrating a procedure inside a POST for sending a REQUESTING token to the CSNI.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying block diagrams and flowcharts.

3 shows a detailed configuration of the SMSC 100 according to the present invention. The SMSC 100 according to the present invention includes a mobilePOST SMSC core 150, an SMPP module 160, a CSNI module 170, a shared memory 120, a file system 130, and a relational database 140. It is composed.

First, the mobilePOST SMSC core 150 controls the transmission and reception of information signals with the outside in connection with the SMPP module 160 and the CSNI module 170, which will be described later, for processing required for short message transmission. An overall control operation related to short message transmission such as storing or reading information to be transmitted to the shared memory 120, the file system 130, and the relational database 140 is performed.

The SMPP module 160 performs interfacing using the SMPP protocol with external ESMEs such as EMS (E-Mail Server), Voice Mail Server (VMS), etc., and receives a short message transmitted to the mobilePOST SMSC 100. And writes to the shared memory 120 and notifies the mobilePOST SMSC CORE 150 of the recording-related matters.

The CSNI module 170 is a signaling network 300 preferably Signaling System No. 7 It is responsible for interfacing with the network, and generates a single mobile application part (MAP) operation according to the IS41 / IS637 protocol specification and encapsulates a short message to be transmitted to the wireless network into a TCAP (Transaction Capabilities Application Part). (Encapsulation) Performs the function.

The shared memory 120 stores the input short message information and all related information, and the file system 130 is shared for reliability of the short message that may be lost due to unstable operation of the system and initialization of the operator. Some information stored in the memory 120 is re-stored, and the relational database 140 performs a function of storing necessary information in the operator's billing process. Here, the characteristic is that mobilePOST SMSC core 150, SMPP module 160, CSNI module 170, file system 130, and relational database 140 are all directly accessible to shared memory 120. That is, the storage data information of the shared memory 120 is configured to be transmitted in the form of token between the above components.

Referring to the operation of the SMSC 100 having the above configuration, first, when a short message transmission request comes through the data network 200, the SMPP module 160 first stores all the information in the shared memory and stores the stored information in the mobilePOST SMSC. The core 150 is notified. After receiving this notification, the mobilePOST SMSC core 150 performs (or simultaneously with) the process of recording or changing the necessary information in the file system 130 and the relational database 140, and then the CSNI module 170. And a corresponding short message to a destination through the signaling network 300.

FIG. 4 illustrates the process of the mobilePOST SMSC core 150 of FIG. 3.

mobilePOST SMSC core 150 includes POST 401, LOGM (LOG Management) 402, Short Message Timer Management (403), TICK (404), Scheduling Message Management Process (SMMP) 405, DBBANK (DataBase BANK); 406), MBNK (Management BaNK; 407), SMDB (Short Message DataBase; 408), BANK (409), GUIP (Graphic User Interface Process) 410, and SPON (SpawN; 411) processor.

POST 401 is a control unit that is responsible for the brain in the message processing of the mobilePOST SMSC core 150, LOGM 402 is responsible for the management of logging files and billing files generated in the operating system, SMTM (403 ) Checks the time in each state for a short message, and TICK 404 performs a function that tells a particular time each application should be run regularly.

In addition, SMMP 405 manages scheduling messages stored in the database, DBBANK 406 is responsible for generating CDR files for billing messages stored in the database, MBNK 407 is a short message to be stored in the database , And the SMDB 408 performs a function of synchronizing between the shared memory and the file system, and the BANK 409 plays a role of generating a CDR file at a predetermined interval with respect to the generated billing files. The 410 manages various commands with operators accessing the mobilePOST SMSC from the outside, and finally, the SPON 411 performs a function of monitoring and managing the processing of the entire mobilePOST SMSC.

FIG. 5 illustrates a configuration of the shared memory 120 of FIG. 3.

The shared memory 120 of the mobilePOST SMSC 100 includes a BATH 501 portion allocated for short message processing and a NOTE 502 portion allocated for operation and maintenance of data.

6 shows a detailed configuration of the BATH 501, where the BATH 501 is a POOL 601, an empty POOL connection list 602, a timer connection list 603, a MIN connection list 604, and a PCS. Structure 605.

POOL (601) stores the payload text and basic parameters of short messages, and the total number of POOL is 5,040,000 (500 (messages per second) * 60 (1 minute) * 24 (1 day) * 7 ( 1 week)).

An empty POOL Link List (602) constructs and operates a POOL, which is empty to store a short message that the POST 401 will receive as a linked list.

The timer link list 603 is operated to meet the time requirements and constraints of various methods before sending the received short message to the destination.

The MIN Link List 604 is used to manage all short messages submitted by an ESME or a mobile terminal in each state.

Finally, a PCS Structure (605) is provided for managing information of various signal networks related to the mobile terminal, which is the destination of the received short message, by interacting with the MIN connection list.

In addition, the NOTE 502 shown in FIG. 7 is used for the operation and maintenance of the short message requested to be transmitted. In order to provide detailed statistics and management information required for each transmission step in processing the short message, a configuration table is provided. 701 and a statistics table 702.

The configuration table 701 applies all configuration changes required by the administrator during the operation of the mobilePOST SMSC to the operation of the mobilePOST SMSC in real time. Therefore, it provides a concise working environment when adding or creating a functional process that is responsible for a specific function or changing source code.

Detailed description of the components of the configuration table is as follows.

Configuration Table Opmtbl Table managed to notify the operator's system of events occurring in mobilePOST SMSC Pfxtbl Configuration table to determine the prefix of MIN number to be operated among messages received by mobilePOST SMSC Smetbl ESME related tables accepted by mobilePOST SMSC Tsvtbl Configuration Table for Teleservice supported by mobilePOST SMSC Smrtbl Table that interacts with Svctbl and manages the next transmission of the short message according to the value responded in each step of short message. Frmtbl Configuration table that interacts with Smrtbl and Acttbl and mutually couples with Acttabl according to Smrtbl's configuration Acttbl Configuration table for resending short messages Svctbl Configuration table of the provided service of the relevant ESME Bfgtbl Configuration table related to billing processing Cautbl Configuration table related to Response_Cause for responding to response from SS7 network Evttbl Event Configuration Table Cantbl CAN (Predefined) Messages Configuration Table

In addition, the Statistics Table 702 provides various statistical functions to provide statistical data on messages processed by the mobilePOST SMSC system operator. Each statistical information is calculated for each state in the POST process 401 of the mobilePOST SMSC core 150, and does not significantly affect the overall performance of the system because only the type count is counted in the shared memory.

The components of each statistics table are as follows.

Statistics Table sp Short message processing statistics by signal point sme Short Message Processing Statistics by ESME service ESME short message processing statistics by service Teleservice Short Message Processing Statistics by Teleservice prefix Statistics that processed short messages by each prefix of MIN tryno Statistics on the status of transmission to the MS

8 is a diagram schematically illustrating the flow of telegram signals between detailed components of the SMSC 100 according to the present invention.

The ESME requests the short message to be sent to the SMSC 100, and the request is first received by the SMPP module 160, which is an interface means within the SMSC 100, and stored in the shared memory 120. Thereafter, the stored information is transmitted to the POST 401 in the mobilePOST SMSC core 150 in the form of a token including the address information where the message is stored.

The POST 401, which has received this information, performs an internal memory management procedure such as generating or updating necessary information for managing the short message, and then transmits a SUBMIT_ACK token to the SMPP module 160 according to the result. The module 170 transmits a REQUESTING token. Here, the SUBMIT_ACK token includes an address of an empty message POOL in the shared memory 120 that can be used when a new message is received, and a POOL address and a message ID of a short message included in the token received from the SMPP module 160. The above message ID is a parameter required to carry out an SMPP operation (for example, a message replacement or deletion procedure). In addition, the REQUESTING token transmitted to the CSNI module 170 includes the type of the operation, the destination address of the short message, and the SSN (SubSystem Number) of the home location register (HLR).

Receiving the above REQUESTING token, the CSNI module 170 transmits a "REQUESTING" operation to the HLR in order to obtain routing information of the MSC (Mobile Switching Center) in the signaling network in which the destination terminal to which the short message is to be transmitted is located.

In response to the above "REQUESTING" operation, the HLR transmits a REQUESTING_ACK containing the destination address information of the short message to the CSNI module 170, and the CSNI module 170 receives the destination point code DPC (included in the REQUESTING_ACK received from the HLR). By extracting the destination point code, it is included in the token and transmitted to the POST 401, thereby providing information that can be routed to the location of the destination required for short message transmission.

In response to this, the POST 401 writes or updates the information contained in the above token to the shared memory 120, and then generates a token of the "SMDPP" operation and transmits it to the CSNI module 170. The token of the "SMDPP" operation includes a destination point code DPC included in the REQUESTING_ACK, a message POOL ID of the shared memory 120 for transmission, and an ESN (Electronic Serial Number).

Upon receiving this, the CSNI module 170 transmits the short message stored in the message POOL ID of the shared memory 120 to the mobile terminal of the destination through the signaling network, and then executes the SMDPP_ACK operation indicating the completion of the transmission through the signaling network. When received, it will notify the POST 401.

In response, the POST 401, after completion of the short message transmission, changes some parameters of the message POOL used for the short message transmission recorded in the shared memory 120 to an empty state to transmit another short message. It connects to an empty POOL connection list so that it can be used, and sends a token including the POOL address of the message to the MBNK 407 so that the MBNK 407 can take charge of the short message transmission.

Through such a process described above, the short message is transmitted. In the above process, only one short message is described as an example, but a plurality of short messages may be simultaneously processed in a multiple manner. As described above, since the present invention can be naturally recognized by those skilled in the art by applying the management scheme of the shared memory of the present invention, a detailed description thereof will be omitted.

9 is a flowchart illustrating a short message processing procedure according to the present invention.

First, upon receiving a short message transmission request from the outside (S901), the SMPP module 160 stores the received short message and related information in the shared memory 120, and a SUBMIT token including the stored information (address information). To the POST 401 (S902), the POST 401 receives the SUBMIT token, records the necessary information in the shared memory 120, and further measures and records the necessary statistics from the recorded information, etc. After performing the internal processing procedure, SUBMIT_ACK is transmitted to the SMPP module 160 (S903).

After that, the necessary information among the information stored in the shared memory 120 is restored to the file system 130 and the relational database 140, and necessary internal processing (update various statistics and related information necessary for the operation of the system) After performing the step, the CSNI module 170 transmits a REQUESTING token (S904). This REQUESTING token contains the type of the operation, the destination address of the short message, and the SSN (SubSystem Number) of the Home Location Register (HLR).

In response to the REQUESTING token, the CSNI module 170 transmits a REQUESTING operation to the HLR in order to obtain routing information of the MSC (Mobile Switching Center) in the signaling network in which the short message is to be transmitted (S905). Preferably, the REQUESTING operation may generate one MAP (Mobile Application Part) operation according to the IS41C / IS637 protocol specification by referring to the REQUESTING token from the POST 401, encapsulated in a TCAP, and transmitted to the HLR.

Receiving the REQUESTING_ACK containing the destination address information of the short message from the HLR, the CSNI module 170 extracts the destination point code DPC (Destination Point Code) included in the REQUESTING_ACK, and includes it in the token to post (401). (S906).

In response, the POST 401 records the various statistical procedures required before the short message transmission, using the information contained in the token, in the NOTE 502 of the shared memory 120, and then configures the BATH 501. After performing the internal procedure of linking the POOL ID of the message corresponding to the timer connection list, which is an element, to meet various constraints, the token of the SMDPP operation is generated and transmitted to the CSNI module 170. The token of the above SMDPP operation is generated. Includes a destination point code DPC included in the REQUESTING_ACK, a message POOL ID of the shared memory 120 for transmission, and an ESN (Electronic Serial Number) (S907).

Upon receiving this, the CSNI module 170 transmits the short message stored in the message POOL ID of the shared memory 120 to the mobile terminal of the destination through the signaling network (S908).

After receiving the SMDPP_ACK operation indicating the completion of the transmission through the signaling network to the CSNI 170, it is retransmitted to the POST (401) (S909).

When the POST 401 receives the notification of the completion of the short message transmission, the POST 401 changes the specific parameter value of the completed POOL to an empty state and connects to the empty connection list to be used again (S910). Then, the token including the address information on the POOL of the transmission is completed to the MBNK (407), so that it is stored in the relational database 140, it is possible to perform the charging process.

According to a preferred embodiment of the present invention, there is enough 5,040,000 message POOLs to accommodate short messages. In the present invention, the total number of POOLs is provided in preparation for the BHSM period in which a large amount of short messages enters the mobilePOST SMSC in a short time. By specifying a threshold for, the new short message is no longer received when the number of short messages currently received exceeds the threshold. This allows the operator to first control the number of POOLs, thereby reducing the number of POOLs in shared memory. If the mobilePOST SMSC does not receive any more input, the normal message system resends the SMSC to the SMSC, so there is no need to be concerned about the message excess from the ESME within the SMSC itself. . As described above, more messages can be accommodated by increasing the number of POOLs in shared memory. As a specific method of checking whether the number of short messages received exceeds the threshold, each time a short message is received, the POST 401 increases the number of parameters SMPOOL_OVERFLOW_NUM by one, and MBNK (407) when the short message transmission is completed. Decreasing the above parameter value by 1), the POST 401 compares the parameter SMPOOL_OVERFLOW_NUM with the threshold value and determines whether it is exceeded to determine whether to receive a new short message.

Here, when the transmission of the short message is completed, rather than initializing the entire message POOL and connecting it to the connection list, the message POOL maintains all the contents because the specific parameter value of the message POOL is connected to the empty connection list with the empty POOL state. Since the token indicating the POOL is transferred to the MBNK process for processing, the contents of the short message can be saved in the database quickly and safely without losing the contents of the short message at the completed POOL address.

FIG. 10 is a detailed flowchart illustrating the SUBMIT_ACK transmission procedure S903 of FIG. 9 performed by the POST 401.

First, upon receiving the SUBMIT token from the SMPP module 160 (S1001), the statistics related to the SUBMIT operation are measured and stored in the shared memory (S1002), and the short message corresponds to the signal network information of the mobile terminal finally reached. A PCS structure is generated (S1003) and an empty message POOL address is obtained (S1004). Thereafter, a MIN number and a SM_ID (short message ID) are generated to distinguish the status of the short message transmitted from the ESME (S1005), the short message entity is found, and the changed SM_ID and the message POOL ID are recorded (S1006). Finally, the submit-ack token is transmitted to the SMPP module 160 (S1007).

FIG. 11 is a flowchart further embodying a "REQUESTING" token transmission procedure S904 of FIG. 9 performed in a POST 401.

First, an Expiration Retry is set for retrying and stopping a short message transmission (s1101), and a token including a message POOL ID in which a short message is stored and a progress state of the short message are transmitted to the SMDB 408 (s1102). . The SMDB 408 manages the file system 130. The SMDB 408 stores the file system 130 in synchronization with the shared memory for various changes in the short message transmission process. Alternatively, even if initialized by the operator in an unstable operation, the loss of short messages requested to be transmitted is minimized, thereby providing reliability as a whole of the system. The process of managing the file system 130 using the SMDB 408 is applied in the above-described short message transmission process ("SUBMIT", "REQUESTING", "SMDPP").

Then, it is determined whether the above information is information stored in the relational database 140 (S1103), and if the information does not need to be stored in the relational database 140, the following procedure is performed, and if the relational data If the information needs to be stored in the base 140, the token is transmitted to the MBNK 407 (S1104). The MBNK 407 manages the relational database 140 in connection with the tariff processing when the transmission of the short message is completed.

Thereafter, a connection is established to an Active link of the MIN structure (S1105), and the short message POOL is set to Requesting (S1106). After setting the response waiting time after transmitting the data information to the network (S1107), the "REQUESTING" token is transmitted to the CSNI 170 (S1108).

It should be understood by those skilled in the art that the above descriptions can be equally applicable to scheduling message handling using a relational database.

As described above, the CDMA-based mobilePOST SMSC according to the present invention records the submitted short message and the information of the transmission step in the shared memory, and the message intercommunication between the processes is an optimal token including the address of the shared memory. Are organized and exchanged.

That is, the mobilePOST SMSC according to the present invention is an effective storage method of a message when processing a submitted short message, a storage technique for providing reliability of message transmission, and a relational database storage technique for billing processing. It provides improved quality for the best performance and reliability of transmission. Therefore, the application of this technique can shorten the transmission message in the system, thereby maximizing the overall SMSC's message transmission capability, thereby providing a wide range of services and maximizing the capacity of the Busy Hour Short Message (BHSM).

In addition, a preferred embodiment of the present invention is disclosed for the purpose of illustration, those skilled in the art will be able to make various modifications, changes, additions, etc. within the spirit and scope of the present invention, such modifications and changes should be regarded as belonging to the following claims. something to do.

Claims (6)

A short message service center for transmitting a short message to a desired destination in response to a short message transmission request, the short message service center comprising: A shared memory for storing all data information related to the short message transmission; An SMPP module for receiving the short message transmission request, storing the short message and related information in a specific POOL of the shared memory, and outputting a first token including the POOL address; Read the short message and related information stored in a specific POOL of the shared memory based on the first token, generate destination information for transmitting the short message to a called terminal, and include the POOL address and the destination information MobilePOST SMSC core to output the second token; And Receiving the second token, collecting routing information of the destination information from an external device, transmitting the collected information to the mobilePOST SMSC core, accessing the shared memory based on the routing information, and storing the short message stored in the POOL address; A CSNI module for sending a message to the destination, The shared memory Short message service center comprising a BATH part for storing data information for short message processing and management, and a NOTE part for storing data information for operation and maintenance of data. The method of claim 1, The short message service center of claim 1, further comprising a file system managed by the mobilePOST SMSC core to re-store all the information stored in the shared memory in preparation for the possibility of loss. The method according to claim 1 or 2, After the short message transmission is completed, the short message service center for storing the information on the billing processing, and managed by the mobilePOST SMSC core further comprises a short message service center. The method of claim 1, The mibilePOST SMSC core provides an empty POOL list in which the short message is not stored in the shared memory to the SMPP module so that the SMPP module can store the short message and related information in a specific POOL among the empty POOLs of the shared memory. Short message service center, characterized in that. The method of claim 4, wherein When a predetermined number of threshold levels are determined among the plurality of POOLs and the number of short messages being processed in the shared memory reaches the threshold level, the short message is no longer received. service center. The method according to claim 1 or 5, And a configuration table for storing all configuration changes including the number of POOLs and the threshold level in the NOTE portion of the shared memory, and applying the configuration changes to the operation of the mobilePOST SMSC core in real time. Short Message Service Center.