Method, system and apparatus for subscriber activity supervision

1. Technical Field of the Invention

The invention relates to the provision of supplementary telecommunications services, and more particularly, to a system and method for facilitating the monitoring of activity of a mobile subscriber.

2. Description of Related Art

Customer demand for customized telecommunications services has been growing ever more rapidly. Special subscriber features such as Call Waiting, Call Forwarding, Abbreviated Dialing, etc., are becoming increasingly important to individual subscribers for the added convenience they provide, as well as to telecommunications service providers as sources of additional revenue. Such services are generally provided by special programming in the software of the central office exchange serving a particular subscriber. That is, the local exchange switch software is separately programmed to provide special service features to the subscribers connected thereto. Often both the hardware and the software of an exchange must be upgraded in order to enable the provision of special subscriber functionality.

When a call involves an interconnection between two parties connected to different exchanges, it is completed via a so-called transit or tandem exchange which forms part of the network interconnecting individual central office switches to one another. In such cases, the transit exchange is totally transparent to the two parties of the call and simply provides a voice path between the two end offices. Any special service features invoked by either party has traditionally been provided by the end office to which that subscriber is connected, independently of the network connection between the two parties.

In most telecommunications systems providing Plain Old Telephone Service (POTS), the communications link between a calling party (A-Party) and the called party (B-Party) is under the control of the A-Party. Consequently, the communications link between the A-Party and the B-Party remains in place until the A-Party's telephone instrument is placed "on-hook" in which case the system breaks the communications link and the end offices of both parties and in any transit exchange's which have been used to link the end offices together. If the B-Party were to place his or her telephone instrument on-hook, it has little effect until after a period of the order of several minutes when a timer triggers the disconnection of the circuits between the calling and the called parties. In newer types of telecommunications services, such as the Integrated Services Digital Network (ISDN), B-Party disconnect is employed but the mechanisms for implementing it are considerably different from those of conventional POTS networks.

Providing special subscriber services within conventional telecommunications exchange requires an extensive upgrading of the software of each and every individual exchange which is to furnish such special services to its customers. Such upgrading of exchanges is often extremely expensive and virtually prohibitive from a cost-effectiveness standpoint with regard to the additional revenue provided by the additional subscriber services. This observation is even more true in small towns or rural areas where the demand for special subscriber services is relatively low and where existing exchanges have been in place for a considerable period of time and continue to adequately serve the basic telecommunications needs of a majority of the subscribers in that area.

The telecommunications business is facing increasing competitive pressures. The per-minute revenues of telecommunications operators everywhere has been steadily decreasing due to a number of factors. The deregulation of telecommunications services has increased the number of competitors in the business. Further, innovations like callback services and calling cards permit users to arbitrage differences in bilateral calling rates between country pairs. Also, cable television companies have now started offering telephone services over their cable networks. Finally, innovative software has now made high-quality full-duplex calls over the Internet feasible.

Improvements in technology have also reduced the cost of providing basic telephone service. The telecommunications companies can no longer justify the relatively high tariffs levied on the provision of basic telephone services. Improvements in technology have lowered the actual cost of delivering a telephone call to virtually nothing. In economic terms, basic telephone services can be viewed as zero marginal cost business. The advances that have increased the power to price performance ratio of desktop computers over the years have also boosted the reliability and efficiency of modem telephone exchanges.

The same situation obtains on interexchange connections also. Due to the use of optical fibre, a substantial amount of capacity has been added to the telephone networks. Bandwidth no longer appears to be the scarce resource that it was just a few years ago, and, in fact has become a commodity that is frequently bought and sold in wholesale quantities.

Improvements in technology have also reduced or eliminated the effects of the geographic distance between a calling party and a called party as a significant factor in the cost of providing a telephone call. It has been argued that it cost no more in terms of network resources to call from Stockholm to Dallas (a distance of about 8,000 kilometers) than it does to call from Dallas to Austin (a distance of about 300 kilometers).

The explosive growth of the Internet has largely been due to the exploitation of the fact that its basic TCP/IP protocol permits e-mail messages to be sent and file transfers to be effected independent of the transmission distances involved.

In spite of the fact that the provision of long distance services does not cost much more than that of local basic telephone services, telecommunications operators continue to charge more for long distance telephone calls than for local calls. The increase in competition in the telecommunications industry is likely to make that situation increasingly unsustainable. Since long distance calls have traditionally been a significant source of the operating profits of the telecommunications companies, it has become increasingly obvious that the telecommunications companies need to find new sources of revenue.

One way in which telecommunications operators can increase revenues is by offering subscribers advanced services for which the subscribers would be willing to pay a premium for. As described earlier, in the network architectures of the past, the additional of new functionality to a network required that core exchange software be rewritten -- an expensive and lengthy process that also carried the additional risk of introducing new bugs into the system. Furthermore, each exchange in the network has to be updated with the new software which further increased the cost of introducing new services. Telecommunications operators are no longer willing to tolerate such a state of affairs. There are great business opportunities for a telecommunications equipment manufacturer who can bring a product to the market first.

Telecommunications operators have expressed a need for faster and less expensive techniques for the introduction of new services into their telecommunications network. Further, they have desired that the impact of the new functionality be limited to one or a few exchanges only. It has also been found desirable for service-administration tasks such as the installation or modification of services, the addition of customer-specific data, etc., be capable of being handled from a central management facility.

It has also been desired that the design and implementation of the new services be done by the telecommunications operators rather than the equipment manufacturer. This would allow telecommunications operators to quickly react to perceived market needs and serve their customers more effectively and efficiently. It has also been found desirable to incorporate greater intelligence in the exchange software to permit various services to interact with subscribers. In this manner, the telephone instrument can become an advanced interface to the telecommunications network.

The Intelligent Network (IN) has been proposed as a solution to address the above requirements. The IN technology is designed to allow a telecommunications operator to design its own set of unique services or to adapt existing services to specific customer requirements. Further, the IN architecture permits the impact of installation of new services to be limited to a few control nodes.

Another design feature of the IN architecture is its centralized administration of services. This improves the response time and decreases the human resource overhead required to run the network. Furthermore, the IN architecture permits customer control of some customer-specific data.

For example, some telecommunications operators offer "personal number" services. The personal number service involves giving each subscriber a specific telephone number, usually one prefixed with an "area code" of 500. The design philosophy behind the personal number service is to supplant the plethora of contact numbers for each subscriber with just one phone number. Thus, when someone dials a subscriber's personal number, the exchange switch will query a central database and obtain a list of all of the telephone numbers where the subscriber might possibly be reached. The switch will then ring each of those numbers in a predetermined order until the call gets answered.

In one variant of this service, a subscriber may be provided the ability to dynamically update the contact number database from any telephone instrument. Such customer control can permit a subscriber to add the number of a hotel or other location where he or she may be temporarily located.

The design philosophy behind the IN architecture is to reduce the time to market for the provision of new services, to lower development and administration costs, and to enhance profits deriving from the provision of premium services. The classic example of an IN service is the use of a single dialed number (the B-number) by customers spanning a large geographic area that is redirected to one of a plurality of local service centers. Thus, a pizza franchise can advertise a single telephone number for ordering pizzas. Whenever a customer dials the advertised number, the IN service can direct the call to the nearest franchisee based upon the number of the dialing subscriber (the A-number).

A Brief History of IN

The Intelligent Network concept originated in the United States. Originally, the intent was to provide a central database for translating a single dialed number into a different terminating number. One of the earliest applications of IN services was to provide toll free calling ("Freephone").

Toll free numbers do not directly correspond to a physical telephone line, but need to be translated into an actual termination number. The translation may be dependent upon the location of the caller and upon the time of day.

A new signaling system called Signaling System No. 7 (SS7) was developed to allow high-speed communications between telephone exchanges before and during call setup. The SS7 protocol allowed for the first time, the fast database lookups needed for the implementation of toll-free calling. After the development of the SS7 technology, it became possible to exchange data across a telephone network virtually instantaneously. This was the genesis of the Intelligent Network.

The next step in the revolution of the IN was to move from static databases to dynamic ones that permitted customer control of customer-specific data. Additional interactivity came to be permitted when subscribers could control the progress of the call by keypad interaction from the subscriber's instrument. Such interactive IN is referred to in the U.S. as the Advanced Intelligent Network (AIN).

Present development and interest in the IN architecture is being driven by a few large-scale applications. Two such applications are the Universal Personal Number (UPN) Service and Virtual Private Network (VPN) Service. In the UPN service, a unique number is assigned to each individual rather than to a telephone instrument. The UPN number can be used to reach a subscriber irrespective of his or her location or type of network (whether fixed or mobile).

The VPN service allows a private network to be constructed using public network resources. Thus, a corporation could have a corporate telephone network that permits all of its employees to communicate with each other without investing in the hardware or software needed for providing a physical private network. By implementing a VPN service using the public network, a corporate customer can also avoid the costs of maintaining a physical network.

Inadequacies of Present IN Systems

The use of the Intelligent Network (IN) architecture has been advocated as a solution for speeding up the incorporation and roll out of new network capabilities and network services. However, the presently articulated standards for implementing IN concepts suffer from a number of shortcomings.

For example, in the Global System for Mobile Communication (GSM), a message service called the Short Message Service (SMS) has been specified. The SMS service enables short text messages to be sent to and from various mobile stations (MSs). An SMS message to a mobile station is always sent from an SMS Service Center (SMSC). If an SMS message cannot be delivered to a subscriber because the subscriber's mobile station is inactive or unable to receive SMS messages due to lack of memory, then the Home Location Register (HLR) associated with a Mobile Switching Center (MSC) creates a Message Waiting Data List (MWD-List) to store such undelivered messages.

When a subscriber activates his mobile unit, the HLR is immediately notified. When the HLR detects that a previously inactive mobile station has become active, it immediately alerts the SMSC that had earlier tried to send an SMS message to the inactive mobile station. Upon receiving this alert, the SMSC is triggered to retransmit SMS messages that could not be delivered earlier because the mobile station had been inactive. Current implementation standards for IN do not have any mechanisms for providing similar or equivalent functionality.

If a telecommunications service provider were to be able to monitor the activity status of a mobile station, and generate a subscriber activity report to the Service Controlled Function (SCP) of an IN, then the service provider would be able to terminate a larger fraction of communication attempts. Consequently, the telecommunications service provider could eam greater revenues and also increase resource utilization within its telecommunications network.

Thus, it would be highly desirable to be able to provide some means within an Intelligent Network system, to monitor the activity status of a mobile subscriber and report the same to the SCP. This in turn, requires a system and method for probing a mobile station and generating a mailbox status report to the controlling entity (i.e. the SCP). Prior art document EP, A1, 0699009, is describing a method for monitoring an initially unreachable mobile station in an PLMN system. A Gateway MCS (GMSC) in the PLMN notifies a Short Message Service Center (SMS-C) as soon as the mobile station becomes reachable.

SUMMARY OF THE INVENTION

Therefore it is a primary object of the present invention to permit the easy detection of renewed activity of a mobile subscriber in a PLMN system. One embodiment of the present invention is implemented in an IN (Intelligent Network) telecommunications system comprising a plurality of IPs (Intelligent Peripherals) connected to an SCP (Service Control Point) and PLMN Gateways over a network.

In one embodiment of the present invention, the activity status of a mobile subscriber in a PLMN system is determined initially. If the mobile subscriber is found to be inactive, the PLMN system is armed remotely from the IN system to detect any renewed activity by the mobile subscriber. The activity status of the PLMN mobile subscriber is continuously monitored.

When renewed activity of the PLMN mobile subscriber is detected, the subscriber activity probe is triggered and an alert message is transmitted from the PLMN system to the IN system. This causes an internal report to be generated within the IN system that notifies the supervisory entity within the IN system to become aware that the mobile subscriber is again active and can now be reached through the PLMN system.

In another embodiment of the present invention, an SCP commands an SMS-IP to probe the activity status of a mobile subscriber. The SMS-IP in turn, sends a dummy SMS message to a Gateway Mobile Service Center (GMSC) in the PLMN system that is dedicated to handling SMS messages. Upon receiving the dummy SMS message, the SMS-GMSC activates the storage of non-delivered messages to a mobile subscriber by enabling the Message Waiting Data List (MWD-List) in the HLR of the mobile subscriber. The SMS-GMSC also acknowledges the arming of the PLMN to the SMS-IP. The SMS-IP in turn notifies the SCP that the "Send Probe" command has been successfully executed.

Upon the completion of these actions, the PLMN becomes armed. When a previously inactive mobile subscriber becomes active, the notification of the renewed activity to the HLR will result in the triggering and transmission of an "Alert" command from the PLMN to the SMS-IP. Upon receiving the alert from the SMS-GMSC, the SMS-IP unilaterally generates a "Mailbox Status Report" notification to the SCP.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete understanding of the method and system of the present invention may be obtained by reference of the detailed description of the preferred embodiments that follow, taken in conjunction with the accompanying drawings, wherein: <ul id="ul0001" list-style="none" compact="compact"><li>FIGURE 1 is an illustrative diagram showing the standard Intelligent Network (IN) Conceptual Model;</li><li>FIGURE 2 shows the components of an exemplary simple Intelligent Network;</li><li>FIGURE 3 shows the structure of a Service Independent Building Block (SIB);</li><li>FIGURE 4 shows the mapping of the various IN functional entities into physical units;</li><li>FIGURE 5 shows an example of an IN implementation with service nodes at the transit level;</li><li>FIGURE 6 shows the preferred methodology for implementing various services in the IN Conceptual Model;</li><li>FIGURE 7 illustrates two approaches towards implementing an API;</li><li>FIGURE 8 shows one technique for defining personal agents using Service Logic Programs (SLPs);</li><li>FIGURE 9 shows the architecture of an exemplary mobile radio telecommunications network;</li><li>FIGURE 10 shows the operation of the Short Message Service (SMS) in a mobile radio telecommunications system;</li><li>FIGURE 11 shows one embodiment of the Networked IP (NIP) system and method of the present invention;</li><li>FIGURE 12 is an overview sequence diagram illustrating the flow of messages between the various logical entities of the present invention;</li><li>FIGURE 13 is a sequence diagram illustrating the operation of the "Mailbox Status Report" command;</li><li>FIGURE 14 is a sequence diagram illustrating the operation of the "Mailbox Status Enquiry" command when the SCP asks for brief information about mailbox status;</li><li>FIGURE 15 is a sequence diagram illustrating the operation of the "Mailbox Status Enquiry" command when the SCP asks for detailed information about mailbox status;</li><li>FIGURE 16 is a sequence diagram illustrating the operation of the "Mailbox Status Enquiry" command when a subscriber asks for brief information about mailbox status;</li><li>FIGURE 17 is a sequence diagram illustrating the operation of the "Mailbox Status Inquiry" command when a subscriber asks for detailed information about mailbox status;</li><li>FIGURE 18 shows the sequence diagram when the SCP probes the activity status of a mobile subscriber;</li><li>FIGURE 19 shows the finite state machine for the SCP during the operation of the present invention; and</li><li>FIGURE 20 shows the finite state machine for the IP during the operation of the present invention.</li></ul>

DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention provides a solution to one set of problems concerning the supervision of the activity status of mobile subscribers whose terminal units are inactive when the delivery of messages originating outside a PLMN network (such as electronic mail (e-mail) messages or SMS (Short Message Service) messages) is first attempted. The extensions to the IN concept disclosed and described in this application can also be used in other telecommunications contexts and can also facilitate the provision of related supplementary services to subscribers.

Intelligent Network (IN) Architecture

An Intelligent Network is a telecommunications network architecture that provides flexibility for facilitating the introduction of new capabilities and services into a network such as the Public Switched Telecommunications Network (PSTN) or a Public Land Mobile Network (PLMN). Examples of such new capabilities and services include toll free calling ("Free Phone"), credit card services and Virtual Private Networks (VPN).

IN embodies the dreams of the unbundled network of the future in which freedom is given to service providers and users to personalize the network services, independently of access, switch term technology and network providers. An international consensus view on IN is described in the ITU-TS Recommendation Q.1200.

The details of the IN architecture have been specified in the International Telecommunications Union (JTU) Recommendation L312/Q.1201 which also contains a verbal explanation of the IN Conceptual Model (INCM) shown in FIGURE 1. The ITU's IN Conceptual Model analyzes and systematizes the various tasks and processes associated with call handling and the provision of services into four planes: a Service Plane 101, a Global Function Plane 102, a Distributed Function Plane 103, and a Physical Plane 104.

So far, IN has been concentrated around a group of services referred to hereafter as Number Services, for example, toll free calling ("Free Phone"), credit card calling, personal number services, televoting, etc. A key characteristic of all these services is that they provide service to numbers that are unbundled from the access ports in the access nodes. Any node in the telecommunications network can be made a service node by the addition of a Service Switching Function (SSF) and/or Special Resource Function (SRF), both under control from a Service Control Function (SCF) via a service-independent protocol interface. The SCF is supported by a Service Data Function (SDF), which may be physically unbundled from the node.

The main building blocks of IN are the SSF, the SCF, the SDF and the SRF. The SRF is also referred to hereafter as the logical Intelligent Peripheral (logical IP). Each of these building blocks is a separate logical entity which may, but need not, be physically integrated with the other entities of the telephone network, logical or otherwise. The physical and logical entities are referred to interchangeably as one in the following description of the preferred embodiment.

The IN architecture divides the basic call process into discrete strictly-defined stages that gives telecommunications service providers and subscribers the ability to manipulate the call process. The components of a simple Intelligent Network 200 has been shown in FIGURE 2. The standard architecture of the Intelligent Network has defined various components of the IN as well as the interfaces between the individual components.

When a call is made to an IN service, the call is first routed to a special node in the network that is called the Service Switching Point (SSP). If the SSP recognizes an incoming call as an IN call, then all further processing of the call is suspended while the SSP informs the Service Control Point (SCP), another node in the IN system, that an IN call has been received.

The SCP provides the "intelligence" in the "Intelligent Network." The SCP controls everything that happens to an IN call and makes all the call processing decisions. When the SCP decides upon the appropriate action that is to be performed on the call, the SCP instructs the SSP to carry out the necessary action.

The Service Control Function (SCF) contains the logic of an IN service and bears the complete responsibility for making decisions related to a call invoking that service. This service logic may run on any telecommunications platform (e.g., Ericsson's AXE platform or UNIX). The node (i.e., the physical hardware and the software) that contains the SCF is called the Service Control Point (SCP) 201.

The data needed for each service (e.g., the list of subscriber telephone numbers) is provided by the Service Data Function (SDF). In one implementation of the IN architecture, the data needed for the services is stored in the SCF itself. Formally, the function of storing the service-related data is allocated to the SDF which provides the data upon demand to the SCF. In a typical IN implementation, the SDF can be UNIX's machine running a commercially-available database program such as Sybase. The physical node that contains the SDF is referred to as the Service Data Point (SDP) 202.

The normal call handling and supervisory functions of an exchange are performed by the Call Control Function (CCF). While the CCF is not formally part of the standard IN architecture, the CCF provides the IN with information about calls and also executes orders that have been received by the SSF.

The Service Switching Function (SSF) interprets the instructions sent by the SCF and passes the commands to be executed to the CCF. The SSF also receives call event data (e.g., the onhook/oilhook status of a subscriber or a subscriber line being busy) from the CCF and passes the data to the SCF. The physical node (i.e., the exchange hardware and software) that contains the SSF is referred to as the Service Switching Point (SSP) 204 and 205.

The Specialized Resource Function (SRF) provides certain resources for use in IN services, e.g., DTMF (Dual Tone Multiple Frequency) digit reception, announcements and speech recognition. In the ITU IN recommendations, the SRF communicates directly with the SCF. In another implementation of the IN, the SRF functionality may be co-located with the SSF. In this case the SRF does not communicate directly with the SCF, but via the SSF. The SRF is not shown in FIGURE 2.

The Service Management Function (SMF) 207 administers the maintenance of IN services, e.g., the addition or removal of data or the installation or the revision of services. The Service Creation Environment Function (SCEF) 207 allows an IN service to be developed, tested and input to the SMF. In one implementation of the IN, the SMF and the SCEF are combined into one and termed the Service Management Application System (SMAS). The SMAS application is part of the TMOS family and runs under the UNIX operating system. It permits services to be designed using a graphical interface and provides convenient forms for the entry of service data.

FIGURE 2 shows an exemplary SCP 201 connected to an SDP 202 and SSPs 204 and 205. The SCP is also connected to an SMF/SCEF 207. All of the links running to and from the SCP 201 are shown as dashed lines in FIGURE 2 to indicate that they are not voice links. The SDP 202 is also connected by a non-voice link to the SMF/SCEF 207. The SSP 204 is connected to two local exchanges (LEs) 223 and 224 as well as to a transit exchange (TE) 211. The transit exchange 211 in turn is connected to two other local exchanges 221 and 222. The SSP 205 is connected to local exchange 225. The local exchanges 223 and 224 are shown in FIGURE 2 to be connected to an exemplary originating subscriber T-A 231 as well as to an exemplary terminating subscriber T-B 232.

If each of the logical building blocks of the IN are also physical entities, in the notation described earlier, the corresponding physical nodes are called the Service Switching Point (SSP), the Service Control Point (SCP), the Service Data Point (SDP), and the physical Intelligent Peripheral (IP). As stated earlier, in the discussion that follows, the term IP is used to generally refer to both a logical IP as well as a physical IP.

The user agent is identified in the SCF by the calling or the called party number, and invoked when an armed trigger point in the serving node is hit. Signaling data and call state data can be manipulated by the user agent. The SRFs are capable of in-band communication with the users or with each other to overcome limitations in the current signaling systems.

Current IN standards assume that the visited location and the home location of a subscriber are collocated but possibly unbundled from the access node and the service node. Although the separation of the access node and the service node functions reduces service introduction costs, it results in potentially unwanted interactions between access port services and number-based services. An enhancement of the access node to a service node is therefore required to provide flexibility in service design.

An alternative would be to add two remotely changeable personal telecommunications categories to the access nodes -- one providing an unconditional hot-line connection to the service node for originating calls, and the other giving an unconditional call forwarding to the service node for terminating calls. It appears necessary in the longer term to separate the visited and home location functions as in cellular networks if costs are to be reduced and capacity is to be improved.

One of the unique characteristic of IN is that services are implemented on the IN service platform based on its service independent building blocks (SIBs), and not directly in the network nodes. The SIBs are part of the SCP. FIGURE 3 shows the structure of a SIB. Each SIB 301 is an elementary logical element in a service logic that hides the implementation from the programmer. When existing SIBs cannot meet a new requirement, new SIBs are defined.

In IN products, the SIBs 301 perform functions such as analysis of signaling information, control of connection topology, interaction with the user, reading and writing of data, collection and output of call data, etc. Other SIBs are pure language elements such as jump, go to subroutine, loop, handover, etc. Each SIB 301 is available in the service platform. Service Logic Programs (SLPs) are built by SIBs 301 and refer to by their names. Service logic can be designed using a Service Creation Environment Function (SCEF). The SIBs 301 are made available to the SCEF through a system-independent Application Programming Interface (API).

The mapping of the various IN functional entities into physical units or entities is shown in FIGURE 4 where the suffix "F" stands for the various functional entities and the suffix "P" stands for physical entities. In FIGURE 4, the acronym SMF refers to the Service Management Function and the acronym CCF refers to the Call Control Function.

An example of an IN implementation with service nodes at the transit level is illustrated in FIGURE 5. The service nodes shown in FIGURE 5 can be reached from any access node such as a local switch in PSTN or ISDN or an MSC in a Public Land Mobile Network (PLMN) system. The service nodes can serve both personal telephony as well as other number-based services. User identities and authentication information may be transferred in-band to the SRF or embedded in calling- and called-party number fields in the signaling systems.

The personal agent has components in the Call Control Function, CCF (i.e., the trigger point data), the Service Control Function, SCF (i.e., the service logic), and in the Service Data Function, SDF (i.e., the service data). The IN platform components illustrated in FIGURE 5 can be either integrated into the access nodes or implemented in separate service nodes.

The role of the Service Switching Function (SSF) is to recognize that a call is invoking an IN service, and then to communicate with the SCF to receive instructions about how to handle the call. The SCF is where the intelligence of the IN resides as it contains the logic required to execute various services. The SDF is a database system that provides the data storage capacity needed for the data intensive supplementary services. The IP is the network element that provides resources for user interaction such as voice announcements and dialogue, dual tone multi-frequency reception (DTMF) and voice recognition.

The IN Application Programming Interface (API)

The ITU's IN Conceptual Model shown in FIGURE 1 also defines the methodology for implementing various services. This is shown in FIGURE 6. In order to implement a service or feature 601, the service requirements are first translated to SIB structures at 602. The resulting SIBs 603 are mapped at 604 to various Functional Entities 605. The Functional Entities 605 in turn are mapped at 606 to one or more Physical Entities 607.

It should be noted that unlike the practice with all non-IN standards, the service requirements in IN are not directly translated into network functionality. Instead, the service requirements are translated into service platform elements (i.e., SIBs) which in turn are implemented according to the IN three-stage model to become reusable capabilities and protocol elements in the telecommunications network.

There are at least two possible approaches toward implementing the Application Program Interface (API) that conform to the ITU's IN Conceptual Model shown in FIGURE I. One approach would be to split the service logic into two parts: a fixed logic part and a flexible logic part. The SIBs are then linked to form decision graphs that are called as subroutines by the fixed logic. The fixed logic can be expressed in a standard programming language such as C or C++, etc., and compiled and loaded into a standard execution environment. The flexible logic part, in contrast, consists only of exchangeable data.

The second approach would be to define a service API that gives full control over all aspects of the logic by combining SIBs with each other to achieve the desired function. Each SIB can be linked to any other SIB in this approach. Some SIBs perform a telecommunications function while others are only linking elements in the logic. All logic is expressed as data that describes which SIBs are to be used, how they are linked, and what data each SIB is to use to perform its function. All implementation details are thus hidden from the service programmer. This is the principal approach taken in Ericsson's IN products.

The two approaches toward implementing the API are illustrated in FIGURE 7. The SIB-platform approach is shown in FIGURE 7A, and the Service Logic Execution Environment (SLEE) approach is shown in FIGURE 7B. The SIB approach of FIGURE 7A expresses all service logic as a combination of elementary SIB functions that are available in the service platform to form flexible service profiles (FSPs). The SLEE approach shown in FIGURE 7B considers the SIBs as subroutines to the fixed logic expressed in a programming language such as C, C++, Service Logic Programs (SLPs), etc. The compiled code uses telecommunications platform primitives, such as INAP (Intelligent Network Application Part) operations and database primitives.

When the same data representation is used for all logic and data, personal agents can be defined by means of Flexible Service Profiles (FSPs), as shown in FIGURE 8. This arrangement offers a number of advantages, for example, permitting different logic elements to be loaded and activated without disrupting service, and in case of a fault in a personal agent, limiting the affected zone to only calls activating the faulty function.

Feature interaction has been a major obstacle in the development of IN systems. This problem arises from the fact that each feature is normally dependent on other features. There is a need to resolve such interactions, but no solution has yet been agreed on. It has been found in practice that existing feature implementations are often affected and many have to be redesigned or completely blocked when new features are introduced. It should be noted that this problem can be approached from two viewpoints: the network-centric view and the user-centric view of IN systems.

The traditional network-centric view sees IN as a complement to other technologies in adding supplementary services to an existing repertoire. Feature interaction has and continues to be the obstacle that prevents this view from being a realistic alternative. Each new supplementary service is composed of a fixed service logic part, and potentially of a flexible logic part. Personalization is thus limited to what can be achieved by combining a number of pre-defined supplementary services or features with each other. The addition of a new service may require long and costly development, not different from the pre-IN experiences in PSTN, PLMN and ISDN. The central issue in this viewpoint is not the design of a new feature, but on the task of integrating a new feature with other preexisting features.

In contrast, the user-centric view of IN focuses on the users rather than on the features. In principle, the needs of individual users are assumed to be unique, with the service provider being in full control of all service logic. The FSP approach is applied, and the result is that a range of unique service profiles can then be created by reusing SIBs rather than reusing features. This means that feature interaction ceases to be a problem, since no individual features are implemented. The interaction between the SIBs constitutes the service logic in this approach.

Interaction between service profiles in this approach is resolved through open signaling interfaces according to the half-call model. Before complete control can be provided from the step-wise developed IN platforms in an economically feasible way, it has been found necessary to use some of the existing supplementary services. It should be borne in mind that this is a shortcut that can result in interaction problems requiring enhancement of the IN platform in the future.

The principal goal in the user-centric view is to make the SIBs standardized so as to achieve both service-independence and system-independence and technology-independence. When this is achieved, a SIB-based service profile can be executed on any compatible platform, whether it is a switch processor, a stand-alone personal computer, or work-station. The old paradigm, giving the same features to all subscribers, is replaced by feature transparency for each individual subscriber, irrespective of access.

IN Signaling

The Intelligent Network Application Part (INAP) Protocol is used for signaling in IN systems. The INAP signaling protocol has been standardized by both the European Telecommunications Standards Institute (ETSI) and the International Telecommunications Union (ITU), and includes the CCITT Signaling System No. 7 (CCS7) which is one, but not the only network protocol that may be used to support INAP.

One of the shortcomings of the core INAP as it is specified today (i.e., the IN CS-1 standard), is that the communication possibilities between the SCF and the IPs are restricted to speech only. Other media such as e-mail, facsimile, data, etc. are currently not supported by the CS-1 standard. Thus, non-call-related and non-real time call-related services are not included in the present CS-1 standard.

The Networked IP (NIP) implementation, of which the present invention is a part, can be characterized as an extension to the INAP to include the handling and processing of non-voice media and the provision of non-call-related communication between the SCF and the IPs. NIP allows the SCF to be in total control of all store-and-forward (i.e. messaging) services such as voice mail, e-mail, SMS messages, etc. The protocol used for the NIP implementation is referred to hereafter as NIP-INAP. The NIP-INAP is an Ericsson-specific extension to the IN CS-1 standard.

Cellular Network Architecture

In the second generation of standards for digital cellular telecommunications systems, e.g., GSM, Base Station Controllers (BSCs) act as access nodes. Each Visited Mobile Switching Centers (V-MSC) comprises hardware and software having the functionality of both a VLR as well as an MSC. Thus, each V-MSC can act as both a switching center as well as a visited location with transparent signaling to the corresponding BSC.

It should be noted that nodes in a GSM system have been standardized to such an extent that new services and features cannot be added without violating (or at least derogating from) the standard. In contrast, the standards governing nodes in an IN system permit extensive customization.

A separate location management mechanism has been developed to associate terminal identities with the geographical and physical addresses that may change when the terminals move. In GSM, each terminal receives its identity from a user's SIM card inserted in the terminal, and bears no association with its physical location in the network.

An addressable entity called the Home Location Register (HLR) handles the terminal agent functions for a partition of the terminal number series. The HLR integrates a number of functions. For example, the HLR performs location management of the call managers to ensure that the flexible (or variable) portion of a subscriber's service profiles are currently updated in every visited location where the fixed portions of the profile have been installed.

The HLR also provides assistance in call set-up to the terminal by forwarding call data to the VLR, and obtaining in return, the Roaming Number (RN), which is then used to set up the connection for the call through the PSTN. The RN is used only during call set-up, to associate the terminal number with the connection, thus circumventing the limitations of the PSTN signaling that permits it to carry only one called party number. The HLR also provides for direct communication with the terminals (using the MAP protocol) to receive service management directives. The use of the personal SIM card unbundles the user from the terminal. However, current standards do not permit more than one user to be registered at any one terminal at a given time.

The supplementary services that are provided to subscribers have also been standardized in GSM. The majority of these supplementary services, especially those using call state information, are implemented in the visited locations. Call forwarding services are performed by the HLR. Use of the same standard by a large number of operators provides feature transparency for users over very large areas.

GSM, for example, will cover all of Europe and several countries. The large number of competing operators and vendors involved make it difficult to arrive at a consensus on additions, amendments or adaptation for personalization. Consequently, the provision of additional functionality and of supplementary services need to be done outside the GSM standard.

FIGURE 9 shows the architecture of an exemplary mobile radio telecommunications network. A cellular network comprises a terminal 903 into which a subscriber 901 inserts a personal SIM card 902. The terminal communicates with a Base Station (BS) 904 over an air interface, such as an air interface specified in an existing communication system. In an alternative implementation of the GSM system, the terminal 903 has an identity of its own that is built in by the manufacturer of the terminal.

Registration and service management, as well as terminating call management based on user changeable data, are all performed in the Home Location Register (HLR) 907. Originating call management and terminating call management based on terminal status are handled by the Visited Mobile Switching Center (VMSC) 906 that also contains the Visitor Location Register (VLR). The VMSC is (conceptually) both the visited location as well as the serving.node.

Routing to a cellular terminal is made by using the Roaming Number (RN) that is obtained using the signaling between the Gateway MSC (GMSC) and the Visited MSC (VMSC) via the Home Location Register (HLR). The Mobile Application Part (MAP) signaling protocol is used for the signaling between the GMSC 908 and the VMSC 906. It should be noted that the signaling between every GMSC and every VMSC is performed through a HLR and not directly. The CCITT Signaling System No. 7 Telephone User Part (TUP) and the CCITT Signaling System No. 7 Integrated Services User Part (ISUP), shown as element 909 in FIGURE 9, connect the cellular system to the public telephone system gateway node. The Base Station 904 is controlled by the Base Station Controller (BSC) 905 that also serves as an access node.

SMS Service in Cellular Systems

The operation of the Short Message Service (SMS) in a cellular system is depicted in FIGURE 10. The originator of a Short Message (SM) shown as MS-A 1060 in FIGURE 10 sends a Mobile Originated Short Message (MO-SM) to a service controller selected by MS-A 1060. The MO-SM is sent by issuing a "Forward SM" MAP command from the visited MSC/VLR 1051 to the Interworking MSC (IWMSC) 1052.

The transmission 1071 from the MSC/VLR 1051 to the IWMSC 1052 is performed by using the selected SC-A address as a "Global Title" as specified in the E.164 standard. The IWMSC 1052 analyzes the SC-A address in the "Called Address" SCCP component, changes the translation type and forwards the MO-SM to SC-A 1053 using the "Forward MO-SM" command in the SMS-MAP protocol, as shown at 1072.

When the Mobile Originated Short Message reaches the selected Service Center (SC-A) 1053, the SC-A executes one of a plurality of actions according to the directions or preferences of the Mobile Subscriber A 1060. It should be noted that the mobile subscriber's preferences need to be stored in the Service Center 1053 before such preferences can be executed.

In one embodiment of the present invention, the Service Center SC-A 1053 can perform a number of operations on the Mobile Originated Short Message. Examples of such actions include duplication and storage of a received Short Message, retransmission of a Short Message based upon a distribution list defined by MS-A 1060; conversion of an SM to a desired or preferred medium, etc. All of these actions can be based either on an indicated Protocol ID (PID) value or are based upon a subscriber defined profile value.

The SC-A 1053 can also distribute a Short Message to a subscriber-defined distribution list after converting the SM to one or more desired media according. Upon receiving the Mobile Originated Short Message, the SC-A 1053 acknowledges the same to the IWMSC 1052 as shown at 1073. The IWMSC 1052 in turn acknowledges the successful reception of the MO-SM using the MAP interface to the Visited MSC/VLR 1051. This is shown at 1074. The visited MSC/VLR 1051 then forwards the acknowledgment to MS-A 1060.

In one exemplary embodiment of the SMS system, the MO-SM is sent as a Mobile Terminated Short Message (MT-SM) to the Mobile Station B (MS-B) 1065. The steps involved in this transmission are shown by arrows labeled 1075-1080 in FIGURE 10.

First, the SC-A 1053 sends an MT-SM using the SMS-MAP interface to a Gateway MSC handling SM messages (SMS-GMSC) 1054. The SMS-GMSC 1054 then sends a query to the HLR 1055 to determine the present location of the intended recipient of the Short Message. The query to the HLR is performed over the MAP interface using the "Send Routing Info For SM" command.

In response to the query, the HLR 1055 returns <i>inter alia</i> an MSC number and the IMSI (International Mobile Subscriber Identity) to the SMS-GMSC 1054 as shown at 1077. The SMS-GMSC sends the MT-SM to the visited MSC/VLR 1056 using the "Forward SM" command. The visited MSC/VLR 1056 then delivers the MT-SM to the Mobile Subscriber B (MS-B) 1065 who acknowledges receipt to the visited MSC/VLR 1056.

Upon receiving an acknowledgment from MS-B, the Visited MSC/VLR 1056 generates an acknowledgment to the SMS-GMSC 1054 as shown at 1079 over the MAP interface using the "Return Result Component To Forward SM" message. The delivery of the Mobile Terminated Short Message to the intended recipient MB-B 1065 is acknowledged back to the SC-A 1053 as shown at 1080 by transmitting a "Return Result Component To Forward MT-SM" confirmation message.

Networked IPs

FIGURE 11 shows one embodiment of the Networked IP (NIP) system of the present invention. A Networked IP system comprises an SCP 1101 that can communicate with a plurality of Intelligent Peripherals (IPs) 1111-1114. Each of these logical IPs are SRFs in IN terminology, as noted earlier. For illustrative simplicity, only four IPs are shown in FIGURE 11: IP₁ 1111, IP₂ 1112, IP₃ 1113 and an SMS-IP, IP_s 1114. The IPs 1111-1114 can communicate amongst each other over a communications backbone 1110 using any protocol, for example, TCP/IP, X.25, etc.

FIGURE 11 also provides an overview of the message flow and operation of an embodiment of the present invention. As shown in FIGURE 11, the networked IPs 1111-1114 interact with the Public Land Mobile Network (PLMN) 1150 through a Gateway Mobile Services Switching Center (GMSC) 1161. As explained earlier in conjunction with the discussion of FIGURE 10, the GMSC 1161 can terminate an SMS message by polling a recipient's Home Location Register (HLR) 1166, ascertaining the current location of a mobile subscriber 1165 and routing the SMS message through a VMSC 1162 and a Base Station Controller (BSC) 1163 and a Base Station (BS) 1164

The conjunctive operation of an IN system and a PLMN 1150 is illustrated in FIGURE 11. The process starts with an SCP 1101 commanding the SMS-IP 1114 to probe the activity status of a mobile subscriber. This is done as shown at 1171 by a "Send Probe" command sent from the SCP to the IP_s, the SMS-IP. In response, the SMS-IP 1114 sends a dummy SMS message to the Gateway MSC 1161 as shown at 1181.

It should be noted that the term "dummy SMS message" as used here can be any syntactically-accurate SMS message. The message is called a "dummy" message because it doesn't have to contain any specific content. The dummy SMS message is thus akin to an empty envelope that is sent to an addressee for the purpose of verifying the existence or accuracy of an address. The dummy SMS message is important for what it does or causes (i.e., activation of the message waiting function in a mobile subscribers HLR, as explained below) rather than for what it contains. Thus, a dummy SMS message can be a real SMS message with null contents, or even a defective SMS message that would be rejected by a mobile subscriber if it were active.

Upon receiving the dummy SMS message, the GMSC 1161 activates the storage of non-delivered messages to a mobile subscriber by enabling the Message Waiting Data List (MWD-List). The GMSC also acknowledges the arming of the PLMN to the SMS-IP 1114 as shown at 1182. The SMS-IP 1114 in turn notifies the SCP 1101 at 1172 that the "Send Probe" command has been successfully executed.

Upon the completion of the above actions, the PLMN 1150 has now been armed. When a previously inactive mobile subscriber becomes active, the notification of the renewed activity to HLR 1166 will now result in the triggering of an "Alert" command from the PLMN 1150 to the SMS-IP as shown at 1183. Upon receiving the alert from the GMSC 1161, the SMS-IP 1114 unilaterally generates a "Mailbox Status Report" notification to the SCP 1101 as shown at 1173.

FIGURE 12 is a sequence diagram illustrating the flow of messages between the various logical entities of the present invention. As shown in FIGURE 12, the subscriber activity monitoring process comprises two phases. In the first phase, upon a probed mobile subscriber not being active, the IN system components arm the PLMN system to generate an activity alert. In the second phase, the PLMN generates an alert to the SMS-IP when an erstwhile inactive mobile subscriber becomes active in turn generating a "Mailbox Status Report" to its controlling SCP.

The communications between the SCP and the various IPs 1111-1114 is shown using Transaction Capabilities Application Part (TCAP) notation in FIGURE 12, with the message type being shown above the arrow and the components of the TCAP message and the parameters being shown beneath each arrow.

The process begins when an SCP attempts a dial-out and fails. Thus, in the first phase, upon receiving a "Send Probe Message" command from the SCP 1101 as shown at 1201, the SMS-IP 1114 in turn issues a "Probe SMS Sending" command at 1202 to the PLMN system 1150. This causes a flag to be activated in the queried recipient's HLR to indicate that the queried SMS-IP is to be notified when the mobile subscriber next becomes active.

Simultaneously, the PLMN system 1150 activates the storage of undelivered messages to the subscriber by enabling the MWU-List. The PLMN then notifies the SMS-IP 1114 by sending a "Message Waiting Set In PLMN" acknowledgment to the SMS-IP at 1203. This in turn is acknowledged by the SMS-IP 1114 back to the SCP 1101 at 1204. The probe here is an SMS message which makes use of the "Message Waiting" feature of PLMN system that can create a MWD-List in the HLR to retain undelivered messages.

In the second phase, the PLMN triggering notification phase, the PLMN 1205 issues an "Alert" notice to the SMS-IP 1114 at 1205. The SMS-IP 1114 in turn generates a "Mailbox Status Report" notification to the SCP 1101 as indicated at 1206. After this notification is received, all further action by the SCP is at its own discretion.

An IN service provider may wish to generate a subscriber activity report. Such a feature would permit an SCP to determine whether a specific mobile station is switched on or not. A subscriber activity report of this kind would be particularly useful, for example, if a dial-out notification fails due to a desired mobile station being detached or out of memory. In such a case, it would be useful for the SCP to be able to monitor the activity of the mobile station in order to detect when the mobile station becomes reachable again.

As detailed earlier, the architecture of a standard cellular system presently includes a facility that causes the Home Location Register (HLR) to create a message waiting date list (MWD-List) if an SMS message cannot be delivered to a mobile subscriber. Consequently, it would be useful if this pre-existing feature of the cellular system can be utilized to solve the need to automatically generate a subscriber activity report.

Mailboxes can exist for several different media, for example, voice mail, facsimile mail, e-mail, SMS, etc. In the present disclosure, each medium and its associated mailbox, is referred to as a logical IP. In order to control the messages received by a subscriber in his mailbox, and to facilitate the notification to the SCP or the subscriber when the status of a subscriber's mailbox changes, it would be useful for an SCP to be informed about the status of a subscriber's mailboxes.

The present invention provides a solution for monitoring the activity of mobile subscribers, and consequently, to notify an SCP when renewed subscriber activity is detected. The present invention does this by introducing two new procedures to the NIP-INAP: the "Send Probe" command which enables an SCP to order an SMS-IP to send a dummy SMS message to a mobile station in a PLMN system; and the "Mailbox Status Report" command which enables an IP to report to the SCP when the status of a specific mailbox has changed.

Presently, an IN node is generally unable to monitor an unreachable mobile station. The present invention provides a networked solution based on the IN architecture by defining a protocol to enhance service revenues by increasing the successful message delivery rates.

Another aspect of the present invention enables an SCP to be updated about the status of a subscriber's mailboxes. Two new procedures have been introduced to the NIP-INAP for this purpose: the "Mailbox Status Report" command which enables an IP to notify an SCP when the status of a specific mailbox has changed; and the "Mailbox Status Enquiry" command which enables an SCP to poll or query an IP about the status of a particular subscriber mailbox.

Extensions to NIP-INAP Procedures

We will next consider the detailed operation of the various new procedures that are introduced to the NIP-INAP for the implementation of the preferred embodiment of the present invention. Before an SCP can order an IP to query the activity status of a mobile subscriber in a PLMN system, procedures are necessary to facilitate the notification of the SCP when an alert message has been received by an SMS-IP from a PLMN system.

The "Mailbox Status Report" Message

The spontaneous report by an IP of the change in mailbox status of a subscriber is implemented by using the "Mailbox Status Report" command. As shown in FIGURE 13, the Mailbox Status Report is sent from an SMS-IP, IP_s 1114 to the SCP 1101 upon any change of mailbox status as long as the change in status was not initiated or controlled by the SCP. However, when a message is deposited in a mailbox (i.e., it is received by the IP designated for receiving messages in a certain medium), the SMS-IP generates a "Mailbox Status Report" message even if the SCP is in control. In the discussion that follows, the role of the SMS-IP can be played by any of the other Networked IPs 1111-1113.

It should be noted that at the time of issuance of this notification by the SMS-IP, IP_s 1114, there may or may not be an ongoing dialogue between SCP 1101 and IP_s 1114. In order for the IP_s 1114 to issue the "Mailbox Status Report" message to the SCP, the status of a subscriber's mailbox must change. After receipt of this command by the SCP 1101, further action is at the discretion of the SCP.

If desired, the SCP may obtain detailed information about the status of various messages using the "Mailbox Status Enquiry" command that is discussed below. Although the "Mailbox Status Enquiry" command is not essential to the operation of the preferred embodiment of the present invention, it is discussed below for the sake of completeness.

The "Mailbox Status Enquiry" Message

In contrast to the "Mailbox Status Report" message, which is spontaneously generated by an IP upon any change in mailbox status, the "Mailbox Status Enquiry" message is triggered only by affirmative action by the SCP or upon affirmative subscriber Enquiry about the status of his or her mailbox. FIGURES 14 and 15 show the sequence diagram when an SCP enquiries an IP about the status of a subscriber's mailbox. If IP_s 1114 has reported a change in mailbox status to SCP 1101 using the "Mailbox Status Report" message discussed earlier, and if the SCP 1101 desires to obtain more or detailed information about a subscriber's mailbox or mailboxes, there are two possible outcomes, as shown in FIGURES 14 and 15.

If the SCP 1101 asks IP_s 1114 for brief information about mailbox status, as shown at 1401, then IP_s H 14 can return the desired result to SCP 1101 as shown at 1402 without segmentation of the results. Likewise, if the SCP 1101 queries IP_s 1114 for detailed information about mailbox status, and if no detailed information is available, then too the IP_s 1114 returns the result in a unitary (i.e. unsegmented) message to SCP 1101 as shown at 1402.

On the other hand, if the SCP 1101 queries IP_s 1114 for detailed information about mailbox status, and if such information is available, then IP_s 1114 sends the information to SCP 1101 in multiple segments, as shown in FIGURE 15. The process starts with the SCP making a detailed enquiry of the IP_s 1114 at 1501. In response, IP_s 1114 sends part of the results to the SCP at 1502. Thereupon the SCP asks for the remaining information at 1503. IP_s provides another standard Return Result segment at 1504 and (optionally) indicates that still more information remains available.

This process is successively repeated with the SCP 1101 asking for more and more information from IP_s as indicated at 1505 until IP_s returns a Return Result component to the SCP as shown at 1506, indicating that no further information about mailbox status is available. When the SCP has obtained, assembled and analyzed the various segments of the result returned by IP_s, all further action on its part is at its own discretion.

In another embodiment of the present invention, the SCP may send a message to a particular recipient, or notify a mailbox owner of the results of the "Mailbox Status Enquiry" command on his mailbox.

The "Mailbox Status Enquiry" command can also be used to service a subscriber who enquires about the status of his or her mailbox or mailboxes. This is illustrated in FIGURE 16 for the case when the returned result is not segmented, and in FIGURE 17, when the returned result is segmented.

As depicted in FIGURE 16, when a user wants to know the status of his mailbox, the SCP issues a "Mailbox Status Enquiry" command as shown at 1602 to IP_s 1114 asking for brief or detailed information as appropriate. If only brief information was asked for at 1601, or if detailed information was asked but was not available, IP_s 1114 returns the result of the enquiry to the SCP as shown at 1602 without segmentation of the results. Thereafter, further action is at the discretion of the SCP 1101.

FIGURE 17 shows a sequence diagram when a user makes a detailed enquiry about the status of his mailbox. Upon receiving the enquiry, SCP 1101 issues a "Mailbox Status Enquiry" command to IP_s1114, as shown at 1701, asking for detailed information about a particular mailbox or mailboxes. IP_s 1114 segments the results to be returned, and sends the first segment back to the SCP as shown at 1702 and indicates that more information remains available. In response, the SCP invokes the "Mailbox Status Enquiry" command a second time at 1703 asking for some or part of the remaining information. The IP_s 1114 responds by returning the second result component to the SCP as shown at 1704 indicating that there is still more information available.

As discussed earlier in connection with the description of the sequence diagram shown in FIGURE 15, the SCP 1101 repeatedly issues the "Mailbox Status Enquiry" command to IP_s 1114 as shown at 1705 until IP _s1114 transmits a Return Result component as shown at 1706 indicating that no more information is available. The SCP then assembles and analyzes the segmented result components returned and performs further actions at its own discretion.

The "Mailbox Status Report" and "Mailbox Status Enquiry" commands make it possible to initiate an alert to the SCP or to a subscriber when the status of the subscriber's mailbox has changed and to centrally control all of a subscriber's different types of mailboxes despite the fact that they are located at physically and/or logically distinct IPs.

We next consider the Subscriber Activity Supervision Service in further detail. Automating the monitoring and third-party notification of renewed activity by subscribers in a PLMN system has long been desired by subscribers and telecommunications service providers. As indicated earlier, there are no procedures within the presently defined IN architecture to monitor an inactive or unreachable mobile station.

The present invention permits an SCP to monitor the activity of a presently-quiescent mobile station by introducing two new procedures: the "Send Probe" command which enables an SCP to order an SMS-IP to probe the activity status of a mobile subscriber in a PLMN and the "Mailbox Status Report" notification which enables an SCP to be notified when a subscriber's mailbox status changes.

In the sequence diagrams presented below, a specific IP IP_s 1114, referred to as the SMS-IP, is used for the exchange of messages between an IN node and a PLMN subscriber. However, it should be emphasized that the actual exchange can take place from an SMS-IP, from any IP supporting SMS messages, or from any other IP containing the necessary processing power and system resources.

The "Send Probe" Command

FIGURE 18 shows the sequence diagram when the SCP probes the activity status of a mobile subscriber. As indicated here, the "Send Probe" command makes use of the pre-existing feature in second-generation PLMN systems that causes the Home Location Register (HLR) in the PLMN to create a Message Waiting Data List (MWD-List) whenever a message cannot be delivered to a subscriber.

When an MS is found to be unreachable, the process begins as shown at 1851 with the SCP 1101 issuing a "Send Probe" message to an SMS-IP 1114. The SMS-IP 1114 in turn sends a dummy SMS message to the unreachable MS in the PLMN 1150, as shown at 1852. Since the MS is unreachable, the HLR corresponding to the MS in the PLMN 1150 creates an MWD-List for the recipient of the dummy SMS message.

The PLMN, acting through the SMS Gateway MSC, acknowledges the activation of the MWD-List to the SMS-IP 1115 as shown at 1853. This report of successful completion is forwarded in an appropriate format by the SMS-IP 1114 to the SCP 1101 as shown at 1854.

As detailed earlier, upon the MS becoming reachable, an alert is generated by the PLMN 1150 to the SMS-IP 1114 causing the SMS-IP to issue a "Mailbox Status Report" message to the SCP 1101.

SCP and IP Finite State Machines

FIGURES 19 and 20 show the finite state machines for the SCP 1101 and the SMS-IP 1114 of the present invention. In FIGURES 19 and 20, the states of the machine are symbolized with an oval, while events causing state transitions are drawn by continuous arrows. Functions are depicted within broken rectangles, while actions ordered by the functions are indicated by broken arrows.

FIGURE 19 shows the finite state machine for the SCP. As can be seen, the SCP has two states: the Idle state 1901 and the Active state 1902. The SCP goes from the Idle state 1901 to the Active state 1902 upon issuing a "Send Probe" command to the SMS-IP 1114, as shown at 1911.

The SCP goes from the Active state 1902 to the Idle state 1901 as shown at 1912 upon normal termination of the dialogue between the SCP and the IPs. if a dialogue were rejected due to the presence of improper components, if a dialogue is aborted from either side or if the operation is timed out. The SCP 1101 loops (i.e. remains) in the Active state 1902 without any state transition as shown at 1913 upon the receipt of the results of the "Send Probe" message from the SMS-IP 1114.

FIGURE 20 shows the finite state machine from the IP side. The SMS-IP has two principal states: the Idle state 2001 and the Active state 2002. There is also one additional quasi-state: the PLMN Probe Handling state 2021.

As shown in FIGURE 20, the SMS-IP 1114 goes from Idle state 2001 to the Active state 2002 upon receiving the "Send Probe" command from the SCP 1101, as shown at 2011. An IP transitions from the Active state 2002 to the Idle state 2001 as shown at 2012 upon normal termination of the dialogue with the SCP or upon rejection of an offered result by the SCP or upon an abort of the dialogue between an SCP and IP from either side.

If an SMS-IP 1114 receives the "Send Probe" command, the transition from the Idle state 2001 to the Active state 2002 is additionally accompanied by the transmission of the Mobile Terminated Probe Message to the PLMN probe handler as shown at 2013 and the return of the results of the same as shown at 2014. The SMS-IP loops (i.e. remains) in the Active state 2002 upon returning the results of the "Send Probe" message back to the SCP as shown at 2015.