Patent Application
20080059582
For exemplification, the system 10 shown in
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.
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.
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.
The operation of a second embodiment of the present invention is described by the flow chart in
In a third embodiment of the present invention, a mobile device 12, a network element 600, and an application server 610 are shown in
In a fourth embodiment of the present invention, keep-alive messaging is approached utilizing a server-centric approach as shown in
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
