GB2460029A

GB2460029A - Handover in a mobile communication system

Info

Publication number: GB2460029A
Application number: GB0808540A
Authority: GB
Inventors: Christophe Janneteau; Alexis Olivereau; Alexandru Petrescu
Original assignee: Motorola Inc
Current assignee: Motorola Solutions Inc
Priority date: 2008-05-12
Filing date: 2008-05-12
Publication date: 2009-11-18
Anticipated expiration: 2028-05-12
Also published as: GB0808540D0; GB2460029B

Abstract

A mobile communication system comprises a first and second access router (103, 105) supporting a mobile entity (101) before and after a handover respectively. The second access router (105) comprises a network interface (201) which receives a proposed care of address for the mobile entity (105) while this is still attached to the first access router (103). Duplicate address detection (DAD) is performed by a validation processor (203) which determines if the proposed care of address is a valid address for the mobile entity (101) when attached to the second access router (105) and if so a response transmitter (207) returns an address acceptance indication for the proposed care of address. A reserved address store (205) stores a set of reserved addresses and the validation processor (203) determines the care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the second access router (105) but not to the stored set of reserved addresses.

Description

HANDOVER IN A MOBILE CO4tJNICATION SYSTEM

Field of the invention

The invention relates to handover in a mobile communication system and in particular, but not exclusively, to handover in an Internet Protocol mobile communication network.

Background of the Invention

There is an increasing tendency to provide mobility support for network systems and protocols that have traditionally been aimed at fixed communication networks. For example, there is a desire to increasingly base cellular communication systems on infrastructure using the Internet Protocol (IP) standardised by the Internet Engineering Task Force (IETF) Accordingly, recent versions of the Internet Protocols have been deve]oped or enhanced to provide mobility support for mobile nodes and networks.

Specifically, a mobility enhancement known as NEMO (NEtwork MObility) has been developed for Internet Protocol version 4 (IPv4) as e.g. described in K. Leunag et al, "Network Mobility (NEMO) Extensions for Mobile IPv4", draft-ietf-mip4-nemo-v4-base-06.txt, IETF Internet Draft, work in progress, 31 October 2007, and for IPv6 as e.g. V. Devarapalli et al., "Network Mobility (NEMO) Basic Support Protocol", IETF RFC 3963, Standards Track, January 2005.

Also, Internet Protocol version 6 (IPv6) is being developed to inherently support mobility as e.g. described in D. Johnson et al., "Mobility Support in IPv6", IETF RFC 3775, Standards Track, June 2004.

Accordingly, these networks allow a Mobile Entity (ME) to move between IP subnets in an IP infrastructure while maintaining its ongoing IP sessions. The supporting mobility protocols are defined for both IPv4 and IPv6, and rely on dynamic establishment of a bi-directional tunnel between the ME's current point of attachment (defined by the Care-of Address (C0A) for the ME) and its mobility anchor point (the Home Agent (HA)) in its home network. In the downstream direction, IP packets addressed to the ME (i.e. IP packets addressed to the ME's home address or to a destination address which matches the ME's mobile subnet (if the ME is a mobile router)) are intercepted by the HA and routed over the tunnel to the ME's C0A. Similarly, in the upstream direction, IP packets sourced by the ME (or by any of its attached nodes in case of a mobile router) are tunnelled towards the HA, and from there routed to the destination.

In order to provide a seamless and efficient mobile performance, it is important that handover of an ME from one access router to another is fast and does not result in a noticeable disruption to the user. However, a recognized limitation of Mobile IP or NEMO handovers is that they typically result in a relatively high handover delay thereby resulting in a lack of seamlessness and possibly a significant packet loss. This handover delay is predominantly due to the time required to perform the following: * Link-Layer switching, * new C0A acquisition on the new link, and * registration of the new C0A at the HA.

Such a handover delay will typically result in a noticeable disruption to real-time applications such as video streaming or Voice over IP (VOiP) during the handover process.

In order to improve the speed of the handovers, handover protocols known as Fast Mobile IP (FMIP) protocols have been designed as described in e.g. R. Koodli, C. Perkins "Mobile IPv4 Fast Handovers", IETF RFC 4988, October 2007; R. Koodli, "Fast Handovers for Mobile IPv6", IETF RFC 4068, July 2005 and R. Koodli, "Mobile IPv6 Fast Handovers", draft-ietf-mipshop-fmipv6-rfc4068bis-04.txt, IETF Internet draft, update of RFC 4068, work in progress, 19 November 2007.

These protocols are aimed at complementing Mobile IP/NEMO protocols in order to improve handover speed and seamlessness. Specifically, the protocols seek to reduce the handover delay and packet loss by providing the following capabilities: * The ME can configure a new C0A which is valid at the new Access Router (AR) while it is still connected at the previous (original) AR, * The previous AR can tunnel packets addressed to the ME's previous C0A towards the ME's new C0A; and * The new AR can buffer data packets addressed to the new C0A (and tunnelled by the previous AR) until the ME has successfully attached to the new link.

As part of the handover, the ME may generate and propose a new C0A to be used for the AR following the handover. This C0A is proposed to the new AR which proceeds to validate the uniqueness of the proposed C0A. If the proposed C0A is not valid (for instance because it is already used by another node), the new AR rejects the proposed C0A and optionally proposes a different CoA. Otherwise, the new AR accepts the proposed C0A. The previous AR then proceeds to tunnel any received packets addressed to the ME's previous C0A towards the ME's new C0A. The ME can then proceed to form the link layer handover after which the buffered data packets are transmitted to the ME from the new AR. The ME then finalises the handover by triggering a registration procedure to indicate the new CoA to the HA. Incoming packets are subsequently routed directly from the HA to the nAR.

However, although FMIP may improve handover efficiency there is still a number of associated disadvantages. For example, the approach requires the new AR to be able to validate the proposed address. Thus the new AR must be able to perform duplicate address detection to verify that the proposed C0A is not already in use. A method of duplicate address detection is proposed in S. Thomson et al, "IPv6 Stateless Address Autoconfiguration", IETF RFC 4862, September 2007.

In accordance with the method IPv6 nodes must validate the uniqueness of an IPv6 address before assigning it to an interface. This is achieved by the node broadcasting a number of Neighbour Solicitation (NS) messages, each separated by a configurable time interval (default = 1000 ms) . The NS messages are broadcast with an indication of the proposed IPv6 address and will be received by any node already assigned the address. In response, to receiving an NS message, the node will respond by returning a Neighbour Advertisement (NA) message. If an NA message is received, the node determines that the target address is already used by another node (i.e. a duplicate address is detected) . If no NA message is received within a given time interval, the address is considered to be unique.

However, such an approach results in a very slow duplicate address detection which will delay the handover process and may result in significant and noticeable disruptions.

Furthermore, the approach is relatively complex and requires relatively complex functionality to be implemented in the AR. Furthermore, it tends to increase the amount of signalling and thus communication overhead in the system.

As another example, the delay and complexity required for the AR to generate an alternative C0A address in case the proposed C0A address cannot be used tends to be significant resulting in reduced performance and increased cost and complexity of the involved AR5.

Also, the current signalling between the ME, the previous AR and the new AR tends to be limited. Specifically, although the signalling is sufficient to affect a handover of the ME it tends to not provide sufficient options for the new AR to control the handover performance and operation of the ME.

Hence, an improved mobile communication system would be advantageous and in particular a system allowing increased flexibility, reduced complexity, facilitated or improved mobility support, improved handover performance, reduced handover disruptions and/or improved performance would be advantageous.

Summary of the Invention

Accordingly, the Invention seeks to preferably mitigate, alleviate or eliminate one or more of the above mentioned disadvantages singly or in any combination.

According to a first aspect of the invention there is provided a mobile communication system comprising: a first access router for supporting a mobile entity prior to a handover of the mobile entity; a second access router for supporting the mobile entity following the handover; an interconnecting network coupling at least the first access router and the second access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the first access router and the second access router using a care of address for the mobile entity; the second access router comprising: means for receiving a proposed care of address for the mobile entity while the mobile entity is attached to the first access router, the proposed care of address being a proposed address for the mobile entity following the handover; means for determining if the proposed care of address is a valid address for the mobile entity when attached to the second access router; means for transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the first access router if the proposed care of address is a valid address; and a store for storing a stored set of reserved addresses; and wherein the validating means is arranged to determine the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the second access router and that the proposed care of address does not belong to the stored set of reserved addresses.

The invention may allow improved or facilitated mobility support in a mobile communication system. In particular improved or facilitated handover performance can be achieved for a mobile entity. In many scenarios, a faster handover operation may be achieved resulting in reduced disruption and an improved user experience. In particular, improved support for real time services may be achieved. In many embodiments, reduced complexity of access routers can be achieved. In many embodiments, faster and simpler duplicate address detection may be used to improve handover performance. Also, signalling overhead may in many cases be reduced substantially.

The Mobile Entity may specifically be a standalone mobile node or a mobile router serving a mobile (sub)rietwork. The stored set of reserved addresses may comprise reserved addresses stored prior to receiving the proposed care of address. In particular, the stored set of reserved addresses may comprise a set of predetermined reserved addresses identified prior to receiving the proposed care of address.

The determination of whether the proposed care of address is valid may be performed without any signalling with other nodes being performed in response to the proposed care of address being received. The detection of the address being valid may be performed in response to only address usage information already available at the second access router when receiving the proposed care of address.

The set of associated addresses may comprise addresses that are assigned or allocated to the second access router. For example, the set of associated addresses may comprise all addresses having an address prefix allocated to the second access router. In some scenarios, the set of associated addresses may only comprise addresses meeting a further requirement. For example, the set of associated addresses may only comprise addresses of the link to which the mobile entity is handing over.

The first access router and the second access router may specifically be Internet Protocol access routers such as IPv4 or IPv6 routers. The mobile communication system may be a MobilLe IP (Mobile IP) network. The proposed care of address may specifically be a network layer address, such as an IPv4 or IPv6 address.

According to another aspect of the invention there is provided ar access router for a mobile communication system including a further access router for supporting a mobile entity prior to a handover of the mobile entity from the further access router to the access router and an interconnecting network coupling at least the access router and the further access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the access router and the further access router using a care of address for the mobile entity; the access router comprising: means for receiving a proposed care of address for the mobile entity while the mobile entity is attached to the further access router, the proposed care of address being a proposed address for the mobile entity following the handover; means for determining if the proposed care of address is a valid address for the mobile entity when attached to the access router; means for transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the further access router if the proposed care of address is a valid address; and a store for storing a stored set of reserved addresses; and wherein the validating means is arranged to determine the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the access router and that the proposed care of address does not belong to the stored set of reserved addresses.

According to another aspect of the invention there is provided a method of operation for a mobile communication system including a first access router for supporting a mobile entity prior to a handover of the mobile entity; a second access router for supporting the mobile entity following the handover; and an interconnecting network coupling at least the first access router and the second access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the first access router and the second access router using a care of address for the mobile entity; the method comprising the second access router performing the steps of: receiving a proposed care of address for the mobile entity while the mobile entity is attached to the first access router, the proposed care of address being a proposed address for the mobile entity following the handover; determining if the proposed care of address is a valid address for the mobile entity when attached to the second access router; transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the first access router if the proposed care of address is a valid address; and storing a stored set of reserved addresses; and wherein the validation comprises determining the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the second access router and that the proposed care of address does not belong to the stored set of reserved addresses.

These and other aspects, features and advantages of the invention will be apparent from and elucidated with reference to the embodiment(s) described hereinafter.

Brief Description of the Drawings

Embodiments of the invention will be described, by way of example only, with reference to the drawings, in which FIG. 1 illustrates an example of a mobile communication system in accordance with some embodiments of the invention; FIG. 2 illustrates an example of an access router in accordance with some embodiments of the invention; FIG. 3 illustrates an example of a signalling flow for a handover in a mobile communication system in accordance with some embodiments of the invention; FIG. 4 illustrates an example of a method of operation for an access router in accordance with some embodiments of the invention; and FIG. 5 illustrates an example of a method of generating a care of address in accordance with some embodiments of the invention.

Detailed Description of Some Embodiments of the Invention The following description focuses on embodiments of the invention applicable to an IP mobile communication system and in particular to a Mobile IPv6 communication system.

However, it will be appreciated that the invention is not limited to this application but may be applied to many other communication systems.

FIG. 1 illustrates an example of a mobile communication system ira accordance with some embodiments of the invention.

In the specific example, the mobile communication system is a Mobile IP communication system using IPv6 mobility protocols.

The mobile communication system comprises a Mobile Entity (ME) 101 which may e.g. be a standalone Mobile Node (MN) or a Mobile Router (MR) serving a subnetwork. The ME 101 is capable of moving within the network such that its attachment point may change between different Access Routers (AR5) . In the example, the ME 101 is a wireless mobile entity which may be supported over a radio air interface and which specifically may be coupled to the communication system via wireless AR5 and Access Points (APs) FIG. 1 illustrates a first and second AR 103, 105 which are coupled to an interconnecting network 107. It will be appreciated that the AR5 103, 105 are merely illustrated as external to the network 107 for clarity of the following description and may also be considered to be part of the interconnecting network 107. It will also be appreciated that the AR5 103, 105 may be considered to comprise both the routing functionality of an AR network element and the Access Points (APs) server by the routing functionality thereof. Thus, the first AR 103 and the second AR 105 also represents any separate AP5 served by the AR5 103, 105.

In the example, the communication system is a Mobile IP network and all communications between network elements including the ME 101 and the AR5 103, 105 are in accordance with the IPv6 protocol. It will be appreciated that FIG. 1 for clarity and brevity only illustrates elements of the system required for the following description, and it will be appreciated that a practical communication system may comprise large numbers of ME5, AR5 and other network elements including routers, charging network elements, operations and management centres etc. As the ME 101 moves in the network, its attachment point may change between different AR5. In the specific scenario illustrated in FIG. 1, the ME 101 is in the process of handing over from the first AR 103, henceforth referred to as the previous AR or pAR, to the 2nd AR 105, henceforth referred to as the new AR or nAR. Thus, initially, the ME 101 is attached to the pAR 103 and the IF data packets are accordingly routed to and from the ME 101 via the pAR 103.

Following the handover, the ME 101 is attached to the nAR and the IP data packets are accordingly routed to and from the ME 101 via the nAR 105.

In the system, data is routed to the ME 101 via a mobility anchor point in the form of a Home Agent (HA) 109. The routing is performed using a Care-of-Address (C0A) which is a temporary allocated address that is compatible with the ME's 101 current location. Specifically, the C0A may be a temporary address of the address space that is assigned to the AR that the ME 101 is currently attached to. Thus, prior to the handover the ME 101 is assigned a CoA within the address space of the pAR 103 and after the handover is completed the ME 101 is assigned a C0A within the address space of the nAR 105. The current C0A assigned to the ME 101 is stored at the HA 109 and accordingly all incoming data packets for the ME 101 are first routed to the permanent HA address for the ME 101 and then from there to the ME 101 using the stored CoA.

When handing over the ME 101 switches from being attached to the pAR 103 to being attached to the nAR 105. Accordingly, the C0A changes from one within the address space of the pAR 103 to an address within the address space of the nAR 105.

FIG. 2 illustrates the nAR 105 in more detail. It will be appreciated that the functionality described with reference to the nAR 105 may be implemented in all AR5 and specifically that both the nAR 105 and the pAR 103 may comprise the described functionality.

The operation of the communication system of FIG. 1 and in particular the nAR 105 of FIG. 2 will in the following be described in more detail with reference to FIG. 3 which illustrates an exemplary handover signalling flow compatible with an IPv6 handover protocol and FIG. 4 which illustrates a flow chart for an exemplary method of operation of the nAR during the handover.

Initially, the ME 101 is attached to the pAR 103 and uses an IPv6 C0A, (henceforth referred to as the previous C0A (pCoA) which is valid under the pAR 103.

The ME 101 continuously monitors for wireless AP5 and may detect that an AP of the nAR 105 is more advantageous than the current AP of the pAR 103. The ME 101 may then communicate with the pAR in order to determine details of the nAR 105 serving the detected wireless AP. Specifically, Router Solicitation for Proxy Advertisement (RtSolPr) and Proxy Router Advertisement (PrRtAdv) messages can be used by the ME 101 to determine the IPv6 address and IPv6 prefix of the nAR 105 serving the detected wireless AP identified as a possible target for the handover.

Ease on the determined IPv6 prefix of the nAR 105, the ME 101 can proceed to determine a proposed CoA that can be used for the ME 101 when attached to the nAR 105. Specifically, the address space of the nAR 105 may typically correspond to all addresses having the same prefix and the ME 101 may thus generate the proposed C0A simply by selecting an address having this prefix. For example, a random suffix may be selected and appended to the prefix.

In some scenarios, the nAR 105 may support a plurality of links corresponding to a plurality of different prefixes or address spaces. In such cases, the ME 101 may determine the prefix or address space of the specific link to which it is intending to handover and may then use this prefix. In some scenarios, the ME 101 may simply randomly select one prefix out of a plurality of available prefixes.

The ME 101 then triggers a Fast Mobile IP (FMIP) handover towards the nAR 105 by sending a Fast Binding Update (FBU) message to the pAR 103. This message comprises an indication of the IPv6 address of the nAR 105 and the tentative proposed C0A, referred to as the new C0A (nCoA) The pAR 103 in response proceeds to transmit a Handover Initiate (HI) message to the nAR 105 thereby requesting that the nAR 105 validates the uniqueness of the nCoA and also that the oAR 105 activates a buffering of any data packets received at the nAR 105 which are addressed to the nCoA.

If the nCoA proposed by the ME 101 is not valid (for instance because it is already used by another node), the nAR 105 may simply reject the proposed address (and e.g. the entire handover) in a Handover Acknowledge (HAck) message returned to the pAR 103. Alternatively the nAR 105 may provide an alternate nCoA in the HAck message. If the proposed nCoA is considered valid, the HAck message indicates that the ME 101 may proceed to use the proposed nCoA.

The information of the HAck message is then conveyed to the ME in a Fast Binding Acknowledgement (FBAck) message sent by the pAR 103. Before sending the FBAck message, the pAR 103 furthermore activates the tunnelling of any received data packets addressed to the pCoA towards the nCoA. Thus, any data packets for the ME 101 received at the pAR 103 will automatically be forwarded to the nAR 105 where they are buffered.

The ME 101 then proceeds to attach to the nAR 105. This step typically involves a Link-layer switching from the pAR 103 to the nAR 105. Once attachment to the nAR's 105 link is complete, the ME 101 proceeds to signal its presence to the nAR 105 by transmitting a Fast Neighbour Advertisement (FNA) message to the nAR 105. When receiving this message, the nAR proceeds to forward any buffered/received data packets addressed to the nCoA to the ME 101 on the new link. At this point, the application sessions resume at the ME 101 with the incoming packets first being routed from the HA 109 to the pAR 103 and from there being tunnelled to the oAR 105.

Finally, the ME 101 proceeds to trigger a MIPv6 registration procedure to provide the nCoA to the HA 109. Following the update of the C0A at the HA 109 any incoming data packets are routed directly from the HA 109 to the nAR 105 without involving the pAR 103.

The operation of the nAR 105 in this scenario will be described in more detail with reference to FIG. 2 and 4.

The nAR 105 comprises a network interface 101 which couples the nAR 105 to the network 107 and which is arranged to receive and transmit data packets. The network interface 201 is coupled to a validation processor 203 which is furthermore coupled to a reserved address store 205.

In response to receiving the HI message from the pAR 103, the nAR 105 is arranged to determine if the proposed nCoA is a valid address that may be used by the ME 101 following the handover.

Specifically, as illustrated in FIG. 4, a validation procedure is initiated in step 401 when the nAR 105 receives the HI message from the pAR 103. The HI message is passed to the validation processor 203 which proceeds to determine if the proposed nCoA is a valid address for the ME 101 when it is attached to nAR 105.

Specifically, the validation processor 203 proceeds to determine if the proposed nCoA is valid by determining if the proposed C0A belongs to a set of associated addresses associated with the nAR 105 but does not belong to a stored set of reserved addresses.

Specifically, the set of associated addresses may comprise the addresses which are allocated to the nAR 105 or to a specific link to which the ME 101 is seeking to handover.

For example, one or more IPv6 prefixes may be assigned to the nAR 105 and the validation processor 203 may determine whether the proposed nCoA belongs to the set of addresses corresponding to the address space formed by these prefixes.

As the ME 101 generally generates the proposed nCoA based on knowledge of the prefixes allocated to the nAR 105, this requirement will typically be met. However, if it is not, the proposed nCoA is considered to be invalid.

If the proposed nCoA is found to be within the appropriate address space, the validation processor 203 proceeds to retrieve the stored set of reserved addresses from the reserved address store 205. The stored set of reserved addresses comprises a list of addresses that the nAR 105 has already determined cannot be used by the ME 101.

Specifically, the stored set of reserved addresses may comprise the addresses that the nAR 105 has previously determined are already used or intended to be used in the system. The validation processor 203 then proceeds to compare the proposed nCoA to the addresses contained in this set. If the proposed nCoA matches a reserved address, it is considered to be invalid.

In the specific example, the proposed nCoA is considered to be valid if the validation processor 203 does not identify a match in the stored set of reserved addresses. However, it will be appreciated that in other embodiments, the validation processor 203 may proceed to evaluate further requirements before the proposed nCoA is considered to be valid.

The validation processor 203 is coupled to a response transmitter 207 which is furthermore coupled to the network interface 201. If the proposed nCoA is considered to be valid, the validation processor 203 indicates this to the response transmitter 207 which in response proceeds to generate and transmit an address acceptance message for the proposed nCoA. In the example the address acceptance message is transmitted to the pAR 103 which forwards it to the ME 101. Specifically, as illustrated in FIG. 3, a HAck message comprising the proposed nCoA is transmitted to the pAR 103 resulting in an FEAck message comprising the proposed nCoA being transmitted from the pAR 103 to the ME 101.

It will be appreciated that in some embodiments the message may be transmitted directly to the ME 101 from the nAR 105.

In the example, a nCoA is thus considered to be valid if it is unique in the system and specifically if it is not allocated to any other node or interface. Furthermore, this determination of uniqueness is performed on the basis of only information which is already available at the nAR 105.

Specifically, no additional signalling is initiated or necessary in order to determine if the proposed nCoA is unique. Accordingly, very fast duplicate address detection can be performed thereby substantially improving the speed of the handover. Furthermore, no additional signalling overhead is introduced.

In the specific example, the validation processor 203 is arranged to validate the proposed nCoA in three subsequent steps as illustrated in FIG. 4.

Specifically, step 401 is followed by step 403 wherein the validation processor 203 proceeds to determine if the proposed nCoA belongs to a set of addresses which are already used by the nAR 105. Thus, the stored set of reserved addresses may comprise the addresses that are currently used by the nAR 105 itself. Specifically, the stored set of reserved addresses can comprise all addresses which are already configured on a network interface of the nAR 105 when the HI message is received.

Thus, the nAR 105 first determines if the proposed nCoA is equal to one of the IPv6 addresses already used by the nAR 105. In order to do this, the nAR 105 may compare the proposed nCoA against all the IPv6 addresses configured on each of its network interfaces and if a match is found the proposed C0A is designated to be an invalid address.

However, if no match is found, the duplicate address detection proceeds in step 405 wherein the validation processor 203 determines if the proposed nCoA matches an address that is already assigned to a ME which is in the process of handing over to the nAR 105 but has not yet handed over. Thus the stored set of reserved addresses may comprise addresses that are reserved for ME5 in the process of handing over to the nAR 105.

In step 405, the oAR 10.5 accordingly determines if the raCoA proposed by the ME is already used by another ME currently moving to the nAR 105, i.e. by another ME in the process of completing an FMIPv6 handover to the nAR 105. This includes any ME for which the nAR 105 has notified acceptance of the FMIPv6 handover (in the HAck message) but where the ME has not yet signalled its attachment to the nAR's 105 link (with the FNA/UNA message).

In the specific example, the nAR 105 evaluates its proxy neighbour cache to determine if this comprises a matching C0A. Specifically, the proxy neighbour cache is in accordance with the FMIPv6 specification used by the FMIPv6 functionality of the nAR 105 to track the IPv6 addresses (i.e. the nCoAs) of ME5 which are in the process of completing an FMIPv6 handover to the nAR 105 and for which the nAR 105 is defending their IPv6 addresses. Thus, in order to protect the nCoAs allocated to the incoming MEs, the proxy neighbour cache stores the assigned nCoAs such that the nAR 105 can respond to any Neighbour Solicitation messages that are received from other nodes seeking to use the address. Thus, the data stored in order for the nAR 105 to support the IPv6 proxy neighbour discovery procedure can be reused to determine the validity of an nCoA proposed by a ME 101 as part of a handover procedure.

If a match is found between the proposed nCoA and the addresses reserved for ME5 in the process of handing over to the nAR 105, the address is designated as being an invalid address. Otherwise, the duplicate address detection proceeds in step 407 wherein the validation processor 203 determines if the nAR 105 has any data stored which indicates that the proposed raCoA is already used by another network node which is supported by the nAR 105.

Specifically, the nAR 105 comprises a message monitor 213 which is coupled to the network interface 201 and the reserved address store 205. The message monitor 213 monitors the operation and communications of the nAR 105 and if a message is received from another node which indicates that it uses a specific IPv6 network address within the address space of the nAR 105, the message monitor 213 proceeds to include this address in the stored set of reserved addresses.

It will be appreciated that the message monitor 213 need not be separate functionality dedicated to the duplicate address detection but may partly or fully comprise functionality used for other purposes.

For example, in accordance with the IPv6 protocol (see T. Narten et al., "Neighbor Discovery for IP version 6 (IPv6)", IETF RFC 4861, September 200) the nAR 105 establishes a neighbour cache which amongst other information includes a list of IPv6 addresses used by nodes currently connected to the nAR's 105 link and which maps each of these IPv6 addresses to the corresponding MAC (Media Access Control) addresses of the connected nodes. The neighbour cache is typically used by the nAR 105 (as a regular IPv6 router) for routing packets to nodes attached to its links (i.e. by using the MAC address) In the example, the stored set of reserved addresses may thus comprise the list of IPv6 addresses in the neighbour cache, i.e. the stored set of reserved addresses may comprise the IPv6 addresses that have been determined in response to the messages from other nodes linking an IPv6 network address to a MAC address for the node. Specifically, such messages may include Neighbour Solicitation or Neighbour Advertisement messages communicated as part of neighbour discovery processes.

As another example, the addresses used by other nodes may be detected in response to one or more messages which are part of a network access control process for the network node.

Thus, the message monitor 213 can monitor any network access control procedures which are used by nodes to authenticate to the network and to obtain IPv6 connectivity at the nAR 105. It can then proceed to cache the IPv6 addresses of nodes that attached to its links and to include this in the stored set of reserved addresses.

Specifically, a security process can be monitored and any used IPv6 addresses can be detected. For example, an IPsec security association may be created between the nAR 105 and an attaching node and the message monitor 213 may retrieve the IPv6 address of the attaching node from this security association.

If a match is found between the proposed nCoA and the addresses identified to be used by other nodes connected to the nAR 105, the proposed nCoA is designated to be an invalid address. Otherwise, the proposed nCoA is designated as being unique for the nAR 105 and thus the system and the duplicate address detection is terminated with a positive income. Thus, the duplicate address detection has Ira this case resulted in an indication that the proposed nCoA is indeed unique and available for use by the ME 101 on the nAR's 105 link.

The method then proceeds in step 409 wherein the response transmitter 207 returns an address acceptance message for the proposed nCoA. Specifically, the response transmitter 207 proceeds to transmit a HAck message indicating acceptance of the FMIPv6 handover and including the proposed nCoA.

It will be appreciated that the stored set of reserved addresses and the reserved address store 205 need not be a single data structure or data store but may specifically represent data stored and used for other purposes.

Specifically, the reserved address store 205 and the stored set of reserved addresses may be considered to include the table(s) of configured addresses on the interfaces of the nAR 105, the proxy neighbour cache, the neighbour cache, any access control or security data stored at the nAR 105 etc. It will be appreciated that the reserved address store 205 and the stored set of reserved addresses may also be considered to include address information specifically derived and stored only for the purpose of performing the duplicate address detection.

It will be appreciated that in situations where the nAR 105 supports a plurality of links (corresponding to different address spaces or prefixes), the duplicate address detection may use only the information relating to the specific link to which the ME 101 is seeking to haradover. E.g. the validation processor 203 may only evaluate the nAR's 105 IPv6 addresses, proxy neighbour cache, neighbour cache and/or access control cache for the specific link that the ME 101 seeks to handover to. The nAR 105 can determine this link (and the associated nAR's interface) by comparing the proposed nCoA to the prefixes managed by the nAR 105 on the different links.

It will also be appreciated that when a proposed nCoA has been determined as valid and is returned to the ME 101 for use in the handover process, this nCoA may be included in the stored set of reserved addresses thereby ensuring that it will be rejected in any subsequent handover attempts from other ME5. Specifically, when the nAR 105 transmits a HAck message comprising an nCoA, the message monitor 213 may include the nCoA in the neighbour proxy cache.

If any of the steps 403, 405 and 407 results in a determination that the proposed nCoA is not available, the method proceeds in step 411 wherein the nAR 105 determines whether it can assign an alternate nCoA to the ME 101.

Specifically, the nAR 105 may determine if it can assign an alternate nCoA to the ME 101 by checking whether a specific configuration variable (e.g. a CAN-ASSIGN-CoA variable) is set or not. This configuration variable can be static, for instance configured by the system administrator or vendor at the time the AR is installed or shipped, depending on whether the AR is equipped or not with the necessary function (e.g. software module) to support the operation of alternate nCoA assignment.

Alternatively, the configuration variable can be set or unset dynamically (while the AR is running) depending on the current status of the AR. For instance, in situation where the AR processing power is overloaded (e.g. due to excessive traffic being routed through the AR) the variable may automatically be unset so as to save processing power of the AR (that otherwise would be increased by the alternate C0A assignment process) . In another scenario, the variable can be unset dynamically when the AR determines that its stored set of reserved address exactly matches its set of associated address, meaning that no free address are left on the AR link for the requesting ME, and this way avoiding triggering unnecessarily the alternate C0A assignment procedure.

If at step 411 the nAR 105 determines it can assign an alternate nCoA to the ME 101, the method proceeds in step 413 wherein the nAR 105 proceeds to generate an alternative nCoA that can be assigned to the ME 101 when handing over to the nAR 105.

Specifically, the nAR 105 comprises a rejection processor 209 which is coupled to the validation processor 203 and the response transmitter 207. The rejection processor 209 may generate a response message which rejects the nCoA that is proposed by the ME 101. However, in cases where the nAR 105 may generate an alternative nCoA, the rejection processor 209 may generate a handover acknowledge message comprising the alternative address. Thus the address rejection message may be a message that accepts the handover but rejects the proposed nCoA, e.g. by including the alternative nCoA generated by the nAR 105. Specifically, the rejection processor 209 can generate a HAck message which comprises the alternative nCoA instead of the proposed nCoA. This message is then forwarded to the response transmitter 207 which transmits it to the pAR 103.

The rejection processor 209 is coupled to an address generator 211 and to the validation processor 203. In step 413 the rejection processor 209 proceeds to generate an alternative address that can be used by the ME 101.

Specifically, the rejection processor 209 can perform the method illustrated in FIG. 5.

The method initiates in step 501 wherein a possible nCoA is generated for the ME 101. In particular, the rejection processor 209 may instigate the address generator 211 to generate the possible nCoA as an address having a prefix corresponding to the address prefix of the link of the nAR that the ME 101 is seeking to hand over to.

The address generator 211 then determines a suffix for the possible nCoA based only on information already stored in the nAR 105, i.e. without initiating any communication or interaction with any other node or in particular with the ME 101, the pAR 103 or the HA 109.

Thus, in the example, the address generator 211 generates the possible nCoA by appending a suffix (comprising a given number of bits) to the nAR prefix on the link the ME 101 intends to move to thereby creating an IPv6 address (i.e. a 128-bit long address) The address generator 211 may use different methods for generating the suffix of the possible nCoA. For example, the address generator 211 can generate the suffix using a random function, or by using a function that processes a previous possible nCoA in a predetermined fashion, for example simply by incrementing the address by one.

Thus, in the example the address generator 211 generates the possible nCoA without considering the current operating conditions or specifically without any consideration or selection based on the current use of addresses in the system. This allows a quick and easy generation of a possible alternative C0A but may result in a possible nCoA being generated which is already in use.

Accordingly, the rejection processor 209 proceeds to feed the generated possible nCoA to the validation processor 203 which proceeds to apply the same tests to the possible nCoA as was used to determine the validity of the proposed nCoA.

Specifically, step 501 is followed by the validation processor 203 performing steps 503, 505 and 507 which directly correspond to steps 403, 405 and 407 previously described with respect to the duplicate address detection performed on the proposed nCoA from the ME 101.

Thus, the nAR 105 uses the same approach and indeed functionality to determine if the possible nCoA as a valid address. In particular this determination is made in response to a determination that the possible nCoA belongs to the set of addresses associated with the nAR 105 but does not belong to the stored set of reserved addresses.

Accordingly, a very fast and low complexity approach is used to determine if the possible nCoA is a valid address that can be used by ME 101 after handing over.

If any of the tests determine that the possible nCoA is not a valid/usable address, the method returns to step 501 wherein the address generator proceeds to generate a new possible nCoA which is then validated.

Thus, of the rejection processor 209 detects that a possible nCoA is determined as an invalid address, it proceeds to repeat the generation and validation of a new possible nCoA.

It will be appreciated that this process may be iterated a number of times, e.g. until a valid CoA is detected or a stop requirement is met.

If none of the tests detect a match with an address of the stored set of reserved addresses, the method continues in step 509 wherein the possible nCoA is assigned to the ME 101.

The method then proceeds in step 511 wherein the validated possible nCoA is included in the stored set of reserved addresses. Thus, the nAR 105 adds the generated alternative nCoA to the list of nCoAs used by ME5 currently moving to the nAR 105. This ensures that the nAR 105 does not re-assign the same nCoA to another ME which subsequently seeks to move to the nAR 105. Specifically, the validated possible nCoA may be added to the nAR's 105 proxy neighbour cache.

Step 413 is followed by step 415 wherer the validated possible nCoA is included in the rejection message transmitted to the pAR 103. Specifically, the validated possible nCoA is included in a HAck message and transmitted to the pAR 103. The conventional handover process then continues.

If it is determined in step 411 that the nAR 105 cannot generate a valid alternative nCoA, the method of FIG. 4 proceeds in step 417 wherein it is evaluated if the nAR 105 can support the ME 101 using the C0A currently used by the ME 101 when attached to the pAR 103.

In accordance with FMIPv6, it is in some scenarios possible for an ME to keep using the C0A of a previous AR after it has handed over to a new AR if the new CoA proposed by the ME is not valid and an alternate (duplicate-free) C0A cannot be assigned. In this case, the nAR may configure a (temporary) host route for the previous C0A to point to the new AR's link and an FMIPv6 tunnel will be configured between the previous AR and the new AR addresses (instead of between the previous AR address and the new C0A) . Although this may allow the handover to be supported in some scenarios where it would otherwise be rejected it also has a number of disadvantages including for example additional functionality being required to support the tunnelling, an incompatibility with some security practises (such as ingress filtering) and a slow down of the MIPv6 registration with the HA.

However, if the nAR 105 can support the ME 101 using the previous C0A, step 417 is followed by step 419 wherein a haridover acceptance message is returned with a C0A indication of the previous C0A.

Otherwise, the method continuous in step 421 wherein the nAR proceeds to generate and transmit a handover rejection message refusing the handover. However, in contrast to conventional FMIPv6 protocols this message indicates that the handover is refused because the proposed C0A is not a valid/ unique address.

Furthermore, in the example, the handover refusal indication specifically comprises a preference indication for whether further CoAs should be proposed by the ME 101. The preference indication can be used by the ME 101 to determine whether the ME 101 should proceed to attempt the handover by using a different proposed nCoA or whether it should abandon the handover completely. The rejection message is in the specific example a HAck message enhanced to comprise an indication that the reason for the handover is that the proposed nCoA is not valid and whether the ME 101 should propose a different C0A or abandon the handover.

Thus whereas the conventional FMIPv6 protocol lacks means for notifying an ME that a handover is refused due to an invalid nCoA being proposed by the ME 101 (and that the ME may retry triggering the FMIPv6 handover by proposing another nCoA), the described system allows the nAR 105 to provide such information to the ME 101. The notification is highly advantageous as it allows the ME 101 to determine whether there is still a possibility of performing a successful handover to the target nAR (by proposing another nCoA) or whether it should instead abort the handover attempt to the target cAR.

Thus the nAR 105 can indicate to the ME 101 that the handover is refused due to an invalid nCoA being proposed by the ME 101 and also whether the ME 101 should retry triggering the handover procedure by proposing another nCoA.

This is specifically achieved by enabling the Code field of an FMIPv6 HAck message and the Status field of an FMIPv6 FBAck to take on new values.

The new values for the Code field of the FMIPv6 flAck message are specifically: * Code #1: Handover refused due to an invalid nCoA, the ME can try another nCoA; and * Code #2: Handover refused due to an invalid nCoA, the ME should not try another nCoA The (respective) new values for the Status field of the FMIPv6 FBAck message are: * Status #1: Handover refused due to an invalid nCoA, the ME can try another nCoA; and * Status #2: Handover refused due to an invalid nCoA, the ME should not try another nCoA Upon receiving a HAck message with a code field set to value "Code #1" from the nAR 105, the pAR 103 accordingly transmits an FBAck message with the status field set to value "Status #1" to the ME 101. Similarly, upon receiving a HAck message with code field set to value "Code #2" from the nAR 105, the pAR 103 transmits an FBAck message with status

field set to value "Status #2" to the ME 101.

It will be appreciated that the above description for clarity has described embodiments of the invention with reference to different functional units and processors.

However, it will be apparent that any suitable distribution of functionality between different functional units or processors may be used without detracting from the invention. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controllers. flence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality rather than indicative of a strict logical or physical structure or organization.

The invention can be implemented in any suitable form including hardware, software, firmware or any combination of these. The invention may optionally be implemented at least partly as computer software running on one or more data processors and/or digital signal processors. The elements and components of an embodiment of the invention may be physically, functionally and logically implemented in any suitable way. Indeed the functionality may be implemented in a single unit, in a plurality of units or as part of other functional units. As such, the invention may be implemented in a single unit or may be physically and functionally distributed between different units and processors.

Although the present invention has been described in connection with some embodiments, it is not intended to be limited to the specific form set forth herein. Rather, the scope of the present invention is limited only by the accompanying claims. Additionally, although a feature may appear to be described in connection with particular embodiments, one skilled in the art would recognize that various features of the described embodiments may be combined in accordance with the invention. In the claims, the term comprising does not exclude the presence of other elements or steps.

Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by e.g. a single unit or processor. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and the inclusion in different claims does not imply that a combination of features is not feasible and/or advantageous. Also the inclusion of a feature in one category of claims does not imply a limitation to this category but rather indicates that the feature is equally applicable to other claim categories as appropriate. Furthermore, the order of features in the claims does not imply any specific order in which the features must be worked and in particular the order of individual steps in a method claim does not imply that the steps must be performed in this order. Rather, the steps may be performed in any suitable order.

Claims

CLPJMS1. A mobile communication system comprising: a first access router for supporting a mobile entity prior to a handover of the mobile entity; a second access router for supporting the mobile entity following the handover; an interconnecting network coupling at least the first access router and the second access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the first access router and the second access router using a care of address for the mobile entity; the second access router comprising: means for receiving a proposed care of address for the mobile entity while the mobile entity is attached to the first access router, the proposed care of address being a proposed address for the mobile entity following the handover; means for determining it the proposed care of address is a valid address for the mobile entity when attached to the second access router; means for transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the first access router if the proposed care of address is a valid address; and a store for storiricj a stored set of reserved addresses; and wherein the validating means is arranged to determine the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the second access router and that the proposed care of address does not belong to the stored set of reserved addresses.
2. The mobile communication system of claim 1 wherein the stored set of reserved addresses comprises addresses used by the second access router.
3. The mobile communication system of claim 2 wherein the addresses used by the second access router comprises addresses configured on a network interface of the second access router.
4. The mobile communication system of claim 1 wherein the stored set of reserved addresses comprises addresses reserved for mobile entities in the process of handing over to the second access router.
5. The mobile communication system of claim 1 wherein the second access router comprises: means for detecting that a network address is used by a network node supported by the second access router in response to a network message received from the network node prior to the handover; means for including the network address in the stored set of reserved addresses.
6. The mobile commurilcation system of claim 5 wherein the network message is a message comprising an association of the network address and a Media Access Control, MAC, address for the network node.
7. The mobile communication system of claim 5 wherein the network message is a message of a network access control process for the network node.
8. The mobile communication system of claim 5 wherein the network message is a message of a security process for the network node.
9. The mobile communication system of claim 1 further comprising: rejection means for transmitting an address rejection indication for the proposed care of address to at least one of the mobile entity and the first access router if the proposed care of address is not a valid address.
10. The mobile communication system of claim 9 wherein the rejection means comprises: address generating means for generating a possible care of address for the mobile entity in response to a detection that the proposed care of address is not a valid address; means for determining if the possible care of address is a valid address in response to a determination that the possible care of address belongs to a set of associated addresses associated with the second access router and that the possible care of address does not belong to the stored set of reserved addresses; and means for including the possible care of address Ira the rejection indication if the possible care of address is a valid address.
11. The mobile communication system of claim 10 wherein the address generating means is arranged to generate the possible care of address as an address having a prefix corresponding to an address prefix of a link of the second access router to which the mobile entity is handing over and a suffix generated in response to only information stored in the second access router.
12. The mobile communication system of claim 10 wherein the rejection means is arranged to repeat a generation and validation of a new possible care of address if a previous possible care of address is determined as an invalid address.
13. The mobile communication system of claim 9 wherein the rejection means is arranged to include a handover refusal indication in the rejection indication, the handover refusal indication comprising an indication of a reason for refusal being that the proposed care of address is not a valid address.
14. The mobile communication system of claim 13 wherein the handover refusal indication comprises a preference indication for whether further care of addresses should be proposed by the mobile entity.
15. The mobile communication system of claim 1 wherein the validating means is arranged to include the proposed care of address Ira the stored set of reserved addresses if the proposed care of address is a valid address.
16. The mobile communication system of claim 1 wherein the set of associated addresses comprises only addresses of a link of the second access router to which the mobile entity is handing over.
17. The mobile communication system of claim 1 wherein the proposed care of address is an Internet Protocol address.
18. The mobile communication system of claim 1 wherein the handover is a Fast Mobile Internet Protocol version 6 handover.
19. An access router for a mobile communication system including a further access router for supporting a mobile entity prior to a handover of the mobile entity from the further access router to the access router and an interconnecting network coupling at least the access router and the further access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the access router and the further access router using a care of address for the mobile entity; the access router comprising: means for receiving a proposed care of address for the mobile entity while the mobile entity is attached to the further access router, the proposed care of address being a proposed address for the mobile entity following the handover; means for determining if the proposed care of address is a valid address for the mobile entity when attached to the access router; means for transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the further access router if the proposed care of address is a valid address; and a store for storing a stored set of reserved addresses; and wherein the validating means is arranged to determine the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the access router and that the proposed care of address does not belong to the stored set of reserved addresses.
20. A method of operation for a mobile communication system including a first access router for supporting a mobile entity prior to a handover of the mobile entity; a second access router for supporting the mobile entity following the handover; and an interconnecting network coupling at least the first access router and the second access router and comprising means for routing data between the mobile entity and a mobility anchor point via at least one of the first access router and the second access router using a care of address for the mobile entity; the method comprising the second access router performing the steps of: receiving a proposed care of address for the mobile entity while the mobile entity is attached to the first access router, the proposed care of address being a proposed address for the mobile entity following the handover; determining if the proposed care of address is a valid address for the mobile entity when attached to the second access router; transmitting an address acceptance indication for the proposed care of address to at least one of the mobile entity and the first access router if the proposed care of address is a valid address; and storing a stored set of reserved addresses; and wherein the validation comprises determining the proposed care of address as a valid address in response to a determination that the care of address belongs to a set of associated addresses associated with the second access router and that the proposed care of address does not belong to the stored set of reserved addresses.