EP1733590A1 - Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes - Google Patents

Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes

Info

Publication number
EP1733590A1
EP1733590A1 EP05707999A EP05707999A EP1733590A1 EP 1733590 A1 EP1733590 A1 EP 1733590A1 EP 05707999 A EP05707999 A EP 05707999A EP 05707999 A EP05707999 A EP 05707999A EP 1733590 A1 EP1733590 A1 EP 1733590A1
Authority
EP
European Patent Office
Prior art keywords
server
client
service module
application
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05707999A
Other languages
German (de)
English (en)
Inventor
Davide Lenzarini
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EMILIO ANTONIO CASAGRANDE
Original Assignee
Forward Information Technologies SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from PCT/EP2004/050111 external-priority patent/WO2005076649A1/fr
Application filed by Forward Information Technologies SA filed Critical Forward Information Technologies SA
Priority to EP05707999A priority Critical patent/EP1733590A1/fr
Publication of EP1733590A1 publication Critical patent/EP1733590A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/14—Reselecting a network or an air interface
    • H04W36/144—Reselecting a network or an air interface over a different radio air interface technology

Definitions

  • This invention relates to communication network access technologies and, more particularly, to a method and system for providing a seamless handover between heterogeneous networks, i.e. a transparent and automatic/semi-automatic switching between different network access technologies without interrupting active network applications or sessions.
  • Wi-Fi rWlreless Fidelity for 802.11 network GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System), EDGE (Enhanced Data-Rates for GSM Evolution), 1XRTT (Radio Transmission Technology), CDMA2000 (Code Division Multiple Access), Bluetooth, etc.) are beginning to change our concept of Internet access from “static” or “nomadic” to “mobile”: nowadays the possibility of connecting to the Internet is no longer limited to a few network access points (e.g. at home, office, school or university) since it is possible to have network availability wherever the user is.
  • GPRS General Packet Radio Service
  • UMTS Universal Mobile Telecommunications System
  • EDGE Enhanced Data-Rates for GSM Evolution
  • 1XRTT Radio Transmission Technology
  • CDMA2000 Code Division Multiple Access
  • Bluetooth etc.
  • Ubiquitous access availability is important but the underlying concept is to provide reliable and continuous Internet access during the mobility of people nowadays, i.e. a seamless handover between difFerent network access technologies. This is important since not all network technologies are suited to cover similar need as range, access speed, etc. Therefore, network technologies as e.g. GPRS based on GSM (Global System for Mobile Communications), UMTS, WLAN (Wireless Local Area Network) or Bluetooth differ greatly in their characteristics and availability.
  • GSM Global System for Mobile Communications
  • UMTS Universal Mobile Communications
  • WLAN Wireless Local Area Network
  • IP Internet Protocol
  • OSI Open Systems Interconnection
  • ISO International Organization for Standardization
  • the core of this standard is the OSI Reference Model, a set of seven layers that define the different stages that data must go through to travel from one device to another over a network.
  • OSI Reference Model a set of seven layers that define the different stages that data must go through to travel from one device to another over a network.
  • FIG 1 an overall scheme for the standard OSI-7 Layers Protocol Stack is shown.
  • the OSI standard is the only internationally accepted framework of standards for communication between different systems made by different vendors.
  • the OSI layers are: Physical Layer (L1), which corresponds to the physical network interface, deals with the physical means of transmitting data over communication lines (referring in a network environment to various Network Interface Cards).
  • each node of a network for example, with a packet-switched interface has an unambiguous network address, these network addresses being called a Data Link Control (DLC) address or a Media Access Control (MAC) address.
  • DLC Data Link Control
  • MAC Media Access Control
  • the DLC addresses are usually called MAC addresses.
  • an address must fulfill at least the OSI reference model.
  • a DLC address, or respectively a MAC address is a hardware address that identifies the node or respectively the physical network interface unambiguously in the network.
  • a circuit-switched interface has no such DLC or MAC address, i.e. thus also no corresponding identification DLCI (DLC Identifier).
  • Examples of protocols using circuit-switched interfaces are inter alia PPP (Point to Point Protocol), SLIP (Serial Line Internet Protocol) or GPRS (Generalized Packet Radio Service).
  • Basic data units of L1 are "Bits”.
  • Data link Layer (L2) which is concerned with procedures and protocols for operating the communication lines.
  • Basic data units of L2 are "Frames”.
  • Network Layer (L3) which provides switching and routing technologies, creating logical paths for transmitting data from node to node. This information may include network or Internet protocol addresses for communication nodes.
  • L3 does not ensure reliability and its basic data units are "Packets”.
  • Transport Layer (L4) which defines the rules for information exchange, e.g. information about various network protocols. L4 ensures that the data is transmitted reliably between the communicating systems, it disassembles and re-assembles data into smaller units for the Network layer. Basic data units of L4 are "Segments”. Session Layer (L5), which negotiates communication settings, establishes, maintains and ends communications between the two communicating systems. It synchronizes operations and coordinates rules for communicating. Presentation Layer (L6), which takes the data provided by L7 and converts it into a standard format that the other layers can understand. Basic data units are of L6 are "Messages”. Application Layer (L7), which supports application and end-user processes.
  • Protocol data units Each PDU has a specific format that implements the features and requirements of the protocol.
  • the communication between layers higher than layer one is logical; the only hardware connection is at the physical layer. Thus, in order for a protocol to communicate, it must pass down its PDU to the next lower layer for transmission.
  • a PDU is a complete message that implements the protocol at that layer.
  • the layer N protocol data unit (PDU) is called the layer N-1 service data unit (SDU).
  • SDU service data unit
  • IP Internet Protocol
  • the source and the destination must have an IP address unique in Internet in order to be reached, something like the telephone number in the telephony world.
  • IP Internet Protocol
  • the destination address of the data packets is a mobile node this means that a new IP network address must be assigned with each change of network location, which makes transparent mobile accesses impossible.
  • the Mobile IP provides for registering the care-of address with a Home Agent.
  • the Home Agent is normally a fixed network node, which administers the two addresses of the mobile node (home address and care-of address) and reroutes or routes the corresponding data packets: it sends datagrams destined for the mobile node through an IP tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node.
  • the Mobile IP of the IETF does not solve all the mobility problems: if, for instance, a user would like to switch between two different network interfaces while an IP application is running, the IP connection is interrupted at the moment when he leaves the old network link. This connection is interrupted at least until the new location, i.e. the new care-of address, is known and it has been registered at the so-called Home Agent. If the interruption time for the change exceeds the time-out delays specified e.g. in the TCP (Transfer Control Protocol), the IP connection is of course interrupted anyway. Even when the interruption time lies within the time-out delays specified e.g. in the TCP, however, the IP applications are not able to maintain the connection if a physical network interface is not permanently available.
  • TCP Transfer Control Protocol
  • WO 02/103978 A2 provides a method and a system to avoid the interruption of service in case of network connection switch with a mechanism operating at layer 3 (Network layer) of the OSI-7 Layers Protocol Stack.
  • the reference numeral 10 refers to the mobile device
  • 11 is the application layer of the IP applications
  • 12 refers to the TCP layer.
  • the solution of WO 02/103978 A2 is based on the three main layers or respectively main modules 131 to 134 which are designated jointly as mobile module by the reference numeral 13.
  • the first layer consists of a mobile IP module 131 and/or an IPSec module 132.
  • the second layer is the virtual network interface 133 of the solution and the third layer is an interface administration module 134 to handle the physical network interfaces 14 - 17.
  • reference numerals 21 to 24 accordingly stand for the various heterogeneous networks and 30 designates the usual, worldwide IP backbone network.
  • the Virtual IP Network Interface (133 in Figure 2) and the Interface Administration Module (134 in Figure 2) make transparent to the Client applications (11-12 in Figure 2) the care-of IP address changing.
  • the main drawback of WO 02/103978 A2 is that, operating at layer 3, the implementation requires a great deal of low-level work for each supported operating system. This vast amount of work reduces the flexibility of this solution in case of variation in wireless networks standards or in, case of introduction of new wireless networks.
  • WO 02/103978 A2 is based on the concepts of Mobile IP, and it solves its problem of IP applications restart in case of a network connection switch. Consequently all the coordination issues between the mobile node and the home agent have to be considered and implemented by this patent. Furthermore WO 02/103978 A2 requires that the Virtual IP Network Interface be under a custom Mobile IP and/or IPSec module (131-132 in Figure 2) that provides Mobile IP and security features (authenticity of the interlocutors, confidentiality of the data exchanged and hashing systems to check whether the data exchanged have been modified during the transport by an unauthorized third party).
  • NAA Network Access Arbitrator
  • the NAA 60 connects the layer 2 (Data Link layer) of the available NICs 62, and it reroutes the data packets from the primary NIC 62 to the corresponding MAC address of a further network interface (secondary NIC) 62.
  • the NAA 60 provides a virtual adapter driver, and it requires that at least one physical interface with a MAC address must be permanently available.
  • the major drawback of the Nortel invention is that it is sensitive to the definition of the network interface hardware-related address.
  • circuit-switched interfaces GPRS, PPP (Point-to-Point Protocol), SLIP (Serial Line Internet Protocol)
  • GPRS Point-to-Point Protocol
  • SLIP Serial Line Internet Protocol
  • EP 1 089495 A2 has its origin in being based on the concepts of Mobile IP.
  • EP 1 089495 A2 solves the problem of IP applications restart in case of network connection switch, but consequently, all the coordination issues between the mobile node and the home agent have to be considered and implemented by this solution. Additionally, this solution does not take care of how the network connection is made which can be problematic for many applications.
  • the solution of EP 1 089495 A2 is limited in its architectural features by Mobile IP concepts, on which it's based.
  • EP 0 998 094 A2 is based on the concepts of Mobile IP to solve the problem of IP applications restart in case of network connection switch. Consequently all the coordination issues between the mobile node and the home agent have to be considered and implemented by this solution. Like the solution of WO 02/103978 A2 and EP 1 089495 A2, additionally, the solution of EP 0 998 094 A2 is limited in its architectural features by Mobile IP concepts, on which it's based.
  • WO 03/065682 A1 provides the seamless handover working at the lowest three OSI layers (Physical, Data Link and Network).
  • the routing, including detection of available networks, address configuration and handover is performed by a Routing Manager object (RM).
  • the Routing Manager object communicates with the bearer objects handling the wireless network interfaces.
  • WO 03/065682 A1 makes use of an IP-IP tunnel to provide the routing mechanism, so it makes use of the packet encapsulation.
  • IP_CLIENT the home address in the Mobile IP terminology
  • IP_BEARER the changing mobile device IP address assigned by the wireless connectivity bearer
  • the mentioned document WO 03/065654 A1 is very similar to the WO 03/065682 A1 and share with it the above described features and drawbacks. It also introduces the possibility that an application, modifying its source code, could access, in a cross-layering way, some low level information. For this reason the MWAL (Multi-Standard Wireless Adaptation Layer) provides an Application Programmers' Interface. The communication between the application and the MWAL daemon is made by using a couple of local socket (one for the commands generated by the application and one for the events detected by the MWAL daemon).
  • the mentioned document WO 02/43348 A1 provides the seamless handover by using an adapted Session Layer with a security sub-layer (Session Mobility).
  • This adapted Session Layer has to intercept and to manage all the TCP/UDP traffic produced by the client and server applications in order to grant the seamless handover (see Figure 35). Furthermore, in order to work properly, it has to be implemented in a platform specific way and this hinder and reduce the platform portability. Finally, the adapted Session Layers, interacting via a common session protocol, must be available on the same devices that are running the client or the server application and not on different devices. This Session Mobility gives the possibility to handle the security at Session Layer, making possible to provide VPN solutions to enforce strong end-to-end security on an application-to-application level but its major drawback is that it lacks in architectural flexibility, requiring the adapted Session Layer to be installed in any devices involved in the communication.
  • this object is achieved through the invention in that a mobile device (10) is moved between different topological network locations (30/31/32/33) and transmits and/or receives data by means of different network access technologies without the data transfer between a Client IP application (11), running on the mobile device (10), and a Server IP application (21) being interrupted, in that the Client IP application (11) of the mobile device (10) makes a request with first data units to a client-service module (12), in that the client- service module (12) creates second data units based on the received first data units and makes a request to a server-service module (22) with the second data units, in that the server-service module (22) creates third data units based on the received second data units and makes a request to the Server IP application (21) with the third data units to handle the data exchange between the Client IP application (11) and the Server IP application (21).
  • the Client IP application (11) of the mobile device (10) makes the request with first data units to the client-service module (12) by means of a first socket.
  • the client-service module (12) makes the request to the server-service module (22) with the second data units by means of a second socket.
  • the server-service module (22) makes the request to the Server IP application (21) with the third data units by means of a third socket.
  • the socket used is connection-oriented or connectionless.
  • the Server IP application (21) makes a reply with fourth data units to the server-service module (22).
  • the server-service module (22) creates fifth data units based on the received fourth data units and makes a reply to the client-service module (12) with the fifth data units.
  • the client-service module (12) creates sixth data units based on the received fifth data units and makes a reply to the Client IP application (11 ) with the fifth data units.
  • a Server IP application (21) wants to use a service provided by a Client IP application (11)
  • the following steps are performed: the Server IP application (21) makes a request with seventh data units to the server-service module (22), the server-service module (22) creates eighth data units based on the received seventh data units and makes a request to the client-service module (12) with the eighth data units, the client- service module (12) creates ninth data units based on the received eighth data units and makes a request to the Client IP application (11 ) with the ninth data units.
  • the Server IP application (21 ) makes the request with seventh data units to the server-service module (22) by means of a fourth socket.
  • the server-service module (22) makes the request to the client-service module (12) with the eighth data units by means of a fifth socket.
  • the client-service module (12) makes the request to the Client IP application (11 ) with the ninth data units by means of a sixth socket.
  • the Client IP application (11) of the mobile device (10) makes a reply with tenth data units to the client-service module (12).
  • the client-service module (12) creates eleventh data units based on the received tenth data units and makes a reply to the server-service module (22) with the eleventh data units.
  • the server-service module (22) creates twelfth data units based on the received eleventh data units and makes a reply to the Server IP application (21) with the twelfth data units.
  • the client-service module (12) if it is installed on the same mobile device (10) running the Client IP application (11), it provides at least a server application emulation interface comprising sockets and server sockets used to exchange data with the Client IP application (11 ) and bound to the loopback address used to communicate with the Client IP application (11), and a client application emulation interface comprising sockets and server sockets used to exchange data with the server-service module (22) and bound to the IP address provided by the physical interface currently selected by the client-service module (12).
  • a server application emulation interface comprising sockets and server sockets used to exchange data with the Client IP application (11 ) and bound to the loopback address used to communicate with the Client IP application (11)
  • a client application emulation interface comprising sockets and server sockets used to exchange data with the server-service module (22) and bound to the IP address provided by the physical interface currently selected by the client-service module (12).
  • the client-service module (12) is installed on any additional mobile device on the same local area network as the Client IP application mobile device (10), it provides at least a server application emulation interface comprising sockets and server sockets used to exchange data with the Client IP application (11) and bound to the IP address provided by a first physical interface used to communicate with the Client IP application (11 ), and a client application emulation interface comprising sockets and server sockets used to exchange data with the server-service module (22) and bound to the IP address provided by a second physical interface currently selected by the client- service module (12).
  • a server application emulation interface comprising sockets and server sockets used to exchange data with the Client IP application (11) and bound to the IP address provided by a first physical interface used to communicate with the Client IP application (11 )
  • a client application emulation interface comprising sockets and server sockets used to exchange data with the server-service module (22) and bound to the IP address provided by a second physical interface currently selected by the client- service module (12).
  • server-service module (22) provides at least a server application emulation interface comprising sockets and server sockets used to exchange data with the client-service module (12) and a client application emulation interface comprising sockets and server sockets used to exchange data with the Server IP application (21).
  • the server-service module (22) is installed on the same device (20) running the Server IP application (21) or on a different device of the same network as the device (20) running the Server IP application (21 ) or on any Internet node.
  • a plurality of Server IP applications (21) resident on one or more devices is handled by the same server-service module (22).
  • a plurality of Client IP applications (11 ) resident on one or more mobile devices is handled by the same client-service module (12).
  • the client-service module (12) is connected simultaneously to a plurality of server-service modules (22).
  • a plurality of client-service modules (12) is connected simultaneously to a single server-service module (22).
  • the Server IP application (21 ) provides a set of server service server sockets listening on ports known by the Client IP application (11) and by the client-service module (12) and by the server-service module (22).
  • the client-service module (12) provides a set of server service emulator server sockets listening on the same ports as the Server IP application (21) services and creates, for each service request received from the Client IP application (11 ), a client request emulation socket with the server-service module (22).
  • the server-service module (22) provides a set of server service emulator server sockets listening on a set of ports known by the client-service module (12) and creates, for each service request received from the client-service module (12), a client request emulation socket with the Server IP application (21), on the port of the service that the Client IP application (11 ) wants to use.
  • the Client IP application (11 ) provides a set of client service server sockets listening on ports known by the Server IP application (21) and by the client-service module (12) and by the server-service module (22), the server-service module (22) provides a set of client service emulator server sockets listening on the same ports as the Client IP application (11) services and creates, for each service request received from the Server IP application (21), a server request emulation socket with the client-service module (12) and the client-service module (12) provides a set of client service emulator server sockets listening on a set of ports known by the server-service module (22) and creates, for each service request received from the server- service module (22), a server request emulation socket with the Client IP application (11), on the port of the service that the Server IP application (21) wants to use.
  • a plurality of client-service modules (12) of two or more mobile devices, providing client service emulator server sockets on the same ports, is connected to the same server-service module (22) and the , client application emulation interface sockets of the server-service module (22) are bound to different Virtual IP addresses created and/or allocated by it.
  • the server-service module (22) provides at least one control server socket listening on a port known by the client-service module (12).
  • the client-service module (12) to exchange data with the server-service module (22), creates at least one control socket with the server-service module (22).
  • the client-service module (12) periodically checks the mobile device, in which it is installed, for available and configurable physical network interfaces and creates a lookup table with the available and configurable ones.
  • the data transfer between the Client IP application (11 ) and the Server IP application (21 ) is suspended but, in order to provide the seamless handover, kept up until the client-service module (12) has obtained a new IP address using the lookup table and has established a new network connection with the server-service module (22).
  • the data transfer between the Client IP application (11 ) and the Server IP application (21 ) is resumed after that the client-service module (12) and the server-service module (22) have completed the handshaking for the switching procedure from the old IP address to the new one and, in case of a sudden IP transition, after that the client-service module (12) and the server-service module (22) have resent the data not received by the other end.
  • the client-service module (12) automatically changes and updates the physical network interface currently used to access the server-service module (22) on the basis of information retrieved from the lookup table.
  • the criteria for the automatic change and/or update of the physical network interface currently used by the client-service module (12) to access the server-service module (22) are defined by the user.
  • a change or an update of the physical network interface currently used by the client-service module (12) to access the server-service module (22) is initiated by the user.
  • the client-service module (12) and/or the server-service module (22) are OSI Layer 7 applications and are created as platform independent applications.
  • the client-service module (12) and/or the server-service module (22) are at least in part composed by Java modules.
  • the data transfer is realized by means of IEEE 802.11 and/or IEEE 802.16 and/or GPRS and/or EDGE and/or UMTS and/or CDMA2000 and/or Bluetooth and/or ZigBee and/or PSTN and/or ADSL and/or Ethernet and/or Token Ring and/or FDDI.
  • the movement between different topological network locations while transmitting and/or receiving data by means of different network access technologies can, for instance, comprise a change of the physical network interface and/or a change among different networks technologies, such as e.g. Ethernet, Bluetooth, mobile radio networks (GSM, EDGE, GPRS, CDMA200, UMTS, etc.) or WLAN (Wireless Local Area Network), or also a topological location change within the same network technology, for example a device linked to an Ethernet network that migrates to another Ethernet network or a device linked to a Wi-Fi HotSpot that migrates to another Wi-Fi HotSpot.
  • networks technologies such as e.g. Ethernet, Bluetooth, mobile radio networks (GSM, EDGE, GPRS, CDMA200, UMTS, etc.) or WLAN (Wireless Local Area Network)
  • the present invention also relates to a system and a computer program product for carrying out the method.
  • This invention provides the seamless handover using a completely different approach compared with the solutions of the prior art mentioned above. It does not modify any OSI protocol stack layer and it does not introduce any sub-layer (see Figures 33,34,35,36).
  • the seamless handover is obtained by a pair of applications (OSI Layer 7), which deceive the Client and the Server applications letting them believe that they are running on the same device, or on different devices belonging to the same network.
  • the Client and the Server applications do not realize that they are communicating via the Internet.
  • This invention solves the problem of the IP address switch by introducing two applications collectively acting as a middleware: the CNAPT (Client Network Address and Port Translator) and the SNAPT (Server Network Address and Port Translator).
  • the CNAPT is an application that can be installed on the same device as the Client application or in a different device in the same mobile network (e.g. a team of consultants, maintenance workers, auditors that require mobility while working together; in this case the CNAPT can be installed in only one of the mobile devices of the mobile network and all the team can share the seamless handover provided by it).
  • the SNAPT is an application that can be installed in the same device as the Server application or in a different device of the same network or in any Internet server (on a corporate front-end server, on the home PC or in any Internet node or router).
  • This feature is particularly important because provides a way to eliminate the scalability problem that affects each of the solutions mentioned in the prior art.
  • This invention provides, in fact also, the possibility to each user to manage its mobility by itself by installing the SNAPT on any Internet node (e.g. on the home PC if directly connected to the Internet). This is a completely new approach: the mobility handling can be distributed and not only centralized as in the prior art.
  • This invention provides a seamless handover solution using a pair of applications which re-route data without any modification of the OSI protocol stack and without any modification of the Client and Server applications source code.
  • the Client application must only be set to consider the CNAPT as its Server application (e.g. its TCP/UDP segments have to be addressed to the CNAPT IP address and not to the Server application IP address); this can be done statically by modifying its configuration file (if present) or dynamically at run time through its GUI (if provided).
  • the Client application data (payload) arrives to the CNAPT, e.g. inside a TCP/UDP segment, and then the CNAPT forwards only the payload e.g.
  • the SNAPT forwards the payload received by the CNAPT, e.g. in a new TCP/UDP segment, to the Server application making an address and port translation (see Figure 33).
  • the Server application receives the TCP/UDP segment sent by the SNAPT considering it as coming from the Client application.
  • the data sent by the Server application follow a mirror path of the Client application data.
  • the address and port translations only require the modification of the transport header (TH) and the network header (NH).
  • This invention requires two additional sockets for each Client/Server socket.
  • the Client/Server socket is replaced at application layer by a Client application/CNAPT socket, a
  • the Client and the Server applications interaction only suffers a temporary reduction of the quantity of data transmitted per unit of time (throughput) and a delay in the replies proportional to the length of the IP transition phase. No one byte is lost or corrupted during the IP transition phase.
  • this invention has many further advantages compared to the methods and systems of prior art: (1 ) It does not have to take care of Mobile IP concepts and implementation; i.e. it works in a transparent way over Mobile IP (v4 or v6) exactly as it works over IPv4 or IPv6. (2) It can use all the widespread commercial products operating at session (L5), transport (L4) or network (L3) or lower level (L1 , L2) to manage the security and to provide all the security features. Particularly, it does not require the implementation of any custom security feature: it can work in a transparent way over IPSec (IP Security by IETF (Internet Engineering Task Force)), L2TP (Layer Two Tunnelling Protocol) or other VPN (Virtual Private Network) protocols.
  • IP Security IP Security by IETF (Internet Engineering Task Force)
  • L2TP Layer Two Tunnelling Protocol
  • VPN Virtual Private Network
  • Figure 1 shows a block diagram illustrating schematically the OSI-7 Layers Protocol Stack as defined in the prior art.
  • Figure 2 shows a block diagram illustrating schematically the architecture of WO 02/103978 A2 of the prior art.
  • Figure 3 shows a block diagram illustrating schematically the architecture of EP 1089495 A2 of the prior art.
  • Figure 4 shows a block diagram illustrating schematically the architecture of EP 0998094 A2 of the prior art.
  • Figure 5 shows a block diagram illustrating schematically a Client/Server application using Internet to exchange data.
  • Figure 6 shows a block diagram illustrating schematically the Client application using a local network connection and the Internet to reach its Server application.
  • Figure 7 shows a block diagram illustrating schematically the Client application sending a request of service A to its appropriate Server application.
  • Figure 8 shows a block diagram illustrating schematically the CNAPT module according to the invention.
  • Figure 9 shows a block diagram illustrating schematically the CNAPT and the Client application installed on different devices directly linked to form a PAN (Personal Area Network).
  • PAN Personal Area Network
  • Figure 10 shows a block diagram illustrating schematically the SNAPT module according to the invention.
  • Figure 11 shows a block diagram illustrating schematically an embodiment according to the invention, the "Basic configuration”.
  • Figure 12 shows a block diagram illustrating schematically an embodiment variant according to the invention, the "Multi-Site configuration”.
  • Figure 13 shows a block diagram illustrating schematically an embodiment variant according to the invention, the "Client PAN configuration”.
  • Figure 14 shows a block diagram illustrating schematically an embodiment variant according to the invention, the "Multi-Server LAN configuration”.
  • Figure 15 shows a block diagram illustrating schematically an embodiment variant according to the invention, the "Multi-Server Internet configuration”.
  • Figure 16 shows a block diagram illustrating schematically an embodiment variant according to the invention, the "Client PAN Multi-Server Internet configuration”.
  • Figure 17 shows a block diagram illustrating schematically an embodiment according to the invention based on the "Basic configuration" where the Client application uses a local network connection and the Internet to reach its server application.
  • Figure 18 shows a block diagram illustrating schematically the CNAPT/Client application interaction of an embodiment according to the invention based on the "Basic configuration”.
  • Figure 19 shows a flowchart illustrating schematically the method used by "Search Activity" to search for alternative network providers.
  • Figure 20 shows a flowchart illustrating schematically the method used by CNAPT module to retrieve an Internet connection at its start.
  • Figure 21 shows a block diagram illustrating schematically the SNAPT/Server application interaction of an embodiment according to the invention based on the "Basic configuration".
  • Figure 22 shows a block diagram illustrating schematically a Client/Server interaction by a system according to the invention.
  • Figure 23 shows a block diagram illustrating schematically the CNAPT module stopping forwarding service requests and sending a SWITCH_STEP1 packet.
  • Figure 24 shows a block diagram illustrating schematically the SNAPT module stopping forwarding data packets and sending an acknowledgement packet and the LAST_MESSAGE_BEFORE_REDIRECTION packets.
  • Figure 25 shows a block diagram illustrating schematically the
  • CNAPT module sending the LAST_MESSAGE_BEFORE_ REDIRECTION packets.
  • Figure 26 shows a block diagram illustrating schematically the SNAPT module sending the OK_TO_REDIRECTION packet.
  • Figure 27 shows a block diagram illustrating schematically the CNAPT module sending the CLIENT_SERVICE_READY_FOR_REDIRECTION packet.
  • Figure 28 shows a block diagram illustrating schematically the SNAPT module sending the
  • Figure 29 shows a block diagram illustrating schematically the CNAPT module sending the SWITCH_STEP2 packet, destroying the Client request emulation sockets and replacing the control socket.
  • Figure 30 shows a block diagram illustrating schematically the
  • CNAPT module recreating the Client request emulation sockets and binding them to the new IP address.
  • Figure 31 shows a block diagram illustrating schematically the SNAPT module sending the ALL_REDIRECTED packet.
  • Figure 32 shows a block diagram illustrating schematically the IP transition phase completed without any interruption of service.
  • Figure 33 shows a block diagram illustrating schematically the payload path from a Client application to a Server application while using the CNAPT and the SNAPT.
  • Figure 34 shows a block diagram illustrating schematically the payload path and the network layer headers from a Client application to a Server application while using the CNAPT and the SNAPT.
  • Figure 35 shows a block diagram illustrating schematically the payload path and the network layer headers from a Client application to a Server application while using the solution WO 02/43348 A1 by Columbitech AB.
  • Figure 36 shows a block diagram illustrating schematically the payload path and the network layer headers from a Client application to a Server application while using one of WO 02/103978 by Swisscom Mobile AG, EP 1089495 A2 by Nortel Networks Limited, EP 0998094 A2 by Nokia Mobile Phones LTD, WO 03/065682 A1 or WO 03/065654 A1 by KONINKLIJKE PHILIPS ELECTRONICS N.V..
  • CPE Customer Premise Equipment
  • socket i.e. one end of a bi-directional communication link between two programs defined as the combination of an IP address and a port number.
  • Figure 5 to 11 illustrate an architecture that can be used to achieve the invention.
  • the invention can be used by any Client application that is connected through an IP network (e.g. Internet or any wired/wireless Intranet) to its Server application ( Figure 5).
  • IP network e.g. Internet or any wired/wireless Intranet
  • the method and system according to the invention comprise one or more Client applications 11 , running on a mobile device 10, that are connected via a local network provider 30/31/32/33 and through an IP network 34, e.g. the worldwide backbone network called Internet or any wired/wireless Intranet, to a Server application 21 ( Figure 6).
  • IP network e.g. the worldwide backbone network called Internet or any wired/wireless Intranet
  • the networks implemented by providers 30/31/32/33 can comprise Ethernet or another wired LAN (Local Area Network), Bluetooth, GSM (Global System for Mobile Communication), GPRS (Generalized Packet Radio Service), EDGE (Enhanced Data-Rates for GSM Evolution), 1XRTT (Radio Transmission Technology), CDMA2000 (Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System) and/or WLAN (Wireless Local Area Network), etc.
  • LAN Local Area Network
  • GSM Global System for Mobile Communication
  • GPRS Generalized Packet Radio Service
  • EDGE Enhanced Data-Rates for GSM Evolution
  • 1XRTT Radio Transmission Technology
  • CDMA2000 Code Division Multiple Access
  • UMTS Universal Mobile Telecommunications System
  • WLAN Wireless Local Area Network
  • the physical network interfaces 40 to 43 of the mobile device 10 can comprise e.g. interfaces for the mentioned networks as e.g. Ethernet or another wired LAN, Bluetooth, GSM, GPRS, EDGE, CDMA2000, UMTS and/or WLAN, etc.
  • the interfaces can be not only packet-switched interfaces, as used directly by network protocols such as e.g. Ethernet or Token Ring, but also circuit-switched interfaces which can be used by means of protocols such as e.g. PPP (Point-to-Point Protocol), SLIP (Serial Line Internet Protocol) or GPRS (Generalized Packet Radio Service), i.e. whose interfaces do not have, for example, any network addresses such as a MAC or a DLC address.
  • PPP Point-to-Point Protocol
  • SLIP Serial Line Internet Protocol
  • GPRS Generalized Packet Radio Service
  • the invention provides any Client application with the best local network connection to the IP network 34 in term of bandwidth, reliability and cost effectiveness among all the wired/wireless network access technologies and/or access providers available at a certain time and location 30/31/32/33, managing the switch (when needed or convenient) in a transparent automatic and/or semi-automatic way without interrupting active network applications or sessions.
  • the switch between the networks can comprise a change of a physical network interface among different networks technologies, such as e.g.
  • Ethernet Bluetooth, mobile radio networks (GSM, GPRS, EDGE, CDMA2000, UMTS, etc.) or WLAN, or also a topological location change within the same network technology, for example a device linked to an Ethernet network that migrate to another Ethernet network or a device linked to a Wi-Fi HotSpot that migrate to another Wi-Fi HotSpot.
  • the invention is suited for client network applications running on a mobile device 10 which is able to hold simultaneously at least two different kind of network connection (GSM, GPRS, EDGE, CDMA2000, UMTS, Satellite Links, Wi-Fi, LAN, PSTN [Public Switched Telephone Network], xDSL as ADSL [asymmetric digital subscriber line] or SDSL [symmetric digital subscriber line] etc): for instance mobile devices with a GPRS modem and an independent Wi- Fi adapter or mobile devices with a Wi-Fi adapter and an independent UMTS modem or so on.
  • GSM Global System for Mobile Communications
  • GPRS Global System for Mobile Communications
  • EDGE Wireless Fidelity
  • CDMA2000 Code Division Multiple Access 2000
  • UMTS Satellite Links
  • Wi-Fi Wireless Fidelity
  • LAN Public Switched Telephone Network
  • PSTN Public Switched Telephone Network
  • xDSL as ADSL [asymmetric digital subscriber line] or SDSL [symmetric digital subscriber line] etc
  • the client application and its server exchange data via an IP network, such as e.g. the Internet, using exactly one network connection at a time.
  • IP network such as e.g. the Internet
  • the server application may provide one or more services and for each of them a server socket 29 listens for client application requests (Figure 6).
  • the mobile device is e.g. connected to Internet via the network provider X [31] and has the IP address "ClientlP_X".
  • the problem is that with the new network connection, the mobile device will be assigned a new IP address (therefore changing its IP address from "ClientlP_X" to "ClientlP_Y”): due to such a change, the service response can no longer reach the client application, resulting in the application/session crash and interruption of the service.
  • the invention avoids any interruption of service without any modification of the providers' infrastructure.
  • One of the purposes of invention is to make the IP address change of the mobile device totally transparent to the client and server applications.
  • the invention acts as a middleware, making the client application to believe that it is running either on the same device as the server application or in a device directly connected to the server (depending on the configuration adopted). This is achieved through the client-service module 12, further called CNAPT (Client Network Address and Port Translator) ( Figure 8), and a server-service module 22, further called SNAPT (Server Network Address and Port Translator) ( Figure 10).
  • CNAPT Client Network Address and Port Translator
  • SNAPT Server Network Address and Port Translator
  • the switch between "ClientlP_X" and “ClientlP_Y” is totally transparent to the client and server applications that continue their execution without any session crash and/or interruption of service.
  • the IP transition phase can be generated also by a temporary interruption of the Internet connection provided by the network provider X, that however remains still available; in fact that temporary interruption may cause a modification on the assigned IP address, e.g. from "ClientlP_X' to "ClientlP_X1".
  • the CNAPT stops forwarding all the outgoing IP packets generated by the Client application. They are buffered by the CNAPT and they will be forwarded at the end of the IP transition phase.
  • the SNAPT stops forwarding all the outgoing IP packets generated by the Server application and directed to the switching CNAPT. They are buffered by the SNAPT and they will be forwarded to the switching CNAPT at the end of the IP transition phase.
  • Comprising the CNAPT module and the SNAPT module the invention is able to act as a layer 7 relay system with a high level of flexibility.
  • the CNAPT module processes the client requests and relays them to the SNAPT module.
  • the SNAPT module processes the client requests and, at its turn, relays them to the server application.
  • the server response path is the mirror image of the client request.
  • the CNAPT module and the SNAPT module comprise the necessary infrastructure, including hardware and software components and/or units, to achieve a described method and/or system according to the invention.
  • the Server IP address is modifiable in the client application (i.e. the Server IP address is not hard coded).
  • the SNAPT module comprises in an appropriate memory unit at least the server IP address (or, in turn, the servers' IP addresses in case of multiple server applications, running on different devices, managed by the same SNAPT module), the server services' ports and the server services' type (connection-oriented, like services based on TCP (Transmission Control Protocol), or connectionless, like services based on UDP (User Datagram Protocol)) of its managed server application.
  • the SNAPT module comprises means to emulate server services 29 providing a set of emulation services 26 operating on emulation ports different from the real services port in order to avoid bind errors ( Figure 10).
  • Each CNAPT module comprises a unique ID (IDentification Number) that differentiates it from the other CNAPT modules.
  • the CNAPT module further comprises in a memory unit at least the SNAPT IP address (or, in turn, the SNAPTs' IP addresses in case of a CNAPT module simultaneously connected to more than one SNAPT module), the server services' ports and type (connection-oriented or connectionless) of the server application managed by the SNAPT and the SNAPT module services' emulator ports.
  • the CNAPT module also comprises in a memory unit the client IP address (or, in turn, the clients' IP addresses in case of multiple client applications, running on different devices, managed by the same CNAPT module), the eventual client services' ports and the client services' type (connection-oriented or connectionless) of its managed client application.
  • the CNAPT module comprises means to emulate the eventual client services 111 providing a set of emulation services 17 operating on emulation ports different from the real services ports in order to avoid bind errors (Figure 8).
  • the SNAPT module comprises, for each CNAPT module that provides client services, the client services' ports, the CNAPT services' emulator ports and the client services' type (connection-oriented or connectionless). These data are grouped by CNAPT module ID. If the client services are used, the SNAPT module must comprise also a set of virtual IP addresses 23 ( Figure 10) belonging to the same network to which it belongs (i.e.
  • the SNAPT module if the SNAPT module has the IP 192.168.102.150 and belongs to the network 192.168.102/24, it must have a set of virtual IP addresses belonging to 192.168.102/24 like 192.168.102.151, 192.168.102.152 and so on). Those addresses are used to accept simultaneous connections of different CNAPT modules managing client applications providing their client services on the same port, in order to avoid bind errors on that port. This is the case e.g. of n identical CNAPT modules managing a client application providing a client service on the port X, connected to a single SNAPT module. A different virtual IP address is used for each of those identical CNAPT modules.
  • the number of virtual IP addresses must be equal to the number of those identical CNAPT modules that can access the SNAPT module simultaneously.
  • the SNAPT module knows the CNAPT module ID and the current IP of all the connected CNAPT modules.
  • the invention comprises the possibility that the client application could also provide a set of services (connectionless or connection-oriented), the client services, that can be used by the server application for "PUSH” or "Publish/Subscribe” paradigms. For instance, the client application contacts the server application to register for some information updates, so when new information becomes available the server application may "push" them to the subscribed client applications on their services' ports. From now on, to simplify the explanation and the drawings, only the services provided by the server application are considered: it is easy to understand that client services are managed by the invention in a mirror-like manner to the server services.
  • the invention does not require any modification of the client applications source code if: (a) The server IP address is not hard coded (that is to say the server IP address is not set directly in the source code). It must be possible to set the server IP address in a configuration file or at run time, with user 1 interaction ( Figure 6), in some client application input mask, (b) The source IP address of the eventual client services provided is not hard coded. It must be possible to set the source IP address of these client services to "loopback" address (the special address "127.0.0.1" for IPv4 and the "::1" for IPv6) in a configuration file or at run time, with user 1 interaction, in some Client application input mask.
  • the source IP address is the client application device PAN IP address 18 (PAN: Personal Area Network) and it does not change during a switch phase (only the CNAPT module Internet IP address 19 changes during a switch phase).
  • PAN Personal Area Network
  • the invention does not require any modification of the Server application source code unless the client IP address, retrieved from the incoming packets, is used for critical internal activities (for instance in case of authentication based on the client IP address).
  • the CNAPT module can be realized by means of appropriate software and/or hardware components.
  • the CNAPT module comprises means to emulate server applications on the client side 14 and means to emulate client applications on the network side 15, e.g. Internet side ( Figure 8).
  • the CNAPT module creates for each server service, a server socket 16 on the client side. This server socket listens on the real server service port (server service emulator server socket).
  • server service emulator server socket For each server service request, the CNAPT module provides a client request emulation socket 121 on the Internet side. This socket relays packets to the right service emulator server socket provided by SNAPT.
  • the CNAPT module For each client service 111, the CNAPT module provides a server socket 17 on the network side, e.g. on the Internet side. This server socket listens on (i.e.
  • the CNAPT module For each client service request, the CNAPT module provides a server request emulation socket 123 on the client side. This socket relays packets to the real Client server socket.
  • the CNAPT module not only acts as a layer 7 relay system. It also launches a "decision task” module in order to provide the client application with the best network connection, e.g. Internet connection, in term of bandwidth, reliability and cost effectiveness.
  • the "decision task” module can be realized as a software and/or hardware module and has two main activities: (1) It continuously verifies the current network connection reliability and performance (Check Activity). (2) It continuously searches for new network providers (Search Activity). At any time, the user 1 can ask to the "decision task” module to switch to another available network provider. This is useful when the current network connection is a wired connection and the user 1 wants to switch to a wireless connection unplugging for instance the Ethernet cable.
  • the "decision task” can launch the Search and the Check activities only if it is running on a mobile device that is able to hold simultaneously at least two different kind of network connection (GSM, GPRS, EDGE, UMTS, Satellite Links, Wi-Fi, LAN,
  • the Search activity can't be launched and the Check activity only verifies the reliability of the current Internet connection signalling to the user 1 its eventual unavailability.
  • the switch from one network provider to another or also, in case of temporary interruption, to the same network provider if it is became available in the meanwhile, e.g. there was only a temporary problem) can be decided only by the user 1 with a specific request to the "decision task".
  • the Check Activity as a part of the "decision task” module verifies the reliability and the performance of the current network connection, e.g. Internet connection, every Y ms. If the reliability/performance indexes go down some specified "warning thresholds" (that can be set by the user 1 ) or if the current Internet connection has been interrupted, the "Check Activity” searches for new network providers in a similar way as the Search Activity (or trying to retrieve a new Internet connection from the same network provider if it is became available in the meanwhile, e.g. there was only a temporary problem). It can work in two ways: manual and automatic mode. In both the modes if it does not find any other network providers, it signals to the user 1 that the current network connection will be no longer available.
  • the “warning thresholds” that can be set by the user 1
  • the "Check Activity” searches for new network providers in a similar way as the Search Activity (or trying to retrieve a new Internet connection from the same network provider if it is became available in the meanwhile, e.
  • the Check Activity in order to avoid any interruption of service, switches to an alternative network provider available (preferring the provider allowing a totally automatic connection procedure) and it signals to the user 1 that the current network connection will be no longer available.
  • the Check Activity finds at least one alternative provider, it automatically decides on the network provider switch (preferring the alternative provider which allows a totally automatic connection procedure). It may perhaps require some user 1 interaction to establish a semiautomatic/assisted network connection.
  • the Check Activity avoids any interruption of service by the method described in this invention. After the switch has been made the old network connection, e.g. Internet connection, will be closed if it is still open.
  • the Search Activity as another part of the "decision task” module searches, without disturbing the current connection, every X ms for other available networks providers ( Figure 19). It can work in two ways: manual and automatic mode.
  • manual mode the user 1 has to choose the available network provider that he prefers.
  • the Search Activity finds at least one network provider that could provide a network connection, e.g. Internet connection, better than the current one, it asks the user 1 if he wants to switch.
  • the Search Activity In the automatic mode, the Search Activity automatically decides on the network provider switch (the decision is made using a set of parameters that can be modified by the user 1 ). It may eventually require some user 1 interaction to establish a semi-automatic/assisted network connection.
  • the Search Activity avoids any interruption of service by the method described this invention. After the switch has been made, the old network connection, e.g. Internet connection, will be closed.
  • the SNAPT module can be realized by means of appropriate software and/or hardware components.
  • the SNAPT module comprises means to emulate the client application on the server side 24 and means to emulate the server application on the network side 25, e.g. Internet side ( Figure 10).
  • the SNAPT module creates for each server service 29, a server socket 26 on the Internet side. This server socket listens on the server service emulator port (server service emulator server socket). This port is different from the server service real port in order to avoid a bind error.
  • the SNAPT module provides a client request emulation socket 60 on the server side 24. This socket relays packets to the real service server socket.
  • For each client service the SNAPT module creates a server socket 28 on the server side 24.
  • This server socket listens on the real client service port (client service emulator server socket).
  • the client service emulator server sockets are grouped by CNAPT module ID. Those groups using the same ports are bound to different Virtual IP addresses 23 in order to avoid bind errors.
  • the SNAPT module For each client service request, the SNAPT module provides a server request emulation socket 61 on the Internet side 25. This socket relays packets to the right client service emulator server socket provided by the correspondent CNAPT ID. Further the SNAPT module comprises a control server socket 27 on the network side 25.
  • the CNAPT module communicates with the SNAPT module over the network 30/31/32/33/34 through this "control server socket". This connection is used to exchange handshaking packets during an IP address-changing phase and it can be used to optimize the interaction between the client and the server application.
  • each SNAPT module can accept the simultaneous connection from more than one CNAPT module.
  • the “Basic configuration” the CNAPT module is installed on the client application mobile device 10 and the SNAPT module is installed on the same device 20 as the server application 21 ( Figure 11).
  • the server IP address is set to "loopback” (50) in the client application.
  • the CNAPT module sets the SNAPT IP address for each server service to "ServeriP" (51 ).
  • the CNAPT module emulates the server services on the client side providing a server socket "loopback:ServiceEmulator” 16 for each of them ("loopback:ServiceA”, “loopback:ServiceB” and so on). This socket can handle multiple concurrent client requests.
  • the client application accesses the services by sending and receiving data to/from these sockets.
  • the SNAPT module emulates the client application requests providing a socket "loopback:CasualPort” 60 for each of them.
  • the Server application handles Client requests by sending and receiving data to/from these sockets.
  • the CNAPT module is installed on the client application mobile device 10 and it is connected simultaneously to more than one SNAPT module.
  • Each SNAPT module is installed on the same device as its server application ( Figure 12).
  • the Servers IP addresses are set to "loopback" (50) in the client application.
  • the CNAPT module sets the SNAPT IP address to "Serverl IP” for the services A.B..Z and to "Server2IP” for the services 1 ,2..N (51 ).
  • Figure 12 a unique client application and a unique server application are shown. None changes if there are n client applications on the mobile device that, through the local CNAPT module, are simultaneously using the services provided by the m server applications managed by all the connected SNAPT modules.
  • This embodiment variant has the advantage that the system according to the invention can grant the seamless handover for the network connection among one or more client applications and two or more server applications running on different Internet nodes.
  • a user 1 without interruption of service, can move from one local network provider to another one keeping active multiple sessions with multiple different service providers.
  • the "Client PAN configuration" PAN: Personal Area Network
  • the CNAPT module is installed on an additional mobile device 13, that could act as a "connectivity box” able to manage the highest possible number of network access technologies and linked to the original mobile device through a broadband IP connection 131 ( Figure 13).
  • the client application mobile device 10 and the "connectivity box” have a fixed private IP address each, “ClientlP” and “CBoxlP”: they are part of a very small local network (e.g. they are connected using an Ethernet cross cable or a Wi-Fi ad- hoc connection or a Bluetooth connection).
  • the server IP address is set to the "connectivity box” IP address (“CBoxlP”) (50) in the client application.
  • the CNAPT module sets the SNAPT module IP address for each server service to "ServeriP" (51).
  • the CNAPT module comprises means to emulate the server services providing, on the client side, a server socket "CBoxlP: ServiceEmulator” 16 for each of them ("CBoxlP:ServiceA", " CBoxlP:ServiceB” and so on). This socket can handle multiple concurrent client requests.
  • the client application accesses the services by sending and receiving data to/from these sockets.
  • the SNAPT module comprises means to emulate the client application requests providing a socket "loopback:CasualPort" 60 for each of them.
  • the server application handles client requests by sending and receiving data to/from these sockets.
  • This embodiment variant has the advantage that the user 1 has to interact with a mobile device 10 simpler and maybe smaller than in the previous embodiments.
  • this mobile device should have more than one network adapter and it must run the CNAPT module and the client application.
  • this embodiment variant instead it must have only one network adapter and it must run only the client application, while the system according to the invention, granting the seamless handover, is provided by the "connectivity box”.
  • Another advantage of this embodiment variant is that, in order to avoid any modification of the client applications source code, it is not necessary to set the source IP address of the eventual client services to "loopback" address.
  • the source IP address is the client application device PAN IP address ("ClientlP") 18. Since it does not change during a switch phase (only the CNAPT Internet IP address 19 changes), the client services will not be interrupted.
  • the "Multi-Server LAN configuration” the CNAPT module is installed on the client application mobile device 10 and the SNAPT module is installed on an additional dedicated device 70 placed in the same network of the original server device 20 ( Figure 14); in this way a unique SNAPT module can manage more server applications on different devices at a time.
  • the CNAPT module sets the SNAPT IP address for each server service to "SNAPTIP" (51 ).
  • the CNAPT module comprises means to emulate the servers' services providing a server socket "loopback:ServiceEmulator" 16 for each of them ("loopback:Service1A",.., “loopback:Service1Z,.., “loopback:ServiceNA”,..., “loopback:ServiceNZ”).
  • This socket can handle multiple concurrent client requests.
  • the client application accesses the services by sending and receiving data to/from these sockets.
  • the SNAPT module emulates the client application requests providing a socket "SNAPTIP:CasualPort" 60 for each of them.
  • the server applications (1..N) handle client requests by sending and receiving data to/from these sockets.
  • This embodiment variant has the advantage that a SNAPT module can manage simultaneously more different server applications running on different devices on the same network; in this way a company that provides more and differentiated server services can offer to its customers the seamless handover feature using a unique SNAPT device.
  • the “Multi-Server Internet configuration” the CNAPT module is installed on the client application mobile device 10 and the SNAPT module is installed on an additional dedicated Internet server 70 placed on an Internet site reachable from the CNAPT module and different from the Internet sites 20 running the server applications ( Figure 15).
  • the CNAPT module sets the SNAPT IP address for each server service to "SNAPTIP" (51 ).
  • the CNAPT module comprises means to emulate the Servers' services, providing a server socket "loopback:ServiceEmulator" 16 for each of them ("loopback:Service1A",.., “loopback:Service1Z,.., “loopback:ServiceNA” "loopback:ServiceNZ”).
  • This socket can handle multiple concurrent Client requests.
  • the Client application accesses the services by sending and receiving data to/from these sockets.
  • the SNAPT module comprises means to emulate the client application requests providing a socket "SNAPTIP:CasualPort" 60 for each of them.
  • the servers applications (1..N) handle client requests by sending and receiving data to/from these sockets.
  • This embodiment variant has the advantage that a SNAPT module, installed on an Internet node, can manage simultaneously more different server applications running on different Internet nodes. In this way the seamless handover of the network connection among one or more client applications and one or more server applications can be provided by a company, different from the services providers, that does not require any modification or installation on the services providers sites and that only requires the installation of the CNAPT module on the final customer mobile device.
  • a customer of the above-described company e.g. an active trader
  • the "Client PAN Multi-Server Internet configuration” the CNAPT module is installed on an additional mobile device, that could act as a "connectivity box” able to manage the highest possible number of network access technologies and linked to a set of mobile devices through a broadband IP connection (Figure 16).
  • the client applications' mobile devices and the "connectivity box” have a fixed private IP address each, “Clientl IP”..”ClientNIP” and “CBoxlP”: they are part of a very small local network (e.g. they are connected using an Ethernet hub or a Wi-Fi ad-hoc connection or a Bluetooth connection).
  • the Servers' IP addresses are set to the "connectivity box” IP address (“CBoxlP”) in the client applications.
  • the CNAPT module sets the SNAPT IP address for each server service to "SNAPTIP” and sets the client IP address for each client service to the IP address of the mobile device running the related client application ("Clientl IP” for client service 1 A, 1B...1Z "ClientNIP" for client service NA, NB...NZ).
  • the SNAPT module is installed on an additional dedicated network server or Internet server 70 placed on an Internet site reachable from the CNAPT module and different from the Internet sites 20 running the server applications. This way the mobile devices are able to benefit by the above-mentioned advantages of the invention with any server providing services on the network and/or Internet, without the need to have a SNAPT module installed on every single server of interest.
  • the CNAPT module comprises means to emulate the servers' services providing a server socket "CBoxlP:ServiceEmulator" for each of them. This socket can handle multiple concurrent client requests.
  • the client applications access the services by sending and receiving data to/from these sockets.
  • the SNAPT module comprises means to emulate the client applications' requests providing a socket "SNAPTIP:CasualPort” for each of them.
  • the servers' applications (1..N) handle client requests by sending and receiving data to/from these sockets.
  • the set of embodiment variants described above is not intended to be exhaustive: it will be understood that further permutations of the base configurations and various changes in form and in detail may be made therein without departing from the spirit and the scope of the invention.
  • the concept of the invention has been explained using a simplified model, but this concept is, obviously, more general: (1)
  • the CNAPT module can emulate a great number of server and client services and can handle multiple concurrent requests to the same client or server service or to different services.
  • the CNAPT module can handle any number of client applications resident on the same device or in different devices.
  • the SNAPT module can handle multiple concurrent client requests coming from the same CNAPT module as well as multiple concurrent client requests coming from different CNAPT modules.
  • the SNAPT module can handle multiple concurrent server requests of client services coming from the same server application as well as multiple concurrent server requests coming from different server applications.
  • the SNAPT module can handle any number of server applications resident on the same device or in different devices.
  • a system according with the invention can support the dynamic update of the QoS (Quality of Service) parameters of the client and the server applications following a switch between two different network providers.
  • the switch between two different network providers could sometimes determine a relevant variation in the bandwidth available or in others connection parameters like packet delay, packet loss probability etc.
  • This variation should entail a QoS (Quality of Service) variation whenever the client and the server applications could dynamically change it. For instance, if the client and the server applications provide a real-time videoconference system, at their start a set of QoS parameters are exchanged and defined: frame rate, picture format, compression quality, ...etc.
  • the CNAPT module and the SNAPT module can be configured to send to the client and the server applications all the information they need to update their QoS.
  • the client and/or server services byte streams between the CNAPT module and the SNAPT module could be compressed in order to reduce the amount of data exchanged.
  • the CNAPT module and the SNAPT module have to know which services byte streams have to be compressed.
  • the mobile device 10 using the client application 11 is able to hold two different network connections simultaneously, e.g. Internet connections, through the network adapter 1 and 2 (40 and 41 in Figure 17).
  • the network adapter 1 and 2 are wireless adapters.
  • the server application 21 provides only two connection-oriented services (like services based on TCP): ServiceA and ServiceB (this assumption is used only to simplify the drawings; obviously the switch procedure handles also the connectionless server services).
  • ServiceA and ServiceB this assumption is used only to simplify the drawings; obviously the switch procedure handles also the connectionless server services.
  • a server socket 29 listens for client application requests (Figure 17).
  • the server device is connected to Internet 34 and it has the IP address "ServeriP".
  • the mobile device 10, using the wireless adapter 1 [40], is connected to Internet 34 via the wireless provider 1 [30] and it has the IP address "ClientlP_1".
  • the client application does not provide any client services (this assumption is used only to simplify the drawings; obviously the switch procedure handles also the connection- oriented/connectionless client services).
  • the CNAPT module and the SNAPT module will be described as middleware software application installed respectively on the mobile device 10 and on the server PC 20.
  • the CNAPT module and the SNAPT module run on a dedicated device. In this case the client and the server applications send/receive packets to/from the external dedicated device.
  • the unique difference from the other implementation is that the CNAPT module and SNAPT module are not referred to by the loopback address, but by their external dedicated device IP address.
  • the CNAPT module is a software module that comprises means to emulate the server application on the client side 14 and means to emulate the client application on the Internet side 15 ( Figure 18).
  • the services' real ports, the services' emulator ports and the services' type it , provides: (1) for each server service, a server socket 16 on the client side. This server socket listens on the real service port (Server Service Emulator server socket). (2) For each server service request, a Client Request Emulation Socket 121 on the Internet side. This socket relays packets to the right Service Emulator Server Socket provided by the SNAPT module.
  • the mobile device 10 is connected to Internet via the wireless provider 1 and has the IP address "ClientlP_1".
  • the server IP address has been set to "loopback” in the client application, when it requests the ServiceA, it sends a request to the "loopback:ServiceA" address 50.
  • This request is received from the ServiceA Emulator server socket 16.
  • the CNAPT module changes the source address from "loopback:ReqPort” 52 to "ClientlPjl :CasualPortX” 53 and the destination address from "loopback:ServiceA" 50 to "ServerlP:ServiceAEmulator” 54 and it then resends this request through the Client Request Emulator socket 121.
  • the CNAPT module When the Client Request Emulator socket 121 receives the server response, the CNAPT module changes the source address from "ServerlP:ServiceAEmulator” 55 to “loopback:ServiceA” 57 and the destination address from "ClientlPjl : CasualPortX” 56 to “loopback:ReqPort” 58 and it then resends this response through the Server Service Emulator server socket 16.
  • the CNAPT module and the SNAPT communicate through a "Control socket" 122. This connection is used to exchange handshaking packets during an IP address-changing phase and to optimize the interaction between the client and the server application. This connection is not always on; it is established when the CNAPT module has some needs, and it is closed when the operation has been completed.
  • the CNAPT module provides: (1 ) For each client service, a server socket 17 on the Internet side ( Figure 8). This server socket listens on the client service emulator port (Client Service Emulator server socket). This port is different from the real client service port in order to avoid a bind error. (2) For each client service request, a Server Request Emulation Socket 123 on the client side. This socket relays packets to the real client server socket 111.
  • a CNAPT module can emulate more than one server application simultaneously and in parallel.
  • This CNAPT module can be used by more than one client application.
  • the CNAPT module preferably has to be started before the client application. It has to run until the client application stops in order to provide it with a good, reliable and cost effective network connection to the server application.
  • the CNAPT module at the start, does the following: (1) Obtains a network connection ( Figure 20). If this is not possible, the CNAPT module can be stopped, for instance, and the client application cannot be started. (2) Launches the "decision task" module. (3) Creates the Server Service Emulator server sockets 16 on the Client side 14. (4) Creates the Client Service Emulator server sockets 17 on the network side 15.
  • Control server socket 27 creates a local Control socket 122 connected to the SNAPT (or, in turn, to the SNAPTs in case of "Multi-Site configuration") Control server socket 27 and uses it to send a "CONNECT" packet from which the SNAPT can retrieve the CNAPT ID, its current IP address and the connection optimization parameters.
  • the SNAPT module receives the initial "CONNECT" packet, it does the following: (1) Checks whether it can handle the new connection (obviously it has limited resources).
  • the CNAPT module at the end, has to create a local Control socket 122 connected to the SNAPT (or, in turn, to the SNAPTs in case of "Multi-Site configuration") Control server socket 27 and use it to send a "DISCONNECT' packet.
  • the SNAPT module receives a "DISCONNECT' packet it does the following: (1 ) Releases the internal resources of the disconnecting CNAPT ID and removes it from the list of connected CNAPT modules. (2) Destroys the Client service emulator server sockets 28 related to the CNAPT ID and unbinds them from the allocated Virtual IP address 23. (3) Sends the disconnect acknowledgement to CNAPT.
  • the SNAPT module associates with each connected CNAPT module a maximum inactivity time (inactivity timeout). When this inactivity time has elapsed, the CNAPT will be considered disconnected, and the previous steps (1-3) will be executed.
  • the SNAPT module can be produced as a software module that emulates the client application on the server side 24 and the server application on the network or Internet side 25 ( Figure 21 ). It provides: (1 ) For each server service, a server socket 26 on the Internet side 25. This server socket listens on the server service emulator port (Server Service Emulator server socket). This port is different from the real server service port in order to avoid a bind error. (b) For each service request, a Client Request Emulation Socket 60 on the server side 24. This socket relays packets to the real Service server socket 29.
  • the SNAPT module When the SNAPT module receives a ServiceA request, it changes the source address from "ClientlPjl :CasualPortX" 62 to “loopback:CasualPortY” 64 and the destination address from "ServerlP:ServiceAEmulator” 63 to "ServerlP:ServiceA” 65. It then resends this request through the Client Request Emulator socket 60.
  • the SNAPT changes the source address from "ServerlP:ServiceA” 66 to "ServerlP:ServiceAEmulator” 68 and the destination address from "loopback:CasualPortY" 67 to "ClientlPjl :CasualPortX” 69.
  • the SNAPT module provides: (1) For each Client Service, a server socket 28 on the Server side. This server socket listens on the real Client Service port (Client Service Emulator server socket). (2) For each Client Service request, a Server Request Emulation Socket 61 on the network side, e.g. Internet side. This socket relays packets to the right Client Service Emulator Server Socket provided by the correspondent CNAPT module ID.
  • the SNAPT module can comprise means to emulate more than one client application request simultaneously and in parallel, and the SNAPT module can be used by more than one server application.
  • the mobile device 10 is connected to the Internet via the Wireless Provider 1 [30], and it has the IP address "ClientlPjl".
  • the client application 11 has already requested the ServiceA, and it is now exchanging data with the server application 21 ( Figure 22).
  • the "Control Socket" 122 is used only to exchange data for the Client/Server connection optimization.
  • two cases will be illustrated: first the Wireless Provider 1 [30] that gradually becomes unavailable (slow switch) and then the Wireless Provider 1 that suddenly becomes unavailable (unexpected switch). Now suppose that the Wireless Provider 1 (30) gradually becomes unavailable (slow switch), for instance the mobile device 10 is slowly leaving its coverage area, while the Wireless Provider 2 (31 ) remains still available.
  • the CNAPT module has to (note that to begin this phase it is not necessary to have the "ClientlP_2" IP address, the unique precondition is to know the wireless provider selected to retrieve the new IP, in this case the Wireless Provider 2): (CNAPT-1 ) Suspend the "decision task” module activities (Search and Check activities). (CNAPT-2) Stop forwarding the connection-oriented server services request packets to the SNAPT module. (CNAPT-3) Stop forwarding the connection-oriented client services reply packets to the SNAPT module. (CNAPT-4) Stop forwarding the connectionless server services packets to the SNAPT module.
  • CNAPT-5 Buffer the pending server service requests and the pending client service replies. They will be forwarded at the end of the IP transition phase., (CNAPT-6) Flush all the transmission buffers. (CNAPT-7) Wait until the Search/Check activities have been suspended. (CNAPT-8) Put the input stream of the connection-oriented sockets linked to the SNAPT module in "waiting for last packet before redirection" mode. These sockets continue to receive data from the SNAPT module as before, until they receive a
  • (SNAPT-7) Put the input stream of the connection-oriented sockets linked to the "SWITCHING-CNAPT" in "waiting for last packet before redirection” mode. These sockets continue to receive data from the "SWITCHING-CNAPT” as before until they receive a "LAST_MESSAGE_BEFORE_ REDIRECTION” packet (note that this step can be avoided for connectionless services because they can tolerate packet losses).
  • (SNAPT-8) Send a "LAST_MESSAGE_BEFORE_REDIRECTION” packet in each output stream of the connection-oriented sockets linked to the "SWITCHING-CNAPT.
  • the CNAPT module When the CNAPT module receives the "OK_TO_REDIRECTION "o packet, it has to ( Figure 27): (CNAPT-15) Destroy the connectionless Client Services Emulator sockets 17 bound to the current CNAPT IP address and receiving data from the SNAPT. (CNAPT-16) Preserving the Client services connections between the Client and the Server applications, destroy the Client services connection-oriented emulation sockets linked to the SNAPT and5 generated by the connection-oriented Client Services Emulator server sockets 17. They were bound to the current CNAPT IP address. Each of these sockets has to be renewed by the SNAPT in order to preserve the Client services connections between the Client and the Server applications.
  • CNAPT-17 Preserving the Client services connections between the Client and the Server0 applications, destroy the connection-oriented Client Services Emulator server sockets 17 accepting requests from the SNAPT. They were bound to the current CNAPT IP address.
  • CNAPT-18 Send a "CLIENT_SERVICES_READY_FOR_REDIRECTION” packet to the SNAPT's control server socket 27.
  • CNAPT-19 Wait for the5 "SERVER_SERVICES_READY_FOR_REDIRECTION” packet coming from the SNAPT's control server socket 27.
  • the SNAPT module When the SNAPT module receives the "CLIENT_SERVICES_READY_FOR_REDIRECTION" packet, it has to (Figure 28): (SNAPT-13) Preserving the Client services connections between the Client0 and the Server applications, destroy the connection-oriented Client Services Server Request Emulation sockets 61 linked to the current "SWITCHING- CNAPT" IP address. (SNAPT-14) Preserving the Server services connections between the Client and the Server applications, destroy the Server services connection-oriented emulation sockets linked to the current "SWITCHING- CNAPT" IP address and generated by the connection-oriented Server Services Emulator server sockets 26.
  • Each of these sockets has to be renewed by the "SWITCHING-CNAPT” in order to preserve the Server services connections between the Client and the Server applications.
  • SNAPT-15 Send a "SERVER_SERVICES_READY_FOR_REDIRECTION” packet to the "SWITCHING-CNAPT control socket 122.
  • SNAPT-16 Wait for the "SWITCH_STEP2" packet coming from the "SWITCHING-CNAPT through the new control socket 122 bound to its new IP address.
  • CNAPT-24 Change the current IP address from the old IP address to the new one (if the client application and the server application are connected through a VPN, this step has to be followed by the following step: Open the new VPN between "ClientlP_2" and "ServeriP”).
  • CNAPT-25 Change to the new CNAPT IP address the binding of the server services connectionless sockets transmitting to the SNAPT module.
  • CNAPT-26 Recreate the connectionless Client Services Emulator sockets 17 receiving data from the SNAPT and bind them to the new CNAPT IP address.
  • CNAPT-27 Preserving the Client services connections between the Client and the Server applications, recreate the connection-oriented Client Services Emulator server sockets 17 accepting requests from the SNAPT and bind them to the new CNAPT IP address.
  • CNAPT-28 Create a new control socket 122 "ClientlP_2:CasualPort” and connect it to the control server socket 27 provided by SNAPT module on "ServerlP:ControlPorf .
  • CNAPT-29 Send a "SWITCH_STEP2" packet to the SNAPT's control server socket 27 using the Wireless Adapter 2. This packet contains the CNAPT ID and through this packet the SNAPT module can deduce the new CNAPT IP address.
  • CNAPT-30 Wait for the renewal of the connection-oriented Client services emulation sockets destroyed in [CNAPT- 16]. This renewal will be done with a connection request [SNAPT-19] of the SNAPT for each connection-oriented socket generated by the Client Services Emulator server sockets 17.
  • the SNAPT module When the SNAPT module receives the "SWITCH_STEP2" packet, it has to: (SNAPT-17) Update the "SWITCHING-CNAPT" IP address with its new IP address as retrieved by the source field of the "SWITCH_STEP2" control packet. (SNAPT-18) Redirect the Client services connectionless sockets transmitting to the "SWITCHING-CNAPT from its old IP address to the new one (no redirection is needed for the connectionless server sockets receiving data from the "SWITCHING-CNAPT"; they are unaffected by the CNAPT IP address switch).
  • SNAPT-19 Recreate the connection-oriented Client Services Server Request Emulation sockets 61 destroyed in [SNAPT-13] and connect them, in order to preserve the Client/Server interaction, to the Client Services Emulator server sockets 17 provided on the new "SWITCHING-CNAPT IP address.
  • SNAPT-20 Wait for the renewal of the connection-oriented Server services emulation sockets destroyed in [SNAPT-14]. This renewal will be done with a connection request [CNAPT-32] of the "SWITCHING_CNAPT for each connection-oriented socket generated by the Server Services Emulator server sockets 26.
  • (CNAPT-33) Wait for the "ALLJ EDIRECTED" packet coming from the SNAPT's control server socket 27.
  • (SNAPT-21) Redirect the correspondent Server services emulation connections to the new "SWITCHING-CNAPT” IP address through the renewed emulation sockets in order to preserve the Client/Server interaction.
  • (SNAPT- 22) Send an "ALL_REDIRECTED" packet to the new "SWITCHING-CNAPT" control socket 122.
  • (SNAPT-23) Wake up all the connectionless/connection- oriented client and server services and send the packets buffered in [SNAPT-5].
  • IP transition phase can be generated also by a temporary interruption of the Internet connection provided by the Wireless Provider 1 , that however remain still available; in fact that temporary interruption may cause a modification on the assigned IP, e.g. from "ClientlPjl” to "ClientlP a".
  • the Wireless Provider 1 becomes suddenly unavailable the correspondent Internet connection will be suddenly interrupted.
  • This interruption will throw on the CNAPT software some exceptions that are used to handle this particular event if and only if the CNAPT was reading or writing on the connection at the time of the interruption; otherwise the Check Activity signals the interruption and invokes the IP transition phase.
  • the interruption will throw on the SNAPT software some exceptions that are used to handle this particular event if and only if the SNAPT was reading or writing on the connection to that CNAPT ID at the time of the interruption; otherwise the interruption is signalled by the reception of the "SWITCH JJN EXPECTED" packet from that CNAPT ID.
  • the reception of the "SWITCHJJNEXPECTED" packet causes the invocation of the IP transition phase for that CNAPT ID.
  • the CNAPT When the CNAPT catches the connection exception or when the Check Activity signals the interruption, the CNAPT has to establish a new Internet connection through the Wireless Provider 2 (or, in turn, through the Wireless Provider 1 if it is became available in the meanwhile, e.g. there was only a temporary problem).
  • the CNAPT When the new Internet connection is available, to begin the IP transition phase from the "ClientlP_1" (no more available) to the "ClientlP_2" the CNAPT has to: (CNAPT-1 *) Suspend the "decision task” activities (Search and Check activities). (CNAPT-2*) Stop forwarding the connection-oriented Server services request packets to the SNAPT.
  • CNAPT- 3* Stop forwarding the connection-oriented Client services reply packets to the SNAPT.
  • CNAPT-4* Stop forwarding the connectionless Server services packets to the SNAPT.
  • CNAPT-5* Buffer the pending Server service requests and the pending Client service replies. They will be forwarded at the end of the IP transition phase.
  • CNAPT-6* For each outgoing connection, store the eventual unsent packets (i.e. the packets that the outgoing connection was eventually sending when the interruption exception was caught).
  • CNAPT-7* Wait until the Search/Check activities have been suspended.
  • CNAPT-8* Destroy the connectionless Client Services Emulator sockets 17 bound to the old CNAPT IP address.
  • CNAPT-9* Preserving the Client services connections between the Client and the Server applications, destroy the Client services connection-oriented emulation sockets linked to the SNAPT and generated by the connection-oriented Client Services Emulator server sockets 17. They were bound to the old CNAPT IP address. Each of these sockets has to be renewed by the SNAPT in order to preserve the Client services connections between the Client and the Server applications.
  • CNAPT-10* Preserving the Client services connections between the Client and the Server applications, destroy the connection-oriented Client Services Emulator server sockets 17 accepting requests from the SNAPT. They were bound to the old CNAPT IP address.
  • CNAPT-11* Preserving the Server services connections between the Client and the Server applications, destroy the connection-oriented Server services Client Request Emulation sockets 121 bound to the old CNAPT IP address.
  • CNAPT-12* Change the current IP address from the old IP address to the new one (if the client application and the server application are connected through a VPN, this step has to be followed by the following step: Open the new VPN between "ClientlP_2" and "ServeriP").
  • CNAPT-13* Change to the new CNAPT IP address the binding of the Server services connectionless sockets transmitting to the SNAPT.
  • CNAPT-14* Recreate the connectionless Client Services Emulator sockets 17 receiving data from the SNAPT and bind them to the new CNAPT IP address.
  • CNAPT-15 * Recreate the connection-oriented Client Services Emulator server sockets 17 accepting requests from the SNAPT and bind them to the new CNAPT IP address.
  • CNAPT-16* Create a new Control socket "ClientlP_2:CasualPortK” and connect it to the Control server socket provided by SNAPT on "ServerlP:ControlPort”.
  • CNAPT-17* Send a "SWITCH_UNEXPECTED" packet to the SNAPT "Control server socket” using the new Internet connection. This packet contains the CNAPT ID and through this packet the SNAPT can deduce the new CNAPT IP address.
  • CNAPT-18 * Wait for the renewal of the connection-oriented Client services emulation sockets destroyed in [CNAPT-9*]. This renewal will be done with a connection request [SNAPT-11*] of the SNAPT for each connection-oriented socket generated by the Client Services Emulator server sockets 17.
  • the SNAPT When the SNAPT catches the connection exception it waits for a "SWITCHJJNEXPECTED" packet coming from that CNAPT ID.
  • the SNAPT associates to that CNAPT ID a max reconnection waiting time (switch timeout). When this reconnection waiting time has elapsed, the related CNAPT will be considered definitely disconnected and the SNAPT should execute these steps: (1 ) release the internal resources of the disconnected CNAPT ID and remove it from the list of connected CNAPT; (2) destroy the Client service emulator server sockets related to the CNAPT ID and unbind them from the allocated Virtual IP address.
  • the SNAPT When, in any way, the SNAPT receives a "SWITCHJJNEXPECTED" packet it has to: (SNAPT-1*) Retrieve from this packet the ID of the sender CNAPT (from now on referred as "SWITCHING-CNAPT"). Through this packet the SNAPT can also deduce the new "SWITCHING-CNAPT" IP address. (SNAPT-2*) Stop forwarding the connection-oriented Server service reply packets to the "SWITCHING-CNAPT". (SNAPT-3*) Stop forwarding the connection-oriented Client service request packets to the "SWITCHING- CNAPT". (SNAPT-4*) Stop forwarding the connectionless Client service packets to the "SWITCHING-CNAPT.
  • SNAPT-5* Buffer the pending Server service replies and the pending Client service requests. They will be forwarded at the end of the IP transition phase.
  • SNAPT-6* For each outgoing connection, store the eventual unsent packets (i.e. the packets that the outgoing connection was sending when the interruption exception was caught).
  • SNAPT-7* Preserving the Client services connections between the Client and the Server applications, destroy the connection-oriented Client Services Server Request Emulation sockets 61 linked to the old "SWITCHING-CNAPT" IP address.
  • SNAPT-8* Preserving the Server services connections between the Client and the Server applications, destroy the Server services connection-oriented emulation sockets linked to the old "SWITCHING-CNAPT IP address and generated by the connection-oriented Server Services Emulator server sockets 26. Each of these sockets has to be renewed by the "SWITCHING-CNAPT” in order to preserve the Server services connections between the Client and the Server applications.
  • SNAPT-9* Update the "SWITCHING-CNAPT" IP address with its new IP address as retrieved by the source address field of the "SWITCHJJNEXPECTED" control packet.
  • (SNAPT-10*) Redirect the Client services connectionless sockets transmitting to the "SWITCHING-CNAPT from its old IP address to the new one (No redirection is needed for the connectionless Server services sockets receiving data from the "SWITCHING- CNAPT". They are unaffected by the CNAPT IP address switch.).
  • (SNAPT-11*) Recreate the connection-oriented Client Services Server Request Emulation sockets 61 destroyed in [SNAPT-7*] and connect them, in order to preserve the Client/Server interaction, to the Client Services Emulator server sockets 17 provided on the new "SWITCHING-CNAPT IP address.
  • (SNAPT-12*) Wait for the renewal of the connection-oriented Server services emulation sockets destroyed in [SNAPT-8*].
  • CNAPT-19* Redirect the correspondent Client services emulation connections to the new IP address through the renewed emulation sockets in order to preserve the Client/Server interaction.
  • CNAPT-20* Recreate the connection- oriented Server services Client Request Emulation sockets 121 destroyed in [CNAPT-11*], bind them to the new "SWITCHING-CNAPT" IP address and connect them, in order to preserve the Client/Server interaction, to the Server Services Emulator server sockets 26 provided on the SNAPT IP address.
  • CNAPT-21* Wait for the "ALL_REDIRECTED" packet coming from the SNAPT "Control server socket".
  • CNAPT-22* Resend the unsent packets eventually stored in [CNAPT-6*].
  • CNAPT-23* Wake up all the connectionless/connection-oriented Client and Server services and the "decision task” activities (Search and Check activities) and send the packets buffered in [CNAPT-5 * ].
  • the minimal duration of the IP transition phase therefore the connection timeout of the client and the server application, must be higher than the time requested for the SNAPT module and CNAPT module activities described above.
  • the CNAPT module and the SNAPT module if suitably configured, could additionally send to the client/server applications special information, e.g. all the information they need to update their QoS (Quality of Service) etc.
  • QoS Quality of Service
  • a system according to the invention can help organizations to improve and diversify their range of services. For instance that system can help the companies' mobile field forces to convey to their customers a sense of efficiency, competence and customer- centric "philosophy".
  • Such system provides the User with the best Internet connection in term of bandwidth, reliability and cost effectiveness among all the wired/wireless network access technologies and/or access providers available at a certain time and location. Let's consider a User connected via GPRS to a competence centre using videoconference and shared whiteboard, i.e. a collaboration application.
  • the system according to the invention can ask him if he wants to switch to the available Wi- Fi connection. If he accepts it can switch, automatically or with a limited user interaction, from the old GPRS connection to the new Wi-Fi connection. The switch is totally transparent for the collaboration application (no restart is needed). The used services remain up and running, and the User experiences a better QoS (as a matter of fact in this case the videoconference and shared whiteboard performance improves). Let's now consider the case where the same User leaves the Wi-Fi covered area.
  • the system can detect the Wi-Fi signal strength degradation, and before the Wi-Fi signal disappears it automatically makes a switch to a GPRS connection if the GPRS signal is present. Also in this case the switch is totally transparent for the collaboration application (no restart is needed). The User only experiences a worse QoS, but the services remain up and running.
  • a system according to the invention requires only limited CPU and/or memory resources so it can be used with PDAs and smart-phones, not only with laptops.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé destiné au transfert sans coupure de dispositifs mobiles dans des réseaux hétérogènes. Un dispositif mobile (10) est déplacé entre des emplacements de réseau topologiques différents (30/31/32/33) et transmet et/ou reçoit des données au moyen de technologies d'accès de réseau différentes sans le transfert de données entre une application IP client (11), fonctionnant sur un dispositif mobile (10) et une application IP serveur (21) interrompue, l'application IP client (11) du dispositif mobile (10) effectuant une requête avec les premières unités de données à un module de service aux clients (12), le module de service aux clients (12) créant des deuxièmes unités de données basées sur les premières unités reçues et effectuant une requête au module de service aux clients (22) avec les deuxièmes unités de données, le module de service aux clients (22) créant des troisièmes unités de données basées sur les deuxièmes et réalisant une requête à l'application IP serveur (21) avec les troisièmes unités de données afin de gérer l'échange de données entre l'application IP client (11) et l'application IP serveur (21).
EP05707999A 2004-02-10 2005-02-10 Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes Withdrawn EP1733590A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP05707999A EP1733590A1 (fr) 2004-02-10 2005-02-10 Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PCT/EP2004/050111 WO2005076649A1 (fr) 2004-02-10 2004-02-10 Procedes et systemes de transfert sans heurts de dispositifs mobiles dans des reseaux heterogenes
EP05707999A EP1733590A1 (fr) 2004-02-10 2005-02-10 Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes
PCT/EP2005/050599 WO2005076651A1 (fr) 2004-02-10 2005-02-10 Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes

Publications (1)

Publication Number Publication Date
EP1733590A1 true EP1733590A1 (fr) 2006-12-20

Family

ID=37398509

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05707999A Withdrawn EP1733590A1 (fr) 2004-02-10 2005-02-10 Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes

Country Status (1)

Country Link
EP (1) EP1733590A1 (fr)

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
GONG SU ET AL: "Mobile Communication with Virtual Network Address Translation", 1 February 2002 (2002-02-01), pages 1 - 14, XP055012337 *
QU X ET AL: "A mobile TCP socket", INTERNET CITATION, April 1997 (1997-04-01), XP002294144, Retrieved from the Internet <URL:http://cs.anu.edu.au/techreports/1997/tr-cs-97-08.pdf> [retrieved on 20040827] *
See also references of WO2005076651A1 *

Similar Documents

Publication Publication Date Title
US7620015B2 (en) Method and system for seamless handover of mobile devices in heterogeneous networks
US9825802B2 (en) Management of seamless handover between different communication systems in an IP dual-mode terminal
EP0936777B1 (fr) Système intégré de télécommunication sans fil et de réseau local
KR100907571B1 (ko) 확장된 자유 이동을 갖는 클라이언트들을 구비한 무선 근거리 통신망
RU2265282C2 (ru) Способ и система для мобильных узлов протокола ip в гетерогенных сетях
US6917592B1 (en) LNS high availability and load balancing with LNS-to-LNS state offloading
JP4772083B2 (ja) リンク方式間の移行方法及びモバイル・コンピューティング装置
EP1520377B1 (fr) Technique de rétroaction adaptative mise en oeuvre dans des réseaux mobiles IP
Sharma et al. OmniCon: a Mobile IP‐based vertical handoff system for wireless LAN and GPRS links
US6483822B1 (en) Establishing a packet network call between a mobile terminal device and an interworking function
JP2613017B2 (ja) データ伝送方法及び装置
KR101005724B1 (ko) 무선 전화/무선 랜의 연동 환경에서 이중 홈 이동성 관리
EP1597934B1 (fr) Procede de commande de session de terminaux radio et procede d&#39;etablissement d&#39;interface
JP2002063088A (ja) データ通信方法
US20140192776A1 (en) Mobile internet protocol square
WO2007139161A1 (fr) Terminal mobile et procédé de communication
KR20120067963A (ko) 물리 네트워크들이 변경될 때 ｔｃｐ 접속을 로밍하기 위한 시스템 및 방법
US20080153498A1 (en) Method of providing a mobility service
JP4477239B2 (ja) 共通ｉｐアドレス付きの移動端末および無線装置
CN105141588A (zh) Ip双模终端中不同通信系统之间的无缝切换的管理
EP1733590A1 (fr) Procede et systeme de transfert sans coupure de dispositifs mobiles dans des reseaux heterogenes
EP1704697A1 (fr) Procede et systeme de retablissement du contexte de flux de paquets de donnees
Paakkonen et al. Performance analysis of HIP-based mobility and triggering
Brzozowski et al. Bonded Wireless Networks: the Gateway to Real-Time Mobile Applications
Chowdhury et al. Design issues for SIGMA: seamless IP diversity based generalized mobility architecture

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20060908

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: LENZARINI, DAVIDE

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: FORWARD INFORMATION TECHNOLOGIES SA

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20090302

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: EMILIO ANTONIO CASAGRANDE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20140528

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04Q0007380000

Ipc: H04W0004000000

REG Reference to a national code

Ref country code: DE

Ref legal event code: R079

Free format text: PREVIOUS MAIN CLASS: H04Q0007380000

Ipc: H04W0004000000

Effective date: 20141029