WO2006045345A2

WO2006045345A2 - Method and apparatus for switching between different protocol implementations

Info

Publication number: WO2006045345A2
Application number: PCT/EP2004/052738
Authority: WO
Inventors: Martin Kappes; Christian Prehofer; Quing Wei
Original assignee: Ntt Docomo, Inc.
Priority date: 2004-10-29
Filing date: 2004-10-29
Publication date: 2006-05-04
Also published as: WO2006045345A3; JP2008518531A; JP4642855B2; EP1856880A2

Abstract

An apparatus for switching between different implementations of a transport protocol, said apparatus comprising: a plurality of different implementations of a transport protocol; an upper transport layer interface for connecting said plurality of different transport protocol implementations with the layer above the transport layer; a lower transport interface for connecting said plurality of a transport protocol implementations with the layer below that transport layer, whereas said upper transport interface and said lower transport interface respectively are capable of switching their connection between the different transport protocol implementation based on switching information, and a control module for determining the switching information for switching the connection between the upper interface and the plurality of transport protocol implementations and the lower transport interface and the plurality of transport protocol implementations such that for a certain communication session the transport protocol implementation which yields an optimised data flow is selected.

Description

METHOD AND APPARATUS FOR SWITCHING BETWEEN DIFFERENT PRO¬ TOCOL IMPLEMENTATIONS

FIELD OF THE INVENTION

The present invention is directed to a method and an apparatus for switching be¬ tween different protocol implementations, in particular for switching between differ- ent implementations of TCP.

BACKGROUND OF THE INVENTION

In recent years networking of computers and other computing and communications devices such as PDAs, mobile phones, etc., has become a major issue. Particu¬ larly the explosive growth of the Internet together with other emerging mobile net¬ working technologies such as GSM, WLAN, GPRS, i-mode, UMTS, etc. have led to a growing demand of merging individual electronic devices into a single or multiple networks so that they can communicate with each other.

In order to connect two devices a wide variety of networking methods and protocols is used. They use different protocols and are agreed upon as different standards, such as just to name a few the GSM standard for mobile phones, the UMTS stan¬ dard for third generation mobile phones, the IEEE 802.11 standard for wireless LANs, etc. The probably most widely used standard for communications between two computers or devices is the protocol which is used by the I nternet, generally referred to as TCP/IP (transmission control protocol/internet protocol).

In order to define and describe such standards and protocols usually the architec- ture is described by making reference to a multi-layer model, the one which is most widely used is the so-called "ISO-OSI layer model". This model uses seven layers from the top application layer to the bottom layer which is called the physical layer and defines the electronic signals and signal structures at a very low level of the network. Hg. 1 schematically illustrates this model.

For the description and definition of TCP/IP specifically reference is often made to a four layer model which is schematically illustrated in Fig. 2. This TCP/IP model shows the network layer as the bottom layer where the specifics of the particular network in operation are defined such as a token-ring LAN, an Ethernet LAN, a X- 25 communication, and so on. Other not shown examples could be a wireless LAN, a GSM communication, or the like.

On the top of the network layer is located the Internet layer which is responsible for the handling of the Internet protocol. Above the Internet layer there is located the so-called transport layer, which handles the transmission control protocol. An alter¬ native protocol for the transport layer is also shown in Fig. 2, it is called the user datagram protocol and works in a manner somewhat differently from the transmis¬ sion control protocol.

Above the transport layer there is located the application layer which is responsible for handling applications such as the ones shown in Fig. 2.

One can recognise from these figures that the transport layer with the transmission control protocol operates lays above those layers which are specific for the network or the underlying network characteristics, such as in Fig 1. the network layer, the data link layer, and the physical layer, or in Fig. 2 the internet layer and the network layer. This makes in particular the transmission control protocol relatively inde¬ pendent from the underlying structure of the network.

However, nevertheless due to the quite substantial differences between the net¬ works which may lay below the transport layer there has evolved some optimisation for individual networks which resulted in different flavours of TCP which are adapted to particular underlying network structures such as GSM networks, wire¬ less LANs, and fixed wired LANs such as Ethernet networks. For these different network structures slightly different versions of TCP have been developed which are optimised to the individual underlying network structure.

For example, in case of a fixed wired network conventional TCP interprets the loss of a segment as an indication of network congestion and accordingly adjusts the sending rate accordingly. However, in case of a mobile network being the underly¬ ing network there may very well be other reasons than network congestion for the occurrence of a segment being lost, and therefore it actually would not be neces¬ sary to adjust the sending rate in response to a lost segment. To deal with the pure performance of classical TCP versions over fragile links and links with high loss rates there have for example been developed special flavours of TCP which can be applied in case of fragile links.

Similarly, TCP often does not exploit the full bandwidth available on a link due to the inherent window size adaptations of conventional TCP implementations. Other cases where the conventional or classical TCP implementations are not providing an optimised performance are for example high-delay (e.g. satellite links). Conse¬ quently, over the years a variety of different TCP implementations and extensions for different contexts such as fragile wireless links, high-speed links, and high-delay links have been proposed. These versions result in considerable performance gains for each of such cases. However, these optimisations are limited to the indi¬ vidual application for which they have been provided.

Examples of different flavours of TCP are Reno TCP, Tahoe TCP, Las Vegas TCP and Sack TCP. These flavours of TCP for example differ in the way how to handle lost packets, e.g. by different flow rate control mechanisms or restart mechanisms. Reno TCP for example includes fast retransmit and thereby is in general more effi¬ cient than Tahoe TCP in case of high loss networks because it does not enter slow start for all packet losses as is done by Tahoe TCP.

While in principle different flavours or implementations of TCP/IP can communicate with each other the resulting data flow in case of the communication between two different TCP/IP implementations is not in all cases optimised. These problems becomes particularly significant as recently heterogeneous networks and communi¬ cation links which may even change over time with respect to their underlying infra¬ structure over time become more popular. E.g. a notebook or PDA may at a certain time be connected to a fixed wired network, and once the user moves the underly¬ ing network structure may change to a WLAN infrastructure like e.g. a hotspot in a cafeteria or to a GSM network structure using a co rresponding adapter card plugged into the notebook. This means that the suitability of a certain TCP imple¬ mentation may change over time, and consequently the resulting data flow being not optimised.

In view of the foregoing it is an object of the present invention to provide a solution for overcoming these deficiencies.

SUMMARY OF THE INVENTION

According to one embodiment of the present invention there is provided an appa¬ ratus for switching between different implementations of a transport protocol, said apparatus comprising : a plurality of different implementations of a transport protocol; an upper transport layer interface for connecting said plurality of different transport protocol implementations with the layer above the transport layer; a lower transport interface for connecting said plurality of transport protocol imple¬ mentations with the layer below that transport layer, whereas said upper transport interface and said lower transport interface respectively are capable of switching their connection between the different transport protocol im¬ plementations based on switching information, and a control module for determining the switching information for switching the con¬ nection between the upper interface and the plurality of transport protocol imple- mentations and the lower transport interface and the plurality of transport protocol implementations such that for a certain communication session the transport proto¬ col implementation which yields an optimised data flow is selected. By switching between different transport protocol implementations the embodiment enables an optimisation of the data flow of a communication session because the transport protocol implementation which is most suitable u nder the given conditions can be determined and selected to route the data flow through the selected TCP implementation. Moreover, by providing the switching functionality together with the capability to determine the switching information, already existing TCP implementa¬ tions can be used and can be switched.

By providing actually different protocol implementations rather than one generic protocol version the embodiment may make use of existing protocol implementa¬ tions and is therefore particularly advantageous when being implemented in already existing systems (legacy systems).

According to one embodiment the control module comprises : a module for determining one or more characteristics which are representative of the type of network structure implemented below the transport layer to determine the transport protocol to be selected such that it is adapted to the underlying net¬ work structure. By determining the underlying network structure characteristics those parameters which most significantly influence the performance of a given transport protocol version are determined and are used as a basis for deciding which TCP version should be used. This allows a particularly efficient adaptation of the switching apparatus to the given network conditions.

According to one embodiment the module for determining underlying network char¬ acteristics comprises : a module for using existing operating system functions to determine the underlying network characteristics.

By using existing operating system functions the implementation of the module for determining the underlying network characteristics becomes particularly simple. According to one embodiment the module for determining the underlying network characteristics comprises : a module for sending probing signals and for evaluating the returning responses to the probing signals to determine the underlying network characteristics based on said evaluation.

The mechanism of probing is advantageous if more simple methods like operating system queries are not available. Moreover, through probing the actual behaviour of the network can be determined rather than the mere underlying hardware compo- nents or structure, thereby making it possible to adapt the selection of the transport protocol implementation to the actual behaviour which may be different from the behaviour one would expect when merely looking at the underlying hardware.

According to one embodiment said module for determining the underlyi ng network characteristics comprises: a module for establishing a communication with the other end point of the commu¬ nication session and for negotiating with the corresponding module at the other end point of the communication session a suitable transport protocol imp lementation session to be used in the communication session.

Direct negotiation makes it possible to take into account not only the situ ation at the communication endpoint where the switching apparatus is located but also the situation at the other communication endpoint. This enables a better adapted selec¬ tion of the transport protocol to be used, moreover it has some advantages in case the switching should be performed during runtime, e.g. making it unnecessary to translate header parameters.

According to one embodiment said control module is adapted to switch between said different transport protocol implementations at run-time during an on-going communication session. This is particularly advantageous if e.g. due to the moving of one of the communication partners the conditions change such that s switching to another transport protocol implementation is necessary or at least preferable. According to one embodiment said control module comprises : a module for triggering the starting of a new transport protocol implementation to be used for switching to said new transport protocol implementation at run-time and a module for translating the contents of the TCP headers of the ongoing transport protocol session such that the headers sent to and from the newly started TCP im¬ plementation match with the TCP headers as sent and received by the transport protocol implementation at the other communication endpoint for an ongoing com¬ munication session.

Using such an independent switching only very few modifications on existing sys¬ tems are necessary and the implementation of the switching mechanism becomes comparatively easy. Furthermore, this can be done in a manner transparent to the application layer such that the application layer does not notice the underlying change. This means that the "session" running on the application layer does not change and is not interrupted. Moreover, the transport control protocol implementa¬ tion used at the other communication endpoint as well as the application layer at both communication endpoints do not notice the switching between different trans¬ port protocol implementations.

According to one embodiment said control module comprises: a module for extracting header data from a previous transport protocol session which is to be switched to a different transport protocol implementation, and a module for inserting said extracted transport protocol session header data into said newly opened transport protocol session such that the newly opened transport protocol session can resume the previous transport protocol session via a different transport protocol implementation.

The direct injection of transport protocol header parameters into the new transport protocol connection makes the transcoding of the header data unnecessary.

Moreover, this can be done in a manner transparent to the application layer, in other words the application sitting on top of the TCP layer does not notice the change in the underlying TCP implementation bei ng used.

According to one embodiment said control module comprises : a module for in case of an on-going transport protocol session to be switched to a different transport protocol implementation at a fi rst communication endpoint, nego¬ tiating with the corresponding module at the corresponding second communication endpoint that a switching is to be performed such that both control modules at those communication end points open an new transport protocol session directed to a different transport protocol implementation such that the on-going traffic is resumed through the newly opened transport protocol sessions and the different transport protocol implementations at both communication end points.

Such a fully co-ordinated switching renders even the injection of header data into the new transport protocol session unnecessary because it becomes possible to establish a completely new (TCP) session on the side of both communication end- points. This also can be carried out in a manner which remains fully transparent for the application which is running on the application layer and uses the communica¬ tion session.

According to one embodiment said control module is adapted to receive a triggering signal for triggering the switch to a different transport protocol implementation.

The reception of a trigger signal makes it possible to react in response to external influences such as a handover, a change in quality of service, or any other condi¬ tions which may influence the switching decision.

According to one embodiment said triggering signal is generated in response to one of the following mechanisms : a hand over during a mobile communication's session ; a change in quality of service during an on-going communication session ; a change in a hardware or a software module used in an on-going communication session.

According to one embodiment there is provided a method for switching between different implementations of a transport protocol, said method comprising: connecting a plurality of different implementations of a transport protocol with an upper transport layer interface for connecting said plurality of different transport protocol implementations with the layer above the transport layer; connecting said plurality of different implementations of a transport protocol with a lower transport interface for connecting said plurality of transport implementations with the layer below that transport layer, switching the connection of said upper transport interface and said lower transport interface, respectively, between the different transport protocol implementations based on switching information, said method comprising: determining said switching information for switching the connection between the upper interface and the plurality of transport protocol implementations and the lower transport interface and the plurality of transport protocol implementations such that for a certain communication session the transport protocol implementation which yields an optimised data-flow is selected.

The aforementioned method can be implemented by an apparatus according to a further embodiment of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 schematically illustrates the layered architecture of a TCP/IP protocol.

Fig. 2 illustrates the layered architecture of a TCP/IP protocol in comparison with the ISO/OSI layer model.

Fig. 3 schematically illustrates the protocol stack of a conventional TCP/IP connec¬ tion. Fig. 4 schematically illustrates c communication link using an embodiment of the present invention.

Fig. 5 schematically illustrates an embodiment of a switching apparatus according to the present invention.

Fig. 6 schematically illustrates an embodiment of a switching apparatus according to a further embodiment of the present invention.

Fig. 7 schematically illustrates an embodiment of a switching apparatus according to a further embodiment of the present invention.

Fig. 8 schematically illustrates the data resulting from a probing mechanism ac- cording to an embodiment of the invention.

Fig. 9 schematically illustrates an embodiment of the invention for negotiated switching.

Fig. 10 schematically illustrates a further embodiment of the invention for negotiated switching

DETAILED DESCRIPTION

Fig. 3 schematically illustrates a typical protocol stack in TCP/IP networks. Above two lower layers L1 (physical layer) and L2 (network layer) there is the Internet protocol layer L3 and on the top of that there is located the transport layer imple¬ menting TCP in this embodiment. One or more sessions are maintained through corresponding socket interfaces which are located above the transport layer imple- meriting TCP. According to an embodiment of the present invention the transport layer shown i n Fig. 3 is implemented by a switching apparatus as will be explained now in connec¬ tion with Fig. 4. Fig. 4 shows a communication link between a communication end- point A and another communication endpoint B. Both endpoints in this embodiment are located on the application layer, and they may be implemented by processes running on a computer, by a mobile phone, by a PDA, by notebook or a comput&r equipped with a WLAN interface, by a smartphone, or the like. The device or proc¬ ess implementing communication endpoint A is connected to the device or process implementing communication endpoint B through switching apparatus SWA imple - menting the transport layer, through layers L3 to L1 of the internet protocol stack, through typically multiple nodes of the internet schematically illustrated in Fig. 4 as IN, through the internet protocol stack L1 to L3 on the side of B, through switching apparatus B, and finally to endpoint B.

Switching apparatuses SWA and SWB each are implementing a plurality of different transport protocol implementations being optimised for different underlying networ-k structures, and switching apparatuses SWA and SWB are capable to switch be¬ tween these different implementations in order to make it possible that the traffic from A to B and backwards is routed through TCP implementations which are most suitable for the given underlying network characteristics. For example device A may be a notebook computer which has been connected to a fixed wired Ethernet fo r establishing a previous connection to device B which may for example be a com¬ pany server of the employer of the user owning device A. However, the user may have left the office so that the fixed wired connection has been disconnected, and he may have entered an area where a WLAN hotspot is provided through which he now wishes to connect to server B via the internet. This means that the underlying network characteristics on the side of A has changed and accordingly a change o-f the TCP implementation to be used for the connection may be advantageous, the switching apparatus in one embodiment detects the underlying network character- istics and suitably chooses one of the provided TCP implementations to be used fo r the communication session. It should be mentioned that this determination and se¬ lection can be carried out even if on the side of B there is provided no switching apparatus SWB. This means that the switching is carried out transparently such that the layers above and below the transport layer on the side of A and also on the other side of B do not notice the switching.

If both communication endpoints are equipped with a switching apparatus as shown in Fig. 4, then an adaptation can be performed on both sides of the communication link.

Moreover, according to a further embodiment the switching apparatus SWA is ca- pable to connect to switching apparatus SWB in order to negotiate a suitable TCP implementation to be used for the communication session between A and B.

With reference to Fig. 5 there will now be described in somewhat more detail an embodiment of a switching apparatus according to the present invention such as apparatus SWA or SWB shown in Fig. 4. As can be seen from Fig. 5 this embodi¬ ment has two different TCP implementations which are labelled TCPx and TCPy. They may for example refer to a TCP implementation optimised for a fixed wired LAN (TCPx) and to a further TCP implementation optimised for wireless LANs (TCPy). Below the two TCP implementations there is located an interface labelled "lower transport interface LTI" which connects the IP layer with the two implemen¬ tations of the different TCP flavours. Similarly, above the two TCP implementations there is another interface labelled "upper transport interface UTI" which connects the two TCP implementations with the socket interface establishing the connection to the application layer. The TCP implementations TCPx and TCPy may be> stan- dard TCP implementations which are connected respectively to the upper and lower transport interfaces LTI and UTI.

With the configuration as shown in Fig. 5 it is possible to route segments arriving through layer L1 through layers L2 and L3 and to direct them through the lower transport interface to the "correct" or "optimised" TCP implementation which may either be TCPx or TCPy depending on the network characteristics of the underlying layers below the transport layer. As can be seen in Fig. 5 the upper and lower transport interfaces can "switch" between the different TCP implementations de¬ pending on which on is most appropriate. The decision as to which TCP imple¬ mentation is used can be made dependent on the underlying netwo rk characteris¬ tics of the underlying layer which here for example could mean which kind of net- work connection is used between the communication partners, such as e.g. fixed wired Ethernet, WLAN, Gbit Ethernet, GSM, or the like. Based on these underlying network characteristics the TCP implementation is chosen and fro m the chosen TCP implementation the data is then further routed to the upper interface and from there to the socket interface.

In the opposite direction packets or segments which arrive through the socket in¬ terface pass through the upper transport interface where depending on the under¬ lying network characteristics they are either directed to implementation TCPx or to implementation TCPy, from there to the lower transport interface and then down through layers L3 to L1 and from there over the internet IN to the other communica¬ tion partner (not shown) as illustrated already in connection with Fig. 4.

In order to chose the right path for the segments it must be decided by the upper and lower interfaces, respectively, which TCP implementation should be used. This is done by the control module CM shown in Fig. 5 and will now be described in the following.

According to one embodiment the control module comprises an interface to one or more of the underlying (lower) layers LL..L3 which is labelled LLI interface in Fig. 5. This interface then is able to retrieve information about the kind of the underlying layer by communicating directly with one or more of the underlying layers. For that purpose it may make use of an (not shown) application programming interface (API) of one of the underlying layers and may thereby contact one or more of the under¬ lying layers to retrieve information about the underlying network structu re. The thus retrieved information about the underlying network characteristics is then forwarded to the evaluation module EVAL which determines based on the retrieved information which TCP i mplementation should be used. Accordingly the control module CM then informs the upper transport interface UTI and the lower transport interface LTI about which of the TCP implementations TCPy and TCPx should be used. The communication may then start as follows.

In case of an outgoing communication the socket interface will start a new session. The application which wishes to use the communication session specifies the desti- nation IP address and the port number as usual in an TCP/IP connection, and will be given an ephemeral source IP port number. With this information the session to be opened is then uniquely identified. The request to open the new session will be regarded by the UTI as a request to determine the appropriate TCP version. Ac¬ cordingly the UTI informs the control module which then carries out a determination procedure as described before to determine the most appropriate TCP version for the session to be opened. Once this information has been obtained, the UTI is in¬ formed accordingly by the control module CM, and also the lower transport inter¬ face LTI is informed accordingly, either directly by the control module CM or, alter¬ natively, by a direct interface between the UTI and the LTI which is not shown in Rg. 5. Using this information, the upper and lower transport interfaces can route TCP segments to the appropriate TCP implementation. This can be done by checking the TCP Header by the UTI and the LTI for the outgoing and the incoming packets, respectively. Therein there can be found information about the quadruple of source/destination IP address and source/destination port, and this information not only identifies the communication session but also the TCP version which has been determined as most appropriate for this session. Accordingly, based on this header information, the UTI and the LTI can perform the routing of the packets to the correct TCP implementation.

It should be mentioned that the UTI and the LTI may be provided with a "default TCP version" which is the version which should be used as long as they have not been explicitly been informed by the control module to use a different version. E.g. the default TCP version could be used for the initial steps of opening the session, e.g. session opening request, assignment of ephemeral port number, etc, which are necessary to define a session such that it can be identified later on and such that the thus identified session may be assigned a specific TCP version determined by the control module.

In the following it will now be described how the routing of the packets works in case of an incoming session, in other words a session which has been initiated by the other communication endpoint. In this case the lower transport interface LTI will at first receive the request to open the session, it will use the default TCP version to route through the com munication inasmuch as necessary to uniquely identify the newly identified session, then the appropriate TCP version will be determined by the control modu le as al¬ ready described hereinbefore, and the resulting information is communicated to the LTI and the UTI which then may use this information for routing the incoming and outgoing packets to the appropriate TCP implementation which has been selected. As described already before, the routing can be done by checking the TCP header, which for the incoming packets is done by the lower transport interface LTI and for the outgoing packets by the upper transport interface UTI.

It should be mentioned that while the control module CM has been shown in Fig. 5 as a single module separate from the UTI and the LTI, it may as wel I be imple¬ mented as a part of the upper transport interface UTI, the lower transport interface LTI, or as part of both. The operation of the control module may be triggered by either the UTI or the LTI, which themselves may interpret a session opening re- quest as a trigger to in turn trigger the operation of the control module in order to determine the appropriate TCP version.

According to a further embodiment shown in Rg. 6 the control module comprises a query module QM for querying operating system primitives of he operating system OS on which the communication endpoint is based. The resulting responses may then be used by the evaluation module EVAL to decide which is the underlying network structure and consequently which TCP flavour should be used, and the TCP implementations are informed accordingly like in the previous embodiment.

One such query could for example be operating system commands like e.g. "ipcon- fig" or "ifconfig" which then returns information about the underlying network being e.g. an Ethernet, a WLAN, a Gbit Ethernet, a GSM connection, or the like. Based on the information stored in a lookup table assigning networks characteristics to appropriate TCP flavours the upper or lower interface the evaluation module EVAL may then decide which TCP flavour should be used for optimising communication efficiency.

There will now be described a further embodiment in connection with Fig. 7. A> cording to this further embodiment the underlying network structure and thereby the appropriate TCP flavour can be determined by a probing mechanism. For that pur¬ pose the TCP interface may comprise a probing module PM shown in Fig. 7 and operating as follows.

Probing module PM transmits probing signals to a probing partner X which may be the communication endpoint B with which the communication should be established or which may be a specific node in the network dedicated for being the target of the probing mechanism. By transmitting probing signals and evaluating the corre¬ sponding reponse from the desired communication partner through the evaluation module EVAL the control module may determine the nature of the underlying net¬ work structure thereby enabling a judgement on the type of TCP to be used. For example the "ping" command could be used to send the probing signals. Each ping triggers a reponse from the corresponding communication partner to which it was addressed if this communication partner is reachable, and the probing module may measure the time until the response is received. While the response time may OB- pend on the actual network load, the particular path a packet may take through the internet, and also on other varying factors the response time for a certain individual ping request may not be characteristic, however in one embodiment one could use a plurality of ping requests which then leads to a certain distribution of response times. This distribution varies around a certain mean response time and/or may have a certain statistical distribution around this mean response time which then may be regarded as being characteristic of the underlying network structure. In case of a fixed wired Ethernet network one could e.g. expect a rather short mean response time and a small variance around this mean response time while in case of a GSM connection one could expect a longer mean response time showing a broader variance. The evaluation module EVAL then evaluates the response distri¬ bution and decides which TCP implementation should be used.

Rg. 8 gives an example of response time distributions for a fixed wired Ethernet (example (a)), and a GSM connection (example (b)). By evaluating the response time distribution and comparing it with certain standard patterns which are charac¬ teristic for the underlying network structure (e.g. by calculating the mean value and the variance, or by using some more sophisticated pattern evaluation mechanisms such as neural networks) the evaluation module can then conclude which underly- ing network structure is present and which TCP version should accordingly be used.

According to a further embodiment other probing methods could be used as well, either alone or in combination with the previously described one. One other probing method could e.g. measure the throughput which can be achieved through a certain connection. In one embodiment for that purpose also the "ping" functionality could be used, e.g. by sending pings while increasing their frequency and simultaneously looking until which point there is reached the maximum throughput. The result can then be evaluated and be used for deciding the most appropriate TCP version.

Another approach could be to vary the packet size and similarly look for the achiev¬ able result. Based thereupon then the TCP version to be used may be selected, e.g. higher possible packet sizes may allow the use of a TCP version specifically designed for such conditions.

According to one embodiment the signal strength of the connection could be checked as an information based on which the appropriate TCP version should be determined. This can e.g. in one embodiment be done by using an operating sys¬ tem function such "iwconfig" which is a UNIX command and returns information about the signal strength in a wireless LAN connection. This information can then also be taken into account when deciding which TCP version should be used.

In one specific embodiment the information about the signal strength or other pa¬ rameters reflecting network properties or the quality of a connection are continu¬ ously monitored, e.g. in predefined intervals, and thereby any degrading or signifi¬ cant change in the underlying parameters could be detected and based thereupon a change to a different TCP version could be triggered.

According to a further embodiment the control module may com prise a module for determining the characteristics of the application (on the appli cation layer level) which is requesting the communications session. The module may determine the type of the application, and then it may refer to a priori knowledge which has e.g. been stored in form of a lookup table to determine which is the most appropriate TCP implementation for this type of application.

According to one embodiment the control module may use a combination of the mechanisms described hereinbefore, such as querying operating system primitives, probing, or checking the type of the application requesting the communications session. In this case the a priori knowledge to be considered when selecting the most appropriate TCP implementation may comprise information about all of these kinds of information to be considered, and the there may e.g. be rules how to finally make the decision if there were conflicting conclusions when o nly one type of h- formation would be considered, like e.g. the probing suggests TCP implementation

A while the requesting application type would suggest to use TCP implementation

B. A rule-based knowledge base could be established to define* for each possible combination of input information which TCP implementation is to be selected based on this information. According to an even further embodiment the control module may comprise a re- gotiating module NM instead of or additional to the probing module which enables it to directly communicate with the corresponding interface at the other end of the communications link. The operation of this negotiation module will now be ex- plained in connection with Fig. 9.

Fig. 9 shows to endpoints A and B of a communication between which a communi¬ cation session should be established. These apparatuses A and B may be comput¬ ers, mobile phones, PDAs, smartphones, notebooks, or they may be applications or processes running on these devices and being itself capable of opening and main¬ taining a communication session.

Each of the elements A and B shown in Fig. 9 is connected to a fronted module SWA or SWB respectively capable of switching between different TCP implementa- tions. These modules SWA and SWB comprise negotiation modules NMA and NMB, respectively.

Assuming now that apparatus A wishes to establish a communication to apparatus B. Apparatus A will then send a request to the IP address of B requesting a com- munication session to be established though a certain port. This request will then be routed through switching module SWA which will be triggered by this request to try to establish a communication session to its counterpart SWB to negotiate the TCP application which should be used by SWA and SWB, respectively. Once this communication session for the purpose of negotiating has been established the module SWA informs the module SWB about the underlying network structure on the side of SWA. This information may be retrieved from a querying mechanism which has been described in a previous embodiment, or it may al ready be present e.g. in a status register of module SWA. Assuming that apparatus A is a mobile phone this could mean that module SWA will send a corresponding information to module SWB that the underlying network infrastructure on the side of A is a GSM infrastructure. The corresponding module SWB may in a similar manner retrieve or h ave already stored information about the underlying network infrastructure on the side of appa¬ ratus B. Based on this information the both negotiation modules NMA and NMB may then negotiate the TCP implementation to be used in the switching modules SWA and SWB, respectively. If e.g. a TCP implementation suitable for <3SM as un¬ derlying network structure is not only available in switching module SvVA but also in switching module SWB, then negotiation module NMB may inform negotiation module NMA accordingly such that both switching modules use such a most appro¬ priate TCP implementation for GSM as the underlying network structure.

In case of a heterogeneous underlying network structure, e.g. the underlying net¬ work structure being a GSM structure on the side of A and a WLAN infrastructure on the side of B, then negotiation module NMB may determine based on some a priori knowledge which may be stored in a lookup-table a most appropriate TCP implementation for such a case. This selected TCP implementation may then be suggested to negotiation module NMA, and if available on the side of A may then be used for the communication session between A and B. If the suggested TCP implementation is not available at switching module SWA, then negotiation module NMA may again suggest a further alternative for the TCP implementation to be used and may send the corresponding information to its corresponding! negotiation module NMB where again the availability of the suggested TCP implementation is checked. By repeating this procedure a suitable and available TCP implementation can be selected.

Another alternative for negotiating the suitable TCP implementation according to a further embodiment operates as follows. When informing negotiation module NMB about the underlying network structure, negotiation module NMA could further transmit information about the TCP implementations which are available in switch¬ ing module SWA. Based on the thus transmitted information the negotiation module NMB may then refer to a knowledge base (e.g. in form of a lookup-table) and may then select the TCP implementation most suitable under the given circumstances. Then module NMB may inform the negotiation module NMA about the selected TCP implementation and the thus selected TCP implementation may be used for the communication session between A and B which may- then be opened using the thus selected TCP implementation after having closed the communication session between SWA and SWB which has been used for negotiating a suitable TCP ^"m- plementation.

In the following there will now be described a further embodiment where the two communication endpoints A and B or at least endpoint Av which initiates the session is capable of switching between TCP implementations. According to this further embodiment there is provided a support node B^' in the network which may act as representative of the other end node B. Node B^' is capable of negotiating a suitable TCP implementation with initiating endpoint A.

This scenario will now be further explained in connection with Fig. 9. Initiating end- point A and support node B^' in this example are both within the range of a certain underlying network structure, e.g. a high-quality high-speed infrastructure provided by a certain provider, the range being schematically illustrated by the area contain¬ ing A and B^' in Fig. 9. Assuming now that endpoint A wishes to establish a commu¬ nication session with endpoint B lying outside the coverage of the mentioned high- quality-high-speed provider as indicated by the dashed line in Fig. 9. Nevertheless endpoint A at first connects to support node B^' for negotiating a suitable TCP im¬ plementation between A and B^', and B^' then contacts B to - if possible - further negotiate a suitable TCP implementation between B' and B. After the negotiation process then either a direct communication between A and B may be established based on the result of the negotiation, or the communication may be routed from A to B' and from there to B, whereas for the path A-B^' a first suitable TCP implemen¬ tation being used and for the path B^'-B a second suitable TCP implementation be¬ ing used, depending on the negotiation result.

In the following there will be described a further embodiment of the present inven¬ tion which is directed to the switching between different TCP implementations at runtime. In the foregoing examples it has been assumed that the control module at first determines the most appropriate TCP implementation, and thereafter the actual communication has been started and was routed through the selected TCP imple¬ mentation. However, today's networks not only often are heterogeneous but even may change over time, and consequently also an ongoing communication session could be confronted with a change in the underlying network infrastructure. One example for the reason of such a change could be a handover in a mobile network. Base stations of mobile networks have a certain coverage area, and once the user comes close to the border of the coverage area a so-called handover may be nec¬ essary, i.e. the ongoing communication session is "handed over" to a different base station. Such a handover may lead to a change in the underlying network charac¬ teristics, e.g. just because the new base station uses a different network platform. E.g. an ongoing communication session may be handed over from a "conventional" mobile phone base station to a WLAN hotspot once the user enters an area cov¬ ered by such a hotspot, like e.g. in an airport, a restaurant, or other locations where such hotspots are provided. On the other hand, a user again may leave the cover¬ age area of such a hotspot and then an ongoing communication session needs to be handed over to a mobile phone base station. Each of these handovers means that the underlying network characteristics changes, and consequently it is desir¬ able that this would also be reflected in a change of the TCP implementation φ- plied for the ongoing communication session.

An embodiment implementing such a runtime switching between different TCP im¬ plementations will now be described in the following. This embodiment will later be referred to as "independent switching" because there is no external co-ordination between the old and the new TCP connection between the upper/lower transport interfaces.

Assuming now that an communication endpoint A has an ongoing session with the other communications endpoint B. Endpoint A then moves and a handover takes place so that the underlying network characteristics for communication endpoint A changes. In this embodiment, the upper and lower transport interfaces pair on the side of endpoint A then stops the current TCP implementation and starts another TCP implementation in a way transparent to the actual TCP implementations and the other endpoint B.

It should be noted here that this form of switching does not require any modifica- tions in hard- or software in any component except for the connection between the control module and the different TCP implementations. The current TCP imple¬ mentation is stopped by the control module by terminating the session through in¬ jecting signals into the lower transport interface indicating that the other endpoint B has closed the connection. Corresponding signals from the actual TCP implernen- tation to the application on the side of A thereby are intercepted and not forwarded. Simultaneously, a new TCP implementation is started using similar techniques by the control module by triggering another TCP implementation module to start a new TCP connection to the application. Since no interfaces other than the ability to open and close a connection are present, in this embodiment it cannot be guaranteed that TCP parameters such as sequence numbers, window size, etc. between the different implementation can be exchanged. So, the TCP implementation at the other endpoint will continue with the current sequence number of the session x while the newly started implementation will begin with a sequence number of 0. Consequently, a translation of port numbers and other fields in the TCP headers by the upper/lower transport interface pair or the control module can be necessary for future segments. In particular, sequence numbers and acknowledgement num bers in the TCP header have to be adjusted to compensate the offset x between the newly started TCP implementation and the TCP implementation on the other end- point that continues with the old sequence numbers. For instance, a sequence number a from the newly started implementation must be converted to a+x (x being the last sequence which has been sent from the other endpoint B) in order to be processed correctly at the endpoint A of the TCP connection. Moreover, the check¬ sum of TCP segments need to be recalculated. Accordingly in this embodiment the control module or the lower transport interface LTI comprises a (not shown) module for amending the TCP header parameters in the newly opened TCP connectio n to ensure that the ongoing communication session can be continued after the switch¬ ing. In the following there will now be described a somewhat different embodiment for performing a runtime switching between different TCP implementations referred to later as "loosely co-ordinated switching". For this embodiment the control module has the capability to insert TCP parameters through an interface into the local TCP implementations. Furthermore there is provided a module to extract the relevant TCP parameters of the ongoing communication session. Hence, the state from the current TCP session is be extracted (sequence number and other relevant pa¬ rameters necessary to ensure a proper resuming of the ongoing TCP connection through a different TCP implementation) and inserted into the new TCP implemen¬ tation. In such a case, the new local TCP implementation can receive the current TCP sequence number of the session as input such that a transcription of TCP header fields by the upper/lower transport interface is not necessary.

There will now be described a further embodiment for performing a runtime switch¬ ing between different TCP implementations referred to as "fully co-ordinated switching". In this embodiment is assumed that the other endpoint B in additi on to the endpoint A, or in other words the front-end connected thereto for realising the TCP implementation switching mechanism is also capable of switching TCP irnple- mentations at runtime. This switching mechanism can be performed analogously to the switching mechanism described in connection with a negotiated switching in a previous embodiment, accordingly a detailed description will be omitted here as the skilled person will readily recognise the analogy. By such a mechanism capable of a negotiated switching a co-ordinated, simultaneous switch on both sides may be facilitated after a negotiation of the TCP implementation to be used on both sides has been successful. Then the communication can proceed using the newly negoti¬ ated TCP implementations, whereas either a TCP header information translation as described in a previous embodiment, a TCP header data injection as described in connection with another previous embodiment, or the establishing of a completely new TCP session could be used. As mentioned before already the change to a different TCP version could be trig¬ gered by external influences such as a handover being performed which leads to changes in the underlying network infrastructure for the ongoing connection . Other circumstances which could trigger a change to another TCP version could be a change in the quality of a connection or a service, e.g. the signal strength. Accord¬ ing to one embodiment some or all of the parameters which are considered when deciding which TCP version should be used are continuously monitored, s.g. by sampling the relevant data in regular intervals. This enables a swift response to any change in the parameters which are considered when the TCP version to t>e used is determined.

It should be mentioned here that the invention outlined above is not limited to TCP only. It can also be applied to switch at runtime between TCP and other types of transport protocols as well as between other transport protocols. In such cases, the upper/lower transport interfaces receive all IP packets where the payload type is TCP or (one of) the other transport protocol(s). One could imagine that a. switch between transport protocols would likely be done fully co-ordinated, however it is also possible to conduct such a switch in loose co-ordination or through independ¬ ent switching if it is possible to transcode between the headers of the new and the original transport protocol connections.

Furthermore it should be mentioned that while the control module has in the fore¬ going examples be described as a module separate from and interacting with upper and lower transport interfaces LTI and UTI, it could also in one embodiment be im- plemented in part or as a whole as an element of the LTI or the UTI or both.

It will be readily understood that a switching apparatus according to the present in¬ vention may be implemented by any computer or computing device which is suita¬ bly programmed to operate as described in the foregoing embodiments. Further- more, a switching apparatus according to embodiments of the invention may also be implemented by a computer program or computer program code which enables a computer or a computing device when being executed to act as a switch ing cte- vice according to the embodiments described hereinbefore. Computer or computing device thereby may mean a.ny device comprising one or more microprocessors making the device programmable to act as mentioned before. Examples of such devices are Personal Computers, notebooks, PDAs, mobile phones, smartphones, or the like. Moreover individual modules of embodiments of the invention as de¬ scribed hereinbefore may be implemented by program modules comprising com¬ puter program code which when being executed implements the function of the de¬ scribed module. An article of manufacture implementing an embodiment of the in¬ vention may comprise a data carrier or any medium having stored thereon or ern- bodying computer program code which enables a computer or a computing device to act as an apparatus as described in connection with the embodiments illustrated hereinbefore.

Claims

1 . An apparatus for switching between different implementations of a transport protocol, said apparatus comprising : an upper transport layer interface for connecting a plurality of dif¬ ferent transport protocol implementations with the layer above tri e trans¬ port layer; a lower transport interface for connecting said plurality of different transport protocol implementations with the layer below that transport layer, whereas said upper transport interface and said lower transport interface re¬ spectively are adapted to switch their connection between the different transport protocol implementation based on switching information, said apparatus further comprising: a control module for determining the switching information for switching the connection between the upper interface and the plurality of transport protocol implementations and the lower transport interface and the plurality of transport protocol implementations such that for a. certain communication session the transport protocol implementation which yields an optimised data flow is selected.

2. The apparatus of claim 1 , wherein said upper and said lower trans¬ port interfaces respectively comprise: a module for assigning one of said plurality of different TCP imple- mentations to a specific communications session based on said switch¬ ing information provided by said control module, and a module for checking the header of incoming and outgoin g pack¬ ets to identify the session to thereby determine to which of said plurality of different TCP implementations said incoming and outgoing packets should be ro uted.

3. The apparatus of claim 1 or 2, wherein said control module com¬ prises : a modu le for determining one or more characteristics which are representative of the type of network structure implemented below the transport layer to determine the transport protocol to be selected such that it is adapted to the underlying network structure.

4. The apparatus of claim 1 , 2 or 3, wherein said module for determining underlying network characteristics comprises : a module for using existing operating system functions to determine the underlying network characteristics.

5. The apparatus of one of the preceding claims, wherein said module for determining the underlying network characteristics comprises : a module for sending probing signals and for evaluating the return¬ ing responses to the probing signals to determine the underlying network characteristics based on said evaluation.

6. The apparatus of one of the preceding claims, wherein said module for determining the underlying network characteristics comprises : a module for establishing a communication with the other end point of the communication session and for negotiating with the corresponding module at the other end point of the communication session a suitable transport protocol implementation session to be used in the cornmunica- tion session.

7. The apparatus of one of the preceding claims, wherein said control module comprises: a module for determining the TCP implementation to be used based on the characteristics of the application which is requesting the communicatio n session.

8. The apparatus of one of the preceding claims, wherein said control module is adapted to determine said switching information before a communication using one of said plurality of different i mplementations of a transport protocol starts.

9. The apparatus of one of the preceding claims, wherein said control module being adapted to switch between said different transport protocol implementations on run-time during an on-going com¬ munication session.

10. The apparatus according to claim 9, wherein said control module comprises : a module for triggering the starting of a new transport protocol im¬ plementation to be used for switching to said new transport protocol im- plementation at run-time and a module for translating the contents of the TCP headers of the on¬ going transport protocol session such that the headers sent to and from the newly started TCP implementation match with the TCP headers as sent and received by the transport protocol implementation at the other communication endpoint for an ongoing communication session.

11. The apparatus of one of claims 9 or 10, wherein said control com¬ prises : a module for extracting header data from a previous transport pro- tocol session which is to be switched to a different transport protocol im¬ plementation, and a module for inserting said extracted transport protocol session header data into said newly opened transport protocol sassion such that the newly opened transport protocol session can resume the previous transport protocol session via a different transport protocol implementa¬ tion.

12. The apparatus of one of claims 9 to 11 , wherein said control module comprises : a module for in case of an on-going transport protocol session to be switched to a different transport protocol implementation at a first com- munication endpoint, negotiating with the corresponding module at the corresponding second communication end point that a switching is to be performed such that both control modules at those communication end points open an new transport protocol session directed to a different transport protocol implementation such that the on-going traffic is re- sumed through the newly opened transport protocol sessions and the different transport protocol implementations at both communication end points.

13. The apparatus of one of claims 9 to 12, wherein said control module is adapted to receive a triggering signal for triggering the switch to a different transport protocol implementation.

14. The apparatus of claim 13, wherein said triggering signal is gener¬ ated in response to one of the following mechanisms : a hand over during a mobile communication's session ; a change in quality of service during an on-going communication ses¬ sion ; a change in a hardware or a software module used in an on-going com¬ munication session.

15. The apparatus of one of claims 1 to 15, wherein said control module further comprises: a module for continuously monitoring one or more parameters based on which the determination which of the plurality of TCP imple- mentations should be used is being made; said module triggering a change to a different TCP version from the one currently being used if according to a set of predefined rules a change in the monitored one or more parameters indicates that said change is to be performed.

16. A method for switching between different implementations of a transport protocol, said method comprising: connecting a plurality of different implementations of a transport protocol with an upper transport layer interface for connecting said plu¬ rality of different transport protocol implementations with the layer above the transport layer; connecting said plurality of different implementations of a transport protocol with a lower transport interface for connecti ng said plurality of transport implementations with the layer below that transport layer, whereas switching the connection of said upper transport interface and said lower transport interface, respectively, between the different transport protocol implementations based on switching information, said method comprising: determining said switching information for switching the connection between the upper interface and the plurality of transport protocol im- plementations and the lower transport interface and the plurality of trans¬ port protocol implementations such that for a certain Gommunication ses¬ sion the transport protocol implementation which yields an optimised data-flow is selected.

17. The method of claim 16, further comprising: assigning one of said plurality of different TCP implementations to a specific communications session based on said switching information, and checking the header of incoming and outgoing packets to identify the session to thereby determine to which of said plurality of different

TCP implementations said incoming and outgoing packets should be routed.

18. The method of claim 16 or 17, comprising: determining one or more characteristics which are representative of the type of network structure implemented below the transport layer to determine the transport protocol to be selected such that it is adapted to the underlying network structure

19. The method of claim 16, 17 or 18, wherein said method further com¬ prises : using existing operating system functions to determine the under¬ lying network characteristics.

20. The method of one of claims 16 to 19, wherein said method further comprises : sending probing signals and for evaluating the returning responses to the probing signals to determine the underlying network characteristics based on said evaluation.

21. The method of one of claims 16 to 20, wherein said method further comprises : establishing a communication with the other end point of the com¬ munication session and for negotiating with the corresponding modu le at the other end point of the communication session a suitable transport protocol implementation session to be used in the communication ses- sion.

22. The method of one of claims 16 to 21 , wherein said method further comprises: determining the TCP implementation to be used based on the characteristics of the application which is requesting the communication session.

23. The method of one of claims 16 to 22, wherein said method further comprises: determining said switching information before a communication using one of said plurality of different implementations of a transport protocol starts.

24. The method of one of claims 16 to 23, further comprising: switching between said different transport protocol implementa¬ tions on run-time during an on-going communication session.

25. The method according to claim 24, wherein said method further corn- prises : triggering the starting of a new transport protocol implementation to be used for switching to said new transport protocol implementation at run-time and translating the contents of the TCP headers of the ongoing trans¬ port protocol session such that the headers sent to and from the nev\/ly started TCP implementation match with the TCP headers as sent and received by the transport protocol implementation at the other communi- cation endpoint for an ongoing communication session.

26. The method of one of claims 24 or 25, further comprising: extracting header data from a previous transport protocol session which is to be switched to a different transport protocol implementation, and inserting said extracted transport protocol session header data into said newly opened transport protocol session such that the nev^ly opened transport protocol session can resume the previous transport protocol session via a different transport protocol implementation.

27. The method of one of claims 24 to 26, wherein method further com¬ prises : in case of an on-going transport protocol session to be switched ID a different transport protocol implementation at a first communication endpoint, negotiating with the corresponding module at the correspond¬ ing second communication end point that a switching is to be performed such that both control modules at those communication end points open an new transport protocol session directed to a different transport proto¬ col implementation such that the on-going traffic is resu med through the newly opened transport protocol sessions and the different transport protocol implementations at both communication end poi nts.

28. The method of one of claims 24 to 27, further comprising: receiving a triggering signal for triggering the switch to a different transport protocol implementation.

29. The method of claim 28, wherein said triggering signal is generated in response to one of the following mechanisms : a hand over during a mobile communication's session ; a change in quality of service during an on-going communication ses¬ sion ; a change in a hardware or a software module used in an on-going com¬ munication session.

30. The method of one of claims 16 to 29, further comprising: continuously monitoring one or more parameters based on which the determination which of the plurality of TCP implementations should be used is being made; changing to a different TCP version from the one currently being used if according to a set of predefined rules a change in the monitored one or more parameters indicates that said change is to be performed.

31. A computer program comprisi ng computer program code which when being executed on a computer enables said computer to carry out a method according to one of claims ^"16 to 30.