HK1040850B - A mobile terminal and wireless device with common ip address - Google Patents

Description

Mobile terminal and wireless device having a common IP address

Background

I. Field of the invention

The present invention relates to wireless data devices. More particularly, the present invention relates to a novel and improved method and system for transposing Internet Protocol (IP) endpoints between devices connected to a network.

Description of the related Art

Internetworking, i.e. connections between respective Local Area Networks (LANs), has rapidly gained popularity. The infrastructure, commonly referred to as the "internet," and related protocols are well known and widely used. It is well known in the art that internet protocols at the core of the internet support the routing of datagrams between LANs, as further described in the paper entitled "internet protocol DARPA internet program protocol specification" in the set of Request For Comments (RFC) dated 9 1981.

IP is a datagram-oriented protocol that provides several services including addressing. The IP protocol encapsulates data into IP packets for transmission and affixes addressing information to the packet header. The IP header contains a 32-bit address that identifies the sending and receiving host. These addresses are used by the intermediate routers to select a path for the packet through the network to the final destination that is the desired address. The basic concept of IP addressing is that the initial prefix of an IP address can be used for a broad routing decision. For example, the first 16 bits of an address may identify QUALCOMM corporation, the first 20 bits identify the QUALCOMM's main office, the first 26 bits identify the office a particular ethernet, and the entire 32 bits identify a particular host on the ethernet. As an example, each address in the IP network of QUALCOMM may be in the form 129.46.xxx, where xxx refers to any allowable integer between 0 and 255 (dot-separated-quadruple notation).

As is known from this prefix-based IP routing feature, the IP address contains implicit geographical information about the location of a particular host on the internet. In other words, whenever any router on the internet receives a packet whose destination IP address begins at "129.46," it sends the packet in a particular direction to the QUALCOMM network, inc. Thus, the IP protocol allows datagrams originating from any internet node in the world to be routed to any other internet node in the world, assuming that the originator knows the destination-side IP address.

With the increasing number of mobile computing and mobile internet access, there is an increasing demand to provide mobile data support to mobile terminals such as laptop or palmtop computers using IP protocols. As mentioned above, however, the IP addressing scheme used for internet routing contains implicit geographical information. In other words, if a user wishes to identify their mobile terminal with a fixed IP address, it is desirable that IP packets destined for the mobile terminal will not be routed to the mobile terminal when the mobile terminal is away from its "home" network (i.e., the network containing its fixed IP address) and lacks some technique for "forwarding" IP packets to the mobile terminal.

For example, consider a user deciding to take their mobile terminal away from their "home" IP network located at san diego QUALCOMM, inc, and travel with him to palo alto, california, where it connects to the stanford university IP network, but still maintains the fixed IP address to which QUALCOMM is assigned. It is expected that any IP datagrams destined for the mobile terminal will still be routed to the QUALCOMM's IP network because the geolocation information is implicit in the fixed IP address of the mobile terminal. Such IP packets will not be sent to a mobile terminal that is now far from its "home" network unless there is some mechanism to send IP packets from the QUALCOMM's IP network to a mobile terminal at the current point of connection to the internet at the stanford university IP network in palo alto.

To meet this requirement, the paper entitled "IP mobility support" in RFC2002, dated 10.1996, specifies a protocol enhancement that allows IP datagrams to be routed transparently to many mobile nodes in the Internet. With many of the techniques described in RFC2002, each mobile node can always be identified by its "home" IP address, regardless of its current point of attachment to the internet. When located away from its home IP network, the mobile terminal may become associated with a "care-of" address, thereby providing the forwarding information needed to route IP datagrams to their current point of attachment to the internet. RFC2002 accomplishes this by providing a "home agent" with a registration of such a "care-of address". The home agent submits IP datagrams destined for the mobile terminal using the so-called "IP pipe" technique. IP tunneling involves the home agent prefixing a new IP header containing such a care-of address to any arriving IP packet having a destination address corresponding to the mobile terminal's home IP address. Upon reaching the care-of address, the "foreign agent" at the care-of address strips off the IP pipe header and delivers the IP packet to the mobile terminal at its current point of attachment to the internet.

In this way, RFC2002 provides mobile data services to users who need to relocate their mobile terminal's point of attachment to the internet without changing the mobile terminal IP address. This capability has several advantages. First, it allows an originating node somewhere else on the internet to send periodic "push" services to mobile terminals wherever they are. Such services may include stock indices or electronic mail (e-mail). This avoids the need for the mobile user to "dial in" or otherwise contact their home network to retrieve the information. Furthermore, it allows the mobile terminal to be relocated as frequently as needed, without the need for any originator having to track the current location of the mobile terminal.

In order to increase the freedom of movement of a mobile terminal, many mobile users typically connect to the internet using a wireless communication device such as a cellular phone or a portable phone. In other words, many mobile users will utilize wireless communication devices, commonly referred to as "mobile stations" or MT2 devices, as access points for land-based networks. As used herein, a "mobile station" or "MT 2 device" will refer to any subscriber station in a public radio network that is intended to be employed while a non-specified point is in motion or during a dwell. Mobile station and MT2 devices include portable units (e.g., handheld personal telephones) or vehicle-mounted units, and Wireless Local Loop (WLL) telephones.

Fig. 1 depicts a high-level block diagram of a wireless data communication system in which a mobile terminal (TE2 device) 102 communicates with an interworking function (IWF)108 via a wireless communication system that includes a wireless communication device (MT2 device) 104 and a base station/mobile switching center (BS/MSC) 106. In fig. 1, the IWF108 acts as an access point to the internet. The IWF108 may be coupled to, and often even co-located with, the BS/MSC106 of an existing wireless base station as is well known in the art. The TE2 device 102 is coupled with the MT2 device 104, which in turn is in wireless communication with the BS/MSC106 and the IWF 108.

There are many protocols that allow data communication between the TE2 device 102 and the IWF 108. For example, published in 2 months of 1998 entitled "data service options for wideband spread spectrum systems: the telecommunications association (TIA)/electronics association (EIA) interim standard IS-707.5 of packet data service specifies the requirements for packet data transmission capability support on the TIA/EIA IS-95 broadband spread spectrum system of which the BS/MSC106 and IWF108 may be a part. IS-707.5 specifies a packet data bearer service that may be used to communicate between TE2 device 102 and IWF108 via BS/MSC 106. The provided procedures are applicable to multi-packet data services including the mobile IP service of RFC2002 and the Cellular Digital Packet Data (CDPD) as described in the specification entitled "cellular digital packet data system specification version 1.1" in CDPD-1995 published by CDPD forum gmbh 1, 29, 1995.

CDPD is an AMPS (analog) cellular data service that includes some of its own support for mobility. CDPD differs from mobile IP in several significant ways. Clearly, the CDPD modem has an assigned IP address belonging to the CDPD network. Thus, although the CDPD modem may roam within the CDPD network, it may not utilize its "home" IP address outside of the CDPD network in the same manner that a terminal supported by mobile IP may utilize its "home" IP address outside of its "home" network.

IS-707.5 also provides many communication protocol requirements for the link between the TE2 device 102 and the MT2 device 104(Rm interface), the MT2 device 104 and the BS/MSC106(Um interface), and the BS/MSC106 and the IWF108(L interface).

Referring now to fig. 2, shown IS a schematic diagram of the protocol stack of the various entities of the IS-707.5 relay model. Fig. 2 corresponds substantially to fig. 1.4.2.1-1 of IS-707.5. Shown remotely on the left side of the figure is a protocol stack, illustrated in a conventional vertical format, showing the protocol layers running on a TE2 device 102, such as a mobile terminal, laptop or palmtop computer. The TE2 protocol stack is illustrated as logically connected to the MT2 device 104 protocol stack over an Rm interface. The MT2 device 104 is illustrated as logically connected to the BS/MSC106 protocol stack over a Um interface. The BS/MSC106 protocol stack is illustrated as logically connected to the IWF108 protocol stack on the L interface.

Fig. 2 operates, for example, as follows. An upper layer protocol 202 entity, such as an application running on TE2 device 102, exists for the need to send IP packets over the internet. An example application may be a web browser such as netscape navigator, microsoft internet Explorer, etc. The web browser requests information such as http: // www.qualcomm.com Universal Resource Locator (URL). A Domain Name System (DNS) protocol, also located in the upper layer protocol 202, translates a textual hostname "www.qualcomm.com" into a 32-digit IP address. Hypertext transfer protocol (HTTP) is also an upper layer protocol 202 that constructs a GET message for the requested URL, and specifies that the message is to be sent using the Transmission Control Protocol (TCP), TCP Port 80 is used for HTTP operations.

The TCP protocol, also an upper layer protocol 202, opens a connection to the IP address specified by DNS, port 80, and sends an HTTP GET message. The TCP protocol specification will use the IP protocol for messaging. The IP protocol, an internet layer protocol 204, sends TCP packets to specified IP addresses. Point-to-point protocol (PPP), a link layer protocol 206, encodes IP/TCP/HTTP packets and sends them over an Rm interface to an EIA-232 compatible port on the MT2 device using the relay layer protocol 208 EIA-232. The PPP protocol is specified in RFC1661 in the paper entitled "point-to-point protocol (PPP)".

The EIA-232 protocol 210 on the MT2 device 104 passes the transmitted PPP packets to a combination of the radio link protocol (RPL)212 and the IS-95 protocol 214 for transmission over the Um interface to the BS/MSC 106. The RLP protocol 212 IS specified in IS-707.2, and the IS-95 protocol IS specified in IS-95 as mentioned above. The supplemental relay layer protocol stack on the BS/MSC106, including the combination of the RLP protocol 216 and the IS-95 protocol 218, receives PPP packets over the Um interface and passes them to the MT2 relay layer protocol 220 to reach the IWF relay layer protocol 228 over the L interface. The MT2 trunk layer protocol 220 and the IWF trunk layer protocol 228 are described in the specification entitled "data service interworking function interface standard for wideband spread spectrum digital cellular system" in TIA/EIA IS-685.

The PPP protocol 226 in the IWF link layer 227 decodes PPP packets output by the TE2 device 102 and serves to terminate the PPP connection between the TE2 device 102 and the IWF 108. The decoded packets are passed from the PPP protocol 226 to the IP protocol in the network layer protocol 224 of the IWF108 for examination and further routing to the IP address specified by the TE2 device 102 in the IP packet header (here IP address www.qualcomm.com). Some upper layer protocol tasks, such as TCP, to be performed at the IWF108 are performed by the upper layer protocol 222.

Assuming the TE2 device 102 generated IP packet is not ultimately destined for the IWF108, the packet is sent to an internet next-to-next router (not shown) via the network layer protocol 224, the link layer protocol 227 of the IWF108, and the relay layer protocol 228. In this manner, the IP packets output by the TE2 device 102 are communicated through the MT2 device 104, the BS/MSC106, and the IWF108 to their ultimate intended destination on the Internet, thereby providing wireless packet data service to the TE2 device 102 in accordance with the Relay model of the IS-707.5 standard.

As illustrated in fig. 2, the IS-707.5 standard presents a number of requirements for the communication protocol over the link between the TE2 device 102 and the IWF108, including requirements for Rm, Um, and L interfaces. These requirements and procedures apply to the support of mobile IP services as specified in RFC 2002. IS-707.5 does not provide the procedure for establishing mobile IP services in the first scenario. In other words, IS-707.5 provides a framework for supporting mobile IP services, rather than processes for negotiating or registering TE2 device 102 with mobile IP services-a home agent and a foreign agent. The above procedure is found in RFC2002 itself.

Moreover, both the network and relay models of IS-707.5 imply the assignment of a single IP address to TE2 device 102. No separate specification is made for the assignment of the second IP address specific to the MT2 device. Indeed, it is currently not possible to obtain more than one IP address per PPP session. The additional resource overhead in the IWF108 to support multiple PPP sessions per mobile unit makes it less attractive to service providers.

This distinction is important when considering that typically some application layer entity must be present in TE2 device 102 to support mobile IP. Unfortunately, Microsoft Windows, the most popular operating system software for personal computers, does not support Mobile IP, nor is it currently anticipated that such support will be available. As a result, TE2 devices running microsoft windows (or one of many other operating systems) cannot use their "home" IP address when they are not connected to their "home" IP network. This prevents mobile users from taking advantage of the benefits of delivering such mobile IP services as "push-out" services and direct electronic mail (e-mail) while away from the "home" IP network.

What is needed is a method and system for performing mobile IP registration for TE2 devices and acting as a proxy for TE2 devices by MT2 devices to establish mobile IP support for TE2 devices. In summary, there is a need for a method and system that enables two networked devices (e.g., MT2 and ET2) to share a single IP address.

Summary of The Invention

The present invention is a novel and improved system and method for transposing IP endpoints, such as may be performed as part of proxy mobile node registration. The method includes signaling, by a terminal device, a need for mobile data services and initiating, in a wireless communication device, mobile node registration with the terminal device responsive to the signaling step. The terminal device transmits the packetized data, and a wireless communication device coupled to the terminal device monitors the packetized data for an Internet Protocol (IP) address contained in the IP address request. If the IP address request requests a static IP address, the wireless communication device initiates registration of the mobile node with the IP address. The wireless communication device prevents the terminal device from transmitting or receiving packetized data upon the originating mobile node registration and allows the terminal device to transmit and receive packetized data once the mobile node registration is completed. As a result, the mobile node registration appears transparent to the terminal device, avoiding the need for the terminal device to have its own mobile IP support.

In another aspect of the invention, a networking device (which may be a wireless communication device) shares an IP address with a separate networking device (which may be a terminal device). Sharing is done by checking the port number of the received IP packet by the networking device. When the port number of the received IP packet corresponds to an application running on the networking device, the networking device routes the IP packet to the application on the networking device. When the port number of the received IP packet does not correspond to an application running on the networking device, the networking device routes the IP packet to a separate networking device.

Further, the networked device, upon determining whether an application on the networked device needs to originate IP packets, originates IP packets that include as an originating address an IP address assigned to the separate networked device.

Alternatively, the IP address may be transposed between the networked device and a separate networked device. The networked device transposes an IP address from the separate networked device to itself by blocking the transmitted IP packet from originating in the separate networked device and originating an IP packet including an IP address assigned to the separate networked device as an originating address when the networked device determines that an application on the first networked device has a need to originate IP packets. The networking device may also ignore received IP packets addressed to the individual networking device when it uses the IP address of the individual networking device.

Brief description of the drawings

The features, objects, and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings. Like reference numerals in the drawings denote corresponding items, wherein:

fig. 1 shows a top block diagram of a wireless data communication system in which terminal devices are connected to the internet via a wireless communication device;

FIG. 2 IS a diagram of the protocol stack in each entity of the IS-707.5 relay model;

fig. 3 is a top state diagram of the operation of the MT2 device of the present invention;

FIG. 4 is a diagram of each entity protocol stack according to one embodiment of the present invention;

FIG. 5 illustrates an extended state diagram of the Mobile IP mode state 310 of FIG. 3;

FIG. 6 is a diagram of each physical protocol stack in accordance with an alternative embodiment of the present invention;

FIG. 7 illustrates an extended state diagram of an alternate embodiment of Mobile IP mode 310 in FIG. 3;

FIG. 8 is a flow diagram illustrating one method of performing IP address transposition;

FIG. 9A is a flow diagram illustrating an alternative method of performing IP address transposition together when receiving IP packets; and

fig. 9B is a flow diagram illustrating an alternative method of performing IP address transposition together when sending IP packets.

Detailed description of the preferred embodiments

The present invention is intended to support transparent mobility to users of MT2 devices that allow data services. Various embodiments of the present invention are intended to support data services under 3 different usage models.

The first usage model is the case where mobile IP is not supported, but data traffic with dynamically assigned IP addresses is supported. In the first usage model, the TE2 device is dynamically assigned an IP address by the Internet Service Provider (ISP) to which it is currently connected. The first usage model does not employ mobile IP support and does not use its "home" IP address. As a result, rather than having data sent from its home IP network to the TE2 device, the TE2 device only receives data that it explicitly requests when connected to the ISP.

The second usage model is the scenario where mobile IP support is provided in MT2 devices as a proxy on behalf of TE2 devices. This second model is applicable to those users who desire TE2 devices that are mobile IP supported, but not mobile IP supported. For example, users of a TE2 device such as a laptop computer running the Microsoft Windows operating system fall into this second usage model. In a second usage model, the TE2 device can use its "home" IP address (i.e., its "permanent" IP address assigned by its home network) whether attached to its home IP network or roaming on a wireless network supporting Mobile IP. This second usage model also provides mobility support for devices such as the so-called "smart phones" (smart phones) that integrate TE2 devices and MT2 devices.

A third usage model is to provide mobile IP support in TE2 devices. This third usage model is applicable to those users of TE2 equipment that have mobile IP support and therefore do not require MT2 device proxy services. Various embodiments of the present invention are intended to meet one or more of the above-described 3 usage models.

It will be apparent to one of ordinary skill in the art that the invention described below may be implemented in many different embodiments of software, firmware, and hardware in the various entities illustrated (TE2 device 102, MT2 device 104, BS/MSC106, and IWF 108). The actual software code or control hardware used to implement the present invention is not limiting of the present invention. The operation of the present invention will thus be described without specific reference to the actual software code, it being understood that one of ordinary skill in the art would be able to design software and control hardware to implement various embodiments of the present invention based on the description herein.

Referring now to fig. 3, there is shown a top state diagram of the operation of the MT2 device of the present invention. In fig. 3, the MT2 device begins in the turned off state 308. The MT2 device in the closed state 308 is not currently in a call, but is waiting to originate a call. Calls terminated via the mobile unit (i.e., those cases where the MT2 device is the called party) are not considered in this state because these calls assume that the MT2 device has either been assigned an IP address or registered to require mobile IP. If the MT2 device is registered for mobile IP, it is not in the off state 308, but is in the mobile IP mode state 310, discussed more fully below.

When the TE2 device originates a packet data call, the MT2 device transitions from the turned off state 308 to "do mobility support? "state 304. At this "whether mobility is supported? "state 304, the MT2 device checks the value of the mobility data item 302 to determine whether mobility support (of mobile IP) is allowed. In one embodiment, the mobility data items 302 may have 1 of 3 values that are optionally configurable by the mobile user as desired through a user interface on, for example, the TE2 device or the MT2 device. Other embodiments may use more or less values to allow the mobile user to have more or less configuration options. Still other embodiments do not allow for user configuration of the mobility data items 302. In still other embodiments, the mobility data item 302 is not present, but rather such a decision is placed in the control software via code curing.

The first value of the mobility data item is "forbidden". The MT2 device does not support mobile IP negotiation and registration when the mobility data item 302 has a value of "forbidden". As a result, all packet data calls that originate with mobility data item 302 having this "barring" value utilize the reduced IP mode 306, which will be discussed more fully below.

The second value is "if any". The MT2 will provide mobile IP negotiation and registration if the mobility data item 302 has a value of "if any", unless the infrastructure (BS/MSC 106 and IWF 108) does not support mobile IP or the MT2 device attempts a mobile node registration failure. If the infrastructure does not support mobile IP, the packet data call is changed to a reduced IP mode 306 call. In other words, the mobility data item 302 "if any" value allows users of TE2 devices and MT2 devices to gain the benefits of mobile IP when supported by infrastructure and successfully negotiated, but still allow packet data calls without mobile IP support for other scenarios. In one embodiment, the mobile user is not allowed to change the value of the mobility data item 302, but instead takes the second value. Alternatively, the mobility data item 302 may always be set to "if any", or ignored altogether, which eliminates "if mobility is supported? A transition between state 304 and reduced IP mode state 306.

This third value is the "exclusive mode". The MT2 will provide mobile IP negotiation and registration if the mobility data item 302 has a value of "exclusive mode" unless the infrastructure (BS/MSC 106 and IWF 108) does not support mobile IP or the MT2 device attempts a mobile node registration failure. However, contrary to the above-mentioned value of "if any", if the underlying implementation does not support mobile IP or the mobile node registration attempt fails, the MT2 device does not complete a simplified IP call but rather forces the scored group call origination attempt to fail completely. In other words, the value of mobility data item 302 "exclusive mode" prevents any call other than a mobile IP supported call from originating from the MT2 device.

If mobility data item 302 has a value of "forbidden," or mobility data item 302 has a value of "if any" but mobile IP is not supported by the infrastructure, the MT2 device enters reduced IP mode 306 based on the packet data call origination attempt. In one embodiment, the simplified IP mode 306 employs the existing IS-707.5 relay model as illustrated and described with reference to fig. 2.

If mobility data item 302 has a value of "if any" or "exclusive mode", the MT2 device is then from "if mobility is supported? State 304 transitions to mobile IP mode 310. It is in this mobile IP mode 301 that the MT2 device registers as a mobile node acting on mobile IP traffic on behalf of the TE2 device as described below.

Referring now to fig. 4, shown is a diagram of various entity protocol stacks in accordance with one embodiment of the present invention. The significant difference between the schematic diagram of fig. 4 and the schematic diagram of fig. 2 is that in fig. 4 there is an additional protocol layer for the MT2 device 104 to support the mobile node registration of the present invention. The further protocol layers include PPP protocol 415, IP protocol 413, UDP protocol 411 and mobile IP protocol 409. To the extent that the protocol layers in fig. 4 operate as in fig. 2, the protocol layers will not be extended. And the following discussion will focus on the differences between fig. 4 and fig. 2.

An example of the operation of fig. 4 is illustrated as follows. The upper layer protocol 402 entity, such as the application running on TE2 device 102, has the need to send IP packets over the internet, similar to the upper layer protocol 202 entity in figure 2. The application generated message employs, for example, a TCP or UDP protocol, which is encapsulated by an IP protocol 404 employing the destination IP address. The point-to-point protocol (PPP) this protocol 406 frames IP-to-IP packets and sends them over an Rm interface using a relay layer protocol 408EIA-232 to an EIA-232 compatible port on an MT2 device running EIA-232 protocol 410.

However, as is known in the art, to establish communications over a point-to-point link, each end of the PPP link (here TE2PPP protocol 406 and IWF PPP protocol 426) must first send Link Control Protocol (LCP) packets for the establishment, configuration and testing of the data link connection. After the link is established by the LCP, the PPP protocol 406 then sends Network Control Protocol (NCP) packets to configure the network layer protocols (here TE2 IP protocol 404 and IWF IP protocol 425). After the respective network layer protocols are configured, datagrams for the respective network layer protocols may be sent over the links between them.

In a certain embodiment, the NCP of the IP is the IP control protocol (IPCP). This IPCP is described in detail in RFC1332, published in 1992, month 5, entitled "PPP Internet Protocol Control Protocol (IPCP)" paper. The IPCP is responsible for configuration, activation, and deactivation of both the TE2 IP protocol 404 and the IWF IP protocol 425 operating on either end of the point-to-point link. As is known in the art, a configuration request used by IPCP is a message that may include an IP address configuration option. The configuration options portion of the configuration request message provides a way to negotiate the IP address to be used by the sender of the configuration request, here TE2 device 102. It allows the configuration request sender to indicate which IP address is needed by specifying the IP address, or to request that the same type of device (here the IWF 108) provide a dynamic IP address to the sender. If the sender of the configuration request sets all the IP address fields in the IP address configuration option to zero, the same type of device can provide a dynamic IP address by sending a configuration NAK (negative acknowledgement) to the option and returning a valid IP address. Conversely, if the sender of the configuration request sets the IP address field in the IP address configuration option to a specified IP address, the peer device may indicate that the specified IP address is acceptable by sending a configuration ACK to the option. The present invention utilizes IPCP communications between TE2 device 102 and IWF108 to determine whether and when to act as a proxy for TE2 devices during mobile node registration.

Fig. 5 shows an extended state diagram of the mobile IP mode state 310 in fig. 3. When "support mobility? State 304 (fig. 3) determines that mobility data item 302 is not barred and transitions to monitoring PPP sub-state 502. It should be appreciated that once the call is ended, it is possible to transition from any of the substates of FIG. 5 to the OFF substate 516. For simplicity, however, the transition after the end of the call is only illustrated as going from the open sub-state 508 to the closed sub-state 516.

During the PPP sub-state 502 monitoring process, the MT2 device 104 inserts the network "tap" 417 into the MT2 device protocol stack between the RLP protocol 412 and the EIA-232 protocol 410 devices of the same type. In other words, PPP packets communicated between the EIA-232 protocol 410 and the RLP protocol 412 are monitored and examined by the MT2 device 104. This allows the MT2 device to monitor the PPP packet as it passes between the TE2 device 102 and the IWF 108.

The first LCP packet is cached by the MT2 device 104 for use after an interworking transition as will be explained below with respect to the initial PPP resynchronization state 504. The MT2 device 104 continues to monitor PPP packets exchanged between the TE2 device 102 and the IWF108 until IPCP packets from the TE2 device 102 are detected by the MT2 device 104. The IPCP packet is then examined by the MT2 device 104 to determine whether a static or dynamic IP address is being requested in the IP address configuration options of the configuration request. If the IP address field contains all zero IP addresses, the TE2 device requests a dynamic address. In this case, without the request of the TE2 device 102 for mobile IP support, the MT2 device 104 transitions to the simplified IP mode 306 (fig. 3).

Conversely, if the IP address field of the configuration request sent by the TE2 device 102 contains a static (i.e., non-zero) IP address, the MT2 device 104 transitions to the monitor IPCP state 506. In monitor IPCP state 506, the MT2 device 104 monitors IPCP packets being exchanged between the TE2 device 102 and the IWF 108. Specifically, the MT2 device 104 examines the IPCP packet to determine whether the static IP address request made by the TE2 device 102 has been accepted by the IWF108 with a configuration ACK (acknowledgement).

If the IWF108 denies the static IP address request made by the TE2 device 102, the MT2 device 104 transitions to "is mobility mode? State 514, where the value of mobility data item 302 is checked. If the mobility data entry 302 has a value of "if any," the MT2 device 104 transitions to the reduced IP mode state 306 because it is assumed that the user is satisfied with the reduced IP call (i.e., the dynamically assigned IP address) when mobile user support is not provided. However, if the mobility data item 302 is in the "exclusive mode", the MT2 device 104 transitions to the off state 516, assuming the user is not satisfied with simplifying the IP call.

If the IWF108 accepts the static IP address request made by the TE2 device 102, the MT2 device 104 transitions to the mobile registration state 512 once the IPCP negotiation is complete. In the mobile registration state 512, the MT2 device 104 originates the PPP protocol 415, IP protocol 413, UDP protocol 411, and mobile IP protocol 409. The MT2 device 104 then performs flow control on the TE2 device 102. As used herein, "flow control" refers to the step of preventing TE2 device 102 from sending or receiving data through its relay layer interface. In the embodiment of FIG. 4, this is the link between the EIA-232 protocol 408 of the TE2 device and the EIA-232 protocol 410 of the MT2 device. Flow direction control in software or hardware may be employed. Specifically, in one embodiment, the MT2 device 104 toggles one of the pin voltages between the MT2 device 104 and the TE2 device 102.

Through the flow control of the TE2 device 102, the MT2 device 104, and in particular the IP protocol 413, may now become an IP-endpoint for mobile node registration purposes. This allows the MT2 device 104 to perform mobile node registration on behalf of the TE2 device 102, transparently to the TE2 device 102. Conceptually, this causes the IP-endpoint to "swap" from TE2 device 102 to MT2 device 104 (and vice versa).

The MT2 device 104 reads a number of Mobile Node Registration (MNR) data items 510. In one embodiment, these data items are stored in corresponding non-volatile storage circuitry (not shown). The MNR data item 510 described above is a data item required to perform registration of the mobile node. The MNR data entry 510 may include a security parameter index, MD5 authentication key, and home agent IP address as specified in RFC 2002.

The MT2 device 104 then performs mobile node registration as specified in RFC2002, using the static IP address and MNR data items 510 requested by the TE2 device 102. The details of the mobile node registration are described in RFC2002 and will not be described in detail here. Briefly, the Mobile IP protocol 409 sends an alien proxy solicitation message to the Mobile IP protocol 421 in the IWF 108. The foreign agent solicits messages to be passed down to the UDP protocol 411. As is known in the art, the UDP protocol 411 acts as a datagram service and passes the foreign agent solicitation message to the IP protocol 413 where it is packetized, as per RFC2002, with the IP header of the broadcast address or "all routers" multicast address.

The IP protocol 413 then passes the IP packet to PPP protocol 415 so that it IS packetized into PPP packets and sent to RLP protocol 412 and IS-95 protocol 414 for transmission over the Um interface. The supplementary RLP protocol 416 and IS-95 protocol 418 in BS/MSC106 pass the data to relay layer protocol 420 for transmission to relay layer protocol 428 over the L interface.

The PPP protocol 426 then depacketizes the received PPP packets and passes them to the IP protocol 425. IP protocol 425 removes the IP header and routes the packets to UDP protocol 423, which in turn passes the depacketized foreign agent solicitation message to mobile IP protocol 421. If the mobile IP protocol 421 exists in the IWF108, a foreign agent entity resides in the IWF108 and responds with an agent advertisement message that is returned to the mobile IP protocol 409 in the MT2 device 104 on the reverse path.

The mobile IP protocol 409 then sends a mobile node registration message to the foreign agent at the IWF 108. If the mobile node registration message is acceptable to the foreign agent, the mobile node registration message is sent to the home agent entity residing in the TE2 device's home IP network (i.e., the home agent entity containing the static IP address requested by the TE2 device 102).

If the mobile node registration message is acceptable to the home agent, the home agent mechanism generates a mobility binding for the TE2 device 102 using the "care-of" address of the foreign agent mechanism. Mobility, as described in RFC2002, is a routing that takes any IP packets intended for the TE2 device 102, which reach the TE2 device's home network and pass them to a foreign agent that utilizes IP tunneling.

Upon receiving the notification from the home agent that the mobility binding was created, the foreign agent generates an association between the internal IP address in the tunneled packet (i.e., the static IP address requested by the TE2 device 102) and the "phone number" of the MT2 device 104. The term "telephone number" is used herein in its broadest sense to mean the identification number of the MT2 device 104. As used herein, it is desirable to refer to a unique identifier, such as the Mobile Identification Number (MIN), Electronic Serial Number (ESN), etc., of the MT2 device 104 with which the MT2 device 104 registers with the BS/MSC106, as is known in the art. The IWF108 maintains the IP to MIN conversion or IP to ESN conversion.

To perform this mobile node registration, the present invention reroutes IP packets from the RLP protocol 412 to the MT2PPP protocol 415 to ensure that the required data is delivered to the mobile node registration software running at the mobile IP protocol 409 level of the MT2 device protocol stack. It should be understood that the MT2PPP protocol 415 is not a full PPP scheme as described in RFC 1661. In the fig. 4 embodiment, the MT2PPP protocol 415 does not perform any negotiation for the establishment of a protocol or link, but only frames, de-frames, and performs any required character escape code for IP packets sent, received by the MT2 device 104 during the mobile registration state 512, since PPP has already been negotiated between the TE2 device 102 and the IWF108 as described above.

If the mobile node registration, described above and performed during the mobile node registration state 512, fails for some reason, the MT2 device 104 in one embodiment exits the mobile IP protocol 409, UDP protocol 411, IP protocol 413, and PPP protocol 415 and transitions to the off state 516. Possible causes of failure may include rejection of the mobile node registration message by a foreign agent or by a home agent. In other embodiments, the MT2 device 104 may attempt to resynchronize PPP to a dynamic IP address, rather than to a static IP address as requested by the TE2 device.

Otherwise, upon successful mobile node registration in the mobile registration state 512, the MT2 device exits the mobile IP protocol 409, UDP protocol 411, IP protocol 413, and PPP protocol 415, and then transitions to the open state 508. In the open state 508, the MT2 device 104 acts as shown in fig. 2 in the relay model of IS-707.5. Once in the open state 508, data arriving at the RLP protocol 412 in the MT2 device 104 is sent only over the EIA-232 interface between the TE2 device 102 and the MT2 device 104.

The MT2 device remains in the open state 508 until one of 3 situations occurs: ending the call; or the MT2 device 104 converts to a different IWF; or has exceeded the mobility registration lifetime. The call may be ended in a number of ways. For example, the user may press an "END" key (not shown) or the like on the MT2 device 104, thereby consciously ending the data call. Another example is TE2 device 102 or IWF108 unilaterally terminating the PPP session between them. In another embodiment, the data call may be terminated simply by dropping the call due to the poor quality of the wireless link between the MT2 device 104 and the BS/MSC 106. If the call ends in one of the above-described ways, the MT2 device 104 transitions to the off state 516.

In the shutdown state 516, if the mobile IP stack is still in place, the MT2 device 104 performs a housekeeping function required to shutdown the mobile IP stack (mobile IP protocol 409, UDP protocol 411, IP protocol 413, and PPP protocol 415). Additionally, if the network "tap" 417 is still in place, the MT2 device 104 releases the network "tap" 417. Finally, any corresponding user notification message may be displayed (e.g., on a user interface not shown) or otherwise provided to the user to indicate that the mobile IP registration process was unsuccessful. In addition, a more detailed description of what faults occurred and the reason (if known) for that can also be displayed. After any notification has been made and any housekeeping is completed, the MT2 device 104 then transitions to the powered off state 308 (fig. 3).

Alternatively, the MT2 device 104 may transition to another BS/MSC106 while in the open state 508. This situation typically occurs when the MT2 device 104 moves from one geographic location to another location that is outside the original BS/MSC106 service area. If the two BS/MSCs are not served by the same IWF108, an inter-IWF transition occurs. The MT2 device 104 may detect this inter-IWF transition by checking for a change in the IS-95 packet zone ID or the System Identification (SID) or Network Identification (NID) in the serving BS/MSC 106. In either case, the MT2 device 104 will transition to the initial PPP resynchronization state 504.

In the initial PPP resynchronization state 504, the MT2 device 104 initiates PPP resynchronization with the IWF108 by sending the first LCP packet cached at the start of the PPP negotiation as described above. As a reaction to the IWF108, this synchronization invokes the exchange of LCP packets. Upon detecting such an exchange of LCP packets, the MT2 device transitions back to state 502 where it monitors PPP as described above.

Conversely, if the mobile registration lifetime specified in RFC2002 is exceeded during the on state 508, the MT2 device 104 transitions directly back to the mobile registration state 512 to negotiate mobile node registration as described above.

Thus, in the embodiment of fig. 4, only the additional protocol layers (PPP protocol 415, IP protocol 413, UDP protocol 411, and mobile IP protocol 409) are provided in the MT2 device 104, perform mobile node registration in the mobile registration state 512, and close after leaving the mobile registration state 512. All IP traffic during the presence of the above additional protocol layers is initiated and terminated at the MT2 device 104. Conceptually, this causes the IP endpoint of TE2 device 102 to "swap" during mobile node registration, and back to TE2 device 102 once mobile node registration is complete. In this manner, the MT2 device 104 acts as a proxy for the TE2 device 102 during mobile node registration, avoiding the need for the TE2 device 102 to have IP mobility support for itself.

Figure 6 shows a schematic diagram of the various entity protocol stacks of an alternative embodiment of the present invention. The significant difference between fig. 6 and fig. 4 is that there is a similar device relationship between the MT2 device 104 and the TE2 device 102 in the PPP level in the embodiment of fig. 6. Note that PPP is implemented in MT2 device 104_RProtocol 605 functions as PPP for TE2 device 102_RThe protocol 605 terminates its role. Also note that PPP in IWF108_UProtocol 626 functions as PPP for MT2 device 104_UProtocol 626 terminates its role. In contrast to the embodiment of FIG. 4, the PPP is described above_RAnd PPP_UThe link is present in the MT2 device 104 after the mobile node has registered.

The operation of fig. 6 will also be described with reference to the state diagram of fig. 7. Fig. 7 is a state diagram of an alternative embodiment of mobile IP mode 310 of fig. 3. The MT2 device 104 begins monitoring PPP_RState 702. In monitoring PPP_RDuring state 702, the MT2 device 104 initiates PPP_RProtocol 605 and negotiate PPP between the MT2 device 104 and the TE2 device 102_RAnd (4) links. The MT2 device 104 also caches the first LCP packets received from the TE2 device 102 for later PPP resynchronization, as needed.

The MT2 device 104 continues to monitor PPP for TE2 device IPCP configuration requests_RAnd (4) links. Upon detecting the TE2 device IPCP configure request, the MT2 device 104 checks the IP address field. If the requested IP address is dynamic, i.e., all zeros, the MT2 device 104 transitions to the start PPP resynchronization state 704.

In the Start PPP resynchronization State 704, the MT2 device 104 closes PPP_RProtocol 605, will (monitor PPP earlier)_RCached in state 702) the original LCP packet is passed to the IWF108, thereby initiating a PPP link directly between the TE2 device 102 and the IWF 108. This is done to avoid operating PPP on the MT2 device 104 for a simplified IP call_RProtocol 605 and PPP_UOverhead of protocol 615. Because a dynamic address IS requested, the additional PPP layer in the MT2 device 104 IS not necessary, and the normal IS-707.5 relay model of fig. 2 applies.

However, if the TE2 device IPCP configure request contains a static IP address, the MT2 device 104 is in PPP_RLink monitoring PPP_RTransition to negotiated PPP after full negotiation in State 702_UState 706. Once in the negotiated PPP_UIn state 706, the MT2 device 104 initiates the MT2 protocol stack including the Mobile IP protocol 609, UDP protocol 611, IP protocol 613 and PPP_UA number of additional layers including protocols 615. The MT2 device 104 also performs flow control for the TE2 device 102. Furthermore, flow control also refers to preventing TE2 device 102 from sending or receiving any data over the Rm interface.

The MT2 device 104 then negotiates PPP_UProtocol 615 and PPP_UPPP between protocols 626_UAnd (4) links. PPP_UIn link negotiation, the MT2 device 104 is in PPP with the TE2 device 102_RThe same parameters requested during link negotiation. Specifically, negotiating PPP with the IWF108_UThe MT2 device 104 uses the static IP address that the TE2 device 102 requested from the MT2 device 104 during the link.

In PPP_UDuring link negotiation, the MT2 device 104 monitors IPCP packets returned by the IWF 108. If the IPCP configure request containing the static IP address is rejected by the IWF108, the MT2 device 104 transitions to "is mobility mode? State 708.

In "is mobility mode? "state 708, the mobility data item 302 is checked. If the mobility data entry 302 has the value "if any," the MT2 device 104 transitions to the start PPP resynchronization state 704 in preparation for a reduced IP call attempt in the reduced IP mode 306. If the mobility data item 302 has a value of "mobile IP exclusive mode", the MT2 device 104 transitions to the off state 710. The off state 710 is similar in operation to the off state 516 in fig. 5.

IPCP configuration if static IP address is includedIf the request is accepted by the IWF308, the MT2 device 104 transitions to the mobility registration state 712. The system condition upon entering the mobile registration state 712 is that the IP address of the MT2 device 104 appears like the IP address of the IWF108 from the perspective of the TE2 device 102. Also, from the standpoint of the IWF108, the IP address of the MT2 device 104 appears like the IP address of the TE2 device 102. In other words, the MT2 device 104 is in PPP_RProtocol 605 and PPP_U2 IP addresses are stored between the protocols 615. As a result, the MT2 device 104 is in PPP without the need for a corresponding IP address_RProtocol 605 and PPF_UPPP packets are passed between protocols 615.

The mobility registration state 712 is very similar to the mobility registration state 512 in fig. 5 with some notable exceptions. First, the mobility registration packet is from PPP in a mobility registration state 712_UProtocol 615 initially passes up to IP protocol 613 instead of to PPP_RAnd (4) a protocol 605. This differs from the operation of fig. 4 and 5 in that the routing of the mobile registration packets takes place at a certain higher layer of the MT2 protocol stack. Second, no network tap is required in the embodiment of FIG. 6, since PPP is used_UThe protocol 615 serves to terminate the PPP link between the MT2 device 104 and the IWF 108. As a result, all PPP packets exchanged during negotiation with the IWF108 are originated and terminated by the MT2 device 104 itself, rather than the MT2 device 104 needing to intercept PPP negotiation between the TE2 device 102 and the IWF108 as in the fig. 4 and 5 embodiments.

If the mobile node registration is successful in the mobility registration state 712, the MT2 device 104 transitions to the open state 714. The open state 104 is very similar to the open state 508 in fig. 5. The significant difference between the embodiments of fig. 7 and 5 is that PPP is shown in fig. 7_RProtocol 605 and PPP_UThe protocol 615 is in place at all times during the open state 714. As a result, IP packets arriving at the MT2 device over the Um interface are routed to PPP via the RLP protocol 612_UProtocol 615 to PPP_RProtocol 605 to EIA-232 protocol 610, rather than directly to EIA-232 protocol 610. Likewise, all IP packets received by the MT2 device 104 over the Rm interface are routed by the EIA-232 protocol 610 to PPP_RProtocol 605, goTo PPP_UProtocols 615 and RLP protocols 612 instead of directly to RLP protocols 612.

If an inter-IWF transition occurs during the open state 714, the MT2 device 104 transitions to the initiate PPP resynchronization state 709. The initiate PPP resynchronization state 709 operates similarly to the initiate PPP resynchronization state 504. It should be understood, however, that in the initiate PPP resynchronization state 709 only PPP is negotiated_ULinks other than PPP_RAnd (4) links. As a result, PPP_RThe link remains unchanged at all times so that the translation between IWFs is transparent to the TE2 device 102 and therefore does not require cached LCP packets.

If the call is terminated while in the open state 714 (or even any other state in fig. 7), the MT2 device 104 transitions to the closed state 710. The off state 710 is very similar to the off state 516 in fig. 5. But in the off state 710, there is no network tap that needs to be removed. In addition, there are still some PPP instances in negotiation, depending on the timing of the end of the call. In any case, if Mobile IP 609, UDP 611, IP 613, PPP_RProtocol 605 and PPP_UThe protocol 615 is running and the MT2 device 104 turns them off. As with the fig. 5 embodiment, the reason for the call failure may also be displayed in an alternative manner.

Thus, in the embodiment of fig. 6, only the additional protocol layers (downward mobile IP protocol 609, UDP protocol 611, and IP protocol 613) in the MT2 device 104 are obtained to perform mobile node registration in the mobility registration state 712 and are closed after leaving the mobility registration state 712. But PPP during the open state 714_RProtocol 605 and PPP_UThe protocol 615 is still in an intact state. In this manner, the MT2 device 104 acts as a proxy for the TE2 device 102 during mobile node registration, avoiding the need for the TE2 device 102 to IP mobility support for itself.

The above description provides an example of a scenario in which proxy services are provided on behalf of connected terminal devices using IP address translation. In addition to mobile IP registration, there are additional applications to the IP address translation method of the present invention. The IP address transposition method can be used for any proxy service or any 2 network devices needing to share a single IP address. For example, when the TE2 device 102 is in a valid data service call (e.g., a user of the TE2 device 102 dials in remotely to check email), the MT2 device 104 may have an application running that requires sending or receiving IP packets (e.g., a web browser application) using the IP address translation method described above between the MT2 device 104 and the TE2 device 102.

The present invention is unique in that a proxy service technique is provided in a system where only a single IP address is available for both the MT2 device 104 and the TE2 device 102. For example, the network and IS-707.5 relay model implicitly assigns a single IP address to TE2 device 102. No separate provision is made for assigning the second IP address exclusively to the MT2 device 104. Of course, it is currently not possible to obtain more than one IP address for each PPP session. The additional resource overhead in the IWF108 to support multiple PPP for each mobile session makes it unattractive to the service provider.

The fact that only one IP address is assigned to the TE2 device 102 also implies that any other application running on the MT2 device 104, whether proxy or not, always requires an IP address, which must somehow be "shared" with the IP address assigned to the TE2 device 102. One method of performing this IP address translation is mentioned above and illustrated in the flow chart of fig. 8. The method of fig. 8 may be performed by the system described above with reference to fig. 4 and 6.

The method of fig. 8 begins with decision 802, where a determination is made as to whether certain applications running on the MT2 device 104 require an originating IP packet. For example, mobile IP application 409 in fig. 4 or mobile IP application 609 in fig. 6 requires an originating IP packet to perform its proxy function of registering as a mobile IP node. Another example of an application running on the MT2 device 104 that may require originating IP packets would be a web browser. Especially if the MT2 device 104 is a combination computer/telephone ("smart phone"), there will be many other applications that can run on the MT2 device 104 that employ IP packets.

The MT2 device 104 then blocks IP packets from being output from the TE2 device 102 at block 804. Such functionality may be implemented by the MT2 device 104 as described above to provide flow control to the TE2 device 102 (i.e., to prevent the TE2 device 102 from sending or receiving data over its relay layer interface). For example, in the embodiment of FIG. 4, the link between the EIA-232 protocol 408 of the TE2 device and the EIA-232 protocol 410 of the MT2 device is controlled by the flow direction of the MT2 device 104. Software or hardware flow control may be employed. For example, in a certain embodiment, the MT2 device 104 bi-stable triggers one of the pin voltages between the MT2 device 104 and the TE2 device 102.

Through the flow control of the TE2 device 102, the MT2 device 104, and in particular the IP protocol 413, can now become an IP endpoint for further transmitted or received IP packets. Conceptually, this allows IP endpoints to be "transposed" from TE2 device 102 (and not the same as it would otherwise be) to MT2 device 104. Thus, the IP packets that the MT2 device then sends and receives at block 806 assume the IP address originally assigned to the TE2 device 102.

In a first embodiment of the IP address transposition method of the present invention, any IP packets intended for the TE2 device 102 may be ignored by the MT2 device 104 at block 808. This situation occurs as long as the IP packets are made to be ignored by any application running on the MT2 device 104.

Fig. 9A-9B illustrate a second embodiment of the IP address transposition method of the present invention. In this second embodiment, the IP address is conceptually "transposed" between the MT2 device 104 and the TE2 device 102 on a packet-by-packet basis, rather than by flow control of the TE2 device 102. The method of fig. 9A-9B may be performed by the system described above with reference to fig. 4 and 6.

At block 902, the MT2 device checks the port sequence number of the inbound IP packet, which is assigned by a transport layer protocol, such as TCP or UDP, as described above. Thus, even though 2 IP packets may have the same IP destination address, they may still have different port number. Different applications running on the same or different devices may use different port numbers, as is known in the art. Checking the port number of the inbound IP packet in block 902 may include de-framing the PPP packet to directly check the IP packet. For example, inIn the network model shown in FIG. 6, PPP_UThe protocol 615 will unframe the incoming PPP packets output by the IWF 108. The MT2 device 104 will then check the port number of the IP packet. Alternatively, it may simply comprise indexing into an IP packet by a specified number of bits. The length of the PPP header, the IP header, and the port number position within the IP packet are specified explicitly by various standards.

At decision 904, the MT2 device 104 determines whether the IP packet includes a port number for an application running on the MT2 device 104. For example, if the MT2 device 104 runs an internet browser application, the browser application will use a specific port number, perhaps port 200. If the port number of the IP packet is also port 200, the IP packet includes the port number used by the instance application running on the MT2 device 104. But if the port number in the IP packet is some number other than 200, the IP packet will not include the port number used by the instance application running on the MT2 device 104.

If the port number of the IP packet is the port number used by the application on the MT2 device 104, the flow proceeds to block 906 where the MT2 device 104 routes the IP packet to the MT2 application. If, however, the port number of the IP packet is not the port number used by the application on the MT2 device 104, the flow proceeds to block 908 where the MT2 device 104 routes the IP packet to the TE2 device. This may involve re-framing the PPP packet and sending it to TE2 device 102 over the Rm link. In the embodiment of the network model illustrated in fig. 6, PPP would be passed_RProtocol 605 accomplishes this function. In this way, the MT2 device 104 intercepts and processes all IP packets for applications running on the MT2 device 104 while also passing all other IP packets to the TE2 device 102. Thus, the MT2 device 104 will not ignore any IP packets and the TE2 device 102 is not streamed to control.

If the application on the MT2 device 104 determines that originating IP packets are needed as determined by decision block 910 in fig. 9B, the MT2 device application originates IP packets at block 912 using the IP address assigned to the TE2 device 102. In either case, flow returns to block 910 where the MT2 device 104 proceeds to determine if there is a need to originate IP packets. Thus, the MT2 device 104 "shares" the IP address assigned to the TE2 device 102 on a packet-by-packet basis.

The previous description of the preferred embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to the above-described embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without the use of the inventive faculty. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims (2)

1. A method for sharing an Internet Protocol (IP) address between a first networked device and a second networked device, the method comprising the steps of:

checking, in the first networking device, a port number of the received IP packet;

routing, in the first networking device, an IP packet to an application on the first networking device when the port number of the received IP packet corresponds to the application; and

routing the IP packet from the first networking device to the second networking device when the port number of the received IP packet does not correspond to the application.

2. A method for transposing an Internet Protocol (IP) address between a first networked device and a second networked device, the method comprising the steps of:

preventing, in the first networked device, the sent IP packets from originating in the second networked device; and

originating an IP packet from the first networked device, the IP packet including an IP address assigned to the second networked device as an originating address.