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

Abstract

A networked device shares a single IP address with a separate networked device. The networked device examines a port number of a received IP packet. The networked device routes the IP packet to an application on the networked device if the port number of the received IP packet corresponds to the application. Otherwise, the IP packet is routed to the separate networked device. The networked device also originates IP packets including as an origination address an IP address assigned to the separate networked device. Alternately, the IP address may be"shifted"to between the networked device and a separate networked device by blocking transmitted IP packets originating in the separate networked device, and originating IP packets, which include as an origination address an IP address assigned to the separate networked device.

Description

? - ~ A MOBILE TERMINAL AND WIRELESS DEVICE WITH COMMON IP ADDRESS • Field of Invention? ~ The present invention relates to wireless data services. More particularly, the present invention relates to a new and improved method and system for switching the Internet Protocol (IP) endpoints between devices connected to a network. 10 Background of the Invention Work on the Internet, for example, connecting networks of individual local areas (LANs), has quickly become very popular. The infrastructure and protocols associates, commonly known as "Internet" have become well known and widely used. At the heart of the "Internet" is the Internet Protocol (IP) that supports the routing of datagrams between the RED LANs, as is known in the art, and is described additionally in the Request for Comment (reference) 791 entitled, DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION OF THE INTERNET PROTOCOL DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION, dated September 1981.

IP is a protocol oriented towards the datagram that provides several services, including addresses. The IP Protocol encapsulates data in an IP packet for transmission and fixes address information to the packet header. The packet header contains 32-bit addresses, which identify the central sending and receiving computers. Intermediate routers use these addresses to select a path for the packet that through the network goes to its last destination in the intended direction. A basic concept of IP address is that the initial prefixes of the IP address can be used for generalized routing decisions. For example, the first 16 bits of an address can identify QUALCOMM Incorporated, the first 20 bits identify the main office of QUALCOMM, the first 26 bits identify a particular ethernet in that office, and the complete 32 bits identify a particular central computer in that ethernet. As an additional example, each address in the QUALCOMM IP network, can be in the form (in "quadruple dotted notation"): 129.46. xxx xxx, where "xxx" refers to any available integer between • zero and 255. As is evident through this 5-base routing in characteristic IP prefixes, the IP addresses contain geographic information about the location of a particular central computer on the Internet. In other words, when any router on the Internet receives a packet that has an address Destination IP that begins with "129.46" the router directs that packet in a particular address to the QUALCOMM Incorporated network in San Diego, California, USA. In this way, the IP protocol allows datagrams originated in any Internet node in the world that would be routed to any other Internet node in the world, taking into account that the point of origin knows the IP address of the destination point. As mobile computing and mobile Internet access have grown in popularity, the The need to provide mobile data support for mobile terminals such as laptops or handheld computers using the IP protocol. However, as mentioned, the IP addressing scheme, which was used for Internet routing, contains geographic information involved. In other words, if a user wishes to use a fixed IP address to identify his mobile terminal, the IP packets destined for that mobile terminal will not be routed to that mobile terminal when he is far from his local network (for example, the network surrounding his IP address set) in the absence of • some technique to forward IP packets to the terminal mobile. For example, assuming that a user decides to remove the mobile terminal from their local IP network at QUALCOMM Incorporated in San Diego, and take it with him on a trip to Palo Alto, California, and there connects to the IP network of Stanford University still maintaining its fixed IP address, assigned by Qualcomm. Any IP datagram • destined for the mobile terminal will still be routed to the QUALCOMM IP network due to the implicit geographical location information in the fixed IP address of the mobile terminal. Such IP packets will not be delivered to the mobile terminal while away from your local network, unless some mechanism is in place to forward IP packets from the QUALCOMM IP network to the mobile terminal at its current point of Internet connection in the IP network of Stanford University in Palo Alto. In order to meet this need, the 2002 reference, entitled "IP Mobility Support", of October 1996, specifies protocol advances that allow transparent routing of IP datagrams to mobile nodes in the Internet. Using the techniques described in the 2002 reference, each mobile node can always be identified by its local IP address, without taking into account its current point in the connection to the Internet. A mobile terminal can be associated with an "auxiliary" address even though it is located far from its local IP network, thus providing the necessary information forwarding to route IP datagrams to its current point of connection to the Internet. The 2002 reference complies by providing the "auxiliary" address record with a "local agent". This local agent forwards IP datagrams projected to the mobile terminal by using a technique called "IP tunneling". The IP tunnel includes the local agent, which connects a new IP header containing the "auxiliary" address of any IP packet that is received, which has a destination address • corresponding to the local IP address of the mobile terminal. After arriving at the "auxiliary" address, a 5"external agent" in the "auxiliary" address removes the IP tunnel header, and delivers the IP packet to the mobile terminal at its current point of connection to the Internet. • In this way, the techniques of the 2002 reference provide mobile data services for users who wish to relocate their point of connection from the mobile terminal to the Internet, without having to change the IP address of the mobile terminal. This ability has many advantages. First, it allows originating nodes in anywhere on the Internet to send services ^ fc newspapers of "impulse" towards the mobile terminal no matter where it is located. Such services may include stored data or email. In this way the need for the mobile user becomes obvious to "mark" or otherwise contact your local network to retrieve information. Additionally, it allows the mobile terminal to relocate as often as it wishes, without any point of origin having to keep track of where the mobile terminal is currently located. To increase the freedom of movement of the mobile terminal, many mobile users will normally use wireless communication devices, such as cell phones or portable telephones to connect to the Internet. In other words, many mobile users will use wireless communication devices, commonly known as "mobile stations," or MT2 devices, such as the ground-based network access point. As used in the present invention, the "mobile station" or apparatus MT2 will refer to any subscriber station in the public wireless radio network that is intended to be used while still in motion or during stops at non-specific points. Mobile stations and MT2 devices include portable units (for example, portable personal telephones) and units installed in vehicles, as well as wireless local circuit (WLL) portable telephones. Figure 1 illustrates a high-level block diagram of a wireless data communication system, wherein a mobile terminal 102 (apparatus TE2) communicates with an inter-operation function 108 (IWF) by a wireless communication system • including, a wireless communication device 104 (device MT2) and a Base Station Switching Center 5 Mobile 106 (BS / MSC). In Figure 1, the IWF 108 serves as the Internet access point. The IWF 108 is coupled to, and is often located in conjunction with the BS / MSC 106, which may be a conventional wireless base station as is known in the art. The device TE2 102 is coupled to the apparatus MT2 104, which in turn is in wireless communication with the BS / MSC 106 and the IWF 108. There are many protocols that allow data communication between the TE2 102 device and the IWF. 108. For example, Standard IS-707.5, of the Association of the Telecommunications Industry (TIA) / Association • Electronic Industries (EIA) entitled "Data Service Options for Broadband Spectrum Broadcast Systems: Data Package Services" ("Data Service Options for Wideband Spread Spectrum Systems: Packet Data Services "), published in February 1998, defines the requirements for the support of the transmission capacity of the data packet in TIA / EIA 1S-95 Band Spectrum Diffusion Systems Wide, the IS-707.5 standard of which the BS / MSC 106 and the • IWF 108 can be a part. The IS-707.5 standard specifies a service that supports a data packet 5 that can be used for communication between the apparatus TE2, 102 and the IWF 108 via BS / MSC 106. It provides procedures that can be applied to multiple data packet services , including the 2002 reference mobile IP service, as well as a Digital Cellular Data Package (CDPD) described in CDPD-1995, entitled Specification of the Cellular Digital Packet Data System Specification, "Version 1.1," published on January 29, 1995 by the CDPD Forum, Inc.

CDPD is an AMPS (analog) cellular data service, which includes part of its own support for mobility. CDPD differs from Mobile IP in many significant ways. The most notable is that a CDPD modem has an assigned IP address that belongs to the network CDPD. Although a CDPD MODEM may be within the CDPD network, it may not use its IP address outside the CDPD network in the same way that a terminal supported by a mobile IP can use its "local" IP address outside of its "local" network . The IS-707.5 standard also provides the requirements for communication protocols in the links between the device TE2, 102 and the device MT2, 104 (the Rm interface), between the device MT2 104 and the BS / MSC 106 (the Interface Um ), and between the BS / MSC 106 and the IWF 108 (the L interface). Referring now to Figure 2, a protocol diagram is shown, stacked in each entity of the relay model of the IS-707.5 standard. Figure 2, corresponds rigorously to Figure 1.4.2.1-1 of the IS-707.5 standard. To the left of the figure, there is a protocol stack, (it refers to the memory area in which it can be stored, information and removed in a reverse order to that of the entry (on the internet)), (referenced a memory area in which it can be stored, information and removed in a reverse order to that of the entry (in the internet)), shown in conventional vertical format, showing the protocol layers that are in the TE2 device (for example, the mobile terminal, laptop, or pocket computer). The protocol stack, (refers to the memory area in which it can be stored, information and • remove it in the reverse order of the entry (on the internet)) TE2 is illustrated as being logically connected to the protocol stack, (it refers to the area of the memory in which it can be stored, information and removed in a reverse order of the input (on the internet)) of the device MT2 104, at the interface Rm. HE • illustrated the MT2 104 device, logically connected to the protocol stack, (refers to the area of the memory in which it can be stored, information and removed in a reverse order of the input (on the internet)) of BS / 106 MSC, at the Um interface. In turn, the protocol stack, (refers to area of the memory in which it can be stored, information and removed in a reverse order of the input (on the internet)) of the BS / MSC 106 is illustrated logically connected to the protocol stack, (refers to the area of the memory in which it can be stored, Information and remove it in a reverse order of the entry (on the internet)) of the IWF 108 at the interface The following is an example of the operation of Figure 2. An entity 202 of the upper layer of the • protocol, such as an application program running on the TE2 102 device, has the need to send 5 IP packets through the Internet. An application example can be a WEB browser such as a Web Browser (Netscape Navigator), or Microsoft Internet Explorer Microsoft Internet Explorer), or the like. The WEB search requires a Localizer of Universal Resources (URL), such as http://www.qualcomm.com. A protocol of the Field Name System, also in upper layer protocols 202, translates the textual name of the textual central computer www. qualcomm com to a numeric 32-bit IP address. The Protocol of ^ fc Hypertext Transfer (http), also a higher layer protocol 202, constructs a GET message for the URL required, and also specifies that the Protocol Transmission Control (TCP) will be used to send the message and that TCP port 80 is used for HTTP operations. The TCP protocol, also a higher layer protocol 202, opens a connection to the IP address specified by DNS, port 80, and transmits the http GET message. The TCP protocol specifies that the ^^ IP protocol will be used to transport messages. The IP protocol, a network layer protocol 5 204, transmits the TCP packets to the specified IP address. The Point-to-Point Protocol (PPP), a link layer protocol 206 encodes IP / TCP / HTTP packets and transmits them through the Rm interface, • using the EIA-232 standard of layer 10 relay protocol 208 to the EIA-232 compatible port on the MT2 device. The PPP Protocol is described in detail in reference 1661, with the title "The Point-to-Point Protocol (PPP)": The EIA-232 protocol 210 in the MT2 device 104, passes to the PPP packet transmitted to a combination of ^ fc Radio Link Protocol (RLP) 212 and that of the standard IS-95 protocol 214 for transmission to the BS / MSC 106 through the Um interface. The RLP 212 protocol is defined in the IS-707.2 standard, and the IS-20 95 standard protocol is defined in the IS-95 standard mentioned above. A protocol stack, (refers to area of the memory in which it can be stored, information and removed in a reverse order of the complementary relay layer in the BS / MSC 106, on the internet); including a • combination of the RLP protocol 216 and the protocol of the IS-95 standard 218 receives the PPP packets through the Um interface, and passes them to the relay layer protocol MT2 220 for the L interface, to the relay layer protocol of the IWF 228 The relay layer protocol MT2 220 and the relay layer protocol IWF 228 are described in the ^ B ^ ISA-658 standard of TIA / EIA entitled, "Standard Inter- operation of the Data Services Function, for a Digital Broadband Spectrum Broadcasting Cell System". The PPP protocol, 226 in the link layer 227 of the IWF, decodes the preceding PPP packets of the apparatus TE2 102, and serves to terminate the PPP connection between the apparatus TE2 102 and the IWF 108. The decoded packets pass from the PPP protocol 226 to the IP protocol in the layer protocols of the network 224 of the IWF 108 for examination, and additional routing to the address IP specified, using the TE2 102 device in the IP header packet (here, the IP address for www .qualcomm. Com). If some task of the upper layer protocol has to be executed in the IWF 108, such as TCP, it is executed by higher layer protocols 222. • Assuming that the last destination of the IP packets generated by the apparatus TE2 102, is not the IWF 108, 5 the packets are forwarded through the network layer protocols 224, the link layers 227 and the relay layer protocols 228 of lq TWF 108 to the next router (not shown) on the Internet. In this way the IP packets coming from the TE2 device 102, are communicated through the apparatus MT2 104, the BS / MSC 106, and the IWF 108 to their last intended destination on the Internet, in such a way as to provide wireless packet data services for the apparatus TE2 102 according to Standard relay model IS-707.5. As illustrated in Figure 2, the IS-707.5 standard provides the requirements for communication protocols in the links between a TE2 102 device and an IWF 108, including the requirements for interfaces Rm, Um, and L. These requirements and procedures are applicable to support the mobile IP services described in reference 2002. However, the IS-707.5 standard does not provide in principle procedures for establishing mobile IP services. In other words, the IS-707.5 standard provides a structure for supporting mobile IP services, but does not provide procedures for negotiating mobile IP services, or registering the TE2 102 device, with a local agent and an external agent for mobile IP services. These procedures are found in reference 2002.

• Additionally, both the network and the relay models of the IS-707.5 standard, involve assigning a single IP address to the apparatus TE2 102. No separate provision was made to assign a second IP address for the exclusive use of the MT2 device 104. In truth, it is currently not possible to obtain more than one address IP per PPP session. The additional cost of resources in IWF 108 to support multiple PPP sessions per mobile, • makes it unattractive to service providers. This distinction is important when considering that normally some application layer entity must exist in the apparatus TE2 102, to support the Mobile IP. Unfortunately, the most popular operating system software for personal computerization, Microsoft Windows, does not have support for mobile IP, and currently there are no forecasts that it may have such • support. As a result, TE2 devices that run on Microsoft Windows (or one of many other 5-operation systems), do not have the ability to use their "local" IP address when they are not connected to their "local" IP network. This prevents the mobile user from taking advantage of the benefits of mobile IP services such as • "impulse" services and email delivery direct, while away from your "local" IP network. What is needed is a method and system for executing register of the device TE2 with the device MT2, acting as a server for the device TE2, for establish mobile IP support for the TE2 device. More generally, what is needed is a method and a system, to enable two devices connected to the network (for example, MT2 and TE2) to share a single IP address. Invention Summary The present invention is an improved new system and method for switching IP endpoints so that they can be performed as part of a mobile node registration of the server. The method includes, signaling from a terminal apparatus, a need for mobile data services, and initiation into a wireless communication device, mobile node registration of the terminal apparatus in response to the signaling step. The terminal apparatus transmits data in packets and the wireless communication apparatus coupled to the terminal apparatus monitors the packet data for an Internet Protocol address contained in an IP address request. The wireless communication device initiates registration of the mobile node using the IP address if the IP address request is for a static IP address. The wireless communication apparatus prevents the terminal apparatus from sending or receiving packet data when the registration of the mobile node is initiated, and allows the terminal apparatus to send and receive packet data when the registration of the mobile node is completed. As a result, the registration of the mobile node occurs transparently for the terminal apparatus, avoiding the need for the terminal apparatus to have its own mobile IP support.

In another aspect of the present invention, an apparatus connected to the network, (which may be the apparatus of • wireless communication), shares an IP address with a separate device connected to the network (which can be the terminal 5 device). The share action occurs through the device connected to the network that examines a port number of a received IP packet. The device connected to the network routes the IP packet to an application on the device connected to the network, if the port number of the received IP packet, corresponds to the application running on the device connected to the network. On the other hand, the device connected to the network routes the IP packet to a separate device connected to the network, if the port number of the received IP packet does not correspond to the application running on the device connected to the network. Additionally, the apparatus connected to the network originates IP packets that include, as a source address, an IP address assigned to the separate device. connected to the network after determining if the application in the apparatus connected to the network has a need to originate IP packets.

Alternatively, the IP address can be switched between a device connected to the network and a • device connected to the network separately. The apparatus connected to the network switches the IP address of the apparatus 5 connected to the network separately, blocking the transmitted IP packets, originated in the apparatus connected to the separate network, and originating IP packets that include as an origin address an IP address assigned to • device connected to the network separately, if the device connected to the network determines that an application in said first device connected to the network needs to originate IP packets. The device connected to the network can also discard received IP packets to the device connected to the network separately while it is using the IP address of the device connected to the network separately.

Brief Description of the Drawings The characteristics, objects, and advantages of the The present invention will become more apparent from the detailed description that is subsequently made when taken in conjunction with the drawings, wherein the symbols similar to the reference identify the corresponding articles in the present invention. Figure 1 illustrates a high-level block graphic of a wireless data communication system, wherein a terminal apparatus connects to the Internet via a wireless communication device. Figure 2 is a graph of the stacks of the protocol (it refers to the area of the memory in which it can be stored, information and withdrawn in a reverse order of the entry (in the internet)) of the protocol (makes reference to the area of the memory in which it can be stored, information and withdrawn in a reverse order of the protocol entry (in the Internet) in each entity of the IS-707.5 standard of the relay model; Figure 3 is a high level status graph of the operation of the MT2 apparatus of the present invention; Figure 4 is a graph of the stacks of the protocol (refers to the area of the memory in which it can be stored, information and withdrawn in a reverse order of the entry (on the internet)) of the protocol of each entity , in one embodiment of the present invention; • Figure 5 illustrates an expanded state graph of the status mode of the mobile IP 310 of Figure 3. 5 Figure 6 is a graph of the protocol stacks (refers to the area of the memory in which it is stored). can store, information and remove it in a reverse order of the entry (on the internet)) of the ^ protocol of each entity, in a preferred embodiment of the present invention; Figure 7 illustrates an expanded state graph in an alternative mode of the mobile IP mode 310 of Figure 3. Figure 8 is a flow chart illustrating a method for executing IP address switching; ^ fc Figure 9A is a flow chart illustrating an alternative method for executing IP addressing switching in connection with the reception of IP packets. Figure 9B is a flow chart illustrating an alternative method for executing IP addressing switching in connection with the sending of IP packets.

Detailed Description of the Invention • The present invention was developed in order to support a transparent mobility for the 5 users of MT2 devices, enabled for data services. Various embodiments of the present invention are developed to support data services under three different usage models. ^ In the first usage model, of the mobile IP, it is not supported however, data services that use a dynamically assigned IP address are still supported. In this first use model, the Internet Service Provider (ISP) assigns the TE2 device an IP address, to which the TE2 device is currently connected. The first use model does not use mobile IP support, and does not use its "local" IP address. As a result, the TE2 device receives only the data it explicitly requests while it is connected to the ISP, instead of having data forwarded from your local IP network. The second use model is one in which the mobile IP support is providing in the apparatus MT2, as a server in the name of the apparatus TE2. This second model is applicable for mobile users who wish to have mobile IP support, but who do not have a TE2 device that • support the mobile IP. For example, users of TE2 devices, such as laptops that are running the Microsoft Windows operating system, fall into this second usage model. In this second usage model, the TE2 device can use its "local" IP address (for example, the IP address assigned as "permanent" IP through its local network), whether it is connected to its local IP network, or travel through a wireless network enabled by a mobile IP. This second use model provides mobility support for devices that integrate the TE2 device and the MT2 device, such as the so-called "smartphones". The third use model is one in which mobile IP support is provided in the TE2 device. This third use model is applicable to users of TE2 devices that have mobile IP support, and therefore do not need services from a server coming from a MT2 device. The various embodiments of the present invention are developed to meet the requirements of one or more of these three use models.

It will be apparent to anyone skilled in the art that the present invention, as described below, • can be implemented in many different software, firmware and hardware modes in each of the 5 entities illustrated in the figures (apparatus TE2 102, apparatus MT2 104, BS / MSC 106 and IWF 108). The current software code or hardware control used to implement the present invention is not limited to the • present invention. Therefore, the operation and The behavior of the present invention will be described without a specific reference to the current software code, it being understood that a person skilled in the art will have the ability to design a software and control hardware to implement the various modes of the present invention, based on the description thereof. Turning now to Figure 3, a high-level state diagram of the operation of the MT2 apparatus of the present invention is illustrated. In Figure 3, the The apparatus MT2 starts in the closed state 308. In the closed state 308 the MT2 device is not currently in a call, but is waiting for a call to originate. Mobile terminated calls (for example, those where the MT2 device is the start call) are not considered in this state, since it is assumed that the MT2 device has already been assigned an IP address, or has been registered to Mobile IP If the MT2 device 3 has already been registered for mobile IP, it is not in this closed state 308, but rather it is in the mobile IP mode state 310, which will be mentioned in more detail later. • When a packet data call is initiated, from the apparatus TE2, the apparatus MT2 transits from the closed state 308 to the state with mobility 304. In the mobility-capable state 304, the apparatus MT2 verifies the value of the mobility data item 302 to determine whether the support of mobility has capacity (for mobile I-P). In one embodiment, the mobility data item 302 of the mobility data may have one of three values that the mobile user may optionally configure as a desired means, for example, a user interface in the device TE2 or the device MT2. Other modalities may use more or less values, to allow the mobile user to have more or less configuration options. In any case, other modalities do not allow the user to configure the mobility data item 302. In other modalities, there is no • mobility data item 302, although the decision is strictly codified in the control software. The first value of the mobility data item 302 is incapacitated. When the mobility data item 302 is incapacitated, "without capacity", the • MT2 device does not support IP negotiation and registration mobile. As a result, all calls of the packet data originated when the mobility data item 302 has the disability value, use the simple IP mode 306, which will be mentioned more extensively later. 15 The second value is "if available". When the mobility data item 302 is "if available", then the MT2 device will provide mobile IP registration and negotiation unless the infrastructure (BS / MSC 106 and IWF 108) does not support the IP mobile or unless the registration of the mobile node attempted by the MT2 device fails. If the infrastructure does not support the mobile IP, then the call of the packet data becomes a simple IP mode call 306. In other words, the value "if available" for the mobility data item 302, allows the user of the device TE2 and of the device MT2 obtain the advantages of the mobile IP when it is supported by the infrastructure and negotiated successfully, but otherwise, still allows a packet data call without mobile IP support. In a modality in which the mobile user can not change the value of the mobility data item 302, this second value is used. Alternatively, the mobility data item 302 may be set to "if available", or omitted altogether, eliminating the transition between the mobility enabled state 304 and the simple IP mode state 306. The third value is "exclusively". When the mobility data item 302 is "exclusively", then the MT2 device will provide mobile IP registration and negotiation unless the infrastructure (BS / MSC 106 and IWF 108) does not support the mobile IP or unless the registration that attempted the mobile node. However, in contrast to the "if available" value mentioned above, if the infrastructure does not support the mobile IP or the mobile node registration fails, then the MT2 appliance does not complete a simple IP call, but it forces to fail by complete to the attempt of ^ F packet call origin. In other words, the "exclusively" value for the mobility data item 302 prevents any call of the packet data other than a call supported by the mobile IP from the MT2 device. If the mobility data item 302 is "without capacity", or if the value of the data item of mobility 302 is "if available", although mobile IP is not supported by the infrastructure, then the MT2 device will enter the simple IP mode 306 in an attempt for a packet data call. In one mode, the simple IP 306 mode uses the model relay of the conventional IS-707.5 standard, as illustrated to- and described with reference to Figure 2. If the value of the mobility data item 302 is "if available" or "exclusively", the MT2 apparatus, transits from the state with capacity to mobility 304 to the mobile IP mode 310. It is in this mobile IP mode 310, where the device MT2 is committed in the registration of the mobile node with the mobile IP services co or a server in the name of the device TE2, as will be described later. • Returning now to Figure 4, a diagram of the protocol stacks is shown, (it refers to the area of the memory in which it can be stored, information and withdrawn in a reverse order of the entry (on the Internet) ) of the protocol of each entity of one embodiment of the present invention. A significant difference between the diagram of the Figure 4 and that of Figure 2, is that, in Figure 4, there are additional protocol layers in the MT2 apparatus 104, to support the registration of the mobile node of the present invention. These additional protocol layers include PPP protocol 415, protocol IP 413, protocol UDP 411 and mobile IP protocol 409. To the extent that the layers of the protocol of Figure 4 operate the same as those of the Figure 2, these will not be expanded. Preferably the following discussion will focus on the differences between Figure 4 and Figure 2. An example of the operation of Figure 4 is as follows. A higher layer protocol entity 402, such as an application program running on the apparatus TE2 102, needs to send IP packets through the Internet, similar to that of the upper layer protocol entity 202 of the Figure 2. The • application generates a message, using for example, either the TCP or UDP protocols, and the TCP or UDP packet that is encapsulated through the IP 404 protocol using the destination IP address. The protocol of Point-to-Point Protocol (PPP) 406 structures IP packets and transmits them through the Rm interface, using the • EIA-232 408 relay layer protocol to the port compatible EIA-232 in the MT2 device that runs the EIA-232 protocol, 410. However, as is known in the art, to establish communications through a point-to-point link, each end of the PPP link (here, the protocol PPP, TE2, 406 and the IWF protocol PPP 426) must first send the Link Control Protocol packets (LCP) to establish, configure and test the data link connection. After the link has been established through the LCP protocol, PPP, 406 sends Network Control Protocol (NCP) packets to configure network layer protocols (here, the IP 404 TE2 protocol and the IP 425 IWF protocol). After each of the network layer protocols has been configured, datagrams can be sent from each network layer protocol through the link between • they . In one embodiment, the NCP for IP is the IP Control Protocol (IPCP). The IPC is described in detail in reference 1332, entitled "The PPP Internet Protocol Control Protocol" (IPCP), published in May 1992. The IPCP has the responsibility to configure, do possible or not, that both the IP 404 TE2 protocol and the IP 425 IWF protocol run at either end of the point-to-point link. As is known in the art, the IPCP uses configuration requests, which are messages that may include a configuration option for IP address. This part of the option ^ fc configuration of the message that requires configuration, provides a way to negotiate the IP address to be used by the sender of the configuration request (here, apparatus TE2, 102). This allows that the sender of the configuration request indicates what IP address he wants, by specifying an IP address, or request that the partner (here, the IWF 108) provide a dynamic IP address for the sender. If the sender of the configuration request, set the address field to zeros • IP in the IP address configuration option, then the pair can provide a dynamic IP address 5, by sending the option a configuration NAK (negative knowledge), and returning a valid IP address. If, on the other hand, the sender of the configuration request, sets the IP address field in the configuration option of the IP address to a IP address specified, the pair can indicate that the specified IP address is acceptable by sending a configuration ACK for the option. The present invention takes advantage of the IPCP communications between the TE2 102 apparatus and the IWF 108, to determine how and where to act as a server for the apparatus TE2 during the registration of the mobile node. Figure 5 illustrates an expanded state diagram of the mobile IP mode state 310 of Figure 3. When the mobility capable state (Figure 3) determines, that the mobility data item 302 is disabled, transits to the secondary state PPP of monitoring 502. It should be noted that it is possible to transit from any secondary state of Figure 5 to the secondary status of closure 516, if the call. However, to simplify the transition of the terminated call, it is illustrated only from the secondary open state 508 to the secondary closing status 516. In the secondary monitoring state PPP 502, the MT2 apparatus 104 inserts a "spigot" of the network 417 in the protocol stack, of the MT2 device between the couple of the RLP protocol 412 and protocol EIA-232 410. In other words, the PPP packets passing between the EIA-232 protocol 410 and the RLP protocol 412 are monitored and examined by the MT2 apparatus 104. This allows the MT2 device 104 to monitor PPP packets as they pass between the TE2 102 device and the IWF 108. 15 The first packet the LCP is hidden in memory ^ fc by the apparatus MT2 104 for use after using an Inter-IWF connection as will be described below with respect to the start PPP resynchronization state 504. The MT2 apparatus 104 continues to monitor PPP packets that are exchanged between the apparatus TE2 102 and the IWF 108 until an IPCP packet from the apparatus TE2 102 which is detected by the apparatus MT2 104. This IPCP packet is then examined by the apparatus MT2 104, to determine whether requests a static or dynamic IP address and is required in the IP configuration option of the configuration request: If the IP address field contains an IP address that is zero, then the TE2 device is requesting a dynamic address. In such a case, no mobile IP support is required by the apparatus TE2 102, and the apparatus MT2 104 transits to the simple IP mode 306 (Figure 3). On the other hand, the IP address field in the configuration request sent by the apparatus TE2 102, contains a static IP address (eg, non-zero), then the MT2 device 104 transits to the monitoring IPCP state 506. In the monitoring IPCP state 506, the apparatus MT2 104 monitors the IPCP packets that are exchanged between the apparatus TE2 102 and the IWF 108. Specifically, the apparatus MT2 104 examines the IPCP packets to determine whether the request for IP address static made by the TE2 102 device, has been accepted by the IWF 108 with a configuration ACK. If the static IP address request made by the apparatus TE2 102 is denied by the IWF 108, then the apparatus MT2 104 transits to the mobility mode state 514, where it verifies the value of the mobility data item 302. If the value of the mobility data item 302 is "available", then the MT2 device 104 transits to the simple IP mode state 306 (Figure 3), because it is assumed that the user will be satisfied with a simple IP call (for example, an IP address assigned dynamically) if mobile IP support is not available. However, in any case, the value of the mobility data item 302 is "exclusive", then the MT2 device 104 transits to the closed state 516, because it is assumed that the user will not be satisfied with a simple IP call. . If the static IP address request made by the apparatus TE2 102 is accepted by the IWF 108, then the apparatus MT2 104 transits to the state of mobile registration 512 upon completion of the IPCP negotiation. In the mobile registration state 512, the MT2 apparatus 104 initiates the PPP protocol 415, the IP protocol 413, the UDP protocol 411, and the mobile IP protocol 409. The MT2 device 104 then controls the flow to the apparatus TE2 102. As is used in the present invention, the term "flow control" refers to the step of preventing the apparatus TE2 102 from sending or receiving • data through its relay layer interface. In the embodiment of Figure 4, this is the link between the apparatus TE2, protocol EIA-232 408 of the apparatus TE2 and the EIA-232 protocol 410 of the apparatus MT2. By controlling the flow of the apparatus TE2 102, the apparatus MT2 104, and specifically the IP protocol 413 • can now become the IP endpoint for the purpose of mobile node registration. This allows the device MT2 104 to perform the mobile node registration on behalf of the apparatus TE2 102, and to do so transparently for the apparatus TE2 102. In this way, this "switches" the IP endpoint from the device TE2 102, where otherwise it would be, the apparatus MT2 104. The apparatus MT2 104 reads the data items of the Mobile Node Registration (MNR) 510. In one embodiment, this data item is stored in an appropriate non-volatile memory circuit (not shown). This game of data MNR 510 is the data item that is needed to perform the mobile node registration. This data set MNR 510 may include the Security Parameter Index, the authentication key MD5, as described in reference 2002, and the IP address of the local agent. The apparatus MT2 104 then performs the mobile node registration as described in reference 2002 using the static IP address required by the apparatus TE2 102 and the data line MNR 510. The details of the mobile node registration are described in the reference 2002, and therefore will not be described in detail in the present invention. In short, the mobile IP protocol 409 sends an external agent request message to the mobile IP protocol 421 in the IWF 108. This external agent request message is passed to the UDP 411 protocol. The UDP 411 protocol acts, as it is known in the art, as a datagram service, and passes the external agent request message to the IP 413 protocol, where it is packaged according to the 2002 reference with the IP header of any of the transmission addresses or the Multitransmission addresses of "all routers" where it is packaged. The IP 413 protocol then passes the IP packet to the PPP 415 protocol, which packages it into a PPP packet and forwards it to the RLP 412 protocol and the IS-95 414 protocol for transmission through the Um interface. A complementary RLP protocol 416 and protocol of the • IS-95 418 standard in the BS / MSC 106, passes the data to the relay layer protocol 420 for the transmission through 5 of the L interface, to the relay layer protocol 428. The PPP 426 protocol, then unpacks the PPP packets received and passes them to the IP 425 protocol. The IP 425 protocol removes the IP header and routes • the packets to the UDP 423 protocol, which in turn passes the External agent request message unpacked to the mobile IP protocol 421. If the mobile IP protocol 421 is present in the IWF 108, then there is an external agent entity resident in the IWF 108, and it responds with an agent announcement message that follow the reverse path of the mobile IP protocol 409 in the apparatus MT2 104. The mobile IP protocol 409 then sends a mobile node registration message to the external agent through the IWF 108. If the mobile node registration message is acceptable to the external agent, it will forward the registration message of the mobile node to a local agent entity resident in the local IP network of the apparatus TE2 (for example, the one comprising the static IP address required by the apparatus TE2 102). • If the registration message of the mobile node is acceptable to the local agent, then the local agent 5 creates a mobility link for the apparatus TE2 102 using the "Auxiliary" address of the external agent. A mobility link, as described in the 2002 reference, is a routing that carries • any projected IP packets for the TE2 device 102 that arrives on the local network of the TE2 device and forwards them to the external agent using the IP tunnel. Upon receiving notification from the external agent that created the mobility link, the external agent then creates an association between the internal IP address in the packet in the tunnel (for example, the IP address ^ fc static required by the apparatus TE2 102), and the "telephone number" of the apparatus MT2 104. In the present invention the term "telephone number" is used in its broadest sense to represent the number of Identification of the apparatus MT2 104. As used in the present invention, the intention is to refer to the Mobile Identification Number (MIN) of the MT2 device 104, its Electronic Serial Number (ESN), or other unique identifier that the device has registered. MT2 104 with the BS / MSC 106 as is known in the art. The • IWF 108 maintains this IP for the translation of MIN or this IP for the translation of ESN. To perform this mobile node registration, the present invention reroutes IP packets from the RLP protocol 412 to the MT2 PPP protocol 415, to ensure the delivery of the required data to the registration software of the mobile node running at the mobile node level. mobile IP protocol 409 of the protocol stack, of the MT2 device. It should be noted that protocol MT2 PPP 415 is not a total PPP implementation as described in reference 1661. In the modality of Figure 4, protocol MT2 PPP 415 does not perform any negotiation for protocol or link establishment, only ^ fc structure, de-structure, and execute any required character that escapes from IP packets that are sent and received by the apparatus MT2 104 during the state of mobile registration 512, because PPP has already been negotiated between the apparatus TE2 102 and the IWF 108 as described above. In one embodiment if the mobile node registration described before and executed during the registration status of the mobile node 512 fails for any reason, the MT2 apparatus 104 leads the mobile IP protocol 409, the UDP protocol 411, the IP protocol 413 and the protocol PPP 415, and transits to closed state 516. Possible reasons for failure may include that the external agent or the local agent rejects in the registration message of the mobile node. In other embodiments, the MT2 apparatus 104 may attempt to resynchronize PPP with a dynamic IP address, instead of the static IP address required by the device TE2. On the other hand, at the time of the successful registration of the mobile node in the mobile registration state 512, the MT2 device opens the mobile IP protocol 409, the UDP protocol 411, the IP protocol 413 and the PPP protocol 415, and then transits to the open state 508. In open state 508, the apparatus MT2 104 acts in accordance with the relay model of the IS-707.5 standard, as shown in Figure 2. Once in this open state 508, the data arriving in the protocol RLP 412 of the apparatus MT2 104 are sent through the EIA-232 interface between the apparatus TE2 102 and the apparatus MT2 104.

The apparatus MT2 remains in the open state 508 until one of three things occurs: the • call, the MT2 104 device is connected to a different IWF, or the life of the mobile registration has been exceeded. 5 The call can end in many ways. For example, the user can press an "END" key (not shown) or similar on the MT2 104 device, and thus intentionally end the call of • data. Another example is that the TE2 102 device or the IWF 108 unilaterally end the PPP session between them. In another example, the data call can be terminated simply because the radio link between the MT2 device 104 and the BS / MSC 106 is degraded to cause the call to be cut off. If the call ends in one of these ways, the MT2 device 104 transits to the closed state 516. In the closed state 516, the MT2 apparatus 104 executes required verification functions to turn off the mobile IP protocol stack (mobile IP protocol 409, protocol UDP 411, IP protocol 413, and PPP protocol 415) if it is still in place. Additionally, the MT2 apparatus 104 removes the "spigot" from the network 417 if it is still in place. Finally, any appropriate notification message of the user (for example, in a user interface, not shown) or presented in a different way to the user may be displayed to indicate that the IP registration process was unsuccessful. 5 Optionally, a more detailed description of what failure occurred and a cause (if known) can be displayed. After making any notifications and completing any verification cleaning, the apparatus MT2 104 then proceeds to the state of closed 308 (Figure 3). Alternatively, while in the open state 508, the MT2 apparatus 104 may be connected to another BS / MSC 106. Typically, this will occur while the MT2 apparatus 104 moves from a geographic location to another that is outside the service area of the BS / MSC A 106 original. If the two BS / MSCs are served by the same IWF 108, then an Inter-IWF connection occurs. The MT2 104 device can detect this either by examining the ID of the Packet Zone of the IS-20 95 standard, by signaling a change in the System Identification (SID) or of the Network Identification (NID). of the service BS / MSV 106. In any case, the MT2 device will transition to the start PPP resynchronization state 504. • In the start PPP resynchronization state 504, the MT2 apparatus 104 initiates a PPP resynchronization with the IWF 108 when sending the first LCP packet that was hidden in the memory at the beginning of the PPP negotiations, as described above. This invokes an exchange of LCP packets in reaction from the IWF 108. Upon detecting this exchange of LCP packets, the MT2 device then transits back to the monitoring PPP state 502, as described above. If, on the other hand, during the open state 508, the lifetime of the mobile register, as defined in reference 2002, is exceeded, the MT2 apparatus 104 transits directly back to the mobile registration state 512 to renegotiate the mobile node registration, as described above. Thus, in the embodiment of Figure 4, the additional protocol layers in the MT2 apparatus 104 20 (PPP protocol 415, IP protocol 413, UDP protocol 411, and mobile IP protocol 409) are brought only to perform the registration of the mobile node in the mobile registration state 512, and they are closed after leaving the mobile registration status 512. In the MT2 apparatus 104 all the IP traffic is started and terminated, during the time • that these additional protocol layers are up. Conceptually, this "switches" the IP endpoint from the apparatus TE2 102 during the registration of the mobile node, and then returns to the apparatus TE2 102 upon completion of the registration of the mobile node. In this way, the apparatus MT2 104 serves as a server for the apparatus TE2 102 • during the registration of the mobile node, making obvious the The need for the apparatus TE2 102 to have IP mobility support itself. Figure 6 shows a diagram of the stacks of the protocol, of each entity's protocol of an alternative embodiment of the present invention. One difference Significant between Figure 6 and Figure 4 is that in the embodiment of Figure 6, there is a relationship between the MT2 apparatus 104 and the apparatus TE2 102 at the PPP level. It should be noted that the PPPR 605 protocol of the MT2 104 device serves as the conclusion for the PPPR protocol 606 of the apparatus TE2 102. It should also be noted that the PPPu protocol 626 of the IWF 108 serves as the conclusion for the PPPu protocol 615 of the MT2 apparatus 104. In contrast to the embodiment of Figure 4, these PPPR links and PPPu subsist in the apparatus MT2 104 after registration of the mobile node. The operation of Figure 6 will be explained with reference also to the state diagram of Figure 7. Figure 7 is a state diagram of an alternative mode of the Mobile IP mode 310 of Figure 3. The MT2 apparatus 104 starts at the PPPR monitoring status 702. In PPPR monitoring state 702, the apparatus MT2 104 initiates the PPPR protocol 605, and negotiates the PPPR link between the apparatus MT2 104 and the apparatus TE2 102. The apparatus MT2 104 also hidden in the memory , the first LCP packet received from the TE2 102 apparatus for use, if required in a subsequent PPP resynchronization. The apparatus MT2 104 continues to monitor the PPPR link, looking for the IPCP configuration request of the TE2 device. Upon detecting the IPCP configuration request of the apparatus TE2, the apparatus MT2 104 examines the IP address field. If the required IP address is dynamic, that is, it is in zeros, then the device MT2 104 transits to start resynchronization of state PPP 704.

At the start of resynchronization of the PPP state 704, the MT2 apparatus 104 closes the PPPR protocol 605, and forwards the original LCP packet (previously hidden in the memory in the monitoring state of PPPR 702) to the IWF > 108. Initiating in this way, a PPP link directly between the apparatus TE2 102 and the IWF 108. This is done to avoid the envelope headed by running the protocol PPPR 605 and protocol PPPu 615 in the device MT2 104 during a single IP call. Since a request was In the dynamic direction, the extra PPP layers in the MT2 device 104 are not required, and the relay model of the standard IS-707.5 of FIG. 2 is applied. However, if the IPCP configuration request of the device TE2 contains a static IP address , then the apparatus MT2 104 transits to negotiate the state PPPu 706, after the PPPR link has been fully negotiated in the monitoring state of PPPR 702. Once in the negotiation state PPPu 706, the apparatus MT2 104 initiates the additional layers in the protocol stack, (refers to memory area in which it can be stored, information and removed in a reverse order of the entry (on the internet)) MT2, including mobile IP protocol 609, the UDP protocol 611, the IP protocol 613, and the PPPu protocol 615. The apparatus MT2 104 also controls the flow of the apparatus TE2 102. Again, the flow control refers to preventing the device TE2 102 from sending or receiving any data through the interface Rm. The MT2 apparatus 104 then negotiates the PPPu link between the PPPu protocol 615 and the PPPu protocol 626. In the negotiation of the PPPu link, the apparatus MT2 104 uses the same parameters # that were required by the apparatus TE2 102 during negotiation of the PPPR link. Specifically, the static IP address required by the apparatus TE2 102 from the apparatus MT2 104 is used by the apparatus MT2 104 when negotiating the PPPu link with the IWF 108. During the negotiation of the PPPu link the apparatus MT2 104 monitors the IPCP packets returned by the IWF 108. If the IWF 108 rejects the IPCP configuration request containing the static IP address, then the MT2 device 104 transits to the mobility mode state 708. In the mobility mode state 708, the mobility data item 302 is verified. If the value of the mobility data item 302 is "yes available", then the MT2 device 104 transits to the beginning of resynchronization of the PPP state 704 in preparation for an attempt of a single IP call in a simple IP mode 306. If the value of the mobility data item 302 is "exclusively Mobile IP", then the MT2 device 104 transits to the closed state 710. The closed status 710 is similar in operation to the closed state 516 of Figure 5. If the IPCP configuration request containing the static IP address is accepted by the IWF 308, then the MT2 device 104 transits to the mobile registration state 712. The condition of the system upon entering the registration status mobile 712 is such that, from the point of view of the apparatus TE2 102, the IP address of the apparatus MT2 104 appears to be that of the IWF 108. Additionally, from the point of view of the IWF 108, the address of the apparatus MT2 104 appears be the one of the apparatus TE2 102. In other words, the apparatus MT2 104 is maintaining two IP addresses between the PPPR protocol 605 and the PPPu protocol 615. As a result, the MT2 apparatus 104 passes PPP packets between PPPR 605 protocol and PPPu protocol 615 without taking consider the IP addresses.

The state of mobile registration 712 is very similar to the state of mobile registration 512 of Figure 5, with some • significant exceptions. First, in the mobile registration state 712 the mobile registration packets pass from the PPPu protocol 615 to the IP protocol 613 instead of the PPPR 605 protocol. The difference in the operation of Figures 4 and 5 is that the Routing of mobile registration packets occurs • in a top layer in the MT2 protocol stack. In Secondly, in the embodiment of Figure 6, some network spigots are not needed because the PPPu protocol 615 serves to terminate the PPP link between the MT2 device 104 and the IWF 108. As a result, all the PPP packets exchanged during the negotiation with the IWF 108 are originated and terminated with the apparatus MT2 104, instead of the apparatus MT2 104 which needs to "carry out a listening" in the negotiation PPP between the apparatus TE2 102 and the IWF 108, as is the case with respect to the embodiment of Figures 4 and 5.

If the registration of the mobile node succeeds in the state of mobile registration 712, then the apparatus MT2 104 transits to the open state 714. The open state 714 is very similar to the open state 508 of Figure 5.

A significant difference between the embodiment of Figure 7 and Figure 5 is that in Figure 7 the PPPR protocol 605 and PPPu protocol 615 remain in place during the open state 714. As a result, the IP packets arriving at the MT2 apparatus through the Um interface, they are routed through the RLP 612 protocol to the PPPu 615 protocol, and in turn to the PPPR 615 protocol and later to the EIA-232 610 protocol, instead of directly to the EIA-232 610 protocol. , all IP packets received by the MT2 104 device through the Rm interface are routed through the EIA-232 610 protocol to the PPPR 605 protocol, and in turn to the PPPu 615 protocol and RLP 612 protocol, instead of directly to the protocol RLP 612. If an inter-IWF connection occurs during the open state 714, then the MT2 device 104 transits to the PPP 709 resynchronization start state. The 709 state operates similarly to that of the 504 state. ervar that, however, in the PPP 709 resynchronization start state, only the PPP0 link is renegotiated in place of the PPPR link. As a result, the PPPR link remains unchanged by making the transparent inter-IWF connection for the apparatus TE2 102, and therefore, no LCP packets hidden in the memory are required. If the call is terminated, while in the open state 714 (or indeed, in any other state of Figure 7), the apparatus MT2 104 transits to the closed state 710. The closed state 710 is very similar to the state of closed 516 of Figure 5. However, in the closed state 710, there is no spigot of the network that needs to be removed. Additionally, depending on the time the call ends, some PPP cases that are in medium negotiation may remain. In any case, the MT2 apparatus 104 closes the mobile IP protocol 609, the UDP protocol 611, the IP protocol 613, the PPPR protocol 605 and the PPPu protocol 615 if they are running. As in the modality of Figure 5, the reason for failure in the call can be displayed optionally. Therefore, in the embodiment of Figure 6, the additional protocol layers in the MT2 apparatus 104 (under mobile IP protocol 609, UDP protocol 611, and IP protocol 613) are brought only to execute mobile node registration in the mobile registration state 712, and stop after leaving mobile registration status 712. However, the PPPR protocol 605 and PPPu protocol 615 remain intact during open state 714. In this manner, apparatus MT2 104 serves as a server for apparatus TE2 102 during mobile node registration, obviating the need for device TE2 102 have IP mobility support by itself. The above description provides an example of the use of IP address switching to provide server services on behalf of a connected terminal apparatus. There are additional applications of the IP address switching method of the present invention in addition to the Mobile IP registration. The IP address switching method of the present invention can be used for any server service, or for any of the two devices that need to share a single IP address. For example, it can be used between an MT2 device 104 and a device TE2 102 when the device TE2 102 is in an active active data service call (for example, the user of the apparatus TE2 102 is dialing in to verify the electronic mail ), and the MT2 device 104 has an application running, which has the need to send or receive IP packets (for example, an application of • WEB search engine). A unique aspect of the present invention is that it provides a technique for server services in a system, where only a single IP address is available for use of both the MT2 device 104 and the device TE2 102. For example, both the relay models • As network IS-707.5 standard involve assigning a single IP address to the apparatus TE2 102. No provision is made separately for assigning a second IP address for the exclusive use of the apparatus MT2 104. Indeed, it is possible to obtain more than one IP address per PPP session at this time. The additional cost of resources in the IWF 108 to support a multiple PPP per mobile sessions, is unattractive to service providers. The fact that only one IP address is assigned to the TE2 102 device also implies that any other If the application running on the device MT2 104 needs an IP address, whether or not for server services, it must somehow "share" the IP address assigned to the device TE2 102. A method for performing the this IP address and graphically presented in the flow chart of Figure 8. The method of Figure 8 can be performed by the systems described above with reference to Figures 4 and 6. The process of Figure 8 begins in the decision 802, wherein it is determined whether any application running on the apparatus MT2 104 needs to originate IP packets. For example, the application of the mobile IP 409 of Figure 4 or 609 of Figure 6 needs to originate IP packets to perform its functions as a server for mobile IP node registration. Another example of an application running on the MT2 device 104, which may need to originate IP packets, would be a WEB browser. There are many other applications that use IP packet services that may be running on the MT2 device 104, particularly if the MT2 device 104 is a combination of computer / telephone (or "smartphone"). The apparatus MT2 104 then blocks the production of IP packets of the apparatus TE2 102 in block 804. This can be achieved as described above by controlling the flow of the apparatus MT2 104, of the apparatus TE2 102 (for example, preventing the device TE2 102 send or receive data through its relay layer interface). For example, in the embodiment of Figure 4, the link between the EIA-232 protocol 408 of the apparatus TE2 and the EIA-232 protocol 410 of the apparatus MT2, is flow controlled by the apparatus MT2 104. Flow control of the device can be used. software or hardware. For example, in one embodiment, the apparatus MT2 104 tilts one of the voltage pins between the apparatus MT2 104 and the apparatus TE2 102. The flow control of the apparatus TE2 102, the apparatus MT2 104, and specifically the protocol IP 413 can become now the end point for the purpose of additional IP IP packets sent or received. Conceptually, this "switches" the IP endpoint from the apparatus TE2 102, where it would otherwise be, to the apparatus MT2 104. Therefore, in the block 806 the apparatus MT2 subsequently sends and receives IP packets using the address IP originally assigned to the apparatus TE2 102. In this first embodiment - of the switching method the IP address of the present invention, any IP packet destined for the apparatus TE2 102 is discarded by the apparatus MT2 104 in the block 808. This may simply occur because the IP packet is ignored by any application running on the MT2 device 104. [0115] In FIGS. 9A-9B a second embodiment of the IP address switching method of the present invention is illustrated. In this second embodiment, the IP address is conceptually "switched" between the apparatus MT2 104 and the apparatus TE2 102 on a base of pack-per-pack, instead of by controlling the flow of the apparatus TE2 102. The method of Figures 9A-9B can be realized by the systems described above with reference to Figures 4 and 6. In block 902, the MT2 device examines the number port of unlinked IP packets. As mentioned above, the port number is assigned by a transport layer protocol such as a TCP or UDP. Therefore, although two IP packets may have the same IP destination address, they may have different port numbers. As is known in the art, different applications that run on the same device, or on different devices, can use different port numbers. Examining the port number of the unbound IP packet in block 902 can include the breakdown of PPP packets • to directly examine IP packets. directly. For example, in the network model described in Figure 6, the PPPu protocol 615 would deconstruct the PPP packet arriving from the IWF 108. The MT2 apparatus 104 will then examine the port number of the IP packet. Alternatively, you can include the indexing in the IP packet by a predefined number of bits The length of the PPP headers, IP headers, and the location of the port number within the IP packet is well defined according to the different standards. In decision 904, the MT2 apparatus 104 determines whether the IP packet includes a port number that is fc used by an application running on the MT2 device 104. For example, if the MT2 104 device were running in an Internet search engine application, that search engine application would be using a number of port, perhaps port 200. If the port number in the IP packet is also port 200, then the IP packet includes a port number that is used by the example application running on the MT2 104 device. However, if the port number in this IP packet is something other than 200, then the packet would not include a port number that is used by the example application running on the MT2 10 device. If the port number of the IP packet is one that is used by an application in the apparatus MT2 104, then the flow follows the block 906 where the MT2 apparatus 104 routes the IP packet to the application MT2. However, if the port number of the IP packet is one that is not used by an application in the apparatus MT2 104, then the stream follows the block 908 where the apparatus MT2 104 routes the IP packet to the apparatus TE2. This may include restructuring the PPP packet and send it through the link Rm to the device TE2 102. In the mode of the network model described in Figure 6, this would be completed by the PPPR protocol 605. In this way, the MT2 104 device intercepts and processes all the IP packets intended for applications running on the apparatus MT2 104, while the other IP packets still pass to the apparatus TE2 102. Therefore, none of the IP packets are discarded by the apparatus MT2 104, and the apparatus TE2 102 has no control of flow. • If the application in the apparatus MT2 104 needs to originate IP packets, as determined in decision 910 of Figure 9B, then the application of the apparatus MT2 originates IP packets using the IP address assigned to the apparatus TE2 102 in the block 912. In any case, the flow returns to block 910 • where the MT2 104 device continues to determine whether there is a need to originate IP packets. Therefore, the MT2 apparatus 104"shares" the IP address assigned to the apparatus TE2 102 on a packet-per-pack basis. The previous description of the preferred modalities is provided to allow any person The person skilled in the art makes or uses the present invention. The various modifications of these modalities will be apparent to those skilled in the art, and the generic principles defined in the present invention can be applied to other modalities. without the use of the inventive faculty. Therefore, the present invention is not intended to be limited to the modalities shown therein, but is in accordance with the broader scope consistent with the new characteristic principles described therein •

Claims (12)

NOVELTY OF THE INVENTION Having described the present invention, it is considered as novelty, and therefore, the content of the following is claimed as property: CLAIMS

1. - A method for sharing an Internet Protocol (IP) address between a first device in the network and a second device in the network, wherein the method comprises the steps of: examining, in said first device in the network, a port number of a received IP packet, to route, in said first apparatus in the network, said IP packet to an application in said first apparatus in the network, if said port number of said received IP packet corresponds to said application; and routing, from said first apparatus in the network, said IP packet to said second apparatus in the network, if said port number of said received IP packet does not correspond to said application.

2.- The method according to the claim

1, further comprising, the step of originating IP packets from said first apparatus in the network, said IP packets including as an address of

• source an IP address assigned to said second packet in the network.

3. The method according to claim 2, further comprising the step of determining, in said first device in the network, if an application in said first device in the network needs to send

• IP packets.

4. A method for switching an Internet Protocol (IP) address between a first device in the network and a second device in the network, wherein the method comprises the steps of: blocking, in said first device in the network, 15 transmitted IP packets originated in said second device in the network; and originating IP packets from said first device in the network, said IP packets including a source address, an IP address assigned to said second device in the network.

5. The method according to claim 4, further comprising the step of determining, in said first device in the network, if an application in said first device in the network, has the need to send or receive IP packets.

6. The method according to claim 5, further comprising the step of discarding said first device in the network, received IP packets addressed to said second device in the network. 1 . - An apparatus in the network comprising: means for examining a port number of a

• received IP packet; Means for routing said IP packet to an application in said apparatus in the network, if said port number of said received IP packet corresponds to said application; and means for routing said IP packet to a device in the separate network, if said port number of said received IP packet does not correspond to said application.

8. The apparatus in the network according to claim 7, further comprising means 20 for originating IP packets from said apparatus in the network, including said packets as a source address, an IP address assigned to said device in the network separated .

9. - The apparatus in the network according to claim 8, further comprising means for determining whether an application in said apparatus in the network has the need to originate IP packets.

10. An apparatus in the network comprising: means for blocking transmitted IP packets, originated in an apparatus in the separate network; and means for originating IP packets from said apparatus in the network, including said IP packets,

10 as a source address, an IP address assigned to said apparatus in the separate network.

11. The apparatus in the network according to claim 10, further comprising means for determining whether an application in said first

15 device in the network has the need to originate

^ fc IP packets.

12. The apparatus in the network according to claim 1, further comprising means for discarding, in said apparatus in the network, received IP packets 20 addressed to said apparatus in the network separately.