Control of plmn messaging services in ip domains

The present invention relates to messaging.

Messaging services in the PLMN domain are becoming more and more popular among mobile subscribers. Short Message Service (SMS) originated from the GSM network and has spread to many different network technologies and is now ANSI-41. It is found in TDMA and CDMA networks and is used in Japanese PDC networks. This growth is being accelerated by subscriber demand for messaging services, providing a means of communication between individuals and groups that was previously unavailable. With the advent of 2.5G and 3G network technologies, there are significant benefits in extending the scope of messaging services beyond the boundaries of mobile networks by bringing packet data network (PDN) domains to interoperability. The Internet domain has shown tremendous growth in recent years, and the number of users who can be contacted via Internet addresses is increasing significantly every year. In addition, the mobility of Internet users is increasingly favored by the mobile IP protocol, allowing individual users to reach the same Internet address regardless of their geographic location.

<p> The present invention provides control and transport entities that enable the execution of integrated messaging services and provides means for sending, transporting and delivering messages between PLMN and IP domains (fixed and mobile). The purpose is.</p>

<p> According to the present invention, a gateway including an interface to a packet network, an interface to a mobile network, and a processor for performing protocol conversion of a packet network connected to the interface and a message communicated between the mobile networks. Is provided.</p><p> In some embodiments, the processor, for detecting and maintaining presence information in the packet network, and mapping a presence state in a form that is used in the mobile network has a presence management function for graying.</p><p> In another embodiment, the presence management function acts as a Session Initiation Protocol (SIP) registrar.</p><p> In yet another embodiment, the presence management function has an interface for accessing an external SIP registrar in the IP network.</p><p> In some embodiments, the interface maintains a cache of SIP entries.</p><p> In another embodiment, the presence management function stores the user's device capability, and the protocol conversion function selects a message delivery protocol based on the device capability.</p><p> In yet another embodiment, the processor further has a message routing function for routing a message having a mobile network address format to a user in the packet network.</p><p> In one embodiment, the routing function translates an address in mobile network format into an address in packet network format.</p><p> In another embodiment, the routing function routes a single message from one network to multiple addresses on another network.</p><p> In yet another embodiment, the routing function interfaces with a packet network broadcast service.</p><p> In some embodiments, the gateway has an interface for emulating a mobile network entity such as SME or SMSC.</p><p> In another embodiment, the interface emulation feature allows the gateway to operate without reconfiguring the traditional mobile network.</p><p> In yet another embodiment, the interface extracts a URL from the text of the message, provides a deferred acknowledgment, and notifies SMSC on the mobile net that a user in the IP domain is active.</p><p> In one embodiment, the processor has a message delivery management function for extending the store-and-forward delivery capability to the IP domain.</p><p> In another embodiment, the presence management function notifies a network entity whether a subscriber has entered a domain of another network.</p><p> In yet another embodiment, the presence management function notifies the entity whether the subscriber is the intended recipient of a message awaiting delivery.</p><p> In some embodiments, the notification signal dynamically identifies search criteria for network entities ranging from direct match criteria to partial match criteria.</p><p> In another embodiment, the gateway has means for modifying a message of a network entity such as SMSC to charge its destination address.</p><p> In another aspect, according to the present invention, there is a method for communicating between a mobile network and a packet network. A mobile device in the mobile network sends a message with a gateway mobile network address and an embedded destination packet network user address as defined above. The mobile network entity routes the message to the gateway interface and A method is provided in which the gateway receives the message at the interface, removes the destination packet network address, and routes the message to a packet network user having the packet network address.</p><p> In some embodiments, the packet network address is in session initiation protocol format.</p><p> In another embodiment, the gateway maintains a table that associates the packet network address with the packet network user's mobile network standard address, and for later messages, the mobile network user has only the mobile network standard address. And the gateway searches the packet network address from the table.</p><p> In yet another embodiment, the gateway is tied to at least one mobile network entity for message communication.</p>

The present invention can be more clearly understood from the detailed description of some embodiments described below as merely examples with reference to the accompanying drawings.

The present invention controls the delivery of common PLMN-based messaging services (eg, SMS, cell broadcast) to users in the IP domain (eg, users with fixed internet addresses or users on currently active wireless LANs). IP vs. PLMN Gateway (IPG) node 1 is provided for this. Users in the IP domain can be fixed or mobile. Mobile subscribers generally allow roaming between PLMN and IP domains. There are two forms of roaming. That is, (1) a form PLMN (HPLMN) subscriber roaming where a PLMN mobile subscriber roams to an IP domain owned by a PLMN operator, and (2) another PLMN (using an existing inter-PLMN roaming contract). A visiting PLMN (VPLMN) subscriber roaming where a PLMN mobile subscriber who is "roaming" roams to the IP domain of the visiting PLMN.

Therefore, by extending the reach of messaging services from the PLMN domain to the IP domain, a wider community of message users will be created and the mobile handset as the only outgoing or incoming device for mobile messaging will be removed. Is done. For example, a mobile subscriber may not be able to contact through a mobile handset, but may want to send a message to another user who may be in a packet data domain, such as a wireless LAN or fixed Internet. Similarly, Internet users may want to send a message on their handset for delivery to a mobile subscriber.

The PDN messaging community can envision many different forms. One community of PDN domains can be a set of users in an airport connected to a wireless LAN hotspot (eg 802.11, Hyper LAN), another community is a "fixed" subscription to an interactive PV domain. Can be a person. All such PDN domains can be part of a single PDN domain that is larger in terms of PLMN, or can be considered equally as separate PDN domains.

The present invention is described in the context of GSM PLMN and IP-based PDN. However, the present invention can be similarly applied to alternative mobile network technologies such as CDMA, TDMA, PDC and UMTS, in addition to PDN technologies beyond IP-based networks.

The IP to PLMN Gateway (IPG) node allows the extension of PLMN messaging domains to IP domains such as fixed Internet and wireless LAN networks. IPG node 1 has an IP transport interface 2 connected to a session initiation protocol (SIP) user agent (UA) 3 and further connected to a message delivery function 4. Function 4 is connected to both protocol conversion function 5 and presence management function 6. The SME interface 7 is connected to the interface on the one hand and to the presence management function 6 and the message routing address management function 8 on the other hand. In addition, the node has a billing function 10.

IPG implements a set of control and transport functions that allow common messaging services and formats in the PLMN domain to be appropriately modified for outbound or delivery in the IP domain. An advantageous element of the present invention is that all enhanced service functions in PLMN (eg, store-and-forward, message wait and alarm functions) are transferred to the messaging services available in the IP domain. IPG ensures that there is no need to modify any existing message service equipment in PLMN for full functional messaging services in the IP domain. However, the present invention also provides extensions to standard interfaces between IPG nodes and messaging platforms to enable optimal delivery of messaging services in the IP domain. Another aspect of the invention is in all PLMN technologies that support messaging services (eg short message services, cell broadcasting, multimedia messaging, instant messaging) and in any IP domain (eg fixed or mobile internet). It is applicable. Execution of the present invention in the context of GSM PLMN and fixed network IP domains is described below and describes short messaging services.

In GSM networks, the Short Message Service Center (SMSC) network element provides short messaging services. The SMSC communicates with another element of the PLMN (like HLR, VLR, MSC) through the interworking gateway MSC (I-GMSC). In addition, SMSC provides an application interface that allows service developers to connect applications with SMSC. An example of such an interface protocol is the short message peer-to-peer (SMPP) protocol identified by the SMS forum. Within the PLMN domain, SMSCs can receive short messages (SMs) from external applications via SMPPs addressed to specific mobile subscriber MSISDN. The SMSC stores the SM in internal storage and then requests routing information from the HLR for the mobile subscriber. When routing information is received, the currently available MSCs / VLRs for mobile subscribers are displayed. The SMSC submits the SM to the MSC / VLR available for delivery to mobile subscribers. If the delivery is successful, SMSC marks the SM as delivered in the message storage device. If the delivery is unsuccessful (perhaps because it cannot be contacted within the network available to the mobile subscriber), SMSC will attempt a later delivery (if the subscriber is operational on the network). A message wait flag can be set in the HLR to inform the SMSC, or the message can be scheduled for retry delivery attempts according to an internal retry algorithm).

IPG Node 1 incorporates all the necessary functional elements that allow PLMN to provide a full range of messaging capabilities in an IP domain. In the embodiment of the present invention shown in FIG. 1, the main functional entity in IPG node 1 is (a) Short Message Entity (SME) Interface to SMSC in PLMN 7, (b) Subscriber presence management 6, (c) Protocol conversion 5, (d) Message delivery management 4, (e) Message routing and address management 8, (f) Billing and billing management 10.

These functional entities are made according to the conditions of each particular embodiment of the invention. For example, in this embodiment of the invention, the SME interface 7 to SMSC is based on the SMPP protocol. Subscriber presence management, protocol translation and message delivery management are based on the Session Initiation Protocol (SIP).

Regarding Figure 1, the end-to-end description of the short message service between PLMN and the IP domain is given as follows.

PLMN-Outgoing / IP Incoming: The mobile subscriber MS uses GSM PLMN to send an SMS to another user known to the mobile subscriber. Mobile subscribers know that the recipient is not using a mobile handset, but can receive SMS over its fixed Internet service via a SIP URL when connected to the network. The mobile subscriber identifies the destination MSISDN corresponding to IPG's SME interface 7 and identifies the user's SIP URL as a text field in the message. When the mobile subscriber sends a message, it is received by SMSC at PLMN and routes the message to SME interface 7 on IPG node 1. SME interface 7 is the destination SIP from the message text Extract the URL and provide this information to subscriber presence management function 6. The SMPP format of the message is provided to the message routing entity 8 and the protocol translation entity 5, where the message is translated into a format suitable for delivery over SIP. Presence management function 6 uses the SIP proxy and SIP registrar entity to determine the current state of the destination user. If it is determined that the user is connected to the IP domain, an appropriately formatted SM is submitted to the message delivery management function 4 for delivery. Message delivery is attempted using the SIP user agent 3 that communicates with the peer SIP user agent 20 on the destination user's device. If the message is successfully delivered to the destination user, this state is returned to SMSC via SME interface 7. If the message is not delivered, the message delivery management function can set a message wait flag for the destination user. When the user connects to the IP domain, this presence is detected via presence management function 6 and a notification signal is sent to PLMN's SMSC, prompting it to try to deliver the SM again through SME interface 7. .. In this way, all the functionality of PLMN's SMS service has been transferred to the IP domain. Call the billing and billing management function 10 to give the billing function to IPG node 1. To support the prepaid billing model, a pre-delivery credit check can be called to check a user's credit balance before initiating a message delivery attempt. If the credit check returns a positive display, a message delivery will be attempted and if the delivery is successful, the appropriate fee will be deducted from the user's account. In the postpaid billing model, CDR (Call Detail Record) events are generated for both successful and unsuccessful delivery attempts. CDR events can be used to generate subscriber billing information

IP-Delivery / PLMN Incoming: A user in IP domain 9 initiates an SM to a mobile subscriber in the PLMN domain, addressed via a SIP URL containing the mobile subscriber's MSISDN. The message is submitted on the user's device via SIP user agent 20, which makes the message a standard SIP. Route to SIP user agent 3 on IPG node 1 based on the URL mechanism. At IPG node 1, SIP user agent 3 processes the URL and pulls out the mobile subscriber's MSISDN. The SM is sent to the protocol converter 5 and converted to the SMPP format with the mobile subscriber's MSISDN as the destination address. The reformatted message is sent to SME interface 7 and thereby submitted to PLMN's SMSC through SMPP. At this point, the message submission acknowledgment can be returned to the user in the IP domain via SIP user agent 3. Further processing of SM delivery is fully processed within the PLMN domain using standard SMS functionality. For message delivery in this direction, subscriber presence and message delivery management function entities 6 and 4 are not used.

The billing and billing management function 10 may support a range of billing models for said services, including billing or non-billing for delivery of incoming messages, billing or non-billing for outgoing messages, and prepaid or postpaid models. it can. In the prepaid billing model, the message delivery or message sending function is interrupted while the billing and billing function is performing a credit query to the subscriber. If the credit check is positive, the delivery or outbound function is initiated. If the credit check is negative, the delivery or outbound function may be revoked and instead offer the subscriber an option to restore credit. In each case, the billing and billing management function 10 records CDR events for message submission and delivery attempts. These CDR events can be processed to generate subscriber billing information for postpaid subscribers, or simply used for auditing and account adjustment purposes in a prepaid billing model.

Other addressing formats for IP domains: Other addressing formats can be used to identify the addresses of users in the IP domain, which are executed by IPG node 1. Below are some examples of other IPG-supported addressing formats. MSISDN-like address-Non-PLMN users receive MSISDN-like addresses. MSISDN-like elements in SIP URLs-Non-PLMN users receive MSISDN-like addresses that are included in the SIP URL. "True" MSISDN in SIP URLs-PLMN users can choose to receive messages in the IP domain, and their PLMN MSISDN can be included in the SIP URL for this purpose. Group addresses with MSISDN-like or group "name" elements-This addressing format is used for one-to-many services. Geographical or regional addresses with MSISDN-like or location "name" elements-This addressing format is used for broadcast services. · SIP representing PLMN users URL-This form of address is used as the destination address for PLMN users when the SM is originating by an IP user. The true MSISDN for PLMN users is usually embedded within the SIP URL.

These addressing formats are processed by IPG node 1 for the IP domain from the PLMN domain so that the PLMN user can trigger the "answer" function when a message is received from the user in the IP domain. It is possible to assist the user in directly addressing.

A more detailed description of the functions executed by each of the functional entities is shown below.

SME interface 7 This functional entity is responsible for ensuring communication between SMSC at IPG Node 1 and PLMN. In this embodiment of the invention, communication between SMSC and IPG is guaranteed using the SMPP protocol. In addition to protocol handling, SME Interface 7 also incorporates certain features that allow IPG Node 1 to appear to SMSC as if it were a standard PLMN SME. They are, -Extracting the SIP URL from the message text · Deferred acknowledgment to message submitted by SMSC for delivery Ability to generate a notification signal to notify SMSC that a user in the IP domain is in a working state (ie, presence is detected) Is.

Subscriber presence management function 6 This management entity is responsible for detecting and maintaining the presence state of users in the IP domain. In this embodiment, this function is based on the mechanism defined in the SIP protocol, that is, it can function as a SIP registrar and process SIP REGISTER messages sent by the SIP user agent 20 in the IP domain. In this case, IPG node 1 stores the SIP-URL and IP address of the "registered" (legitimate) user.

It is possible that the SIP registrar already exists in the IP network domain. In this case, the presence management entity 6 queries the SIP registrar to determine presence information for users in the IP domain each time a message delivery attempt is requested. To reduce communication overhead with external SIP registrars, Function 6 incorporates a SIP registry cache that stores presence information for the configurable period, thus avoiding repeated queries to the SIP registrar. In the event of a message delivery failure due to the absence of an IP domain user, the SIP registry cache entry for that user is automatically deleted.

Protocol conversion This entity provides the translation between the signaling protocol used by PLMN and the protocol used by the IP domain. In this embodiment of the invention, the SIP protocol is used for the delivery of messaging services in the IP domain. Communication with the PLMN domain is performed using SMPP, and the protocol conversion entity performs conversion between SMPP and the SIP protocol.

Generally, the IP domain protocol used to receive a message is determined by the capabilities of the user equipment addressed within the "destination address" parameter of the message. IPG node 1 will select the message delivery protocol based on the capabilities of the user equipment. The functions of the user agent device will be sent to the IPG when the user is registered in the IP domain. The profiles of these user agents will be stored by the IPG presence function.

Message delivery management 4 This functional entity is responsible for ensuring that the store-and-forward messaging delivery model from the PLMN domain is extended to the IP domain. When a message is received from the PLMN domain for delivery to the IP domain, the IPG attempts to deliver it using the IP domain protocol of its choice. Message delivery using the SIP protocol describes this embodiment of the present invention as follows.

Upon receiving a message from PLMN via SME interface 7, message delivery management entity 4 receives the message after it has been converted to SIP format by protocol translation entity 5 and the IP domain destination address (SIP URL) has been extracted. First, the delivery entity can investigate the presence of users in the IP domain by submitting a query to the SIP registrar function. If the user is present, the user's current contacts can be returned by the SIP registrar. Alternatively, the delivery entity may attempt to determine the SIP URL by another means, such as via DNS, or through an internal query using the owner's protocol. The delivery entity 4 generates an appropriately formatted SIP MESSAGE request for delivery of the message to the user. Depending on the delivery protocol in use, SIP MESSAGE may or may instead carry the message within its payload. The INVITE request can be used to establish a session with the user to which the message will be forwarded using the appropriate session protocol. Assuming direct delivery using SIP MESSAGE requests, SIP MESSAGE can be sent directly via the SIP user agent within the IPG if the contact has already been determined. Alternatively, the SIP MESSAGE can be submitted via the SIP proxy responsible for determining the user's current contact information. If the message is successfully delivered to the user, a positive response is received by the delivery entity in the form of a 200 OK response. This status information is then returned to PLMN's SMSC via SME interface 7, where the message can be marked as delivered.

If message transfer fails (due to resource limitations, network issues, or unregistered user agent), delivery entity 4 flags the message wait data (MWD) flag for UAC in the IPG. Set and memorize the outgoing SMSC address. A single UAC can store a number of SMSC addresses, each representing a source SMSC in which messages awaiting delivery to that UAC are stored. After that, when the user registers with the IP domain, the IPG node 1 detects that the MWD flag is set for the user. The delivery entity generates an SMPP "notification" message to be sent to all SMSC addresses stored within the user's MWD flag. This notification message is used by SMSC to trigger a new delivery attempt for all messages waiting to be delivered to users in the IP domain. When IPG node 1 receives the retryed message, it then continues to deliver to the currently registered UAC, as described above.

The present invention enhances the execution of "notification" messages in which SMSC and IPG node 1 can work together to optimize delivery attempts to users in the IP domain, even when no direct address is assigned to the user. Is specified to do. Presence management function 6 can also determine if a subscriber waiting for a message is present in the IP domain and notify SMSC. The enhanced notification message contains the SIP URL of the destination user. When received by SMSC, the enhanced notification mechanism executed by SMSC examines the waiting messages for IPG node 1 and notifies only those messages that match the notified SIP URL. The criteria for "fitting" the notified SIP URL can be changed dynamically, for example, an exact match can be requested, or a partial match in the domain or part of the domain is sufficient. Can be done. In another embodiment of the invention, the notification message itself may include elements that specify the conformance requirements required for each notification.

Message routing and address management 8 This functional entity ensures that messages are properly routed between PLMN and IP domains. It also provides the ability to assign PLMN compatible addresses to IP domain addresses (eg SIP URLs), allowing PLMN domain users to directly address IP domain users using MSISDN-like addresses. There is. According to the present invention, this function enables direct messaging between PLMN and IP domain users, for example, a message received by a PLMN domain user using the "answer" function from an IP domain user. Can respond. The operation of the basic addressing format supported by IPG Node 1 is described below.

1. Address users in the IP domain using SIP URLs: When a PLMN user sends a message to a user in the IP domain, they are required to enter the well-known MSISDN as the destination address and the SIP URL in a special text field in the body of the message, which ensures that the message. Is routed to IPG node 1. When the IPG node 1 receives the message, the SIP URL is extracted from the message and sent to the address management entity. Examine the SIP URL to see if it is assigned to a MSISDN-like address from the range of MSISDN numbers identified by IPG node 1. If no MSISDN-like number is assigned, address management entity 8 selects a free MSISDN from the IPG range and creates a bond with the SIP URL stored in the IPG. Once assigned, this MSISDN-like number can be used as a direct address for IP users with respect to the PLMN domain. SIP If the attempt to deliver the message to the URL is successful, the delivery receipt can be generated by using the MSISDN-like number as the outgoing address. Upon receipt by the PLMN subscriber, this address can be a direct destination address for IP users, eliminating the need to identify the SIP URL in the message text in future messages. When the IPG receives a message to the IP user using MSISDN's direct address, the address management entity 8 automatically searches the IPG table for the SIP URL and completes the delivery in the IP domain.

If the message delivery fails, IPG node 1 replaces the original (IPG) destination address with the newly assigned MSISDN-like destination address in the copy of the message stored in SMSC. Here, subsequent message retries use the MSISDN-like address as the destination address. If the MWD flag is set for an IP user, the "notification" message sent to SMSC will contain the MSISDN-like address, so it will automatically trigger a retry to only a specific subscriber. To.

2. Address IP domain users using MSISDN-like addresses: In this case, the provisioning interface on IPG node 1 is used to create a join in the internal table between the MSISDN-like address and the SIP URL used for delivery in the IP domain. This addressing mode requires PLMN domain users to know the MSISDN-like address of IP domain users, but not the associated SIP URL.

3. IP domain users have MSISDN-like elements in their SIP URL addresses: In this case, IPG node 1 is configured to extract MSISDN-like elements from the SIP URL, or conversely to replay the original SIP URL from the address for MSISDN.

4. IP domain users have a "true" MSISDN element in their SIP URL address: To allow this type of addressing, the IPG automatically prefixes for true MSISDN, which ensures that it falls within the range of MSISDN-like addresses identified when the IPG is associated with SMSC. To do so. Users of the PLMN domain can identify the SIP URL in the text field of the message, or can use it to address the PLMN subscribers of the IP domain by giving them the special prefix. In either case, the address management entity automatically performs the required address translation function between PLMN and the IP domain.

5. A user in the PLMN domain has a "true" MSISDN element in the SIP URL address: This type of addressing allows IP users to send SMs for delivery to PLMN subscribers. The IPG automatically processes the SIP URL to extract the true MSISDN information, which is then used as the destination address to send the message to the PLMN domain.

Billing and billing management 10 This functional entity is responsible for managing the billing and billing elements on Node 1. Important functions performed by this entity include: · Generate CDR events related to sending and delivering messaging to IP domain subscribers. -About IPG Management of billing interface with external prepaid system that handles prepaid billing. If the prepaid authorization is backed by an external prepaid system, this entity may suspend any attempt to send or deliver a message until a response to the authorization is received. Attempts to deliver or send can be initiated or canceled based on the response received.

These functional entities can be replaced or modified to adapt the invention to the control or delivery of other messaging services such as one-to-many, broadcast or multimedia messaging. SME interface 7 can be replaced by a message broadcast entity for broadcast services or by an interface to MMSC for multimedia services. Similarly, protocol translation, subscriber presence management, and message delivery management entities are replaced or modified according to the protocol selected for use with a particular service. Message routing and address management entity 8 is extended to incorporate address management for group and geographic address types. For example, a broadcast message can be addressed to a geographic location identified by the "name" of the location. Address management entity 8 broadcasts this name SIP Translated to that of a list of URLs, which is further converted to a well-defined broadcast IP subnet address through a SIP proxy, which routes the broadcast message to a particular WLAN-based station containing a particular geographic location. To.

Description of SM services coming into the IP domain from PLMN users: The message flow for this service is shown in Figure 2, where the direct address of the user in the IP domain is being used by the PLMN user. IPG node 1, which acts as an SME, is "joined" to PLMN SMSC on behalf of a set of routing numbers assigned as direct addresses to users in the IP domain. Therefore, the direct address can be specified in a MSISDN-like format.

When the mobile station (MS) submits an SMS to SMSC, it is routed to IPG node 1 based on the destination address of the message conforming to the range specified for IPG node 1. IPG node 1 receives DELIVER_SM from SMSC and translates the destination address contained in DELIVER_SM into the SIP URL of the IP user using the address management entity. The SIP URL is converted to an IP address using a DNS query, or the message is routed through a SIP proxy / registrar. The IPG makes a SIP MESSAGE request from the SMPP DELIVER_SM message and delivers the SMS to the destination users included in the SIP MESSAGE.

The successful receipt of the SIP MESSAGE by the UAC will be displayed on the IPG upon receipt of the 200OK response. This 200OK is converted by IPG into the SMPP DELIVER_SM_ack response sent to SMSC.

Description of SM services coming into the PLMN domain from IP users: The message flow for this service is shown in Figure 3. When the SIP UAC requests that an SMS be sent to a PLMN subscriber, the PLMN subscriber's SIP URL domain name is changed to the IPG's IP address by DNS lookup, or the message is routed through a SIP proxy. SIP MESSAGE requests are sent to the IPG acting as the SIP UAS.

IPG node 1 receives the SIP MESSAGE and sends it to the IPG SMPP converter. The SIP MESSAGE request is translated into a SMPP Submit_SM message, and the PLMN user's MSISDN is extracted from the SIP URL by the address management entity. IPG acting as SME sends the Submit_SM to SMSC. SMS-GMSC queries PLMN HLR for available MSCs for subscribers, creates the FSM, and sends SMS to the MSCs available for delivery to the MS.

Additional instructions related to running IPG Node 1 are provided below.

Communication between IPG Node 1 and SMSC is based on the standard SMPP protocol specified by the SMS Forum. To enhance the ability to control messaging in the IP domain, some extensions to standard SMPP behavior can be utilized for communication, making relevant changes to IPG Node 1 and the SMPP protocol module of SMSC. In particular, the extended protocol definition allows IPG node 1 to modify a message in SMSC message storage and change the destination address on the message to a direct address assigned to a user in the IP domain.

IPG node 1 is placed in the network as a highly available and scalable node. It can be configured as a multi-node cluster where individual nodes are available in various MSISDN-like ranges assigned to users in the IP domain. The nodes can also operate as active / standby pairs or in N + M redundancy configurations to provide network operators with a highly available configuration. In the event of an active node failure, it is possible to switch to the cluster instead of the standby node or the node that guarantees available redundant nodes. It implements a robust data sharing mechanism to allow the newly activated node to access the join between the MSISDN-like address and the SIP URL address created earlier by the failed node.

In a minimal configuration, the IPG can be placed as a single node with the ability to dynamically switch to additional nodes to meet increasing capacity requirements. For a minimal high availability configuration, IPG node 1 is deployed as a dual node cluster running on active / standby nodes.

IPG node 1 also provides a billing interface suitable for both postpaid and prepaid operations. For postpaid operations, IPG Node 1 generates a CDR event record for each message submission, delivery attempt, and delivery report. For prepaid operations, the IPG implements a billing interface that can be adapted to communicate with the prepaid billing system. The billing interface and the IPG message delivery entity are designed to perform a pre-delivery credit check of a subscriber account before triggering a delivery attempt when this operation is supported by the prepaid billing system.

It can be seen that the present invention provides a mechanism that can reliably transfer the full functionality of messaging in the PLMN domain to users in the IP domain. Although this is described for SMS services in the above description, the present invention can be similarly applied to other messaging services such as instant messaging, multimedia messaging and message broadcasting services. The IPG can be reconfigured for delivery of various message types by running the appropriate interface module on the appropriate messaging server in the PLMN domain, for example an instant messaging server, multimedia server. In addition, node 1 can be adequately configured to operate successfully within the scope of network technology in both the PLMN domain and the packet data domain.

The present invention is not limited to the above-described embodiment, and various modifications can be made in its configuration and details.

<figref num="1">It is explanatory drawing which shows the interaction between a control entity between PLMN messaging domain and PLMN and IP, and a messaging enable IP domain.</figref><figref num="2">It is a figure which shows the flow of the signal transmission of the SMS which is transmitted by PLMN and is received by PDN.</figref><figref num="3">It is a figure which shows the signal transmission flow of the SMS which originated in PDN domain and received in PLMN domain.</figref>