Control of plmn messaging services in ip domains
Abstract
An access door comprising: an interface (2, 3) to a packet network; an interface (2,7) to a mobile network; a processor (4-8) to perform a protocol conversion for message communications between packet and mobile networks connected to the interfaces; characterized in that, the processor comprises a presence management function (6) to detect and maintain user presence information in the packet network, and to map a presence status of a user in the packet network in the manner used in the mobile network; The access door comprises a message routing function (8) and a message delivery management function (4) to control the supply of a message from the mobile network to the packet network if the presence management function ( 6) determines the presence of a destination user device in the packet network, and said functions comprise a means to: extend storage and the ability to redirect and deliver messages from the mobile network to the packet network: by checking the presence of the destination user's device in the packet network, and if it is present to transfer the message to the packet network, and if the message transfer is not present or fails, set an indicator; and if the destination user's device is subsequently present in the packet network to detect that the indicator has been set and to notify the originating mobile network entity that activates said entity to attempt to deliver the message again.
Term
Term ended
Projected expiry passed 13 May 2023, 3.4 years ago.
- Priority
- Filed
- Published
- Projected expiry
- Today
24 claims: 11 independent, 13 dependent
- 1REIVINDICACIONES 1. Una puerta de acceso que comprende:una interfaz (2, 3) a una red de paquetes;una interfaz (2,7) a una red móvil;un procesador (4-8) para realizar una conversión de protocolo para las comunicaciones de mensajes entre las redes de paquetes y móvil conectadas a los interfaces;caracterizada porque, el procesador comprende una función de gestión de presencia (6) para detectar y mantener la información de presencia de usuarios en la red de paquetes, y para mapear un estado de presencia de un usuario en la red de paquetes en la forma utilizada en la red móvil;la puerta de acceso comprende una función de encaminamiento de mensajes (8) y una función de gestión de suministro de mensajes (4) para controlar el suministro de un mensaje desde la red móvil a la red de paquetes si la función de gestión de presencia (6) determina la presencia de un dispositivo de usuario del destino en la red de paquetes, y dichas funciones comprenden un medio para: extender el almacenamiento y la capacidad de redirigir y suministrar mensajes de la red móvil a la red de paquetes: comprobando la presencia del dispositivo del usuario de destino en la red de paquetes, y si está presente transferir el mensaje a la red de paquetes, y si no está presente o falla la transferencia del mensaje establecer un indicador;y si el dispositivo del usuario de destino está posteriormente presente en la red de paquetes detectar que el indicador se ha establecido y notificar a la entidad de red móvil originadora que active dicha entidad para intentar el suministro del mensaje de nuevo.
- 2Una puerta de acceso de acuerdo con la reivindicación 1 en la que la función de gestión de presencia (6) está adaptada para operar como un registrador del Protocolo de Iniciación de Sesión (SIP).
- 3Una puerta de acceso de acuerdo con la reivindicación 1 ó 2, en la que la función de gestión de presencia (6) comprende una interfaz para acceder a un registrador externo del Protocolo de Iniciación de Sesión (SIP) en una red del Protocolo de Internet (IP).
- 4Una puerta de acceso de acuerdo con la reivindicación 3, en la que dicha interfaz se adapta para mantener una caché de las entradas SIP.
- 5Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la función de gestión de presencia (6) está adaptada para almacenar las capacidades del dispositivo de usuario, y el procesador comprende una función de conversión de protocolo (5) para seleccionar un protocolo de suministro de mensajes basado en las capacidades del dispositivo.
- 6Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la función de encaminamiento de mensajes (8) está adaptada para convertir una dirección del formato de red móvil a una dirección de formato de la red de paquetes.
- 7Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la función de encaminamiento de mensajes comprende un medio para encaminar un único mensaje desde una red a múltiples direcciones en otra red.
- 8Una puerta de acceso de acuerdo con la reivindicación 7, en la que la función de encaminamiento de mensajes está adaptada para hacer interfaz con los servicios de difusión de la red de paquetes.
- 9Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la puerta de acceso comprende una interfaz (7) para emular una entidad de red móvil tal como una SME o un SMSC.
- 10Una puerta de acceso de acuerdo con la reivindicación 9, en la que la capacidad de emulación de la interfaz permite la operación de la puerta de acceso sin reconfiguración de una red móvil convencional.
- 11Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que el procesador comprende un medio para notificar a un Centro del Servicio de Mensajes Cortos (SMSC) que origina la entidad de red móvil que un usuario en la red de paquetes se ha vuelto activo.
- 12Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones 9 a 11, en la que la interfaz comprende un medio para extraer un Identificador de Recursos Uniforme (URI) a partir de un mensaje, un medio para proporcionar una confirmación diferida, y un medio para notificar a una entidad de red móvil que un usuario en la red de paquetes se ha vuelto activo.
- 13Una puerta de acceso de acuerdo la reivindicación 12, en la que dicha entidad de red móvil es un Centro del Servicio de Mensajes Cortos (SMSC).
- 14Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la función de gestión de presencia (6) comprende un medio para notificar a una entidad en la red si un abonado entra en el dominio de otra red.
- 15Una puerta de acceso de acuerdo la reivindicación 14, en la que la función de gestión de presencia comprende un medio para notificar a la entidad si el abonado es el receptor pretendido de un mensaje que espera el suministro.
- 16Una puerta de acceso de acuerdo con la reivindicación 14 ó 15, en la que la señal de notificación especifica de un modo dinámico los criterios de búsqueda para la entidad de red que varían desde un criterio de coincidencia directa a un criterio de coincidencia parcial.
- 17Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que la puerta de acceso comprende un medio para notificar un mensaje en una entidad de red tal como un SMSC para cambiar su dirección de destino.
- 18Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones anteriores, en la que el procesador comprende un medio para almacenar la dirección de una entidad de la red móvil originadora del mensaje y para almacenar múltiples direcciones de la entidad de red móvil frente a un único usuario de destino, representando cada una, una entidad de red móvil fuente donde están almacenados los mensajes esperando el suministro al usuario del destino, y para notificar a cada una de dichas entidades de red cuándo el usuario del destino está presente posteriormente en la red de paquetes.
- 19Una puerta de acceso de acuerdo con cualquiera de las reivindicaciones 14 a 18, en la que la entidad de red es un Centro del Servicio de Mensajes Cortos (SMSC).
- 20Un método para comunicar entre una red móvil y una red de paquetes, comprendiendo el método las etapas de:un dispositivo móvil en la red móvil que transmite un mensaje con una dirección de la red móvil de una puerta de acceso de acuerdo con cualquiera de las reivindicaciones 1 a 19 y una dirección del usuario de la red de paquetes de destino incorporada;una entidad de la red móvil que encamina el mensaje a la interfaz (7) de la puerta de acceso (1), recibiendo el mensaje la puerta de acceso (1) en la interfaz (7), extrayendo la dirección del usuario de la red de paquetes de destino, y encaminando el mensaje al usuario de la red de paquetes con la dirección de la red de paquetes.
- 21Un método de acuerdo con la reivindicación 20, en el que la dirección del usuario de la red de paquetes está en un formato del Protocolo de Iniciación de Sesión.
- 22Un método de acuerdo con las reivindicaciones 20 ó 21, en el que la puerta de acceso mantiene una tabla que asocia la dirección del usuario de la red de paquetes con una dirección normalizada de la red móvil para el usuario de la red de paquetes, y para un mensaje posterior el usuario de la red móvil incluye sólo una dirección normalizada de la red móvil y la puerta de acceso recupera la dirección de la red de paquetes de la tabla.
- 23Un método de acuerdo con cualquiera de las reivindicaciones 20 a 22, en el que la puerta de acceso se une al menos a una entidad de la red móvil para la comunicación de mensajes.
- 24Un método de acuerdo con la reivindicación 23 en el que la entidad de red móvil es un SMSC.
Independent claims24
113 paragraphs, as filed
Field of the Invention
The invention relates to messaging. Description of the Prior Art
The messaging services in the PLMN domains have reached significant levels of use among mobile subscribers. The Short Message Service (SMS) originated in the GSM networks and its diffusion to many different network technologies, are now in the ANSI-41 TDMA and CDMA networks and has also been deployed in the Japanese PDC networks. This growth has been driven by the demand of the messaging service subscribers, which provide a means of communication between individuals and groups that was not previously available. With the advent of 2.5G and 3G network technologies, there is now a significant interest in extending the range of messaging services beyond the limits of mobile networks by providing interoperability with data packet network (PDN) domains ). The Internet domain has seen massive growth in recent years with the number of connectable users through Internet addresses increasing significantly each year. In addition, the mobility of Internet users is increasingly supported by mobile IP protocols, allowing an individual user to be connectable to the same Internet address regardless of the geographic location where they connect to the Internet.
WO00 / 74409 describes an integrated IPSS7 access door and the local location register.
WO01 / 56308 describes a system and method for sharing user event information such as presence over the network.
This invention is aimed at providing a control and transport entity that enables the implementation of an integrated messaging service, providing the means for the origin, transport and supply of messages between the PLMN and PDN domains (fixed and mobile). SUMMARY OF THE INVENTION
According to the invention an access door is provided as
is shown in claim 1.
In another embodiment, the presence management function operates as a logger of the Session Initiation Protocol (SIP).
In a further embodiment, the presence management function comprises an interface for accessing an external SIP recorder in an IP network.
In one embodiment, said interface maintains a cache of SIP entries.
In another embodiment, the presence management function stores the capabilities of the user device and the processor comprises a protocol conversion function to select a message delivery protocol based on the capabilities of the device.
In one embodiment, the message routing function converts a mobile network form address to a packet network form address.
In another embodiment, the message routing function comprises a means to route a single message from a network to multiple addresses in another network.
In a further embodiment, the message routing function interfaces with the broadcast services of the packet network.
In one embodiment, the access door comprises an interface to emulate a mobile network entity such as the SME or the SMSC.
In another embodiment the emulation capability of the interface allows the operation of the access door without the reconfiguration of a conventional mobile network.
In one embodiment, the processor comprises a means to notify the originating mobile entity of the Short Message Service Center (SMSC) that a user in the packet network has become active.
In a further embodiment, the interface comprises a means to extract a URI from a message, a means to provide deferred confirmation and a means to notify a mobile network entity that a user in the data packet network has become active.
In one embodiment, said entity is an SMSC.
In another embodiment, the presence management function comprises a means to notify an entity in a network if a subscriber enters the
domain of another network.
In a further embodiment, the presence management function comprises a means to notify the entity if the subscriber is the intended recipient of a message awaiting delivery.
In one embodiment, the notification signal dynamically specifies the search criteria for the network entity ranging from a direct match criteria to a partial match criteria.
In another embodiment, the gateway comprises means for modifying a message in a network entity such as an SMSC to change its destination address.
In one embodiment, the processor comprises means for storing the address of the mobile network entity originating the message and for storing the multiple addresses of the mobile network entity in front of a single destination user, each representing a mobile network entity source where messages are stored waiting for delivery to the target user, and to notify each of said network entities when the destination user is subsequently present in the packet network.
In one embodiment the entity is an SMSC
In another aspect, the invention provides a method for communicating between a mobile network and a packet network, the method comprising the steps of:
a mobile device in the mobile network that transmits a message with an address of the mobile network of an access door as defined above and a user address of the network of embedded destination packets;
an entity of the mobile network that routes the message to a gateway interface; and
the gateway that receives the message on the interface, which extracts the user's address from the destination packet network, and that routes the message to the user of the packet network with the address of the packet network.
In one embodiment, the address of the packet network is in a Session Initiation Protocol format.
In another embodiment, the access door maintains an association table of the address of the user of the packet network with a standardized address of the mobile network for the user of the packet network, and for a subsequent message the user of the network mobile includes only a standardized address of the mobile network and the gateway retrieves the address of the packet network from the table.
In a further embodiment, the access door joins at least one entity of the mobile network for message communication.
In one embodiment, the entity is an SMSC. DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings
The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:
Fig. 1 is a schematic diagram illustrating the interaction between a messaging domain of the PLMN, a control entity between the PLMN and the IP domains and an IP domain enabled for messaging;
Fig. 2 is a diagram illustrating a signaling flow for the origin of the SMS in the PLMN and the termination in the PDN; and
Fig. 3 is a diagram illustrating a signaling flow for an SMS that originates in the PDN domain and ends in the PLMN domain. Description of the Accomplishments
The invention provides a node 1 of the IP Gateway to the PLMN (IPG) to control the provision of common messaging services based on the PLMN (eg, SMS, Cell Broadcast) to users in IP domains ( for example, users with fixed internet addresses or currently active users on a Wireless LAN). The users of the IP domain can be fixed or mobile. Mobile subscribers will generally be able to 'roam' between the PLMN and IP domains. There are two forms of roaming: (1) roaming of subscribers of the local PLMN (HPLMN), where the mobile subscriber of the PLMN roams within the IP domain owned by the PLMN operator, and (2) roaming of subscribers of the PLMN Visited (VPLMN), where a mobile 'roaming' subscriber in another PLMN (using existing roaming agreements between PLMN) wanders within the IP Domain of the visited PLMN.
Therefore, extending the reach of messaging services from PLMN to IP domains creates a wider community of messaging users and removes the mobile phone as the only source and termination device for mobile messaging. For example, a mobile subscriber may wish to send a message to another user that may be connectable through a mobile phone but may be present in a data packet domain, such as a Wireless LAN or the fixed Internet. Similarly, an Internet user may wish to originate a message to be provided to a mobile subscriber on his phone.
PDN messaging communities can take several different forms. A community in a PDN Domain could be the set of users in an airport connected to an access point of the Wireless LAN (for example, 802.11, Hyper-LAN), while another community could be of 'fixed' subscribers of a interactive TV domain. Such PDN domains could be part of a single larger PDN domain from the PLMN perspective or they could also be considered as separate PDN domains.
The invention is described in the context of a GSM PLMN and an IP-based PDN. However, the invention is equally applicable to alternative mobile network technologies such as CDMA, TDMA, PDC and UMTS, as well as PDN technologies beyond IP-based networks.
The node of the IP Gateway to the PLMN (IPG) enables the extension of the messaging domain of the PLMN within IP domains such as the fixed Internet and Wireless LAN networks. The IPG node 1 comprises an IP transport interface 2 connected to a user agent (UA) 3 of the Session Initiation Protocol (SIP), in turn connected to a message delivery function 4. Function 4 is connected to both the protocol transfer function 5 and the presence management function
6. An SME interface 7 is connected on one side to interface 2 and on the other hand to the presence management function 6 and a message routing address management function 8. The nodes also comprise a billing function 10.
The IPG implements a set of control and transport functions that allow messaging services and common formats in the PLMN domain to be adequately adapted for the origin and supply in the IP domain. An advantageous element of the invention is that all the functions of enhanced services in the PLMN (for example, the functions of storing and redirecting, of waiting and alert message) are performed in the messaging service available in the IP domain. The IPG ensures that no modification is necessary in the messaging service equipment existing in the PLMN for a fully functional messaging service in the IP domain. However, the invention also provides extensions to the standardized interfaces between the IPG node and the messaging platforms to allow optimized provision of messaging services in the IP domain. A further aspect of the invention is that it can be applied to all PLMN technologies that support messaging services (for example, Short Message Service, Cell Broadcasting, Multimedia Messaging, Instant Messaging) and any domain of IP (for example, fixed or mobile internet). An implementation of the invention in the context of a GSM PLMN and the fixed network IP domain is described below, and illustrated for the Short Message Service.
In a GSM network, the Short Message Service is provided by a network element of the Short Message Service Center (SMSC). The SMSC communicates with other elements in the PLMN (such as HLR, VLR, MSC) through an MSC Inter-Functioning Gateway (I-GMSC). In addition, the SMSC provides an application interface that allows service developers to join an application to the SMSC. An example of such an interface protocol is the Short Message Peer Protocol (SMPP) specified by the SMS Forum. Within the PLMN domain, the SMSC can receive a short message (SM) from an external application through the SMPP addressed to a particular mobile subscriber MSISDN. The SMSC stores the SM in an internal warehouse and then requests routing information from the HLR for the mobile subscriber. If the routing information is received, it indicates the MSC / VLR in current service for the mobile subscriber. The SMSC presents the SM to the MSC / VLR in service to supply the mobile subscriber. If the supply is satisfactory, the SMSC marks the SM as supplied in the message store. If the delivery is unsatisfactory (perhaps because the mobile subscriber is not reachable on the network in service), the SMSC will attempt the delivery some time later (a message indicator can be established waiting on the HLR so that the SMSC is notified if the subscriber becomes active in a network, or you can program the message for an attempted retry delivery according to an internal retry algorithm).
The IPG 1 node incorporates all the required functional elements that allow the total range of messaging capabilities from the PLMN to be offered in the IP domain. In the embodiment of the invention illustrated in Figure 1, the main functional entities in the IPG 1 node are:
(a) interface 7 of the Short Message Entity (SME) 7 for the SMSC in the PLMN,
<dl><dt>(b)</dt><dd> subscriber presence management 6, </dd></dl>
<dl><dt>(c)</dt><dd> protocol conversion 5, </dd></dl>
<dl><dt>(d)</dt><dd> message delivery management 4, </dd></dl>
<dl><dt>(and)</dt><dd> message routing and address management 8, </dd></dl>
<dl><dt>(F)</dt><dd> billing and charge management 10, </dd></dl>
and these functional entities are adapted according to the requirements of each of the particular embodiments of the invention. For example, in the current embodiment of the invention, the SME 7 interface for the SMSC is based on the SMPP protocol. Subscriber presence management, protocol conversion and message delivery management are based on the Session Initiation Protocol (SIP).
Referring to Fig. 1, a description from beginning to end of a short message service between the PLMN and the IP domains is provided below. PLMN Origin / IP Termination:
A mobile subscriber MS uses the GSM PLMN to originate an SMS to another user known to the mobile subscriber. The mobile subscriber is aware that the receiver does not use a mobile phone but can receive SMS about their fixed Internet service through the SIP URL when connected to the network. The mobile subscriber specifies an MSISDN destination corresponding to the SME interface of IPG 7 and specifies the URL of the user's SIP as a text field in the message. When the mobile subscriber sends the message, it is received by the SMSC in the PLMN, which routes the message to the SME 7 interface of the IPG 1 node. The SME 7 interface extracts the URL from the destination SIP from the message text and presents this information to the subscriber's presence management function 6. The SMPP format of the message is presented to the message routing entity 8 and the protocol conversion entity 5, where the message is converted to a format suitable for delivery over the SIP. The presence management function 6 uses the SIP Proxy entities and the SIP Registrar to determine the current status of the target user. If it is determined that the user is connected to the IP domain, the properly formatted SM is transmitted to the supply management function of message 4 for delivery. The message delivery is trying to use the SIP 3 User Agent, which communicates with a SIP User Agent par 20 on the destination user's device. If the message is successfully supplied to the destination user, this status is returned through the SME 7 interface to the SMSC. If the message is not supplied, the message delivery management function 4 can set a message waiting indicator for the destination user. If the user connects to the IP domain, this presence is detected through the presence management function 6 and a notification signal is sent to the SMSC in the PLMN, indicating that it tries to supply the SM through the SME interface 7 one more time. In this way the total functionality of the SMS service in the PLMN is performed over the IP domain. The billing and charge management function 10 is invoked to provide the billing function for the IPG 1 node. To support a prepaid billing model, a credit check can be invoked before delivery to check the user's credit balance before the attempt to deliver the message begins. If the credit check returns a positive indication, the delivery of the message is attempted and the appropriate charge is deducted from the user's account for a satisfactory supply. For the post-paid billing model, a CDR (call detail record) event occurs for both successful and unsuccessful delivery attempts. The CDR event contains all the relevant information such as the source address, the destination address and the delivery status that can be used to produce the subscriber's billing information. IP Origin / PLMN Termination:
A user in the IP 9 domain initiates an SM to a mobile subscriber in the PLMN domain, directed through a SIP URL containing the mobile subscriber's MSISDN. The message was presented through the SIP User Agent 20 on the user's device, which routes the message based on the standard mechanism of the SIP URL to the SIP 3 user agent on the IPG 1 node. In the IPG 1 node the SIP 3 user agent processes the URL to deduce the MSISDN from the mobile subscriber. The SM is passed to protocol converter 5 where it is converted to an SMPP format, with the mobile subscriber's MSISDN as the destination address. The reformatted message is redirected to the SME 7 interface, which presents it over the SMPP to the SMSC in the PLMN. At this point, a confirmation of the message presentation to the user in the IP domain can be returned through the SIP user agent 3. The additional processing of the SM supply is handled entirely within the PLMN domain using the functionality of Normalized SMS For the provision of the message in this direction, the functional entities of the presence management of the subscriber and the supply management of the message 6 and 4 are not used.
The billing and charge management function 10 is capable of supporting a range of billing models for the service, including charging or not charging for the supply of termination messages, the charge or non-charge for the origin of a message, and prepaid or post-paid models. For a prepaid billing model, the function of providing the household goods or origin of the message is suspended while the billing and charging function asks a question of the credit against the subscriber. If the credit check is positive, the supply or origin function is resumed. If the credit check is negative, the supply or origin function is canceled and instead a credit recharge option may be presented to the subscriber. In all cases, the billing and charging function 10 records the CDR events for submission and supply attempts. These CDR events can be processed to generate the subscriber's billing information for the post-paid subscriber, or they can simply be used for auditing and reconciliation purposes in a prepaid billing model. Other Address formats for the IP Domain:
Other addressing formats can be used to specify a user's address in the IP domain and are implemented by the IPG node 1. Below are some examples of alternative addressing formats supported by the IPG.
<dl><dt>• </dt><dd>Address like the MSISDN - a non-PLMN user receives an address like the MSISDN. </dd></dl>
<dl><dt>•</dt><dd> Element like the MSISDN in the SIP URL - a non-PLMN user receives an address like the MSISDN and this is incorporated into the SIP URL. </dd></dl>
<dl><dt>• </dt><dd>'Real' MSISDN in the SIP URL - a PLMN user may choose to receive messages in an IP domain and their PLMN MSISDN may be incorporated into the SIP URL for this purpose. </dd></dl>
<dl><dt>•</dt><dd> Group addresses comprising elements such as the MSISDN or group 'names' - this addressing format is used for point-to-multipoint services. </dd></dl>
<dl><dt>•</dt><dd> Geographic or area addresses comprising elements such as the MSISDN or the 'name' of the location - this addressing format is used for broadcast services. </dd></dl>
<dl><dt>• </dt><dd>SIP URLs representing a PLMN user - this form of addressing is used as the destination address of a PLMN user when an SM is originating from an IP user. The actual MSISDN of the PLMN user is normally incorporated into the SIP URL.</dd></dl>
These addressing formats can be processed by the IPG 1 node to support direct addressing of users in the IP domain from the PLMN domain, such as allowing a PLMN user to invoke the 'Response' function when a response has been received. message from a user in the IP domain.
A more detailed description of the functions implemented in each of the functional entities is provided below. SME 7 interface
This functional entity is responsible for ensuring communication between the IPG 1 node and the SMSC in the PLMN. In the current embodiment of the invention, communication between the SMSC and the IPG is ensured using the SMPP protocol. In addition to the protocol management, the SME 7 interface also incorporates specific functions that allow the IPG 1 node to appear for the SMSC as if it were a standardized SME of the PLMN. These include:
• Extracting the SIP URL from the message text
<dl><dt>•</dt><dd> Deferred confirmation for a message submitted for delivery from the SMSC. </dd></dl>
<dl><dt>•</dt><dd> Ability to generate a notification signal to alert the SMSC that a user in the IP domain has become active (i.e. </dd></dl>
detected its presence). Subscriber Presence Management Function
This functional entity is responsible for the detection and maintenance of the presence status of users in the IP domain. In this embodiment, these capabilities are based on the mechanisms defined within the SIP protocol, that is, it functions as a SIP registrar and is capable of processing the SIP REGISTER messages sent by the SIP user agent 20 in the IP domain. In this case, the IPG 1 node stores the SIP URI and the IP address of the 'registered' user.
A SIP registrar may already be present in the domain of the IP network. In this case the presence management entity 6 requests the Registrar of the SIP to determine the presence information for the user of the IP domain each time it is required for an attempt to provide a message. To reduce control of communications with the external SIP Registrar, function 6 incorporates a SIP cache record that stores presence information for a configurable period, thereby avoiding repetitive questions to the SIP registrar. In the case of a message delivery failure due to the absence of the IP domain user, the entry to the SIP Cache Registrar for the user is automatically deleted. Protocol Conversion
This entity provides the conversion between the signaling protocols used in the PLMN and the protocol used in the IP domain. In the present embodiment of the invention, the SIP protocol is used for the provision of messaging services in the IP domain. Communication with the PLMN domain is done using SMPP and the protocol conversion entity performs the conversion to / from the SMPP and SIP protocols.
In general, the IP domain protocol used to terminate the message will be determined by the capabilities of the user device addressed in the message parameter 'destination address'. The IPG 1 node will select the message delivery protocol based on the capabilities of the user device. The device capabilities of the user agent will be transmitted to the IPG during user registration in the IP Domain. These user agent profiles will be stored by the presence function of the IPG.
Message Supply Management 4
This functional entity is responsible for ensuring that the storage supply and message redirection model of the PLMN domain extends to the IP domain. When a PLMN domain message is received for delivery to the IP domain, the IPG attempts the delivery using the protocol of the selected IP domain. The message delivery using the SIP protocol is described below for the current embodiment of the invention.
When a message is received from the PLMN through the SME interface 7 the message delivery management entity 4 receives the message after it has been converted to a SIP format by the protocol conversion entity 5 and the message has been extracted destination address (the SIP URL) in the IP domain. The supply entity can first verify the presence of the user in the IP domain by submitting a request to the SIP Registrar function. If the user is present, the user's current contact address can be returned by the SIP Registrar. Alternatively, the supply entity may attempt to resolve the SIP URL by other means such as through a DNS or through an internal request using a proprietary protocol. The supply entity 4 generates a SIP MESSAGE request properly formatted for the delivery of the message to the user. Depending on the supply protocol in use, the SIP MESSAGE can carry the message within its payload, or alternatively the INVITE SIP request can be used to establish a session with the user in which the message will be transferred using an appropriate session protocol. Assuming direct delivery using the SIP MESSAGE request, if a contact address has already been resolved, the SIP message can be sent directly through the SIP User Agent within the IPG. Alternatively, the SIP MESSAGE can be presented through a SIP Proxy, which takes responsibility for resolving the current contact address for the user. If the message is supplied successfully to the user, a positive confirmation is received by the supply entity in the form of an OK 200 response. This status information is then returned to the SMSC in the PLMN via the SME 7 interface. , where the message can be marked as supplied.
If the message transfer fails (due to resource restrictions, network problems or because the user's agent is not registered), then the provisioning entity 4 sets a Data Waiting Message (MWD) indicator for the UAC within the IPG, storing the originating SMSC address. Multiple SMSC addresses can be stored in front of a single UAC, each representing a source SMSC where messages awaiting delivery to the UAC are stored. At a later time, when the user registers in the IP domain, the IPG 1 node detects that the MWD indicator has been set for the user. The supply entity generates a 'Notify' message to be sent to all SMSC addresses stored within the user's MWD indicator. The notify message is used by the SMSC to activate a new delivery attempt for any messages waiting for the delivery to the user in the IP domain. Retry messages are received by the IPG 1 node, which then proceeds with the supply to the UAC now registered as described above.
This invention specifies an improved implementation of the 'notify' message that allows the SMSC and the IPG node 1 to cooperate to optimize delivery attempts for users in the IP domain even if a direct address for the user has not been assigned. Also, the presence management function 6 can determine if a subscriber with waiting messages is present in the IP domain, and notifies the SMSC. An improved notification message contains the SIP URL of the destination user. When received by the SMSC, the enhanced notification mechanism implemented in the SMSC tracks messages waiting for the IPG 1 node and extracts only those messages that match the URL of the notified SIP. The criterion for a 'match' for the URL of the notified SIP can be modified in a dynamic way, for example an exact match, or a partial match over the domain, may be required, or some part of the domain may be sufficient. In an alternate embodiment of the invention, the notification message itself may contain an element that specifies the matching criteria required based on each notification. Message Routing and Address Management 8
This functional entity ensures that messages are properly routed between the PLMN and IP domains. It also provides an ability to assign a PLMN-compatible address for an IP domain address (for example, the SIP URL), thus allowing a user in the PLMN domain to address a user of the IP domain directly using an address like the MSISDN. With that capability, the invention allows messaging between users in the PLMN and IP domains to be directed, for example a user in the PLMN domain can use the 'Reply' function to reply to a message received from a user in the domain of IP. The operation of the main addressing formats supported by the IPG 1 node is described below.
1. The user in the IP Domain is addressed using the SIP URL:
When a PLMN user sends a message to a user in the IP domain, it is required to enter the SIP URL in a special text field in the message body while entering a MSISDN well known as the destination address, which ensures that the message is routed to the IPG 1 node. When the message is received by the IPG 1 node, the SIP URL is extracted from the message and redirected to the address management entity 8. The SIP URL is checked to see if an address has been assigned as the MSISDN of the MSISDN number range specified by the IPG 1 node when it joined the SMSC. If no number such as the MSISDN has been located, the address management entity 8 selects a free MSISDN from the IPG range and creates an association with the SIP URL that is stored in the IPG. Once assigned, this number as the MSISDN can be used as a direct address for the IP user with respect to the PLMN domain. If the attempt to supply the message to the SIP URL is satisfactory, a supply receipt can be generated using the number as the MSISDN as the source address. When received by the PLMN subscriber, this address can be as a direct destination address for the IP user, eliminating the need to specify a SIP URL in the message text in future messages. When the IPG receives a message for an IP user using the direct address such as the MSISDN, the address management entity 8 automatically retrieves the SIP URL from the IPG tables to complete the supply in the IP domain.
In the event of a failure to deliver the message, the IPG 1 node replaces the original destination address (IPG) with the destination address as the newly assigned MSISDN in the copy of the message stored in the SMSC. Future retries of the message then use the address as the MSISDN as the destination address. If the MWD indicator is set for the IP user, the 'notify' message sent to the SMSC contains the address such as the MSISDN, thereby activating retries automatically for the specified user only.
two. The user in the IP Domain is addressed using an address such as the MSISDN
In this case, a provisioning interface is used on the IPG 1 node to create an association in the internal table between the address such as the MSISDN and the SIP URL used for provisioning in the IP domain. With this addressing mode, the user in the PLMN domain must be informed of the address as the user's MSISDN in the IP domain, but it is not necessary to know the URL of the associated SIP.
3. The user in the IP Domain has an element similar to the MSISDN in the SIP URL:
In this case, the IPG 1 node is configured to extract the MSISDN-like element from the SIP URL and, conversely, recreate the original SIP URL from the address such as the MSISDN.
Four. The user in the IP Domain has a 'real' MSISDN element in the SIP URL:
To enable this type of addressing, the IPG automatically creates a prefix for the actual MSISDN to ensure that it falls within the address range as the specified MSISDN when the IPG joins the SMSC. A user in the PLMN domain can specify the SIP URL in a message text field or can be informed of the special prefix to use when the PLMN subscriber is addressed in the IP domain. In any case, the address management entity automatically performs the address conversion function as required between the PLMN and IP domains.
5. The user in the PLMN Domain has a 'real' MSISDN element in the SIP URL:
This type of addressing is used to allow an IP user to originate an SM to supply a PLMN subscriber. The IPG automatically processes the SIP URL to extract the actual MSISDN information and is then used as the destination address to redirect the message within the PLMN domain. Billing and Cargo Management 10
This functional entity is responsible for managing the billing and debit elements in node 1. Important functions performed by this entity include:
<dl><dt>•</dt><dd> Generation of CDR events related to the origin and supply of messages for subscribers in the IP domain. </dd></dl>
<dl><dt>•</dt><dd> Management of a charge interface for an external prepaid system that handles prepaid billing for the IPG. </dd></dl>
<dl><dt>• </dt><dd>When a prepaid credit question is supported by the external prepaid system, this entity is able to suspend an attempt to originate or provide a message until an answer to the credit question has been received. Based on the response received, it is able to resume or cancel the attempted origin or supply.</dd></dl>
These functional entities can be replaced or modified to adapt the invention for the control or provision of other messaging services such as point-to-multipoint, broadcast or multimedia messaging. The SME 7 interface would be replaced by a message broadcasting entity for a broadcasting service, or by an interface for an MMSC for a multimedia service. Similarly, protocol conversion, subscriber presence management, and message delivery management entities would be replaced or modified according to the protocols selected for use for a particular service. Message routing and address management entity 8 would be extended to incorporate address management for groups and geographic address type. For example, a broadcast message may be directed to a geographic location identified by a location 'name'. The address management entity 8 would convert this name to a list of Broadcast SIP URLs that would later be resolved through a SIP proxy within the well-defined broadcast IP subnet addresses, which would route the broadcast message to specific WLAN base stations that cover the specified geographic location. Illustration of the termination of the SM Service in an IP Domain from a PLMN user:
The message flow for this service is illustrated in Figure 2 where a direct address has been used for the user in the IP domain by the PLMN user. The IPG 1 node that functions as an SME is 'joined' to the SMSC of the PLMN on behalf of a block of routing numbers that are assigned as direct addresses for users in the IP domain. Therefore direct addresses can be specified in a format such as MSISDN.
When the Mobile Station (MS) transmits the SMS to the SMSC, it is routed to the IPG 1 node based on the destination address in the message matching the interval specified for the IPG 1 node. The IPG 1 node receives the SUPPLY_SM from the SMSC and the address contained in the SUPPLY_SM becomes the URL of the SIP for the IP user using the address management entity. The SIP URL is resolved for an IP Address either using a question to the DNS or the message can be routed through the SIP Registrar / Proxy. The IPG creates a SIP MESSAGE request from the SMPP SUPPLY_SM message and supplies the SMS to the destination user encapsulated in the SIP MESSAGE.
The successful receipt of the SIP MESSAGE request by the UAC is indicated to the IPG with the receipt of the OK 200 response. The IPG transfers this OK 200 to a SMPP_SUMINISRO_SM Confirmation response sent to the SMSC. Illustration of the termination of the SM Service in the PLMN domain from an IP user:
The message flow for this service is illustrated in Figure 3. When a SIP UAC requests to send an SMS to the PLMN subscriber, the domain name of the PLMN subscriber's SIP URL is resolved for the IP address of the PLMN subscriber. IPG either by a DNS search or the message is routed through a SIP Proxy. The SIP MESSAGE request is redirected to the IPG functioning as a SIP UAS.
The IPG 1 node receives the SIP MESSAGE and passes it to the IPG SMPP converter. The request of the SIP MESSAGE becomes an SMPP Submit_ SM message, and the MSISDN of the PLMN user is extracted from the SIP URL by the address management entity. The IPG acting as an SME redirects the Submit_SM to the SMSC. The SMSGMSC requests to the PLMN HLR for the MSC in service of the user, creates the FSM and then redirects the SMS to the MSC in service to supply the MS.
Some additional details relevant to the implementation of the IPG 1 node are described below.
Communication between the IPG 1 node and the SMSC is based on the standardized SMPP protocol specified by the SMS Forum. To provide enhanced capabilities for messaging control in an IP domain, the communication may use some extensions to standardized SMPP operations, with associated modifications for the SMPP protocol modules over the IPG 1 node and the SMSC. In particular, the extended protocol definition allows the IPG node 1 to modify a message in the SMSC message store to change the destination address on the message to a direct address assigned to the user in the IP domain.
The IPG 1 node is deployed in the network as a highly available and scalable node. It can be configured as a multi-node group, in which individual nodes can serve different address ranges such as the MSISDN assigned to users in the IP domain. The nodes can also operate as active / standby pairs in a redundant N + M configuration to provide high availability configurations for network operators. If an active node fails, a waiting node or an available redundant node can be switched within the group instead of the failed node. A robust data sharing mechanism is implemented to allow the newly activated new node to access associations between the SIP URL and addresses such as the MSISDN that were previously created by the failed node.
In a minimal configuration, the IPG can be deployed as a single node with the ability to dynamically switch on additional nodes to meet increasing capacity demands. For a minimum high availability configuration, the IPG 1 node is deployed as a dual node group that operates in active / standby mode.
The IPG 1 node also provides a billing interface that is suitable for both post-paid and prepaid operation. For post-paid operation, the IPG 1 node produces CDR event logs for each message presentation, delivery attempt and supply reports. For prepaid operation, IPG implements a charging interface that can be adapted to communicate with a prepaid billing system. The charging interface and the message delivery entity in the IPG are designed to perform a credit check before supply on a subscriber's account before invoking a delivery attempt if this operation is supported by the prepaid billing system.
5 It will be appreciated that the invention provides a mechanism that ensures that full messaging capabilities in the PLMN domain can be provided to users in the IP domain. Although this has been illustrated for the SMS service in the above description, the invention can also be applied similarly to other messaging services such as the
10 Instant messaging, multimedia messaging, and message broadcast services. The IPG can be reconfigured to deliver different types of messages by implementing an appropriate interface module for the appropriate messaging server in the PLMN domain, for example the Instant Messaging server, the Multi-media server, etc. In addition, node 1 can
fifteen properly configured to operate successfully with a range of network technologies both in the PLMN domain and in the data packet domain. The invention is not limited to the described embodiments but can be varied within the scope of the appended claims.
20
17 members in 10 offices
Priority claims1
| Document | Office | Kind | Date |
|---|---|---|---|
| 37940402 | United States of America | P |
Members17
| Document | Office | Kind | |
|---|---|---|---|
| CA2485661A1 | Canada | A1 | |
| WO03103308A1 | World Intellectual Property Organization (WIPO) | A1 | |
| AU2003273550A1 | Australia | A1 | |
| EP1504620A1 | European Patent Office (EPO) | A1 | |
| US2005117602A1 | United States of America | A1 | |
| JP2005526470A | Japan | A | |
| CN1666545A | China | A | |
| CN100346622C | China | C | |
| AU2003273550B2 | Australia | B2 | |
| JP4399599B2 | Japan | B2 | |
| US7701969B2 | United States of America | B2 | |
| EP1504620B1 | European Patent Office (EPO) | B1 | |
| AT479298T | Austria | T | |
| ATE479298T1 | Austria | T1 | |
| DE60333915D1 | Germany | D1 | |
| ES2348867T3This record | Spain | T3 | |
| CA2485661C | Canada | C |
Numbers
- Publication
- 2348867
- Application
- 3756091
Titles2
- Spanish
- CONTROL DE SERVICIOS DE MENSAJERIA EN DOMINIOS DE IP.
- English
- MESSAGE SERVICE CONTROL IN IP DOMAINS.
Classification
- CPC, 25
- H04W4/12
- H04L12/14
- H04L12/1403
- H04L61/10
- H04W84/042
- H04W84/12
- H04W88/16
- H04W88/18
- H04W88/184
- H04W92/02
- H04W92/06
- H04W92/16
- H04W92/24
- H04L51/066
- H04L67/30
- H04L67/303
- H04L69/08
- H04L69/329
- H04L61/4557
- H04L61/00
- H04L51/48
- H04L51/56
- H04L51/58
- H04L67/54
- H04L9/40
- IPC, 16
- H04L12 66
- H04W4 12
- H04L12 14
- H04L12 28
- H04L12 58
- H04L29 06
- H04L29 08
- H04L29 12
- H04W84 04
- H04W84 12
- H04W88 16
- H04W88 18
- H04W92 02
- H04W92 06
- H04W92 16
- H04W92 24