U.S. patent application number 11/516922 was filed with the patent office on 2008-03-06 for mobile network optimized method for keeping an application ip connection always on.
This patent application is currently assigned to NOKIA CORPORATION. Invention is credited to Rauno Hartikainen, Mika Joutsenvirta, Pertti Kasanen.
Application Number | 20080059582 11/516922 |
Document ID | / |
Family ID | 39153315 |
Filed Date | 2008-03-06 |
United States Patent
Application |
20080059582 |
Kind Code |
A1 |
Hartikainen; Rauno ; et
al. |
March 6, 2008 |
Mobile network optimized method for keeping an application IP
connection always on
Abstract
A system and method of maintaining an always-on application
client communication is provided. An application programming
interface implemented on a device hosting an always-on application
client determines if network-based keep-alive functionality exists
in a network where the device operates. If network-based keep-alive
functionality exists, a network element is instructed to transmit
keep-alive messages to the application server on behalf of the
device. The network element can be implemented in or as a variety
of existing network elements, e.g., as a GPRS gateway serving node
or a standalone keep-alive network element. Alternatively, an
application server communicatively connected to the always-on
application client may query whether network-based keep-alive
functionality exists. If network-based keep-alive functionality
exists, the application server negotiates with the always-on
application client to determine an application-specific mechanism
for implementing the network-based keep-alive functionality. When
an application server queries for network-based keep-alive
functionality, an application programming interface need not be
utilized.
Inventors: |
Hartikainen; Rauno; (Espoo,
FI) ; Kasanen; Pertti; (Helsinki, FI) ;
Joutsenvirta; Mika; (Tampere, FI) |
Correspondence
Address: |
FOLEY & LARDNER LLP
P.O. BOX 80278
SAN DIEGO
CA
92138-0278
US
|
Assignee: |
NOKIA CORPORATION
|
Family ID: |
39153315 |
Appl. No.: |
11/516922 |
Filed: |
September 6, 2006 |
Current U.S.
Class: |
709/204 |
Current CPC
Class: |
H04L 69/24 20130101;
H04L 67/145 20130101; H04L 67/14 20130101 |
Class at
Publication: |
709/204 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A method of maintaining an always-on application client
connection, comprising: implementing a keep-alive application
programming interface on a device communicatively connected to an
always-on application client; determining keep-alive parameters via
the keep-alive application programming interface; and instructing a
network element via the keep-alive application programming
interface to transmit keep-alive messages to an application server
on behalf of the device, wherein the application server hosts an
always-on application for the device.
2. The method of claim 1, wherein the keep-alive parameters include
a message sending period, at least one parameter defining message
content, and a target IP address of the application server.
3. The method of claim 1, wherein the keep-alive application
programming interface determines if a network element-based
keep-alive messaging service exists in a network in which the
always-on application client operates, before the transmitting of
the keep-alive messages.
4. The method of claim 3, wherein upon a determination that a
network element-based keep-alive messaging service does not exist,
the device transmits the keep-alive messages to the application
server.
5. The method of claim 1, wherein the keep-alive application
programming interface comprises a filter description for defining
application server messages that are not to be forwarded to the
device.
6. The method of claim 5, wherein upon a determination that the
application server messages are not to be forwarded to the device,
the transmission of the application server messages is
prevented.
7. The method of claim 1, wherein before the transmitting of the
keep-alive messages, the network element first determines whether
the device is sending keep-alive messages.
8. The method of claim 7, wherein upon determining that the device
is sending keep-alive messages, the network element instructs the
device to stop sending the keep-alive messages.
9. The method of claim 8, wherein the determining that the device
is sending the keep-alive messages further comprises utilizing a
filter to filter out the keep-alive messages from any outgoing
traffic from the device.
10. The method of claim 1, wherein before the transmitting of the
keep-alive messages, the application server requests network
element-based keep-alive messaging from the network element without
utlizing the keep-alive application programming interface.
11. The method of claim 10, wherein before the requesting of the
network-element-based keep-alive messaging, the application server
performs a query to determine if network-element-based keep-alive
messaging functionality is available.
12. The method of claim 11, wherein upon determining that the
network-element-based keep-alive messaging functionality is
available, the application server and the always-on application
client negotiate an application-specific mechanism for the
network-element-based keep-alive messaging.
13. The method of claim 1, wherein the network element is a GPRS
gateway serving node.
14. The method of claim 1, wherein the network element is
interposed between the device and the application server.
15. The method of claim 14, wherein upon determining an IP address
of the network device during a dynamic host configuration protocol
procedure, the device requests network address translation-based
keep-alive messaging from the network element.
16. A device for maintaining an always-on application client
connection, comprising: a processor; and a memory communicatively
connected to the processor and including: computer code for
implementing a keep-alive application programming interface on a
device communicatively connected to an always-on application
client; computer code for determining keep-alive parameters via the
keep-alive application programming interface; and computer code for
instructing a network element via the keep-alive application
programming interface to transmit keep-alive messages to an
application server on behalf of the device, wherein the application
server hosts an always-on application for the device.
17. The device of claim 16, wherein the keep-alive parameters
include a message sending period, at least one parameter defining
message content, and a target IP address of the application
server.
18. The device of claim 16, wherein the keep-alive application
programming interface determines if a network element-based
keep-alive messaging service exists in a network in which the
client device operates, before the transmitting of the keep-alive
messages.
19. The device of claim 18, wherein the memory unit further
comprises computer code for, upon determining that a network
element-based keep-alive messaging service does not exist,
transmitting the keep-alive messages to the application server.
20. The device of claim 16, wherein the keep-alive application
programming interface comprises a filter description for defining
application server messages that are not to be forwarded to the
device.
21. The device of claim 20, wherein the memory unit further
comprises computer code for, upon determining that the application
server messages are not to be forwarded to the device, preventing
the transmission of the application server messages.
22. The device of claim 16, wherein the memory unit further
comprises computer code for, receiving instructions to stop sending
keep-alive messages upon the network element determining that the
device is sending the keep-alive messages.
23. The device of claim 22, wherein the memory unit further
comprises computer code for, utilizing a filter to filter out the
keep-alive messages from any outgoing traffic from the device.
24. The device of claim 16, wherein the network element is a GPRS
gateway serving node.
25. The device of claim 16, wherein the network element is
interposed between the device and the application server.
26. The device of claim 25, wherein the memory unit further
comprises computer code for, upon determining an IP address of the
network device during a dynamic host configuration protocol
procedure, requesting network address translation-based keep-alive
messaging from the network element.
27. A computer program product, embodied on a computer-readable
medium, for maintaining an always-on application client connection,
comprising: computer code for implementing a keep-alive application
programming interface on a device communicatively connected to an
always-on application client; computer code for determining
keep-alive parameters via the application programming interface;
and computer code for instructing a network element via the
application programming interface to transmit keep-alive messages
to an application server on behalf of the device, wherein the
application server hosts an always-on application for the
device.
28. A method of maintaining an always-on application client
connection, comprising: communicatively connecting to an always-on
application client, wherein a device has implemented therein a
keep-alive application programming interface; transmitting
keep-alive messages to the device; and receiving automated reply
messages in response to the keep-alive messages.
29. The method of claim 28, wherein the keep-alive application
programming interface comprises a filter description for defining
application server-originated keep-alive messages.
30. The method of claim 29, wherein responding to the keep-alive
messages occurs if the keep-alive messages match the filter
description for application server-originated keep-alive
messages.
31. The method of claim 30 wherein a network element
communicatively interposed between the application server and the
device drops the keep-alive messages before reaching the device,
preempting the need for responding to the keep-alive messages.
32. An application server for maintaining an always-on application
client connection, comprising: a processor; and a memory
communicatively connected to the processor and including: computer
code for communicatively connecting to an always-on application
client, wherein a device has implemented therein a keep-alive
application programming interface; computer code for transmitting
keep-alive messages to the device; and computer code for receiving
automated reply messages in response to the keep-alive
messages.
33. The application server of claim 32, wherein the keep-alive
application programming interface comprises a filter description
for defining application server-originated keep-alive messages.
34. The application server of claim 33, wherein the memory unit
further comprises computer code for, responding to the keep-alive
messages if the keep-alive messages match the filter description
for application server-originated keep-alive messages.
35. The application server of claim 34, wherein the memory unit
further comprises computer code for, allowing the need for
responding to the keep-alive messages to be preempted when a
network element communicatively interposed between the application
server and the device drops the keep-alive messages before reaching
the device.
36. A computer program product, embodied on a computer-readable
medium, for maintaining an always-on application client connection,
comprising: computer code for communicatively connecting to an
always-on application client, wherein a device has implemented
therein a keep-alive application programming interface; computer
code for transmitting keep-alive messages to the device; and
computer code for receiving automated reply messages in response to
the keep-alive messages.
37. A method of maintaining an always-on application client
connection, comprising: implementing keep-alive functionality in a
network element; receiving keep-alive message sending parameters at
the network element from a keep-alive application programming
interface implemented on a device; and transmitting keep-alive
messages to an application server from the network element on
behalf of a device, wherein the application server hosts an
always-on application for the device.
38. A system for maintaining an always-on application client
connection, comprising: a device in which an always-on application
client is hosted for communicatively connecting to a keep-alive
application programming interface; an application server configured
to host an always-on application communicating with the always-on
application client; and a network element configured to transmit
keep-alive messages to the application server on behalf of the
device.
Description
FIELD OF THE INVENTION
[0001] The present invention relates generally to keep alive
messaging in IP networks. In particular, the present invention
relates to a system and method of allowing an IP network entity to
transmit keep alive messages on behalf of a communications
terminal.
BACKGROUND OF THE INVENTION
[0002] This section is intended to provide a background or context
to the invention that is recited in the claims. The description
herein may include concepts that could be pursued, but are not
necessarily ones that have been previously conceived or pursued.
Therefore, unless otherwise indicated herein, what is described in
this section is not prior art to the description and claims in this
application and is not admitted to be prior art by inclusion in
this section.
[0003] Data networks have become commonplace in today's world,
allowing for various types of communications including e-mail,
instant messaging, web browsing, voice, interactive and multimedia
communications, etc. In the various types of data communications,
it is important to maintain connections between an application
server or service provider entity located on a data network and a
communication device, such as a personal computer (PC) or a
networked workstation as communications may occur at any time. This
is in contrast more traditional telecommunications scenarios where
an incoming call is detected on a dedicated line, connected, and
released upon completion of the communication.
[0004] To maintain "always-on" connections, communication devices
generally employ or have integrated therein, applications that send
static or random data to application servers just to keep the
connection open. Usually, this static or random data comprises a
small static package sent every 30 seconds, for example. In a wired
or "fixed power" environment, this transmission of random data is
generally not a concern. However, in mobile environments the
constant transmission of such data poses a major problem in that
the battery life of a mobile device is constantly being depleted
during each random data transmission. This promotes bad battery
performance, as the mobile device has to maintain a constant or at
least a periodic connection to a mobile station or application
server. The problem is exacerbated when a single mobile device has
multiple connections to multiple application servers, where
connection maintenance is performed separately for each application
server, because different applications may have different timing
mechanisms for keep-alive messaging. Therefore, less battery life
is available for actual communications in this situation. In
conventional systems, always-on applications are implemented on
mobile devices as a basic requirement for maintaining the constant
connection between the mobile device and an application server in
the network. In addition, there are generally several network
components between the mobile device and the application
server.
[0005] Low-level Internet Protocol (IP) connections are generally
short-lived. A mobile service provider can control the timeout in
the service provider's core network but typically cannot control
the network timeouts in connections to application servers of
3.sup.rd party service providers. It should be further noted that
connection timeouts in a mobile core network are not different for
different communication protocols. In fixed network connections to
application servers, there are significant timeout differences when
utilizing Universal Datagram Protocol (UDP) and Transmission
Control Protocol (TCP). UDP is a protocol that does not guarantee
delivery and duplicate packet protection, while TCP provides a more
reliable, connection-oriented protocol that generally operates in a
layered protocol hierarchy. Mobile applications can use either UDP
or TCP connections.
[0006] Different types of always-on IP applications are becoming an
increasingly important part of not only mobile devices, but of
communication terminals in general. An application cannot
necessarily trust that a connection will remain open, as it may get
closed by the network due to inactivity or some other network
problem. Therefore, the connection must always be kept on. As
discussed above, one example is e-mail. Quite often, obtaining an
e-mail connection to corporate servers is not allowed without some
kind of security. Security is offered via IPsec tunneling. In
addition, connections generally involve traversing a Network
Address Translation (NAT) device. The process of network address
translation, also known as network masquerading or IP-masquerading,
involves re-writing the source and/or destination addresses of IP
packets as they pass through a router or firewall.
[0007] Most systems using NAT do so in order to enable multiple
hosts on a private network to access the Internet using a single
public IP address. For example, a local network may use IP
addresses from one of the private IP address ranges (for example,
192.168.x.x and 10.x.x.x) and use a NAT router to connect to the
Internet. As terminals send traffic from the local network, the NAT
router translates the local IP address to one of its own public
addresses. In order to get through NAT devices, an IPsec tunnel is
created using UDP encapsulation. However, as NAT mappings used in
UDP traffic are relative short (i.e., 20-60 seconds), a mobile
device needs to send keep-alive message quite often to keep NAT
mappings active. Otherwise, responses sent to the mobile device may
not be able to be routed thereto.
[0008] This frequent keep-alive message sending has various
drawbacks. First, a mobile device needs to wakeup, for example,
every 20 seconds to send single keep-alive message. This changes
the state of the radio bearer from IDLE to ACTIVE and the mobile
device will stay in the ACTIVE state for several seconds before
moving back to IDLE, just to be activated again due to the next
keep-alive message. This frequent state change and usage of ACTIVE
state causes significant battery consumption. In fact, the mobile
device is in a type of high level standby mode where it is active
almost continuously, resulting in high power consumption. Another
problem is seen on network side. Because mobile devices are more
frequently in an ACTIVE state, they will consume more network
resources and a single base station is not able to serve as many
mobile devices as it could if the mobile devices were not jumping
between IDLE and ACTIVE due to keep-alive messages.
[0009] Previous solutions for this problem entail sending
keep-alive messages from the mobile device itself to another mobile
device or application server it wishes to remain connected to.
Alternatively, an application server may send keep-alive messages
to the mobile device. This method of keep-alive signaling has been
specified for IPsec (RFC3948), available at
http://www.ietf.org/rfc/rfc3948.txt and incorporated by reference
herein in its entirety, and MIP (RFC3519), available at
http://www.ietf.org/rfc/rfc3519.txt and incorporated by reference
herein in its entirety. In addition, it is the responsibility of
the terminal to send such a message if a NAT device is detected in
the path. Other conventional systems involve a network entity such
as a network operations center sending keep-alive messages to a
gateway. However, this is again done for the purpose of the network
operations center, and not on the behalf of another entity, such as
a mobile device.
SUMMARY OF THE INVENTION
[0010] Various embodiments of the present invention provide a
system and method of maintaining an always-on application client
communication between an always-on application client and an
application hosted on an application server. In one embodiment of
the present invention, an application programming interface
implemented on a device hosting the always-on application client
determines if network-based keep-alive functionality exists in a
network where the device operates. If network-based keep-alive
functionality exists, a network element is instructed to transmit
keep-alive messages to the application server on behalf of the
device. Additionally, replies to the keep-alive messages can be
dropped to prevent the device from receiving the replies. In
another embodiment of the present invention, the network element
determines that the device is transmitting keep-alive messages to
the application server. Upon this determination, the network
element instructs the device to stop sending the keep-alive
messages and resumes the sending of the keep-alive messages on
behalf of the device. The network element can be implemented in or
as a variety of existing network elements, e.g., as a GPRS gateway
serving node or a standalone keep-alive network element.
[0011] Battery performance of a device hosting the always-on
application client can be improved with the present invention
because the device is no longer required to continuously transmit
keep-alive messages to the application server. Also, the hosting
device need no longer reply to keep-alive messages from an
application server, or at least can transmit automated replies.
Control signaling and traffic is reduced as well for both the
device and supporting network elements such as base stations,
allowing the supporting network elements to serve more mobile
devices. In addition, implementing the various embodiments of the
present invention allows service providers the freedom to focus on
optimizing actual call performance instead of on keep-alive
transmissions, as well as easing the burden on application
developers by removing the responsibility to consider future
networks and different country configurations.
[0012] These and other advantages and features of the invention,
together with the organization and manner of operation thereof,
will become apparent from the following detailed description when
taken in conjunction with the accompanying drawings, wherein like
elements have like numerals throughout the several drawings
described below.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG. 1 is an overview diagram of a system within which the
present invention may be implemented;
[0014] FIG. 2 is a perspective view of a mobile telephone that can
be used in the implementation of the present invention;
[0015] FIG. 3 is a schematic representation of the telephone
circuitry of the mobile telephone of FIG. 2;
[0016] FIG. 4 is a flow chart of the processes performed in a first
embodiment of the present invention;
[0017] FIG. 5 is a flow chart of the processes performed in a
second embodiment of the present invention;
[0018] FIG. 6 shows a network architecture in which a third
embodiment of the present invention can be implemented;
[0019] FIG. 7 shows a network architecture in which a fourth
embodiment of the present invention can be implemented; and
[0020] FIG. 8 shows a network architecture in which a fifth
embodiment of the present invention can be implemented.
DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS
[0021] FIG. 1 shows a system 10 in which the present invention can
be utilized, comprising multiple communication devices that can
communicate through a network. The system 10 may comprise any
combination of wired or wireless networks including, but not
limited to, a mobile telephone network, a wireless Local Area
Network (LAN), a Bluetooth personal area network, an Ethernet LAN,
a token ring LAN, a wide area network, the Internet, etc. The
system 10 may include both wired and wireless communication
devices.
[0022] For exemplification, the system 10 shown in FIG. 1 includes
a mobile telephone network 11 and the Internet 28. Connectivity to
the Internet 28 may include, but is not limited to, long range
wireless connections, short range wireless connections, and various
wired connections including, but not limited to, telephone lines,
cable lines, power lines, and the like.
[0023] The exemplary communication devices of the system 10 may
include, but are not limited to, a mobile device 12, a combination
PDA and mobile telephone 14, a PDA 16, an integrated messaging
device (IMD) 18, a desktop computer 20, and a notebook computer 22.
The communication devices may be stationary or mobile as when
carried by an individual who is moving. The communication devices
may also be located in a mode of transportation including, but not
limited to, an automobile, a truck, a taxi, a bus, a boat, an
airplane, a bicycle, a motorcycle, etc. Some or all of the
communication devices may send and receive calls and messages and
communicate with service providers through a wireless connection 25
to a base station 24. The base station 24 may be connected to a
network server 26 that allows communication between the mobile
telephone network 11 and the Internet 28. The system 10 may include
additional communication devices and communication devices of
different types.
[0024] The communication devices may communicate using various
transmission technologies including, but not limited to, Code
Division Multiple Access (CDMA), Global System for Mobile
Communications (GSM), Universal Mobile Telecommunications System
(UMTS), Time Division Multiple Access (TDMA), Frequency Division
Multiple Access (FDMA), Transmission Control Protocol/Internet
Protocol (TCP/IP), Short Messaging Service (SMS), Multimedia
Messaging Service (MMS), e-mail, Instant Messaging Service (IMS),
Bluetooth, IEEE 802.11, etc. A communication device may communicate
using various media including, but not limited to, radio, infrared,
laser, cable connection, and the like.
[0025] FIGS. 2 and 3 show one representative mobile device 12
within which the present invention may be implemented. It should be
understood, however, that the present invention is not intended to
be limited to one particular type of mobile device 12 or other
electronic device. The mobile device 12 of FIGS. 2 and 3 includes a
housing 30, a display 32 in the form of a liquid crystal display, a
keypad 34, a microphone 36, an ear-piece 38, a battery 40, an
infrared port 42, an antenna 44, a smart card 46 in the form of a
UICC according to one embodiment of the invention, a card reader
48, radio interface circuitry 52, codec circuitry 54, a controller
56 and a memory 58. Individual circuits and elements are all of a
type well known in the art, for example in the Nokia range of
mobile telephones.
[0026] Various embodiments of the present invention comprise a
software application programming interface (API) implemented on a
mobile device. An API is an interface that a computer system,
library or application provides in order to allow requests for
services to be made of it by other computer programs, and/or to
allow data to be exchanged therebetween. In particular, the API
implemented in the various embodiments of the present invention
allows for keep-alive messaging between an application client of a
mobile device and an associated application server.
[0027] FIG. 4 shows a flow chart describing the operation of a
first embodiment of the present invention. A software API is
provided which can determine various keep-alive message sending
parameters at 400. The various parameters can include, but are not
limited to, for example, a message sending period, a message
content, and a target IP address, which can be gleaned from a
mobile device. It should be noted that the message content can
comprise, but is not limited to, static data, static data and
random data, and parameters defining certain message content. An
implementation behind the API can check if a keep-alive message
sending service exists in the mobile network within which the
mobile device operates at 410. If so, the keep-alive message
sending parameters are given to a network element within the mobile
network at 420. The network element then starts to send keep-alive
messages on behalf of the mobile device at 430. It should be noted
that the network element sending the keep-alive messages can be any
server or other processor that can be implemented with this
functionality. Furthermore, this functionality can be implemented
in an existing network element within the mobile network. In the
event that the mobile network does not support keep-alive message
sending, the mobile device (i.e., the API and protocol stack) will
send the keep-alive messages on behalf of the application client at
440.
[0028] The operation of a second embodiment of the present
invention is described by the flow chart in FIG. 5. The API can
optionally include a filter description which defines application
server messages that should not be forwarded to the application
client of the mobile device. These not-to-be forwarded application
server messages are determined at 500. As before, keep-alive
message sending parameters are sent to the network element at 510,
and the network element sends keep-alive messages on behalf of the
mobile device at 520. At 530, it is determined whether the
application server is in fact sending replies to the keep-alive
messages to the mobile device, where the replies are defined in the
filter description. If so, at 540, transmission of these replies is
prevented. It should be noted that the filter determination shown
at 500 need not occur after the processes described at 510 and 520,
but can be performed at any time prior to receiving at least a
first keep-alive message reply. This further conserves the mobile
device's battery life and resources of the mobile network.
Alternatively, the application server can be configured to send the
keep-alive messages, for example, after an initial negotiation with
the application client. The filter feature described above can also
cover application server-originated keep-alive messages by defining
an automated reply message for server messages matching the filter
description.
[0029] In a third embodiment of the present invention, a mobile
device 12, a network element 600, and an application server 610 are
shown in FIG. 6. It should be noted that the application server 610
can comprises, but is not limited to, a standalone server, an
existing network element, and another mobile device. When the
network element 600 recognizes that the mobile device 12 is sending
keep-alive messages 620 to the application server 610, the network
element 600 can negotiate with a filter (not shown) of the mobile
device 12 as described above, to filter out the keep-alive
messages. Specifically, a negotiation 630 occurs between the
network element 600 and the mobile device 12, where the network
element 600 provides information regarding which messages and/or
message types comprise keep-alive messages. The network element 600
then transmits instructions 640 to the mobile device 12 to stop
sending such messages to the network element 600. The filter of the
mobile device 12 can be used to determine if any messages
to-be-sent from the mobile device 12 are keep-alive messages. If
so, the filter filters out those messages from the outgoing traffic
of the mobile device 12. After a successful negotiation 630, the
network element 600 will assume the task 650 of sending keep-alive
messages to the application server 610.
[0030] In a fourth embodiment of the present invention, keep-alive
messaging is approached utilizing a server-centric approach as
shown in FIG. 7, which depicts a conventional communications
network in which the various embodiments of the present invention
can be implemented. A mobile device 12 is shown to communicate with
a GPRS Gateway Serving Node (GGSN) 700 via a radio network. A GGSN
is network node that acts as a gateway between a General Packet
Radio Service (GPRS) wireless data network and other networks such
as the Internet or private networks. The GGSN acts as an anchor
point that enables the mobility of a mobile device in
GPRS/Universal Mobile Telecommunication System (UMTS) networks. In
essence, the GGSN in a GPRS network is similar to of a Home Agent
in Mobile IP, by maintaining any routing necessary to tunnel
Protocol Data Units (PDUs) to the Serving GPRS SGSN that service a
particular MS (Mobile Subscriber).
[0031] In order for an Internet-based application client of the
mobile device to function, the mobile device 12 must further
communicate with an application server 720 via a network address
translation (NAT) device 710 and the Internet. As shown in FIG. 7,
the operator core network encompasses at least the GGSN 700 and the
NAT device 710. The application server 720 attempts to negotiate a
keep-alive messaging function with a network element, such as the
GGSN 700. If the negotiation is successful, the application client
of the mobile device 12 and the application server 720 negotiate an
application-specific mechanism relieving the mobile device 12 of
the duty to send keep-alive messages.
[0032] Specifically, at 730, the application server 720 requests a
keep-alive function from the GGSN 700, with message sending period
and message content as parameters. To penetrate firewalls and NAT
devices it is better that the keep-alive message comes from mobile
device direction, as at 740. In this case it is not necessary for
the application server 720 to send a reply to keep-alive messages,
but there is an optional parameter for application
server-originated, keep-alive messages that a network element such
as the GGSN 700 should drop (i.e., not deliver to the mobile device
12). The parameters include also a message that the GGSN 700 should
send in case the mobile device connection is terminated, such as at
750. Using this functionality instructs the GGSN 700 to not timeout
this PDP context or alternatively, implements setting a timeout
period different than the default GGSN 700 configuration. It should
be noted that in the fourth embodiment of the present invention, a
software API need not be utilized.
[0033] For certain embodiments of the present invention, to avoid
Denial Of Service attacks, a network element, such as the GGSN 700,
can only accept requests from application servers it knows. In
addition there is a lightweight agreement process between the
operator and the application service provider, as a GGSN is
typically not accessible from the public internet. In a service
operator's network Demilitarized Zone (DMZ), there can be a server
from where the application server asks for a desired service. The
operator in turn sets up a Domain Name Service (DNS) service record
for this server, in the same domain from where the original
application server connection comes from. The request from the
application server would contain the origin IP address and port
number of the application connection from mobile device as
parameters.
[0034] As described above, a network element such as a GGSN can be
used to provide keep-alive messaging to an application server in
lieu of a mobile device. FIG. 8 shows that a new keep-alive network
element 800 can also be used to provide keep-alive messaging,
instead of utilizing a GGSN. In this embodiment of the present
invention, a network service operator can provide a service that
sends NAT keep-alive messages on behalf of the mobile device 12.
This new keep-alive network element 800 can be located before the
first NAT device 710 and the mobile device 12 can request NAT
keep-alive services from it. In addition, the new keep-alive
network element 800 can learn of the keep-alive functionality by
performing its own network analysis. It should be noted as well
that a software API need not be utilized in this example. Another
network element that can be used for the keep-alive assistance
functionality is the Home Agent (not shown). As 3GPP is
standardizing Mobile IP (MIP) usage for inter access mobility
between 3GPP and non-3GPP systems, a network element placed before
the Home Agent does not solve NAT keep-alive problem that occur
after traversing the Home Agent. Therefore, MIP signaling can be
used to inform a proper Home Agent to start its own keep-alive
assistance functionality.
[0035] Specifically, the mobile device 12 can get the IP address of
the new keep-alive network element 800 during the dynamic host
configuration protocol (DHCP) procedure. The DHCP is a protocol
used by network entities to obtain unique IP addresses,and other
parameters like: default router, subnet mask, and IP addresses for
DNS servers. This protocol is used when network entities are added
to a network because these settings are necessary for the host to
participiate in the network. When the mobile device 12 detects a
NAT device 710 in the communication path (for example, Internet Key
Exchange (IKE) specifies a mechanism to detect NAT devices), the
mobile device 12 can request a NAT keep-alive service from the new
keep-alive network element 800 by sending a special message to the
new keep-alive network element 800. That message can contain source
and destination IP/port information. The new keep-alive network
element 800 then sends keep-alive messages on behalf of the mobile
device 12 using the parameters received from mobile device 12.
[0036] In implementing the keep-alive features discussed above, a
software API can be created on the device side, where device
application developers can use the API or alternatively,
application servers are made aware of mobile networks. Also,
wireless network providers can implement the keep-alive features in
some network components. In the case of network support being
available, battery performance of a mobile device can be improved
as result of reduction in traffic over the air interface, which in
turn lessens the need to keep a radio element of the mobile device
on. A mobile device's battery performance no longer needs to depend
upon a network air interface configuration. Service operators can
also keep optimizing network parameters for the best speech call
performance instead of being burdened with the transmission and
receipt of keep-alive messages. In addition, keep-alive
functionality that resides outside of the mobile device also
simplifies the task of application developers and makes
applications more "future-proof" and independent upon multiple
access methods. Furthermore, managing future networks and
configurations in different countries need not be the
responsibility of application developers any longer, but rather the
responsibility of network operators and platform providers.
[0037] It should further be noted that client originated,
keep-alive messages are desirable when connecting to existing
application servers, requiring no changes to the servers. However,
if the application server is aware of mobile networks and the keep
alive functionality, using server-originated keep alive messages,
where the server can comprise, but is not limited to, an
application server, a GGSN, or a Home Agent as described above,
would enable changing the keep alive behavior without updating the
clients.
[0038] The present invention is described in the general context of
method steps, which may be implemented in one embodiment by a
program product including computer-executable instructions, such as
program code, executed by computers in networked environments.
Generally, program modules include routines, programs, objects,
components, data structures, etc. that perform particular tasks or
implement particular abstract data types. Computer-executable
instructions, associated data structures, and program modules
represent examples of program code for executing steps of the
methods disclosed herein. The particular sequence of such
executable instructions or associated data structures represents
examples of corresponding acts for implementing the functions
described in such steps.
[0039] Software and web implementations of the present invention
could be accomplished with standard programming techniques with
rule based logic and other logic to accomplish the various database
searching steps, correlation steps, comparison steps and decision
steps. It should also be noted that the words "component" and
"module," as used herein and in the claims, is intended to
encompass implementations using one or more lines of software code,
and/or hardware implementations, and/or equipment for receiving
manual inputs.
[0040] The foregoing description of embodiments of the present
invention have been presented for purposes of illustration and
description. It is not intended to be exhaustive or to limit the
present invention to the precise form disclosed, and modifications
and variations are possible in light of the above teachings or may
be acquired from practice of the present invention. The embodiments
were chosen and described in order to explain the principles of the
present invention and its practical application to enable one
skilled in the art to utilize the present invention in various
embodiments and with various modifications as are suited to the
particular use contemplated.
* * * * *
References