WO2008093069A1

WO2008093069A1 - Communications system and method

Info

Publication number: WO2008093069A1
Application number: PCT/GB2008/000295
Authority: WO
Inventors: Khong Neng Choong; Andy Lock Yen Low; Cheng Suan Lee; Charles Aik Hun Chong
Original assignee: British Telecommunications Public Limited Company
Priority date: 2007-01-31
Filing date: 2008-01-29
Publication date: 2008-08-07

Abstract

There is provided a method of dynamically switching the mobility management protocol of data packets in a communication session. The method comprises routing packets (350, 355) of a communications session across a network (130) between a mobile terminal (105) and a corresponding node (110) according to a first mobility management protocol (MIP) (235); monitoring a quality parameter of the communications session (240); in response to determining that the quality parameter has degraded below a predetermined quality parameter threshold (240Y), routing packets of the communications session according to a second mobility management protocol (SIP) (270).

Description

COMMUNICATIONS SYSTEM AND METHOD

Field of the Invention

The present invention relates to mobile communications and in particular to switching of mobility management protocols and respective data packet routing used for maintaining communications sessions with mobile terminals.

Background of the Invention

Wireless Internet access has recently gained significant attention as wireless and mobile communications and networking becomes widespread. The convergence of different types of networks has made VoIP and other computing activities both practical and economical. To cater for the requirements of wireless connectivity and connection handover, several mobility management schemes have been proposed and implemented, the two most common mobility management protocols being the Session Initialization Protocol (SIP) and Mobile IP (MIP). These protocols operate at different layers and provide diverse functionality, and the most optimal one to use is dependent on the type of mobility and other circumstances. Indeed various hybrid models have been proposed. For example, C. Politis, et al., "Multilayer mobility management for all-IP networks: pure SIP vs. hybrid SIP/mobile IP," Vehicular Technology Conference, 2003, VTC 2003-spring, the 57th IEEE Semiannual, 2003 proposes defining SIP to serve real time applications and MIP is for non real time application. In Q. Wang and M. A. Abu-Rgheff, "Integrated Mobile IP and SIP Approach for Advanced Location Management", Proc. IEE 4^th International Conference on 3G Mobile Communication Technologies, London, UK, Jun 2003, pp. 206-210, MIP is used for wired or stationary mobile nodes and SIP for wireless or frequently moving mobile nodes.

However the most optimal mobility management protocol to use is typically also dependent on user requirements including cost and quality of service, as well as network factors such as network congestion and resources, and router distance between the mobile terminal and a corresponding node.

Summary of the Invention

In one aspect the present invention provides a method of dynamically switching the mobility management protocol such as SIP or MIP of data packets in a communications session such as a VoIP call in order to adjust the routing of the data packets carrying the communications session across a network between a mobile terminal and a corresponding node. By switching the mobility management protocol during a communications session rather than just defining this at the start of the communications session, the data packets carrying the communications session can be re-routed across the network in response to changes in either the network or user preferences which could affect the quality or wanted quality of the communications session.

In this context a> mobility management protocol is a control and/or signalling protocol for creating and modifying (and in some cases terminating) a communications session with two or more participants. Examples include session initiation protocol (SIP), mobile internet protocol (MIP), stream control transmission protocol (SCTP) and datagram congestions control protocol (DCCP).

The communications session may be any stream or group of data packets carrying audio, video or other data across a network between two or more end points such as a mobile terminal and corresponding node. Examples include real time transport protocol (RTP), file transfer, protocol (FTP), and hypertext transfer protocol (HTTP).

In an embodiment, the mobility management protocol is switched in response to changes in a quality parameter of the communications session. For example a user of the session may set a threshold packet latency or dropped packet level, and if the packet latency or dropped packet level of the communications session degrades below the respective threshold, then routing of data packets carrying the communications session across the network is switched to be routed according to a different mobility management protocol; for example from MIP to SIP. This change in routing may then have the effect of improving the quality of the communications session, for example improving its packet latency or dropped packet levels.

In an embodiment the quality parameter (eg packet delay) is monitored, for example by receiving and analysing real time control protocol (RTCP) packets associated with an RTP communications session as is known. The quality parameter threshold (eg minimum packet delay) can be specified by the user or the network according to a defined quality of service requirement.

In an embodiment, the dynamic switching of mobility management protocols is implemented on a mobile terminal and a corresponding node using a standard network supporting both mobility management protocols. A universal adapter is used on each device to change the destination and sending addresses of data packets carrying the communications session according to the mobility management protocol currently in use.

In an embodiment the mobile terminal is coupled to the network, and hence the corresponding node, using one or more wired or wireless connections as the mobile terminal moves about. Re-routing of the data packets of the communications session may be further dependent on a change in the connection to the network. Examples of wireless connections include one or more Wi-Fi networks, one or more GPRS connections, one or more Wi-Max connections.

Switching of the mobility management protocol may be made further dependent on network conditions; for example a nearby RTP translator, and/or the number of routers between the mobile terminal and the corresponding node.

As used in this specification, the term core engine refers to a software module or other functionality which creates, sends and receives data packets. This is typically a combined transport and network layer module which will be familiar to those skilled in the art and is therefore not further discussed here. Well known examples include the UDP/IP (user datagram protocol/internet protocol) core engine typically used for real-time communications sessions for example delivering voice calls (RTP), or the TCP/IP (transport control protocol/internet protocol) core engine typically used for non real-time communications sessions for example delivering web pages (HTTP).

Brief Description of the Drawings

Embodiments will now be described with respect to the following drawings, by way of example only and without intending to be limiting, in which:

Figure 1 is a schematic of a communications system according to an embodiment;

Figure 2 is a flow diagram of a method of dynamically switching routing protocols according to an embodiment;

Figure 3 is a schematic illustrating a universal adapter according to an embodiment;

Figure 4 is a signalling diagram illustrating MIP registration;

Figure 5 is a signalling diagram illustrating SIP registration;

Figure 6 is a schematic illustrating the universal adapter of Figure 3 in more detail; and

Figure 7 illustrates a mobile terminal.

Detailed Description

Figure 1 illustrates a communication system 100 comprising a mobile terminal 105 such as a mobile phone or laptop computer and a corresponding node 110 such as a VoIP phone or Web Server coupled together by a network 130 such as the Internet. The mobile terminal 105 and corresponding node 110 each comprise a universal adapter 115. The network comprises a number of routers 135, a number of DHCP servers, and a number of IEEE802.21 information servers 155. The network 130 is coupled to two wireless base stations 120a and 120b such as Wi-Fi base stations, each having an RTP translator 125a and 125b respectively. The mobile terminal 105 connects to the network 130 initially using a first wireless (eg Wi-Fi) link or connection 160a with the first base station 120a and then as the mobile terminal 105 moves it connects to the network using a second wireless connection 160b with the second base station 120b.

The network also comprises various SIP proxies 140 used to facilitate SIP signalling in order to setup and tear down communications sessions across the network 130 between two endpoints. As is known, the SIP mobility management protocol may be used to setup an RTP communications session between two applications on different computing platforms, for example a VoIP call between the mobile terminal 105 and the corresponding node 110. Once setup, RTP packets carrying the VoIP call are routed directly between the mobile terminal 105 and corresponding node 110. When the mobile terminal 105 moves and connects to another base station 120b (from 120a), it receives a new temporary IP address associated with a local server (eg 120b) from the DHCP server 150 as is known. A new SIP session is setup using a REINVITE message sent to the corresponding node 110 together with the mobile terminal's new temporary IP address. Subsequent RTP packets of the VoIP call are then sent via the new route between the new temporary IP address of the mobile terminal 105 and the continuing IP address of the corresponding node 110 setup by the new SIP signalling session.

The network also comprises various MIP capable servers 145 used to facilitate the MIP mobility management protocol and associated data packet routing across the network 130. In the example of the mobile terminal 105, a permanent or home IP address is assigned and associated with a home agent 145ha in the mobile terminal's home network (including base station 120a here). When the mobile terminal 105 moves away from' its home network to a different network, in this example including the second base station 120b, the mobile terminal receives a new temporary IP address from the DHCP server 150 as before. A MIP foreign agent 145fa within the new or moved-to network allows packets sent to the mobile terminal's home address to be forwarded by the home agent 145ha to the foreign agent 145fa and on to the mobile terminal at its new temporary IP address as is known. If the mobile terminal moves again to a new network, a new foreign agent is used to route the packets to from the home agent 145ha. The mobile terminal 105 typically sends packets directly to the other node (eg 110) rather than via the home agent, resulting in the well known triangular MIP routing arrangement.

The RTP translators 125a and 125b may be used to briefly forward RTP packets on to a new network which the mobile terminal 105 has handed over to. For example packets received from the corresponding node 110 at the first base station 120a after the mobile terminal 105 has moved to or handed over to the second base station 120b are forwarded to the second base station 120b for forwarding to the mobile terminal 105. This situation may occur immediately following a change in the mobile terminals temporary IP address but before this change has been implemented at the corresponding node 110 which is still sending packets to the mobile terminal's previous temporary IP address. Whilst RTP translators may not be used for real-time applications such as VoIP due to the re-routing delay, they are useful in non-real time applications such as file transfer in order to avoid missing packets.

The IEEE802.21 information server 155 facilitates seamless handover between networks, for example handover of the mobile terminal 105 between different connection points (120a and 120b) to the network 130. It provides information such as whether the new network connection point (eg 120b) has an RTP translator 120b, and the router distance or number of routers 135 between the mobile terminal 105 and the corresponding node 110.

Figure 2 illustrates a method of dynamically changing the mobility management protocol and associated routing of packets in a communications session, for example a VoIP/RTP session. This method 200 is implemented in the universal adapter 115 when a new application such as a VoIP call is being setup and carried out during mobility of one or both of the endpoints (105 or 110) to the call. When a communications session setup command is issued by an application such as a VoIP, Email, Browser or other user application and which interfaces with the universal adapter 115, this is received at step 205 by the method 200. The method then determines whether the application is real time or non-real time at step 210. If the application is real time (210Y), for example a VoIP phone call application, the SIP mobility management protocol is assigned to the application's new communications session at step 212. If the application is not real time (210N), for example a file transfer application such as a web page download to a browser application, the MIP mobility management protocol is assigned to the application's new communications session at step 215.

The method then determines whether the mobile terminal (which is hosting the universal adapter and its method 200) has recorded any recent mobility at step 220. Recent mobility indicates that the mobile terminal 105 is likely to be moving and thus is likely to need to handover to another connection (160a or 160b) to the Internet 130 during the communications session being setup. Recent mobility can be determined from a mobility log within the universal adaptor and which tracks changes in temporary IP addresses for the mobile terminal and other mobility indicators. An example mobility log is illustrated in table 1 below.

TABLE 1 From the first three logs, it can be seen that the terminal with ID John-Mobile (for example the mobile terminal 105), has moved through 3 different networks, namely Tmobile-1, LinkSys-2 and 3Com-l, using the same network interface (and hence the same MAC address). There were changes on the IP addresses, but associated to the same Mac Address.

The fourth log indicates that there was a switch from John-Mobile to another terminal called John-Notebook. There was a change on the Mac Address column. This corresponds to personal mobility rather than the terminal mobility shown in the first three logs.

The fifth log, which includes a change of MAC address but the same machine or terminal ID, indicates that there was a change on the interface on John-Notebook. For example, turning on WiMAX and shutting down WiFi. As this is neither terminal mobility nor personal mobility, no action needs to be taken as packets addressed to the IP address associated with the WiMAX interface (192.168.2.7) can be routed directly to the WiFi interface within the John-Notebook terminal.

Recent mobility, as determined at step 220, may correspond to a new log entry within the mobility log and corresponding to a personal or terminal mobility change within the last 2_x minutes, or any other suitable predetermined duration. If there has been no personal or terminal mobility log entry or change within this predetermined duration (220N), the method moves on to start a new connection session using the assigned mobility management protocol at step 235. However if the method determines that there has been personal or terminal mobility within the predetermined duration (220Y), the method moves on to determine whether the latest mobility log (from Table 1) indicates terminal mobility at step 225. As noted above, personal mobility is when a communications session moves to a different terminal, for example from a mobile phone to a notebook within the same network. By comparison, terminal mobility occurs when the same terminal (eg- mobile phone) moves between two different networks. • If the method determines terminal mobility (225Y), then the method assigns the MIP mobility management protocol to the new communications session at step 227, and moves on to start a new connection session using the assigned mobility management protocol at step 235. However, if the method determines that the latest log entry did not relate to terminal mobility (225N), for example the log related to personal mobility, then the method assigns the SIP mobility management protocol to the new communications session at step 230, and moves on to start a new connection session using the assigned mobility management protocol at step 235.

A new connection session using the assigned mobility management protocol (SIP or MIP in this embodiment) is started or established at step 235. This is described in more detail below, but in one embodiment for a SIP mobility management protocol this involves calling a SIP client in order to setup the communications session, or for a MIP mobility management protocol this may involve signalling to invoke a MIP foreign agent if the mobile terminal 105 has moved away from its home network.

During the communications session, for example a VoIP voice call, the method monitors the session performance or quality and determines at step 240 whether this has dropped below a predetermined threshold or has dropped a predetermined amount since the last monitoring period. For example a predetermined packet delay or dropped packet rate (or change) may be used. If the performance of the communications session drops below the performance threshold or by the predetermined amount (240Y), the method then determines whether MIP was initially assigned to setup the communications session and ' is being used at step 245.

Various methods of monitoring network performance will be known to those skilled in the art, and typically involve receiving performance indicators or quality parameters from the network. For example the real time transport control protocol (RTCP) will deliver network performance indicators such as packet latency to an application (eg VoIP) using the corresponding real time transport protocol (RTP). If MIP is being used (245Y), the method monitors for a network change at step 250. If the mobile terminal 105 does not change network (250N), for example from 120a to 120b, within a predetermined time (for example 2 minutes), then the method returns to monitoring performance for the predetermined performance threshold or predetermined performance change (drop) since the last monitoring period at step 240. The existing mobility management protocol (MIP) is maintained where a network change hasn't occurred within the predetermined time (250N).

A network handover or change will typically instigate a new SIP session sending a REINVITE message to the corresponding node 110 when using the SIP protocol as is known. When using the MIP protocol, network handover will typically instigate registering with a new foreign agent 145fa in the case of MIP as is known.

When a network handover has taken place (250Y), and before any changes associated with the mobility management protocol are undertaken, the method first determines whether the application is real time (eg VoIP) and if so whether there is only one corresponding node 110 involved in the communications session at step 255 - as opposed to for example a conference call involving the mobile terminal 105 and two corresponding nodes 110. If the application is real time and there is only one corresponding node (255Y), for example a VoIP call between two parties and not a conference call involving three or more parties, then the method moves to switch to the SIP mobility management protocol at step 270. If however the application is real time (eg VoIP) but involves more than one corresponding node (eg voice or video conference call), or the application is not real time (255N), then the method determines whether there are RTP translators 125a and 125b near the old 120a and new 120b networks connecting the mobile terminal 105 to the network 130 at step 260. This information may be determined from the IEEE802.21 information server 155. The definition of near may be any suitable network parameter, for example 100ms to reach the respective RTP translator 125a or 125b from the respective mobile terminal access point 120a or 120b. If there are RTP translators 125a and 125b nearby the respective networks 120a and 120b (260Y), then the method moves to switch to the SIP mobility management protocol at step 270. If however there is no RTP translator 125a or 125b near one or both of the connection networks 120a and 120b (260N), then the method determines whether the router distance between the mobile terminal 105 and the corresponding node 110 is greater than a predetermined router number at step 265. This information can also be obtained form the IEE802.21 information server 155. An example predetermined router number is eight routers 135. If the router distance is less than the predetermined router number (265N), then the method returns to the performance monitoring step 240 without changing the mobility management protocol (from MIP). Thus if there is no RTP translator 125a or 125b nearby, and the router distance is not too large, the communications session remains using the MIP routing protocol. If however the router distance is greater than the predetermined router number (265Y), then the method moves to switch to the SIP mobility management protocol at step 270.

The switch to the SIP mobility management protocol at step 270 is described in more detail below, but in one embodiment invokes a SIP client in order to determine the correct IP addresses of the mobile terminal 105 and corresponding node 110 and to modify these addresses as appropriate in the RTP packets of the communications session. Following the switch to SIP, the method returns to monitoring the performance of the communications session at step 240.

When the performance drops using SIP (240Y and 245N), the method determines whether the communications session is currently using the lowest VoIP codec at step 275. In different embodiments using different user applications a suitable set of codecs may be available; however some user applications will not provide different codecs. Because SIP can control the communications session directly between the mobile terminal 105 and corresponding node 110 (unlike MIP), different codec rates can be specified for the communications session of some user applications, and these can be changed during the session as is known. A lower codec rate will have a lower data rate for transferring call data, however it may be more tolerant of packet delays. If the communications session is not using the lowest VoIP codec rate (275N), then the method switches the communications session to a lower codec rate at step 280. The method then returns to monitoring the performance of the communications session at step 240. If however the lowest rate VoIP codec is already being used (275Y), the method informs the user than they should upgrade their communications package at step 285.

The communications package the user of the mobile terminal 105 has signed up for will typically include certain quality of service features (minimum bandwidth allocation) for an agreed cost per unit (time or data). The performance of the communications session may have dropped due to congestion on the network 130 for example, in which case lower cost packages may have their allocated bandwidth reduced, impacting on the quality of service of any communications sessions they may have at that time. The QoS of these sessions may be improved by upgrading to a higher (perhaps more expensive) package which allocates greater bandwidth for example.

The need or suggestion to upgrade the package may be informed to the user using a graphical user interface on the mobile terminal. The method awaits a response from the user at step 288. If the user does not approve of the package upgrade (288N), the method returns to monitoring the performance of the communications session at step 240. If however the user approves of the package upgrade (288Y), the method instigates the package upgrade at step 290. This may involve a negotiation protocol with the service provider to the user as would be appreciated by those skilled in the art, in order to increase the network resources allocated to the mobile terminal 105. Following package upgrade, the method returns to the initialisation part of the method at step 210. The method then again determines a mobility management protocol assignment (SIP or MIP) at steps 210 - 230. At step 235, instead of starting a new communications session using the newly assigned mobility management protocol (MIP or SIP), a mobility management protocol switch (from SIP to MIP) may be made if required and as described below in more detail. Figure 3 illustrates a mechanism for switching between MIP and SIP routing protocols using a universal adaptor comprising a universal interface 310, a mobility manager 315, and respective MIP and SIP registration modules 320 and 325 respectively. A user application such as a VoIP application 305 interfaces with the universal interface μsing standard API calls including create packet, send/receive packet, and new session. Known user application packages typically call specific session/mobility management protocol modules (eg SIP) directly and so are typically tightly-coupled with one specific protocol. If a different mobility management protocol is to be used (eg MIP), then a different version of the user application (VoIP with MIP instead of VoIP with SIP) must be used. In contrast, the universal interface includes SIP and MIP (and possibly other) protocol modules 320 and 325, and abstracts the differences between any such protocol to the application. The universal interface also comprises a number of application libraries 330 so that it can interface with a number of different user applications using the standard API calls. The examples of a VoIP, Browser and Email client libraries are shown. Following a create command from the user application 305, the respective application library 330 will generate one or more packets (typically RTP for VoIP applications) with the payload from the create command. These are applied to a core engine module 340 which manipulate packet creation, sending and receiving at the transport and network layers in order to insert appropriate IP addresses into the RTP packets for the VoIP (or SMTP for Email and HTTP for browser) communications session.

A send RTP packet 350 is shown having a header with an IP destination address (IPdest) and an IP source address (IPsource). If using the MIP routing protocol, IPdest=CN, the IP address of the corresponding node 110, and IPsource=FA, the IP address of the foreign agent 145fa. If using the SIP routing protocol, IPdest=CN, the IP address of the corresponding node 110, and IPsource=Temp, the temporary IP address assigned to the mobile terminal 105 by the DHCP server 155, and associated with a respective connection (160a or 160b) to the network 130. The core is arranged to insert the appropriate IPdest and IPsource into RTP packets for transmission to the corresponding node 110. A receive RTP packet 355 is shown also having a header with an IP destination address (IPdest) and an IP source address (IPsource). If using the MIP routing protocol, IPdest=Temp, the temporary IP address assigned to the mobile terminal 105 by the DHCP server 155, and associated with a respective connection (160a or 160b) to the network 130, and IPsource=HA, the IP address of the home agent 145ha. If using the SIP routing protocol, IPdest=Temp, and IPsource=CN, the IP address of the corresponding node 110. The core 340 is arranged to direct the payload of these received RTP packets to the appropriate (VoIP) user application 305 using the appropriate IPdest and IPsource values.

If there is a switch from say MIP to SIP, the core starts inserting Temp instead of FA into the IPsource field of the send packets 350. Similarly, instead of looking for RTP packets with IPdest^Temp and IPsource=HA to send the payload to the user application 305, the core looks instead for packets with IPdest=Temp and IPsource=CN. There may be some period of overlap where both sets of packet payloads are sent to the user application 305 in order to recover any delayed packets using the old mobility management protocol.

The relevant IPdest and IPsource IP address values are controlled in the core engine 340 by the mobility manager 315. The mobility manager operates according to the method 200 of figure 2, and step 270 (switching to SIP) comprises replacing the IPdest and IPsource values in the core 340 from the MIP mobility management protocol with corresponding values for the SIP protocol. Step 235 (starting new session) comprises calling the core 340 and inserting the appropriate (MIP or SIP) IPdest and IPsource values. These SIP or MIP IPdest and IPsource values are obtained by the mobility manager 315 by calling the SIP or MIP registration modules 320 or 325 as appropriate. When switching from SIP to MIP (step 245 following package upgrade), the IPdest and IPsource parameters from the SIP mobility management protocol are replaced with corresponding values associated with the MIP mobility management protocol.

The mobility manager 315 is also arranged to receive any RTCP packets in order to monitor one or more quality parameters of the RTP communications session, for example packet latency. In alternative embodiments using different communications sessions, equivalent methods of monitoring for quality parameters may be used.

Figure 4 illustrates a signalling diagram of the MIP registration process used by the MIP registration module 320. A detailed knowledge of the MIP registration procedure will be known to those skilled in the art, and only an overview description is given here for explanatory purposes. A foreign agent 145fa advertises its presence to the mobile terminal 105, for example as part of the mobile terminal's DHCP discovery procedure when it changes networks. The mobile terminal 105 request registration with the foreign agent 145fa and gets a corresponding temporary IP address from the DHCP server 150 which is also provided to the registered MIP foreign agent 145 fa. The MIP foreign agent 145 fa requests registration with the mobile terminal's home agent 145ha in the same network or sub-network as the mobile terminal's permanent IP address. Following approval from the MIP home agent 145ha, which may include various authentication procedures as are known, the MIP foreign agent 145fa replies to the mobile terminal's foreign agent registration request. The mobile terminal 105 then forwards packets associated with a communications session directly to a corresponding node 110. However return packets from the corresponding node are sent to the mobile terminal's permanent IP address and forwarded to the foreign agent 145fa by the home agent 145ha, and then on to the mobile terminal 105. Packets from the same communications session are then able to follow the mobile terminal 105 as it moves between networks and changes its (temporarily assigned) IP address.

Figure 5 illustrates a signalling diagram of the SIP registration process used by the SIP registration module 325. A detailed knowledge of the SIP registration procedure will be known to those skilled in the art, and only an overview description is given here for explanatory purposes. The mobile terminal 105 gets a temporary IP address from the DHCP server 150, and registers with a SIP server 140. The SIP module 325 then sends a SIP invite message to the corresponding node 110, which is received by a corresponding SIP server servicing the corresponding node 110. Following an OK response from the corresponding node 110, the RTP session can be started using the direct IP addresses of the corresponding node 110 and the mobile terminal 105, though in the later case this will be the DHCP temporarily assigned IP address. Packets from the same communications session are able to follow the mobile terminal 105 as it moves between networks and changes its (temporarily assigned) IP address by using SIP RE-INVITE messages which seamlessly join an RTP session using the different IP addresses for the mobile terminal 105 as is known.

Returning to figure 3, when a new session call is received from the user application 305 by the universal interface 310, the mobility manager 315 checks the mobility log (Table 1) as previously described in order to determine which mobility management protocol (SIP or MIP) to assign the to the new session. The mobility manager 315 then calls the MIP (320) or SIP (325) registration modules as appropriate. The respective registration module (320 or 325) communicates with various network components as described above with respect to figures 4 and 5 in order to set up the new session according to the respective mobility management protocol. In the case of SIP, the SIP registration module 325 of the corresponding node 110 is involved in the session setup and is configured to pass the appropriate source and destination addresses (IPsource and IPdest) parameters to the mobility manager 315 of the mobile terminal 105, and vice versa. The SIP registration module 325 of the corresponding node 110 also sets up the communications session to allow the user application (eg VoIP call) of the corresponding node to join the communications session as is known. In the case of MIP, because the corresponding node 110 is not involved in the session setup, the mobility manager 315 of the mobile terminal 105 signals the mobility manager 315 of the corresponding node 110 with the appropriate IPdest and IPsource addresses to use with the data packets it is sending and receiving for the communications session - eg IPdest=HA and IPsource=CN for sending (350), and IPdest=CN and IPsource=FA for receiving.

Figure 6 illustrates a mobile terminal 105 in more detail according to an embodiment. The mobile terminal 105 is connected to the network 130 and an IEEE802.11 information server 155 as shown. Typically this connection (160a or 160b) to the network will be via a wireless network or connection, although wired connections may also be used. The mobile terminal 105 comprises a user application 305 such as a VoIP phone call application which interfaces with a universal adapter 115. The application 305 is associated with a configuration file 655, a number of VoIP codecs 660, and a media manager 670. The universal adapter 115 comprises a universal interface 310, and a mobility manager 315 as previously described with respect to figure 3, a mobility log 615 as previously described with respect to Table 1, together with a number of mobility protocol modules 605, a persistence manager 620, and a QoS manager 630.

The application 305 could be any networking application, from conventional Telnet, FTP, web browsing to today's multimedia real time application such as VoIP and video streaming. The coding of these applications can exploit the flexibility of the universal adapter 115 through a standardised API. These applications need be written only once and can then run on any mobility management protocol in the future. The universal adapter provides that the applications will always be connected by seamlessly swapping the underlying mobility management protocols, and abstracting application developers ' from the intricacies of managing the underlying network conditions.

Using the configuration file 655, application developers or end-users can first configure the requirements and adaptability of the application 305. By first stating the application type, followed by the required QoS level, applications 305 can relay their requirements/preferences to the universal adapter 115, which in turn forward them to the respective network control elements, such as the QoS Manager 630 and Persistence Manager 620. The configuration file can be used to set user defined performance parameters such as the predetermined performance drop (see 240), or the router distance (265 - eg 8). .

The media manager 670 is responsible for switching the (eg VoIP) codec 660 currently used by the application 305 based on a QoS report given by the QoS Manager 630. There is a pool of codecs, each with a different bitrate to cater for different network conditions, for example wired verses wireless. The lowest bitrate is generally of lower quality, but could sustain over low bandwidth connections. As discussed previously, the universal interface 310 is the standard interface which all applications 305 conform to in order to take advantage of the mobility features supported by the universal adapter 115. All applications follow a standard step-by-step instruction to configure, register, connect, manage and disconnect, from the universal adaptor 115. The universal adapter 115 is responsible for customizing the connectivity property according to the configuration file 655 configured by the user, and then to register the application with the appropriately configured universal interface 310 in order to adopt the appropriate mobility management protocol (eg MIP or SIP) to communicate with the corresponding node.

As discussed previously, the mobility manager 315 decides when to switch the mobility management protocol. This can be done by either referring to the user configuration, or by inferring based on the network conditions, i.e. location of the corresponding node 110 or distance of the CN from the current mobile terminal 105. SIP tends to perform better than MIP when the router distance is larger. However, this applies only for inter-domain handover, but not the case for intra-domain handover. Also the link delay can be used to switch mobility management protocols, noting that the overall signalling delay to handle handoff will considerably increase. This is particularly true in the SIP inter-domain handover. It can be seen then that switching of the underlying mobility management protocol can be based on a number of user defined connectivity properties (eg packet latency level) and network conditions (eg router distance).

The IEEE802.21 Information Server (IS) is a repository of network information within a geographical area to facilitate handovers and possibly for other network enhancement purposes. It includes support for various information elements (IE). IE can be classified into three groups: general network information, link layer information and higher layer information. Detailed of the IS can be found from the IEEE standard site.

The persistence manager 620 is in charge of extending the connectivity of conventional applications. Its main functionality is to mimic the availability of the corresponding node 110 even with brief interruptions to network connectivity. The persistence manager 630 keeps the connection request from the application 305 in a loop until the next network is detected; and will be well known to those skilled in the art.

The mobility protocol modules 605 perform various functions such as registration (modules 320, 325), session management including sending Re-invite, Transfer etc., and querying IP addresses of HA or FA.

The embodiment provides a universal adapter 115 that dynamically switches the underlying mobility management or routing protocols (e.g. MIP or SIP) adaptively based on the network characteristics (eg packet delay due to congestion) and user preferences (QoS requirements, pricing and security levels). Unlike existing integration/hybrid MIP/SIP schemes which statically assign specific applications to use a particular mobility management or routing protocol, the embodiment triggers the mobile terminal 105 to change its routing or mobility management protocol customized to the requirements of different applications 305 and according to user preferences. For example, it is often recognised that SIP supports better personal mobility, though is less optimal for terminal mobility (switching terminals as opposed to switching locations on the same terminal). However users who frequently use multiple terminals at any location may prefer to run all their mobile application on top of SIP. Users who are less mobile may prefer using just MIP for terminal mobility. Rather than writing each application (say VoIP) twice using both MIP and SIP, the underlying universal adapter 115 selects the appropriate mobility management protocol based on user configuration and network conditions. Because there is typically no single mobility management protocol that suits the needs or requirements of all users, it is advantageous to allow the underlying universal adapter to dynamically switch to the most optimal mobility management protocol during a communications session of an application, rather than just when setting up the session.

Whilst the embodiments have been described with respect to SIP and MIP, other mobility management protocols could additionally or alternatively be used. Examples include SCTP (stream control transmission protocol) and DCCP (datagram congestions control protocol)

Figure 7 illustrates a mobile terminal suitable for use with an embodiment in more detail. The mobile terminal 700 comprises one or more processors 705, 710, an antenna 715, one or more memory components 720, user actuable keys 725, a user display screen 730, and an audio interface comprising a speaker and a microphone 735.

One of the processors may be a dedicated function processor 705 for performing digital signal processing for connecting to an external network and implemented using one or more ASICs 705. A more general purpose microprocessor 710 may also be used to implement various functions by executing software modules stored in the memory 720; for example the routing of data packets according to different mobility management protocols by interfacing with a core engine 340, typically also implemented as a software module, in order to modify the IP packet addresses as previously described.

The memory 720 may comprise working memory such as (eg RAM) as well as one or more static memories (eg ROM) for storing third party applications such as the VoIP application 305 and universal interface functionality implemented as software modules such as the mobility manager 315.

The skilled person will recognise that the above-described apparatus and methods may be embodied as processor control code, for example on a carrier medium such as a disk, CD- or DVD-ROM, programmed memory such as read only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. For many applications embodiments of the invention will be implemented on a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). Thus the code may comprise conventional programme code or microcode or, for example code for setting up or controlling an ASIC or FPGA. The code may also comprise code for dynamically configuring re-configurable apparatus such as re-programmable logic gate arrays. Similarly the code may comprise code for a hardware description language such as Verilog ™ or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate, the code may be distributed between a plurality of coupled components in communication with one another. Where appropriate, the embodiments may also be implemented using code running on a field- (re)programmable analogue array or similar device in order to configure analogue hardware.

The skilled person will also appreciate that the various embodiments and specific features described with respect to them could be freely combined with the other embodiments or their specifically described features in general accordance with the above teaching. The skilled person will also recognise that various alterations and modifications can be made to specific examples described without departing from the scope of the appended claims.

Claims

1. A method of dynamically switching the mobility management protocol of data packets in a communication session, the method comprising: routing packets of a communications session across a network between a mobile terminal and a corresponding node according to a first mobility management protocol; monitoring a quality parameter of the communications session; in response to determining that the quality parameter has degraded below a predetermined quality parameter threshold, routing packets of the communications session according to a second mobility management protocol.

2. A method according to claim 1, wherein routing packets according to the first or second mobility management protocol comprises inserting destination and source addresses into the data packets which are associated with the respective mobility management protocol.

3. A method according to claim 1 or 2, wherein the quality parameter threshold is dependent on a user defined parameter and the monitored quality parameter is a network parameter determined from the network.

4. A method according to any one preceding claim, wherein the mobile terminal is coupled to the corresponding node using a first connection to the network, and wherein routing packets of the communications session according to the second mobility management protocol is further dependent on the mobile terminal connecting to the network using a second connection.

5. A method according to claim 4, wherein the first and second connections are wireless connections between the mobile terminal and respective base stations.

6. A method according to any one preceding claim, wherein routing packets of the communications session according to the second mobility management protocol is further dependent on a predetermined network condition.

7. A method according to claim 5, wherein the predetermined network condition comprises the number of routers between the mobile terminal and the corresponding node being greater than a predetermined router number.

8. A method according to any one preceding claim, wherein the first mobility management protocol is the mobile internet protocol and the second mobility management protocol is the session initiation protocol.

9. A communications system comprising: a mobile terminal and a corresponding node coupled to a network; means for routing data packets of a communications session across a network between the mobile terminal and the corresponding node according to a first mobility management protocol; means for monitoring a quality parameter of the communications session; means for dynamically switching the mobility management protocol of data packets in the communication session in response to determining that the quality parameter has degraded below a predetermined quality parameter threshold, in order to route the data packets according to a second mobility management protocol.

10. A system according to claim 9, wherein the means for monitoring the quality parameter comprises means for receiving the quality parameter from the network, and the means for routing data packets and the means for dynamically switching comprises a core engine arranged to insert network addresses into the data packets, the addresses corresponding to the respective mobility management protocol.

11. A mobile terminal in a communications system comprising a network and a corresponding node, the mobile terminal comprising: a processor arranged to route data packets of a communications session across a network between the mobile terminal and the corresponding node according to a first mobility management protocol; the processor further arranged to monitor a quality parameter of the communications session; the processor further arranged to dynamically switch the mobility management protocol of data packets in the communication session in response to determining that the quality parameter has degraded below a predetermined quality parameter threshold, in order to route the data packets according to a second mobility management protocol.