Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
  • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers

Definitions

• 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.
• TCP/IP transmission control protocol/internet protocol
• ISO-OSI layer model 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.
• TCP/IP 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.
• the Internet layer 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.
• the transport layer there is located the application layer which is responsible for handling applications such as the ones shown in Fig. 2.
• 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.
• TCP interprets the loss of a segment as an indication of network congestion and accordingly adjusts the sending rate accordingly.
• a mobile network being the underly ⁇ ing network
• 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.
• special flavours of TCP which can be applied in case of fragile links.
• 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).
• high-delay e.g. satellite links.
• these versions result in considerable performance gains for each of such cases.
• these optimisations are limited to the indi ⁇ vidual application for which they have been provided.
• 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.
• an appa ⁇ ratus for switching between different implementations of a transport protocol 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.
• 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.
• the embodiment may make use of existing protocol implementa ⁇ tions and is therefore particularly advantageous when being implemented in already existing systems (legacy systems).
• 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.
• 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.
• the module for determining underlying network char ⁇ acteristics comprises : a module for using existing operating system functions to determine the underlying network characteristics.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a method for switching between different implementations of a transport protocol 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• TCPx and TCPy may be> stan- dard TCP implementations which are connected respectively to the upper and lower transport interfaces LTI and UTI.
• the TCP implementation which may either be TCPx or TCPy depending on the network characteristics of the underlying layers below the transport layer.
• 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.
• 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.
• 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.
• 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.
• API application programming interface
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• the evaluation module EVAL may then decide which TCP flavour should be used for optimising communication efficiency.
• 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.
• 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.
• 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.
• 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.
• the evaluation module EVAL 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)).
• the evaluation module can then conclude which underly- ing network structure is present and which TCP version should accordingly be used.
• 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.
• 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.
• 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.
• 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.
• an operating sys ⁇ tem function such as "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.
• 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.
• 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.
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a knowledge base e.g. in form of a lookup-table
• the two communication endpoints A and B or at least endpoint Av which initiates the session is capable of switching between TCP implementations.
• 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.
• 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.
• 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.
• 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.
• endpoint A 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.
• 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.
• 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.
• 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.
• Endpoint A 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.
• 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.
• 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 impriven- tation to the application on the side of A thereby are intercepted and not forwarded.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• a TCP header information translation as described in a previous embodiment
• a TCP header data injection as described in connection with another previous embodiment
• the establishing of a completely new TCP session could be used.
• 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 .
• TCP version could be a change in the quality of a connection or a service, e.g. the signal strength.
• 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.
• 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).
• the payload type is TCP or (one of) the other transport protocol(s).
• 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.
• 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.
• a switching apparatus 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.
• 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Communication Control (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=34959311

Family Applications (1)

Country Status (3)

Families Citing this family (10)

Family Cites Families (5)

• 2004
  • 2004-10-29 EP EP04791354A patent/EP1856880A2/de not_active Withdrawn
  • 2004-10-29 JP JP2007538279A patent/JP4642855B2/ja not_active Expired - Fee Related
  • 2004-10-29 WO PCT/EP2004/052738 patent/WO2006045345A2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events