WO2008093046A2

WO2008093046A2 - Session dependent network handover

Info

Publication number: WO2008093046A2
Application number: PCT/GB2008/000221
Authority: WO
Inventors: Fernando Jover Aparicio; Gidon Moshe Reid
Original assignee: British Telecommunications Public Limited Company
Priority date: 2007-01-31
Filing date: 2008-01-22
Publication date: 2008-08-07
Also published as: WO2008093046A3; GB0701917D0

Abstract

A method of selecting a candidate network from a plurality of candidate networks available for a client device to handover to from a first network. The method determines if the client device is supporting one or more sessions over said first network, determines one or more session characteristics of one or more of said sessions, determines one or more criteria for a candidate network to support said one or more session characteristics, and processes candidate network session information retrieved from a data store, wherein the candidate network session information comprises session information reported dynamically by at least one other client device having a session in a candidate network. Which available candidate networks is suitable for handover by the client device is determined by comparing processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics.

Description

SESSION DEPENDENT NETWORK HANDOVER

The present invention relates to a method of selecting a candidate network for handover from a plurality of candidate networks. In particular but not exclusively, the invention relates to a client device performing a method of selecting a candidate handover network dependent on the real-time capability of the candidate network to support one or more on-going communications sessions in which the client device is participating.

Mobile communications devices are now capable of supporting applications which establish multi- media communications sessions in which video and audio signals are streamed in real-time. Examples of such communications sessions include sessions delivering one-to-one and many-to-one video conferencing sessions, and sessions delivering multi-cast and broadcast "television" type content. Such communication sessions usually utilise more than the threshold service capabilities of the supporting network infrastructure. Consequently, knowledge of the static, worse case, network characteristics does not provide a reliable indication of whether a network has in fact the minimum resources to support such types of communication sessions. As contention for bandwidth in a network varies according to the number of communication devices in the network and the resources required to support the communication sessions that are being run on the network, real-time knowledge of the network capabilities is advantageous. Many techniques are known in the art which enable the network operator to determine the current "load" on a network in terms of network characteristics such as the contention ratio for bandwidth, delay, jitter (variation of delay), etc and how these characteristics are impacting various types of network traffic according to the priority levels assigned.

Communications devices which have the ability to utilise more than one type of communications network and to utilise different communications protocols (e.g., the suite of IEEE communications protocols 802.x such as WiFi, WiMax, as well as protocols such as Bluetooth™, and other ad hoc communications networks) are also known in the art. Such communications devices may operate to handover from one communications network to another at a time or utilise more than one communications network at a time (which may require multiple handovers to be co-ordinated at the same and/or off-set timings). Where multiple communications networks are available a selection must be performed by the device to determine which are to be used to support either an entire communications session or one or more selected streams comprising components of the communications session (or sessions if a plurality of communication sessions can be supported at any time by the communications device). The term "client device" is used herein to refer to a communications device capable of utilising one or more communications networks in such a manner that the communications device can control the selection of the network for handover. Handover can be vertically (heterogeneously) or horizontally (homogeneously) performed (i.e., the client device may operate in more than one communications mode, such that it is capable of, say, utilising a short range wireless local area network utilising a wireless "broadband" type communications protocol and also at least one wide area network (such as a cellular mobile communications network for example).

The IEEE 802.21 standard proposes a network architecture where a "connection manager" hosted on a client device is able to take decisions regarding the connectivity of the client based on the networks available to the client device at the decision time. Whereas previous this decision would be based on

OSI layer 2 connectivity conditions such as signal strength, IEEE 802.21 seeks to enable communications devices to perform handovers based on network conditions between different networks (either vertically (heterogeneous network handover) as well as horizontally (homogeneous network handover). The connection manager determines the network features and/or user profiles and preferences prior to making the handover decision. More information and a tutorial on

IEEE802.21 can be accessed via the following web-site http://www.ieee802.org/21.

The ability of mobile communications devices to support communications services such as VoiceOver IP (VOIP) and to control the selection of handover networks is being addressed standards bodjes. Standard bodies such as the 802.21 working group are developing functionality to support Media Independent Handover (MIH) services which are intended to aid IP handover mechanisms between heterogeneous wired and wireless access systems. These handover systems provide a mechanism by which information such as the presence of neighbouring links and networks and their associated characteristics, can be delivered to mobile and other network nodes for the purposes of supporting better handover decisions. The MIH protocol comprises a unified set of common functions supporting a more diverse set of application specific protocols. More information on MIH and the design considerations for the common MIH protocol functions can be found at http://tools.ietf.ora/wq/mipshop/draft-hepworth-mipshop-mih-desiqn-considerations-01.

The OverDRIVE document "Current Approaches to IP multicast in a Mobile Environment" provides a general review of how SDP and SIP can be implemented in IP multicast environments. United States Patent Application number US20050237978 describes how a device running multiple sessions and connected to a first network can handover to a second network in a seamless manner (which may be implemented using SIP and SDP). Information on the sessions to be transferred must be shared by the device (or previous network) with the new (second) network prior to handover in order to continue the session through the new network.

In "Session Aware Network Controlled Interface Selection for Multi-homed hosts" Narayanan Venkitaraman, p. 1963, WCNC 2004/IEEE Communications Society, 0-7803-8344-3/04/$20.00© 2004 IEEE, describes a network-controlled architecture to enable multi-homed devices (devices which have multiple network interfaces independently connected to different networks) to effectively use all the available interfaces simultaneously. The choice of network interface is based on the network state and session characteristics. Venkitaraman describes how using multiple interfaces simultaneously provides greater aggregate bandwidth, but that the value derived by a user from out of a session increases only when the right streams are matched to the right interfaces and the selection of content adaptation handlers and network treatment of the stream is performed intelligently. In Venkitaraman, application awareness for the choice of network interface and adaptation preference is based on application type and user preferences. More specifically, Venkitaraman teaches that, as SIP is a session layer solution for session initiation, modification and termination, SIP can be used to enable a session originally destined to a given IP address to use a different one during the course of a session.

As SIP is an application level solution, SIP requires each application to be aware of the characteristics of the network layer and initiate migration. Venkitaraman proposes a "decision manager" which is implemented as middle-ware (i.e., which is hosted by a platform located remotely from the client device and which communicates with the client device over the communications network). The decision manager (DM) of Venkitaraman obtains session level information by residing in the control path of all sessions and which interacts with other network entities such as a user profile manager to get user preferences and a bandwidth broker to obtain network state information. This information is then used by the DM to determine the device interface to use for each stream and the adaptation policy which should be implemented. In Venkitaraman, in a wireless or converged network the DM can reside in a Softswitch which in the path of all control packets, for example, one which implements the functions of a SIP proxy. Alternatively, the DM could be located behind a firewall and/or a virtual private network gateway in a customer enterprise network scenario.

Venkitaraman thus considers a network approach to select a network interface for supporting a particular media stream by using SIP control messages to receive SDP content from a client device seeking to establish a session with another client device.

IEEE 802.21 considers a connection manager located on a client device making interface decision based on static network conditions.

In contrast, embodiments of the invention seek to enable a connection manager located on the client device and arranged to control and perform handover operations between networks to determine from real-time or near real-time information which candidate network for the handover operation is in fact the most suitable for supporting the applications currently running on the device.

Whilst Venkitaraman describes the network selection of a destination network interface on the basis of the features available to support a particular session and whilst IEEE 802.21 standard seeks to provide client devices with the ability to perform network selection based on static or default network conditions, the embodiments of the invention allow other devices already located in a candidate network to report the prevailing network conditions experienced by communications sessions on-going in that network and to share this information with other client devices who are searching for suitable networks.

The embodiments of the invention thus seek to obviate and/or mitigate the above limitations of the prior art.

One aspect of the invention seeks to provide a method of selecting a candidate communications network from a plurality of candidate communications networks available for a client device to handover to from a first communications network, the method comprising: ' determining if the client device is supporting one or more communication sessions over said first communications network; determining one or more session characteristics of one or more of said communication sessions; determining one or more criteria for a candidate network to support said one or more session characteristics; generating a request for candidate network session information reported dynamically by at least one other client device having a communication session in a candidate communications network, and determining which of said candidate networks is suitable for handover by the client device by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics.

In one embodiment, the session characteristics comprise session characteristics for a media stream component of a session.

In one embodiment, said candidate network communication session information is generated by said at least one other client device whilst said communication session is still on-going.

In one embodiment, said candidate session information is processed to determine the level of available bandwidth in said candidate network.

In one embodiment, said processing is performed by the client device.

In one embodiment, said processing is performed remotely by a server arranged to retrieve said candidate network session information from said data store and to send said processed information to said client device. In one embodiment, said determining a candidate network for handover by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics is performed by the client device.

In one embodiment, a connection manager on said client device performs said step of determining a candidate network and the method further comprises: selecting an interface on said client device associated with the candidate network selected for handover; and controlling the handover operation performed by the client device from said first network to the candidate network selected for handover.

In one embodiment, said data store collates information from a plurality of other devices in one or more candidate networks.

One aspect of the invention seeks to provide a client device arranged to implement a method aspect.

One aspect of the invention seeks to provide apparatus arranged to collate session information from a plurality of client devices, the apparatus comprising: means to receive session related information reported by a plurality of client devices in one or more networks; means to associated said session related information with one or more session characteristics; means to provide said session related information to a client device arranged to implement said processing step in a method as claimed in any one of claims 1 to 9.

One aspect of the invention comprises apparatus arranged to perform said processing in a method aspect.

One aspect of the invention seeks to provide a client device controlled handover method for a communications system, the handover method selecting a candidate network from a plurality of candidate networks for said client device to handover to from a first network, the method comprising the client device: determining if one or more sessions are on-going over said first network; determining one or more session characteristics for each said session; determining one or more criteria for a candidate network to support said one or more session characteristics; processing candidate network session information reported dynamically by at least one other client device having a session in a candidate network; determining which of said candidate networks is suitable for handover by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics; and selecting an interface associated with the candidate network which is determined as most suitable for handover to; and handing said session over from the first network to the network associated with said selected network.

Another aspect of the invention comprises a communications system having means arranged to implement a method aspect.

Another aspect of the invention comprises a suite of one or more computer programmes which when executed on one or more processing platforms are arranged to implement the method aspect. r The aspects and preferred features of the invention are as described above and by the accompanying independent and dependent claims respectively, and may be combined in any appropriate manner apparent to those skilled in the art.

Accordingly, given the problem of a client device selecting a suitable network for handover, the invention seeks to enable the client device to select from a number of potential candidate networks which theoretically can support any ongoing sessions, a network which at the handover decision point is in fact the most suitable by determining the "real-time" network characteristics of each candidate network. This allows the client device to select a network according to its true ability to support any on-going sessions that will need to be seamlessly maintained during the handover operation. The invention also seeks to enable any quality of service criteria for an on-going session to be maintained or improved by the choice of network selected for handover to by the connection manager.

The invention also seeks to improve the selection process for candidate networks for handover by providing a data store which retrieves session-related information from a plurality of other devices currently running sessions in other handover candidate networks. This information or derivative information is provided to the connection manager located on the client device and is used to determine which network currently has conditions most suitable for the type of session which is being supported by that client device.

The invention seeks to enable the handover decisions to be made in a relatively timely manner so that there is no undue delay prior to performing the handover. In addition, in one embodiment of the invention, individual applications supporting sessions and running on a client device generate one or more selection criteria which must be met before a connection manager located on the client device .

performs a network handover from one device interface to another device interface during an on-going session.

Advantageously, the solution(s) proposed by the invention seek(s) to be scalable, i.e., to perform consistently no matter how many client devices are reporting information in candidate networks and no matter how many candidate networks are available to the client device seeking a network to handover to. It also enables different types of networks to report their performance characteristics in a consistent manner to simplify the task addressed by the client device which reduces the processing task the client device must complete in order to perform the handover operation.

Preferred embodiments of the invention will now be described with reference to the accompanying drawings which are by way of example only, and in which:

Figure 1 shows schematically a communications system according to an embodiment of the invention;

Figures 2 and 3 show schematically the message flows between components of the communications system shown in Figure 1 ;

Figure 4 shows steps in a method of subscribing to the invention; and

Figure 5 shows steps in a method of performing a network handover according to the invention.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in simplified diagrammatic form to facilitate explanation and additional detail known to one of ordinary skill in the art has been omitted for clarity. The description of preferred embodiments is not intended to limit the scope of the claims appended hereto.

Figure 1 shows a communications system according to an embodiment of the invention comprising a plurality of networks 10a, 10b, 10c and 10d within which client devices 12a, 12b, 12c, 12d, and 12e are located. As described herein, a client device is defined herein to comprise any device capable of establishing at least one communications session over one or more wireless communications networks, for example, a mobile telephony type device, personal digital assistant, laptop computer etc. A client device comprises a number of interfaces enabling communications sessions to be established over a range of potential candidate networks and is also provided with sufficient processing power to control the selection of candidate networks for performing a network handover. In the following description of an embodiment of the invention, each of the client devices 12a...e shown in Figure 1 is also configured to function as a reporting node to a dynamic network information data server (DNID server) 14.

In Figure 1, client device 12a comprises a plurality of communications interfaces, each arranged to enable the client device to connect to a different wireless communications network, for example, to one or more of 802.11x (WIFI) , or 802.16 (WiMax), or Bluetooth™ type communications networks. The client device 12a is arranged to implement a device controlled network handover according to the IEEE 802.21 standards using a connection manager (CM) 20 which is shown in Figure 1 as being co- located with a session initiation protocol (SIP) application 22 on the client device 12a.

The connection manager 20 is shown in Figure 1 as a connections manager 20 hosted on the client device 12a. Alternatively or additionally, certain functionality of the connections manager 20 may be implemented off the communications device (shown by as a network connections manager 26 in Figure 1).

The connection manager 20 located on the client device 12a is configured to interface with a Session Initiation Protocol (SIP) client application 22 co-located on the client device 12a via a connection manager/SIP client interface (not shown in Figure 1). The connection manager/SIP client interface enables information about ongoing SIP sessions to be shared with the connection manager by sending Session Description Protocol (SDP) code to the connection manager client to enable one or more requirements to support the on-going SIP session to influence the network selected by the connection manager for handover.

The Invention uses SDP info from other devices to generate a suitability report or scorecard, which can be provided to the connection manager. This enables the conditions experienced by similar sessions to be reported to the connection manager 20 so that one or more session requirements for a particular application can be determined (for example, such as the audio codecs required to establish a session supporting the required audio QoS) given the prevailing network conditions. This enables the connection manager to have sufficient information to hand when making the network handover selection to ensure that the new network characteristics are capable of supporting that particular session.

In the embodiment shown in Figure 1 , each of the communications devices 12a...12e is capable of generating information using the session description protocol (SDP) which is then provided to the DNID server 14 where it is stored in an appropriate format to enable the characteristics of the session reported to be associated with one or more prevailing characteristics of the network supporting that session. In one embodiment, the devices themselves provide the SDP code itself In embodiments where a session comprises a plurality of differing media streams (e.g. video and/or audio streams and/or content which is not dependent on real-time streaming), the session-related information is structured in such a way that each session component reports its performance characteristics independently. This is useful as it enables the way a network impacts a type of session component to be determined and used as a basis for network selection. For example, an audio stream may experience very little delay or jitter due to its low bandwidth requirements whereas a video stream associated with the same session could experience a large delay and/or jitter due to its high bandwidth requirements. Another client device seeking a network for handover may want to select this network if they are only supporting communications sessions which have an audio stream (e.g., a VoIP session) but would probably want to reject it if the communication session included a video stream.

The client device 12a according to the invention is capable of controlling the selection of a network when seeking to perform a handover between networks. For example, consider the following scenario with regard to Figure 1. A user of a client device 12a moves into a first network 10a (for example, a WiFi hotspot). Client device 12a connects to network 10a and generates a request for 802.21 information on the other networks available in that area as future possible handover network candidates. This request is sent to the 802.21 information server (information server) 18 shown in Figure 1. The information server 18 returns information to the client device 12a in the form of a list of networks and their static network characteristics and/or network type. In an alternative embodiment, this information is instead or additionally provided to a central network connection manager 26, shown in Figure 1 as a dotted element of the drawing.

Client device 12a then commences a communications session including a live video stream with another communications device 12b (which in Figure 12 is capable of communicating using networks 10b and 10d). Consider a scenario in which, in the middle of the video session, the user leaves the area of coverage of network 10a and/or the network conditions fall to below the levels acceptable for maintaining the video session. This triggers a response by the connection manager 20 on the client device 12a to seek an alternative network to handover to.

It is known from the prior art for the connection manager 20 to make such a decision based only on the information provided by the information server (IS) 18, for example, connection manager 20 may choose to handover to an 802.16 WiMax network 12d rather than another WiFi network 12c. However, if this new network is congested, after handover, the video session stream may be interrupted and/or downgraded to audio only to cope with the congestion in network 12d, whereas in reality if the handover had been to WiFi network 12c, the lack of congestion would have enabled the video session to be maintained. The client device 12a of the invention addresses this problem by being provide with an internal interface (not shown in Figure 1 ) to enable information provided by a local SIP agent resident on the client device 12a (shown in Figure 1 as SIP application 22 hosted on the client device) to be shared with the connection manager 20. The SIP client application 22 is arranged to receive network selection information from a dynamic network information data (DNID) server 14 via SIP server 16. This information enables the connection manager 20 of the invention to initiate a network interface selection scheme and/or network handover scheme by retrieving information on the availability and characteristics of one or more potential network handover candidate networks reported in real-time by other communications devices 12b, 12c, and 12d, and 12e. In this embodiment, it will be assumed that client device 12a has suitable network interfaces to all available networks 10a ...1 Od.

Referring again to Figure 1 of the accompanying drawings, the information server 18 comprises a data store arranged to provide information to the connection manager 20 on the client device which indicates the availability of networks 10a,b,c,d in a particular geographic area or area of network coverage. In one embodiment, information server 18 also provides information on the static characteristics of the networks 10a,b,c,d such as the theoretical maximum bandwidth and average bandwidth. The information server is not arranged to provide information which is updated dynamically to reflect the current (i.e., actual) network conditions at the point in time when the client device is considering performing a handover operation to another available networks, as this would require a hugely complex processing power - instead, it merely provides a list of suitable candidate networks given the current location of the device requesting this information.

According to the invention, to enable the client device 12a to maintain one or more on-going communications sessions during the network handover, the connection manager 20 located on client device 12a is arranged to receive "live" session-related information from the other client devices currently conducting sessions in the candidate networks via SDP code extracted from the SIP control messages passed by the other client devices to the data store 14 which are passed to the SIP application 22 supported by the client device 12a via SIP server 16. The session-related information provided by the data store 14 enables the client device 12a to determine the prevailing network conditions at the point in time when a candidate network for the handover operation is being considered by the connection manager 20 of that particular client device.

In the embodiment of the invention shown in Figure 1 , each client device 12a...e also function as a reporting node. A reporting node is arranged to provide session related information via one or more communication networks 10a...d to DNID server 14 (as shown in Figure 1). Each reporting node is provided with an appropriately configured reporting engine (for example, reporting engine 24 for reporting node 12c as shown in Figure 1). The reporting engine is arranged to extract session description protocol information from the on-going sessions run by one or more applications running on the respective reporting node. When a SIP session is negotiated the SDP code is included in the body of a SIP INVITE message. The client may store this code and it can parse the SDP code to identify the fields in which specify each of the parameters needed (such as codec).

Each reporting engine 24 is configured to extract relevant session description information and associate the network characteristics with one or more session characteristics when generating its reporting data. - For example, a session characteristic such as the transmission codec(s) currently being used for a particular type of media stream (e.g. a video stream) by an application to maintain a particular quality of service can be correlated with the network characteristics that communications session is experiencing, e.g. the level of packet loss and/or network congestion experienced by the session traffic.

Reporting communications devices may have the ability to maintain communication sessions simultaneously in a plurality of networks and generate session-related information on each session separately and/or separate communications sessions over a plurality of networks. For example, in the embodiment of the invention shown in Figure 1 , it is possible for reporting node 12b to maintain a video communication session stream over WiMax network 1Od simultaneously with an audio stream in WiFI network 10c. Where a reporting node supports a number of sessions (or session components) in a plurality of differing networks, session-related information is generated on each session separately and reported by the reporting node.

The reporting nodes may push information to the DNID server 14 or information may be requested by the DNID server 14. In one embodiment of the invention, the session related information is pushed by each client device 12a...e to the server 14 on a periodic basis whilst a communications session is ongoing but alternatively, a report may be triggered by certain session-related events (for example, the initiation and/or interruption of a communications session), and/or using the session description protocol. Before a node may report information or implement a handover which utilises dynamic network information for network selection, it must subscribe to the relevant services provided by the DNID server 14 and the information server 18.

Figure 2 of the accompanying drawings shows the message flow in an embodiment of the invention in which a client device 12a subscribes to a service enabling candidate handover network selection based on dynamic network information according to the invention. The client device 12a registers with the SIP server 16 using a standard SIP message exchange (messages 1 ,2 in Figure 2). The SIP application 22 of client device 12a then subscribes to the 802.21 information service supported by the 802.21 server 18 by generating a registration request which is conveyed as a SIP subscribe message (messages 3,4 which are relayed by the SIP server 16 to the information server 18. This message is acknowledged by the information server 18 providing network notification information as a response (messages 5,6, also relayed via the SIP server 16). The SlP user agent in client device 12a also subscribes to the real-time network information service supported by the server 14 by sending a SIP subscribe message (message 7) to the SIP server 16 which forwards this one to the real-time network information data (DNID) server 14 (message 8). The response from the DNID server 14 is provided by SIP control messages and contains an indication of the suitability of each of the available communication networks for the particular type of communication session(s) which will need to be supported.

Consider an embodiment in which client device 12a connects to a network using a first network interface, for example, a radio access interface such as WiFi. The client device 12a then requests 802.21 information (or equivalent information) over the first interface with the static network information server 18 and provides an indication of its physical location. In one embodiment, the physical location information is determined by the client device, for example, by using a GPS functionality or equivalent but in an alternative embodiment the network tracks the location of the device.

Dependent on the location given, the information server 18 provides static network information which is delivered through the first network interface. The static network information includes a list of available networks for all the interfaces 1-N (WiFi, WiMAX, 3G etc) that the device is able to utilise when in that location.

Figure 3 shows for one embodiment of the information the flow of SIP messages required to enable a client device to implement a network handover operation.

As shown in Figure 3, it is assumed that a communications device is arranged to support real-time media sessions using SIP. When the communications device changes network, the device is registered with the SIP server (messages 1 and 2 of Figure 3). This registration process automatically triggers a request for information to the information server 18 (messages 3 and 4). This automatic trigger is dependent on the user of the device having already established a SIP subscription, and this subscription enables a trigger to be set so that subsequent SIP REGISTER messages are forwarded automatically to the information server. As is well known to those of ordinary skill in the art, SIP servers, as part of the IP Multimedia Subsystem (IMS), accept various triggering levels to achieve this. In this way, the information server 18 acts as an application server. In one embodiment of the invention, the location of the device is included in the payload of the SIP REGISTER message.

The SIP server forwards the REGISTER message (4) to the information server 18 and upon receipt of the REGISTER message by the information server 18, the information server issues information related to the current location of the client device 12a to the SIP server 16. In one embodiment of the invention, the SIP server 16 then forwards the 802.21 information received from the information server 18 to the client device 12a as payload data in a standard SIP NOTIFY message. A Type-Length- Value (TLV) type field limit format is applied to the message according to the MIH protocol. Examples of 802.21 network information include information on the following: name of the network, owner, technology (WiFi etc), QoS supported etc.

Now consider that a time point in time, the user of client device 12a seeks to establish a communications session with another user, say of other client device 12b. This communications session requires the exchange of information in real-time to be supported, i.e., at least one audio stream and/or video stream must be supported by the communications session in real-time. In order to achieve this, the device sends a SIP INVITE message (messages 7,8) via the SIP_' server 16 to device 12b (via the correspondent endpoint node (CN) - the client device 12b). This INVITE message contains the Session Description Protocol (SDP) code for the session. The other client device 12b generates an appropriate SIP response (OKAY messages 9, 10) which is again relayed to the SIP application via the SIP server 16, which contains information such as the codec capabilities of the other client device.

This exchange of messages (invite messages 7,8 and response messages 9,10) enables each client device to establish a session using specific codecs for audio and/or video. The SIP client application 22 forwards session related information to the dynamic network data server 14. This enables this information and derived information to be provided to other devices who are also seeking to implement a network handover according to the invention. In the mode of the invention currently considered the preferred mode by the inventor, the session related information relating to dynamic network performance is forwarded by the SIP client 22 in the payload of a SIP message (message 11 ,12). SIP message 11 , 12 comprises SDP code together with static network performance information derived from or copied from the 802.21 report (which the SIP client application 22 received in notify messages 5,6 shown in Figure 2).

The dynamic network information server 14 processes received SIP control messages to extract from the SDP code dynamic network performance data in the context of the specific sessions that the client device is supporting. For example, the server 14 will store information on the codec(s) in use by the client device to support each media stream forming the communications session and will store this information in a database of current sessions for that subscribed device A, together with an indication of how current the information is, for example, the date and time of the start of the session (and if relevant when a session ended) are also stored. In one embodiment, the destination IP address is also stored which enables the destination IP address to form part of the network selection process (for example, should a session be established with destination device 12b over network 10c or 10d in Figure 1). The DNID server also indexes all stored information to a geographic location to enable the dynamic conditions of each available communications network at a particular geographic location to be mapped to a client device seeking to perform a handover operation at that geographic location.

Figure 4 summaries the steps required to register a communications device as a reporting node for reporting session related information according to an embodiment of the invention. First the communications device subscribes to the DNID server by completing the registration process (step 100). When the device participates or initiates in a communications session, it registers the communication session (step 102) with the DNID server 14. When the DNID server receives a request for dynamic network session related information, it determines this by requesting relevant information from each appropriate reporting node. Each reporting node receiving the request then reports the appropriate perceived session characteristics as requested (step 104) to the DNID server 14. The DNID server 14 then processes this information and forwards this to the client device 12a which has requested the information in order to make an appropriate network selection. The information reported is then stored as historic session-related information for that type of session, time, and network (step 106). This enables session-related information to be retrieved to assess the network performance in future even if no on-going sessions can send in reports for that network at the time the DNID server 14 receives the request for network information.

Figure 5 show schematically the selection process according to one embodiment of the invention. A requesting client device 12a seeking to select a network for a handover operation generates a request for dynamic network information (step 110) which is sent to the DNID server 14. The DNID server 14 then determines if at least one similar type of session is registered as on-going in a candidate network (step 112). If none are registered, the DNID server 14 retrieves historical information from previous sessions in that network as uses this to generate a network suitability indication, for example, in the form of a numerical score or "scorecard" (step 118). If at least one device is registered as hosting a similar type of session to the sessions which will be required to be supported by the network if selected for handover by the client device 12a, then the DNID server 14 requests "live" or "real-time" information from the reporting node hosting the on-going session (step 114). The reporting node then returns appropriate information (step 116), which is used to generate an appropriate network suitability indicator (step 118 which is described in more detail herein below). Once a number of score-cards have been generated by a number of reporting nodes in each candidate networks an overall assessment can be made of the likely conditions in each candidate network and the relative merits of each candidate network determined (step 122) by the DNID server 14 and/or by the network connections manager 26 and/or local connections manager 22. The local connection manager 22 then selects the most suitable network as the network to handover to and performs the handover operation (step 124).

Server 14 is arranged to generate a "suitability" report indicating the dynamic network conditions prevalent in each network reported as available by the information server 18. The server 14 receives information from one or more devices in each network available at a particular location. In one embodiment of the invention, this information processed by the server 14 to generate a report for each available network. In another embodiment of the invention, the suitability of each available network for a particular type of communication session is provided by means of a scorecard. For example, a score may be generated to indicate the following information:

Score Indication

-2 Real time sessions will have to be stopped if handover performed to this candidate network. -1 In the event of handing over to this candidate network the session will need to be downgraded. E.g. from video and audio to only audio.

0 Session may be handed over without modifications. ^'

1 Opportunity to upgrade session in new candidate network.

Yo assess what score should be applied, the server 14 requires information from the client device 12a on the nature of the sessions currently supported (see messages 11 , 12 in Figure 3). Server 14 processes this information to determine session related information such as the codecs currently used by client device 12a. Server 14 then finds out about the current real network conditions of the available networks that have been offered by the information server 18 as candidates for a handover.

The server^"14 performs a look-up operation in its database to determine what subscribers currently are associated with on-going communications sessions and to determine if the type of sessions which are on-going are in any of the available networks to client device 12a. If the server 14 finds one or more users utilising one of the available networks, for example other client device 12c (as shown in Figures land 3), the server 14 will issue a network report request (message 13) to the SIP agent resident on device 12c.

In one embodiment, the request message 13 is sent using as a SIP MESSAGE. The request message 13 specifies specific information to be reported by the SIP client resident on the receiving device. The resident SIP agent processes the request message 13 and responds by performing the requested operations. For example, in one embodiment, the resident SIP agent monitors the packet loss of any ongoing communication sessions, for example by means of the Real-Time Control Protocol (RTCP), which is used in conjunction with the Real Time Protocol (RTP) commonly used to deliver real-time packets. Once the relevant information has been acquired locally on other client device 12c, the local SIP agent on client device 12c generates a report which is sent back to the DNID server 14 (message 14). In the preferred embodiment of the invention, the report is sent to the DNID server 14 using a SIP MESSAGE message and includes information on the current codecs that the client device 12c is using. In one embodiment, the DNID server 14 limits the amount of information gathered from each candidate network. For example, the criteria to choose nodes to report on candidate networks could be limited to a maximum number (e.g. 5) and the nodes selected might be the ones that have established their sessions at a later time. In a different embodiment, nodes are selected according to the location of a session end-point, so that this is as close as possible to the end point of the current session(s) supported by client device 12a. In one embodiment, the DNID server 14 tracks each reporting communications device (for example, using GPS monitoring system or equivalent), in order to select reporting devices which are located as close as possible to client device 12a. Each the report delivered by a reporting communications device to the DNID server 14 includes at least one parameter indicating a characteristic of the communications sessions which has been impacted by the underlying network performance, for example, apart from the selection of an appropriate code, other parameters such as packet loss, delay and/or jitter for the communication session(s) are reported.

Once the dynamic network information server 14 has received information reported by one or more other client devices in a candidate network, it generates a "suitability" report for that network for the communications sessions that client device 12a is currently supporting to enable the client device 12a to determine if the reported network(s) is(are) suitable candidate handover network (s).

In one embodiment of the invention, the "suitability report" is generated by processing the information received from reporting devices as follows:

i) the packet loss that the reporting device 12c is experiencing at the candidate network using the codecs C is using is calculated. If, for example, according to the calculation no loss should be occurring and yet a packet loss is reported by the client device 12c, the candidate network is experiencing congestion.

ii) the current bandwidth is then determined by the dynamic network information data server. If enough to support the kind of session that device A is currently undertaking, the server registers this information and assign an appropriate score (as indicated above) using the information on the requirements of the current session(s) supported by device A, included in the SDP code passed to the DNID server 14.

It is possible for the DNID server 14 to receive information from different reporting devices which generate conflicting dynamic network conditions. In such circumstances, the scorecard may be provided with a "degree of confidence" for the report. For example, if five devices are polled in a candidate network and four respond in such a way as to indicate the network conditions are acceptable but one responds with information which indicates unacceptable network conditions, an 80% degree of confidence could be applied as 4 out of 5 reports are consistent. In the rare event in which all reports where conflicting to each other the DNID server might be able to declare itself unable to issue a scorecard. Other implementations for weighting multiple reports are also possible. If two networks were to be indicated as suitable, but one has a greater degree of confidence than the other, this will bias selection towards the network whose results exhibit a greater degree of confidence. The DNID server 14 then stores its reports in an appropriate format to enable a historical network performance to be accessible.

In one embodiment, if the DNID server 14 finds less than the minimum number of devices required to generate a report in a particular candidate network of if the DNID server does not find any communications device in that network, the DNID server 14 performs a look up operation on the historic database. As this data base has been constructed over time, the historic information provides some indication of expected performance of a network at a given time at a given day of the week. The historic database might also be used in conjunction with live reports to show that although no current congestion is happening right now at the candidate network the historic reports indicate that is likely for that situation to change at that time of the day.

When the DNID server 14 has generated an appropriate scorecard for each candidate network, this information is provided via SIP NOTIFY messages 15 (see Figure 3) to the local SIP agent resident on the client device 12a which is seeking to perform the network handover operation. The local SIP application agent 22 on client device 12a then sends this information via the SIP/connection manager interface of device 12a to the locally resident connection manager connection manager 20. connection manager 20 is configured to process this received information to determine which available candidate handover network has the optimum score indicating its suitability to support any on-going communication session(s).

In one embodiment, this information is obtained automatically when a new session is commenced by the client device 12a prior to any need to perform a handover operation. In an alternative embodiment, this information is requested periodically or triggered by certain session-related events. Alternatively, ' the information request is triggered by initiation of a handover operation by the connection manager on the client device. The information is considered to be available when the connection manager 20 is making the handover decisions via the local SIP agent by providing a suitable Application Programming Interface (API) which allows the connection manager 20 to receive the relevant information from the local SIP application agent 22.

Referring back now to Figure 1 of the accompanying drawings, consider a scenario in which client device 12a is connected to network 10a and has a video communications session established with another device. At some point, the client device determines a handover is required. The connection manager 20 already has knowledge of available networks (candidate handover networks) as these were retrieved by the client device 12a requesting a list of networks available in that location from the information server 18. This 802.21 information is provided by the information server 18 performing an appropriate network look-up operation based on the current geographic location of the client device. Meanwhile, the reporting engines 24 of other communications devices in each candidate network independently convey session description information and 802.21 information to the data store 14 in the form of SIP messages and in one embodiment, the information from the information server 18 is also conveyed to the client over SIP using the MIH protocol.

In this way, in one embodiment of the invention, a candidate network is selected from a plurality of candidate networks available for a client device 12a to handover to from a first network by performing the following steps: determining if the client device is supporting one or more sessions over said first network; determining one or more session characteristics of one or more of said sessions; determining one or more criteria for a candidate network to support said one or more session characteristics.

Then, information is obtained from one or more reporting devices either in real-time or from a store of such information reported by other reporting devices. This session performance related information is then processed by the dynamic network information data server 18 in one embodiment of the invention. In another embodiment, a connection manager located either locally on the client device seeking 12a (e.g. connection manger 22) or remotely within the network (connection manger 26, described in more detail later herein below) processes candidate network session information retrieved from the dynamic network information data store. When the candidate network session information comprises session information reported dynamically by at least one other client device having a session in a candidate network, the process of determining which of said candidate networks is suitable for handover by the client device by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics is responsive to the real-time conditions experienced by the reporting devices and so provides a better indication of the suitability of an available candidate handover network.

Thus according to the invention, the DNID server 14 runs an appropriate selection function to determine a number of reporting nodes (e.g. client devices 12b,c,d,e etc as shown in Figure 1). Reporting nodes comprise communications devices which are already using each available candidate network at the location of the client device 12a when it is seeking to perform a network handover operation. For example, if the information server indicates that networks 10a,b,c and d are available to the client device 12a, after the client device 12a has registered via its subscription to the SIP server 16 its subscription to the DNID server 14, the DNID server 14 seeks to gather information from one or more other client devices and/or nodes in each of the networks available to the client device 12a at that location to determine their current utilization. In network 10d, for example, information is retrieved from reporting nodes 12b, 12d, and 12e as shown in Figure 1. Reporting nodes 12b,c provide information for network 10b, and reporting node 12e provides information for network 10c as shown in Figure 1.

Each reporting node provides current real performance of the respective network characteristics requested to the DNID server 14. Based on this information, the DNID 14 generates a scorecard as described above for each of the available networks at that location to indicate their current suitability. In one embodiment of the invention, this information is forwarded to the client device 12a via the SIP server 16. Alternatively, it may be forwarded via the information server 18 and/or via a network connections manager 26. If network conditions trigger a handover request on the client device and/or if network conditions trigger an indication that a handover request is likely to be generated which is forwarded to the client device, the connection manager 22 on the client device initiates a selection process which utilizes information based on the network conditions reported by other reporting nodes in the available candidate networks. This information, for example, a network scorecard value generated by the DNID server 14 as described in more detail herein below, is then used by the CM to select a network. The CM then generates appropriate commands for completing the handover operation to the selected network.

For example, consider if the Connections Manager receives a "network link going down" message from the IS 18. A "network going down" trigger comes from the MIHF₁ a 802.21 function that sits between the CM and the radio interfaces. This would trigger a network handover operation response. The connection manger 20 will initiate the handover process by performing a look up operation to determine from the local SIP agent 22 what are the dynamic network conditions on the candidate networks that the IS 18 has previously indicated are available in that location. In this embodiment, the local SIP agent 22 has already forwarded the information provided by the DNID server 14 which the connection manager processes to select an appropriate candidate network for the handover operation (if not, then requesting the information as the link goes down might be too late).

A candidate network may be selected as follows:

i) Dependent on the scorecards received for each candidate network , the connection manager selects to perform a handover operation to a network that the DNID server 14 has reported as most able to maintain any ongoing communication sessions.

The connection manager achieves handover by issuing a command to the drivers to connect and disconnect interfaces. The commands are well specified in the IEEE 802.21 standard and are executed at interface driver level as are well known in the art. The SIP agent issues a SIP re-INVITE, with new SDP parameters (new IP address) that will maintain the real time session. ii) Dependent on the scorecards received for each candidate network, the connection manager 20 performs a handover operation to a network that the DNID server 14 has reported as most able to maintain an upgraded version of the current session.

The connection manager 20 issues commands for connection and disconnection as required and will use the API to the SIP agent to advice on a possible session upgrade. The SIP agent may then issue a SIP re-INVITE, with new SDP parameters that will improve the real time session.

iii) Dependent on the scorecards received for each candidate network, the connection manager performs a handover operation to the network that the DNID server says will be able to maintain the least downgraded version of the current session.

The connection manager issues commands for connection and disconnection as required and will use the API to the SIP agent to advise on a possible session downgrade. The SIP agent issues a SIP re- INVITE, with new SDP parameters that will modify the real time session which are sent to the responding communications device at the other end of the communications session.

In the event that the DNID server issues reports with "degree of confidence" the connection manager might decide to discard any candidate networks with a confidence below a lower limit threshold.

In an alternative embodiment, such as is also shown in Figure 1 by the dotted drawing component labelled connection manager 26, a network connection manager 26 is provided. Part of the functionality of the connection manager sits on the network. In this embodiment, information reported by reporting devices may be stored on the DNID server 14 and forwarded to the connection manager 26 for processing, which enables information reported by a plurality of network devices supporting appropriate communications session to be provided to the connection manager 26 via the DNID server 14 and associated with available networks as indicated by the Information server 18. Providing the network connection manager 26 is implemented in an appropriately scalable manner, the information on dynamic network conditions for each type of application's communication session requirements (including the appropriate codec) can be made available more rapidly to client devices seeking to implement a network handover operation. This reduces the processing time required as a device can request this information directly from the connection manager. In one embodiment, the information hosted centrally by the network connection manager 26 supplements the locally supported connection manager 22 hosted on the client device 12a seeking to implement the handover operation. The network connection manager 26 can be integrated with the dynamic network information server 14 and/or the dynamic network information server 14 can be configured to directly receive 802.21 information (either direct or via the network connection manager) about a specific location directly from the 802.21 information server. Those of ordinary skill in the art will be aware of many functionally equivalent alternatives to the specific features of the embodiments described herein, and the description is implicitly extended to include such alternatives where these are so apparent. Modifications to the above features of the invention and features having equivalent effect to the features known to those skilled in the art are thus implicitly included in the description, and the scope of the invention should be determined by the accompanying claims.

The text of the abstract repeated below is incorporated in the description of the invention:

Claims

1. A method of selecting a candidate communications network from a plurality of candidate communications networks available for a client device to handover to from a first communications network, the method comprising: determining if the client device is supporting one or more communication sessions over said first communications network; determining one or more session characteristics of one or more of said communication sessions; determining one or more criteria for a candidate network to support said one or more session characteristics; generating a request for candidate network session information reported dynamically by at least one other client device having a communication session in a candidate communications network, and determining which of said candidate networks is suitable for handover by the client device by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics.

2. A method as claimed in claim 1 , wherein the session characteristics comprise session characteristics for a media stream component of a session.

3. A method as claimed in claim 1 or 2, wherein said candidate network communication session information is generated by said at least one other client device whilst said communication session is still on-going.

4. A method as claimed in any previous claim, wherein said candidate session information is processed to determine the level of available bandwidth in said candidate network.

5. A method as claimed in any previous claim, wherein said processing is performed by the client device.

6. A method as claimed in any previous claim, wherein said processing is performed remotely by a server arranged to retrieve said candidate network session information from said data store and to send said processed information to said client device.

7. A method as claimed in any previous claim, wherein determining a candidate network for handover by comparing said processed candidate network session information with said one or more criteria for a candidate network to support said one or more session characteristics is performed by the client device.

8. A method as claimed in claim 7, wherein a connection manager on said client device determines a candidate network and the method further comprises the connection manager: selecting an interface on said client device associated with the candidate network selected for handover; and controlling the handover operation performed by the client device from said first network to the candidate network selected for handover.

9. A method as claimed in any previous claim, wherein said data store collates information from a plurality of other devices in one or more candidate networks.

10. A client device arranged to implement a method as claimed in any previous claim.

1.1. Apparatus arranged to collate session information from a plurality of client devices, the apparatus comprising: one or more processors arranged to: receive session related information reported by a plurality of client devices in one or more networks; associate said session related information with one or more session characteristics; provide said session related information to a client device arranged to implement said processing in the method as claimed in any one of claims 1 to 9.

12. Apparatus arranged to perform said processing in the method as claimed in any one of claims 1 to 9.

13. A client device controlled handover method for a communications system, the handover method selecting a candidate network from a plurality of candidate networks for said client device to handover to from a first network, the method comprising the client device: determining if one or more sessions are on-going over said first network; determining one or more session characteristics for each said session; determining one or more criteria for a candidate network to support said one or more session characteristics; processing candidate network session information reported dynamically by at least one other client device having a session in a candidate network; determining which of said candidate networks is suitable for handover by comparing said processed candidate network session information with said one or more criteria for a candidate - network to support said one or more session characteristics; and selecting an interface associated with the candidate network which is determined as most suitable for handover to; and handing said session over from the first network to the network associated with said selected network.

14. A communications system having means arranged to implement the method as claimed in any qne of claims 1 to 9 or 13.

15. A suite of one or more computer programmes which when executed on one or more processing platforms are arranged to implement the method as claimed in any one of claims 1 to 9 or 13.