System for forwarding and logging a digital message from a telecommunications device

[0002] The present invention relates to a system for forwarding and logging a digital message, especially as applied to a digital message originated by a cellular telephone or other telecommunications device.

[0003] The present invention relates to cellular radio and telephone networks. These networks generally consist of mobile communications units (e.g., cellular telephones) which users employ to send radio signals carrying voice data over the air to other users. A mobile unit sends a signal which is received by a base station for the area or “cell” in which the mobile unit is located. The base station forwards the signal to a mobile services switching center, which routes the signal to its destination. This destination may be a ground-based telephone network or another base station which will re-broadcast the signal to another mobile unit. In either case, the signal is routed through a cellular telecommunications network before being either re-broadcast to another mobile unit or forwarded to the ground-based telephone network.

[0004] The cellular telecommunications network referenced above includes base stations strategically located in a geographical service area (each including an antenna, a base station controller, and a transceiver). Each base station is connected to a mobile switching center, with each mobile switching center serving several base stations. The mobile switching center is, generally, a small facility located between the base stations it serves and a centralized facility for the network. A home location register (HLR) is located at the centralized network facility, and serves all the mobile switching centers for the network. The HLR stores and provides access to network subscriber data. The HLR stores, for example, data describing a network subscriber's home network, type or level of service, and other subscription information. Each mobile switching center contains a visitors' location register (“VLR”), which registers users who access the network, but who are not listed in the network HLR because they are geographically located outside their home network when they access the cellular communications system. The VLR communicates with HLRs across the system to obtain user data about the users who access the network.

[0005] In addition to sending voice data signals carrying voice data, mobile units send digital messages to a telecommunications network. These messages can be used to, for example, change a subscriber's level of service, change a subscriber's service options, or change a subscriber's registered number to which incoming calls to the subscriber are to be forwarded. Like voice data signals, messages are also received by base stations and forwarded to mobile services switching centers. However, messages are then processed by the network, rather than forwarded to, or linked in communication with, another user. The messages may be processed and implemented by the HLR or another component of the network designed to act on the information specified in the message. The messages can operate as commands with regard to these components. These components of communications networks generally comprise standard micro-computers which are programmed to receive digital messages from mobile units forwarded via a base station. The computers, based on the messages, perform operations such as changing a subscriber's service options, or changing a number to which a subscriber's calls should be forwarded.

[0006] Current telecommunications systems have the capability of remote feature control, allowing a subscriber to, for example, establish an account, change a password, change a level of service, or change other service features such as call forwarding options. The current remote feature control systems receive messages through an HLR. All these functions are performed within the telecommunications network without the need for forwarding messages to outside, often incompatible, systems operated by outside vendors.

[0007] In current systems, messages are received by an HLR and either processed within the HLR or processed by another component of the network developed to perform the function specified by the message. The component processes the message according to the message contents and initiates the feature requested by the message. For example, a message requesting an updating of a call forwarding number contains a certain code signaling the network that it is a call forwarding number update request. A network component reads this code and determines that the message is not to be terminated within that component, but should be forwarded to a component within the network specifically designed to handle call forwarding. The component in which the message is to be terminated then initiates the call forwarding number updating sequence.

[0008] Current systems provide only for forwarding of messages within a network. New applications for the use of over-the-air digital messages require the forwarding of messages outside the network. Beyond changing user and service options, digital messages transmitted by mobile units can be used, for example, to provide information from remote locations to centralized databases (e.g. gas, water, or electric meter readings provided directly into a company database), or to transmit a specific geographical location of a user, or to provide commands to remotely-located devices (e.g. a power on/power off command).

[0009] U.S. Pat. No. 5,577,102 describes a system for processing short messages in a cellular telephone network. The system is designed to be a simple method for transmitting short messages from one subscriber on a cellular network to another subscriber. A message is received by a mobile switching center, which then checks the message address, stores the message, communicates with an HLR to obtain routing information, and transmits the message to the intended subscriber. This system receives, processes, and forwards digital messages within a cellular telecommunications network. It does not forward messages outside the network.

[0010] U.S. Pat. No. 5,428,665 describes a method for managing supplementary service procedures in a global system for mobile communications. Mobile stations send messages which are to be processed either in a mobile services switching center/visitor location register (MSC/VLR), or in a home location register (HLR). The MSC/VLR forwards messages destined for the HLR to the HLR, without seeing their contents or processing them in any other way. Messages to be terminated within the MSC/VLR are kept by the MSC/VLR and processed internally.

[0011] U.S. Pat. No. 5,594,740 describes a method and apparatus for using the control channels of an existing cellular telephone network to transmit and receive two-way wireless data messages. The system includes manipulation, translation, and encryption of control channel data bits, and provides for application-specific messaging on the control channels of an existing telecommunications network. This system does not provide for forwarding of application-specific messages outside a telecommunications network.

[0012] In an exemplary embodiment of the present invention, a system including multi-threaded processes is provided for forwarding digital messages outside a telecommunications network, and for logging those messages for billing purposes, for example. The system receives a message and determines whether the message should be processed within the network, or should be forwarded outside the network, for example, to a vendor application. The system employs a home location register (HLR), running a service logic program (SLP), a plurality of relays (implemented as a main relay and one or more sub-relays), a discriminator, and message log files, and complies with the IS41 telecommunications standard.

[0013] In an exemplary embodiment, the SLP receives a digital message from a telecommunications device and determines whether the message is to be forwarded outside the network. If the message is to be forwarded, the SLP formats the message and sends it to the main relay. When the main relay receives a message from the SLP, the main relay writes the message to a log file. The main relay then forwards the message to the discriminator which, based on information contained in the message, routes the message to one of the sub-relays. Each main relay and sub-relay is in read/write communication with a log file. The sub-relay receiving the message sends the message to a specific vendor application via a vendor-relay which is outside the telecommunications network.

[0014] The relay/discriminator/sub-relay system operates as an interface between the telecommunications network and an outside system, forwarding messages from the telecommunications network to the outside system where they are processed and used for the specific business application of the outside vendor.

[0015] FIG. 1 is a block diagram of the overall system architecture of an exemplary embodiment of the present invention.

[0016] FIG. 2 illustrates the structure of an exemplary digital message.

[0017] FIG. 3 is a flowchart of a portion of a Service Logic Program (SLP).

[0018] FIG. 4 is a flowchart of an exemplary main relay process.

[0019] FIG. 5 is a flowchart of an exemplary discriminator process.

[0020] FIG. 6 is a flowchart of an exemplary sub-relay process.

[0021] FIG. 7 shows the threads created by a relay in accordance with the exemplary embodiment of the present invention.

[0022] FIG. 8 shows the operations of a thread in accordance with the exemplary embodiment of the present invention.

[0023] FIG. 9 shows the operations of an exemplary relay process.

[0024] FIG. 10 shows the “handshaking” operations of the relay-client connections in accordance with the exemplary embodiment of the present invention.

[0025] Architectural Overview: Referring initially to FIG. 1, a block diagram of the overall system architecture of an exemplary embodiment of the present invention is illustrated. An HLR 101 is provided, which comprises a digital computer, such as, for example, a Sun Microsystems™ SPARC® or UltraSPARC® workstation. The HLR 101 executes an HLR software program. The HLR 101 includes a database containing network subscriber data (such as user identification numbers) and message destination data (such as host names, network service names, and vendor identification numbers). Additionally, the HLR 101 executes an SLP 102.

[0026] The SLP 102 is a process that determines whether messages should be processed by the HLR 101, or forwarded to an outside vendor. In the exemplary embodiment of the present invention, the SLP 102 is created using a Service Creation Environment (SCE), a software tool used for the creation and monitoring of complex software programs for telecommunications networks. The SCE allows designers to put together pre-written independent building blocks of code using flow charts and an interactive graphics editor.

[0027] The SCE enables an SLP designer to design a new SLP in a window-driven interactive environment. The designer begins designing a new specific SLP by installing a generic SLP (provided by the SCE). The designer then customizes the generic SLP, as required, to transform it into a specific SLP designed for the specific requirements of the designer. Finally, the designer tests the SLP with the animation feature of the SCE.

[0028] The designer installs a generic SLP by clicking a mouse button on a generic SLP icon, and then selecting the create function. The designer can then construct the generic SLP by inserting and connecting service independent building blocks (SIBs). SIBs are blocks of code which are independent of service applications. In accordance with the exemplary embodiment, the SIBs are represented as flow-chart objects. An SIB may be an entry SIB, an input SIB, or a decision SIB. Clicking on an SIB will display a parameters window which the designer can use to modify the parameters of the SIB. Once the generic SLP is created, it is stored by clicking the “save” icon button, before the SLP is modified into a specific SLP.

[0029] To modify the generic SLP into a specific SLP, the designer first sets up subscribers. The designer allocates a service number and a service name to the SLP. The designer clicks on a “create” button and then enters the service number. By clicking on a “select service” button, the designer allocates the service to an existing subscriber. To create a new subscriber, the designer clicks a “create subscriber” button and inputs the subscriber number, the subscriber name, and the triggers for the SLP. Once this is complete, the designer switches the SCE to subscriber mode, allowing the subscriber to modify the generic SLP.

[0030] To edit the generic SLP, the designer can click on each SIB to bring up an edit parameter window. Modifications are made in this window, and then applied to the SIB when the window is closed. When the SLP modifications are complete, the SLP is stored as a specific SLP by clicking a save edit button.

[0031] The new specific SLP is then tested using the features of the SCE. This function employs intelligent network application and animation and monitoring control windows and a service switching point window to simulate phone calls. The SCE offers evaluation animation of the operation of the SLP.

[0032] The specific SLP 102 of the present invention is coupled to a main relay 103, via a standard Transmission Control Protocol/Internet Protocol (TCP/IP) connection 123. The main relay 103 is a process implemented in software which can run on the HLR 101, or on a separate computer (e.g. a Sun Microsystems™ SPARC® or Ultra SPARC®, or a standard desktop personal computer).

[0033] The main relay 103 (implemented in, for example, the C++ programming language) relays messages received from the SLP 102 to a discriminator 104.

[0034] Additionally, the main relay 103 logs each message into a log file 109 via a file I/O system call. In the exemplary embodiment, the log file 109 is stored on a hard drive local to the computer executing the main relay 103.

[0035] The main relay 103 is coupled to the discriminator 104 via a TCP/IP connection 134. The discriminator 104 is a process implemented in software (e.g., in the C++ programming language) which can run on the same computer as the main relay 103 or on a separate computer connected to the main relay 103. The discriminator 104 receives messages from the main relay 103 and forwards each received message to an appropriate sub-relay 105, 106.

[0036] The discriminator 104 is coupled to two sub-relays 105, 106. Although two sub-relays 105, 106 are illustrated, the system of the present invention can include any number of sub-relays.

[0037] Each sub-relay 105, 106 is a process implemented in software (e.g., in the C++ programming language) which can run on the same computer as the discriminator 104, or on a separate computer connected to the discriminator 104 via TCP/IP connections 145, 146. This computer may be, for example, a Sun Microsystems™ SPARC® or Ultra SPARC®, or a standard desktop personal computer. Multiple sub-relays may run on the same computer, or each sub-relay may run on a separate computer.

[0038] Each sub-relay 105, 106 is connected to a respective vendor relay 107, 108 via a TCP/IP connection 157, 168. Each sub-relay receives messages from the discriminator 104 and relays the received messages to the respective vendor relay 107, 108 that is outside the telecommunication network.

[0039] Additionally, each sub-relay 105, 106 logs each message it receives into a respective log file 110, 111 via a file I/O system call. In the exemplary embodiment, each of the log files 110, 111 is stored on a hard drive local to the computer executing the respective sub-relay 105, 106.

[0040] The vendor relays 107, 108 are executed on computers separate from the sub-relays 105, 106, and outside of the telecommunications network. Furthermore, in the exemplary embodiment, each of the vendor relays 107, 108 is executed on a separate, individual computer. The vendor relays 107, 108 are portions of vendor applications that receive the messages that are processed by vendor applications.

[0041] Operational Overview: In operation, in the exemplary embodiment of the present invention, the HLR 101 receives a digital message, which has been forwarded from a base station via a mobile services switching center. The format of the digital message is that of a remote feature control message according to the IS41 telecommunications standard, and includes a field containing a mobile identification number (MIN), a field containing a mobile serial number (MSN), and a field containing the user's dialed digits. The message is processed and formatted by the SLP 102. The SLP 102 determines whether the digital message is to be forwarded to an outside vendor by mapping the MIN into a database. In particular, the SLP 102 searches the database to determine if the MIN of the message is contained within the MIN ranges listed in the database. If the MIN is found to be within one of those ranges, the SLP retrieves the information corresponding to that range from the database and constructs a message in the format that is later described in connection with FIG. 2. The SLP 102 then forwards the message to the main relay 103 through the TCP/IP connection 123. If the MIN of the message is not found within the ranges contained in the database, the message is not to be forwarded, and the SLP 102 processes the message internally.

[0042] The main relay 103 writes a record ID into designated fields of the message. The record ID identifies the main relay and serves to uniquely identify the message. The main relay 103 then writes (i.e., “logs”) the message to the log file 109, and forwards the message to the discriminator 104 through the TCP/IP connection 134.

[0043] In the exemplary embodiment, the main relay 103 includes objects such as a log manager object (“LogMgr”) and a relay manager object (“Mgr”), and is implemented as a multi-threaded process. A multi-threaded process operates by creating several “threads”, or “lightweight” processes, which can operate simultaneously. These threads are member functions of the Mgr object. Lightweight processes are mini-processes which can communicate with each other through simple memory read/write commands, in contrast to “full” processes which must communicate through TCP/IP interfaces. A multi-threaded process operates like a multi-tasking system except that the communication between threads requires fewer resources than communication between the processes of a multi-tasking system. The threads can communicate through simple memory read/write functions, avoiding the need to go through the operating system.

[0044] The main relay 103 creates separate threads to communicate with individual clients and can therefore communicate with a number of clients simultaneously.

[0045] The main relay 103 operates as a server from the TCP/IP network connection point of view. Client/server architecture describes a common form of distributed system in which software is split between server tasks and client tasks. A client sends requests to a server, according to some protocol, asking for information or action, and the server responds by providing the information or performing the action and sending a confirmation message back to the client.

[0046] As a server, the main relay 103 allows connections by external clients (not shown in FIG. 1). These external clients are software processes which can reside on the same computer as the main relay 103, or on a different computer. When clients connect to the main relay 103, the main relay 103 creates threads for each one (managed by the Mgr) to communicate with the clients. These clients may require information from the log file 109 to perform their functions, such as determining whether or not there are any unforwarded messages stored in the log file 109, or archiving the sent messages from the log file 109 so that space in the log file 109 can be cleared for new messages.

[0047] A client, for example an archive process, can request “unspooling” of messages from the log file 109. This request is sent from the thread, through the LogMgr. The LogMgr manages the interaction between the main relay 103 and the log file 109, and performs the write/read functions necessary to carry out the functions of the main relay 103 and the requests of the clients. The main relay 103 also includes a record map, which is a data structure that acts as a “dictionary” or “map” of the contents of the log file 109.

[0048] An archive process, for example, may request that all “sent” messages be unspooled. The LogMgr looks up the messages marked “sent” in the record map to determine their locations in the log file 109. The LogMgr then reads each sent message from the log file 109, marks the message as copied or archived, and writes the message to a temporary file. The main relay 103 then sends an acknowledgment message to the archive process. The archive process sends an acknowledgment message back to the main relay 103. The LogMgr then marks the copied or archived messages to be overwritten, and removes their entries from the record map. Finally, the archive process retrieves the temporary file. The messages in the log file 109 that were unspooled can then be overwritten. This effectively deletes the unspooled messages, and increases available space in the log file 109.

[0049] The discriminator 104 receives a message from the main relay 103, and forwards the message to the proper destination sub-relay 105, 106 based on routing information contained in the message.

[0050] The sub-relay 105, 106 logs the received message to its log file 110, 111 and passes the message to its respective vendor relay 107, 108 for further processing in accordance with the function of the vendor application corresponding to the vendor relay 107, 108.

[0051] In an exemplary embodiment of the system, the sub-relays 105, 106 comprise essentially the same software as the main relay 103, and thus operate in substantially the same way as the main relay 103. Accordingly, the general operation of the sub-relays 105, 106 is substantially the same as described above in connection with the main relay 103, except that the sub-relays 105, 106 process messages received from the discriminator 104 (rather than from the SLP 102), and relay the processed messages to vendor relays 107, 108 (rather than relaying the messages to the discriminator 104).

[0052] The HLR 101 software, SLP 102, main relay 103, discriminator 104, and the sub-relays 105, 106 can run on the same computer. However, running the discriminator 104 and the sub-relays 105, 106 on separate computers saves memory space in the HLR 101 and reduces the general load on the HLR 101, making the system more efficient.

[0053] Message Structure: In an exemplary embodiment of the present invention, the messages that are forwarded to outside vendors are structured as illustrated in FIG. 2. A digital message 200 can comprise, for example, 156 bytes of digital information, divided into different fields.

[0054] In this exemplary embodiment, a Host ID field 201 is provided at bytes 0-3 of the message. The Host ID field 201 identifies the main relay 103 which forwarded the message, and the computer upon which it executes. A Sequence ID field 202 is located at byes 4-11 of the message. The Sequence ID field 202 is a sequence number assigned by the main relay 103. The main relay 103 increments this sequence number for each forwarded message. The Host ID field 201 and the Sequence ID field 202 together make up a record ID which uniquely identifies the message.

[0055] A Time Stamp field 203, 204 provides a time stamp for the message. The Time Stamp field 203, 204 occupies bytes 12-15 and 16-17 of the message.

[0056] At bytes 18-27, a Mobile Identification Number field (MIN) field 205 is provided. The MIN field 205 identifies the mobile user that sent the message.

[0057] A Mobile Serial Number (MSN) field 206 is provided at bytes 28-31 of the message. The MSN field 206 provides the serial number that is hard-wired into the mobile unit that sent the message.

[0058] A Dialed Digits field 207 at bytes 32-63 of the message provides the sequence of digits dialed at the mobile unit.

[0059] A Message Rate field 208 is provided at bytes 64-67 of the message.

[0060] At bytes 68-71 of the message, a Vendor Number field 209 is provided.

[0061] A Host Name field 210 and a Service Name field 211 are provided at bytes 72-77 and 78-91 respectively. The information in the Host Name field 210 and the Service Name field 211 are read from a database by the SLP 102, and are used by the discriminator 104 to determine to which sub-relay the message should be forwarded.

[0062] At bytes 92-155 of the message, other data 212 is stored.

[0063] SLP Process: The process illustrated in FIG. 3 shows the portion of the SLP 102 relevant to the present invention, which determines whether a message is addressed to a vendor application, or is to be retained and processed by the HLR 101. As shown, the SLP 102 receives a message (step 301). This message is, for example, forwarded from a base station through a mobile switching center.

[0064] Next, the Mobile Identification Number (MIN) in the message is obtained (step 302) and used to search a database (step 303). The database contains a list of MIN ranges, correlated with a list of message rates, a list of host names, a list of service names, a list of vendor numbers, and a list of variable-length character strings. If the MIN is found to fall within one of the MIN ranges listed in the database, the SLP 102 formats the message as shown in FIG. 2 by filling the designated fields with the corresponding information from the database (step 304). As part of the formatting procedure, the SLP also writes a time stamp into the designated fields in the message. The SLP 102 then forwards the message to the main relay 103 via TCP/IP interface 123 (step 305). If the MIN is not found in the ranges contained in the database, a “No Match” is returned and the message is further processed internally by the SLP 102 (step 306).

[0065] Main Relay Process: When the main relay 103 receives a message from the SLP 102, the main relay 103 logs the message to the log file 109, and forwards the message to the discriminator 104. In addition, the main relay 103 unspools records from the log file upon request from a client, e.g. an archive process.

[0066] Since the main relay is a multi-threaded process, the log file 109 is carefully synchronized so that the log file 109 is not accessed by more than one thread at a time. In accordance with the exemplary embodiment of the present invention, the synchronization of the log file connections is accomplished through the use of a semaphore. A semaphore is an access bit which allows for only single user read and single user write functions and is known and used in the art for synchronization tasks. When a thread accesses the log file 109, the semaphore bit is set. When the semaphore bit is set, no other threads can access the log file 109. Each thread which accesses the log file 109 attempts to get as much data through as possible, and also tries to release the semaphore as soon as possible. The write/read functions performed to/from the log file 109 are performed and controlled by the LogMgr.

[0067] FIG. 4 is a flowchart of the main relay 103 process. The main relay 103 is a multi-threaded program implemented as a server from the TCP/IP network connection point of view. In the exemplary embodiment of the present invention, the SLP 102 is the left-hand client of the main relay 103, and the discriminator 104 is the right-hand client of the main relay 103.

[0068] Referring now to the flowchart of FIG. 4, the main relay 103 receives a message from the SLP 102 (step 401). The main relay 103 writes a record ID comprising a Host ID 201 and a Sequence ID 202 into the designated fields of the message (step 402). The Host ID uniquely identifies the main relay 103. The sequence ID 202 is a sequential number incremented by the main relay 103 for each message received by the main relay 103.

[0069] The main relay 103 then tests the semaphore to determine if the log file 109 is available to receive a message (step 403). If the main relay 103 determines that the log file 109 is busy (i.e. the semaphore is set) the main relay 103 waits until the log file becomes available.

[0070] If the main relay 103 determines, that the log file is not available because the log file is full (step 404), the main relay 103 drops the message (step 409). Dropped messages are deleted from temporary memory and are completely lost from the system. The main relay 103 will then send an information problem report to the system manager (step 410).

[0071] If the log file 109 is not busy or full, the main relay 103 writes the message to the log file 109 (step 405). The main relay 103 then writes the record state to the log file 109, setting it as “sent” (step 406). The main relay 103 then writes the record index information into the record map (step 407). The main relay 103 then forwards the message to the discriminator 104 through the TCP/IP connection 134 (step 408).

[0072] Discriminator Process: FIG. 5 is a flowchart of the discriminator 104 process. The discriminator 104 operates as a client to the main relay 103 and to the sub-relays 105, 106 from the TCP/IP connection point of view. When the discriminator 104 first starts up, it reads a configuration file which resides on the same computer as the discriminator. The configuration file lists the host name, service name, and server type of each of the servers to which the discriminator should attempt a connection. The server type defines whether the server is to be a “left hand” server (main relay) to the discriminator or a “right hand” server (sub-relay) to the discriminator. The discriminator then attempts to establish connections with the main relay 103 and the sub-relays 105, 106 specified in the configuration file. After making the connections specified in the configuration file, the discriminator 104 waits for a message to be forwarded from the main relay 103.

[0073] In accordance with the exemplary embodiment, the discriminator 104 receives a message from the main relay 103 (step 501). Next, the discriminator 104 obtains address information comprising the Host Name 210 and Service Name 211 from the received message (step 502). The discriminator 104 then compares the Host Name 210 and network Service Name 211 to the entries in the configuration file (step 503).

[0074] If the discriminator 104 does not find a match, or the discriminator 104 finds that the destination sub-relay 105, 106 is not running (i.e. down)(step 504), the discriminator 104 drops the message (step 506). The dropped message will be lost from the discriminator, but, unlike the case where the main relay drops a message, the message is not lost from the system because it has been written into the log file 109 of the main relay 103.

[0075] If a match is found, the discriminator 104 forwards the message to the sub-relay 105, 106 (identified by the host name and service name) through a TCP/IP interface 145, 146 (step 505).

[0076] If a sub-relay 105, 106 goes down (as the result of a normal shutdown or a sub-relay failure), it will not accept TCP/IP connections until it is able to re-initialize. Once the sub-relay 105, 106 re-initializes, the discriminator 104 will re-initialize to re-establish the sub-relay connection. When the discriminator 104 re-initializes, it sends a message to the main relay 103 requesting that all messages that were marked as “sent” in the log file, but for which no acknowledgment message has been received, be re-sent to the discriminator 104.

[0077] Sub-Relay Process: Referring now to the flowchart of FIG. 6, an exemplary sub-relay 105 process is illustrated (the same process is also performed by each of the other sub-relays of the system). As described above, each of the sub-relays 105, 106 perform similar functions as the main-relay 103. Accordingly, in the exemplary embodiment of the present invention, each of the sub-relays 105, 106 comprise essentially the same software as the main relay 103. Like the main relay 103, each of the sub-relays 105, 106 are multi-threaded processes. Accordingly, each sub-relay 105, 106 has a LogMgr, a Mgr, a record map, and utilizes a semaphore to synchronize each thread's use of its respective log file 110, 111.

[0078] Referring now to the flowchart of FIG. 6, sub-relay 105 receives a message from the discriminator 104 (step 601). The sub-relay 105 tests the semaphore associated with log file 110 to determine whether the log file 110 is available (step 602). If the log file 110 is busy, the sub-relay waits until the log file 110 becomes available. The sub-relay 105 tests to determine if the log file 110 is full (step 603). If the log file 110 is full, the sub-relay 105 drops the message (609) and sends an information problem report to the system manager (610).

[0079] If the log file 110 is available, the sub-relay 105 writes the message to the log file 110 (step 604). The sub-relay 105 then writes the record state to the log file 110, setting it as “sent” (step 605). The sub-relay 105 then writes the record index information into the record map (step 606). The sub-relay 105 then sends an acknowledgment message to the main relay 103, through the discriminator 104 (step 607). The sub-relay 105 then forwards the message to the vendor relay 106 assigned to the sub-relay 105 (step 608).

[0080] Once the vendor relay 106 receives the message, the vendor application associated with the vendor relay 106 processes the message in any manner chosen by the vendor.

[0081] Relay Threads: FIG. 7 details the threads created by a relay 700. This relay 700 could be a main relay or a sub-relay, as both are constructed of essentially the same code and operate in the same manner. The relay 700 creates a Left Hand Side (“LHS”) thread 701, a Right Hand Side (“RHS”) thread 702, an Archive thread 703, a Check File Full Thread 704, and a Signal Handle thread 705. The use of multiple threads allows a relay to perform many functions at one time.

[0082] The relay 700 creates the LHS and RHS threads 701 and 702 to communicate with the processes connected to the left hand and right hand sides of the relay, respectively. For example, the LHS thread 701 of the main relay 103 communicates with the SLP 102, while the RHS thread 702 of the main relay 103 communicates with the discriminator 104. Correspondingly, the LHS thread 701 of a sub-relay 105, 106 communicates with the discriminator 104, while the RHS thread 702 of the sub-relay 105, 106 communicates with a vendor relay 107, 108.

[0083] The relay 700 creates the archive thread 703 to communicate with a client which is requesting the archiving of records from a log file 109, 110, or 111. This thread is created when the client sends a connection request to the relay 700, as described below.

[0084] The relay 700 also creates the check file full thread 704 to determine if the log file is filled above a threshold value, and to send an alarm message if it is.

[0085] Additionally, the relay 700 creates a signal handle thread 705, which enables multi-threaded processes to work with multiple clients by disabling a UNIX® signal that would otherwise prevent this function.

[0086] FIG. 8 shows the interaction of a relay 700 and a client 803. The relay could be a main relay 103 or a sub-relay 105, 106. The client could be, for example, an archive process. In response to a connection request 809 from a client 803, the relay 700 will (if the client is recognized and the connection is accepted) create a thread 800 to communicate with the client 803. This thread-client communication 807 is carried out across a TCP/IP connection. The thread is also able to detect a connection failure 808.

[0087] The client can make requests for information from the log file (not shown in FIG. 8) through the LogMgr 801. The client 803 can send an information request message to the thread through the thread-client communication 807. The thread 800 then dispatches the message 805 to the LogMgr 801. The LogMgr 801 will then process the request contained in the message and perform the requested log file function.

[0088] The Mgr object 802 monitors 806 the operation of the thread for the relay 700.

[0089] FIG. 9 shows the operations of a relay 700 in communication with clients in the system. Because the relay 700 is a multi-threaded process, the functions shown in FIG. 9 can be carried out independently and simultaneously. The relay 700 acts as a server connected to several clients, including a Left Hand Side (LHS) 901 and a Right Hand Side (RHS) 902.

[0090] If the LHS 901 forwards a message 910 to the relay 700, the relay 700 sends a “record acknowledgment” message 911 back to the LHS 901 if the message is successfully received.

[0091] When the relay 700 forwards the message 913 to the RHS 902, the RHS 902 sends a “record acknowledgment” 914 message back to the relay 700 if the message is successfully received.

[0092] The Clock 903 is used to signal 916 the “Check File Full” thread 704, a thread which is usually in a “sleep” state, but periodically “wakes up” when signaled 916 by the clock 903 to check the availability of the log file 905.

[0093] The relay 700 has a log file 905, the availability of which is governed by how full (i.e., the percentage full) the log file 905 is. If the log file 905 is filled above a threshold capacity, the relay 700 sends a “log file full” message 917 to the Information Problem Report (“IPR”) process 904. The IPR “sounds an alarm” by sending the “log file full” message to a maintenance operator via the HLR 101.

[0094] The memory of the log file 905 is mapped (indexed) 918 for the relay through a data structure of the relay 700 called the record map. This enables the relay 700 to search for and retrieve the messages in the log file 905.

[0095] When the Archive Process client 907 sends an archive records request 927 or a copy records request 922, the LogMgr of the relay 700 reads the requested records (e.g. all the records marked “acknowledged” or “sent”) from the log file 905, and writes 919 them into a temporary file 906. The LogMgr then sends an archive acknowledge 926 or a copy acknowledge 921 message to the archive process 907. The archive process 907 then retrieves the data from the temporary file, and then sends an archive complete 925 or a copy complete 920 message to the relay 700. The relay 700 then purges 919 the temporary file 906.

[0096] The Archive Process client 907 can also send an initialize record request 923. The LogMgr will then clear the whole log file, and send back an initialization acknowledge message 924.

[0097] FIG. 10 shows the “handshaking” operations of the relay-client connections. Each client (for example the LHS 901, the RHS 902, or an archive process 907) sends a connection request message 1005, 1009, 1013 to the relay 700. The connection request message 1005, 1009, 1013 contains information about the type of client sending the message. The relay 700 determines the type of client attempting to connect, and will accept the connection if it recognizes the client, and reject the connection if it does not recognize the client type. If the relay 700 rejects the connection, it will send a “connection reject” message 1007, 1011, 1015 to the client. If the relay 700 accepts the connection, the LHS 901, the RHS 902, or the archive process 907 will then send a “start up” message 1006, 1010, 1014 to the relay 700.

[0098] When the LHS 901, the RHS 902, or the archive process 907 is connected to the relay 700, that client is able to send or receive messages to/from the relay 700 and can request the relay 700 to retrieve files from the log, according to the procedures outlined above.