Technical Field

The present invention relates to a method and apparatus for use in communications networks, and in particular to a method and apparatus for access selection of a mobile terminal having multiple access capabilities.

Background Mobile IP is a mechanism for maintaining transparent network connectivity to and from a mobile node, such as a mobile terminal or telephone, over an IP based network whilst the mobile node is roaming within or across network boundaries. Mobile IP enables a mobile node to be addressed by a fixed IP address regardless of the network to which it is currently physically attached. Mobile IP can be implemented using IP version 4 (IPv4) or IP version 6 (IPv6), although IPv6 is generally preferred as IPv4 has a number of limitations in a mobile environment. The IPv6 protocol is specified in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 2460, whilst Mobile IP using IPv6 is specified in IETF RFC 3775, 'Mobility Support in IPv6'.

Most of today's mobile terminals, such as mobile telephones and generally referred to herein as User Equipments (UEs), are equipped with more than one wireless interface, allowing them to operate as multi-access terminals. This multi-access capability is advantageous for mobile users because each wireless access technology has different characteristics in terms of bandwidth, cost etc. and mobile applications place varying demands on such parameters of the access technology. Moreover, the variety of different networks currently in operation presents a variety of different access technologies available to mobile IP users. For example, although the Long Term Evolution (LTE) being defined by the Third Generation Partnership Project (3GPP) will become the most stable wireless access technology available, there will still be situations where it is advantageous for a UE to obtain IP connectivity over a wireless local area network (WLAN) interface, e.g. for cost reasons.

The availability of these multi-access capabilities requires IP Mobility Management

(IPMM) to control the access technology and use of the appropriate interface at the UE. Many networks support both client-based and network-based IP Mobility Management. The client-based IPMM is referred to as Client Mobile IP (CMIP) and the network- based IPMM is referred to as Proxy Mobile IP (PMIP) hereafter. An example of CMIP is Dual Stack Mobile IPv6 (DSMIPvθ) and an example of PMIP is Proxy Mobile IPv6 (PMIPvθ). An example of a mobile network that supports both CMIP and PMIP is the 3GPP Evolved Packet System (EPS - see 3GPP TS 23.402, "Architecture enhancements for non-3GPP accesses," version 8.2.0, June 2008). In 3GPP EPS, a Packet Data Network Gateway (PDN-GW) serves as a global mobility anchor point for UEs. A PDN-GW serves as a Home Agent (HA) when the UE is operated in a CMIP mode, while it serves as Local Mobility Anchor (LMA) when the UE is operated in a PMIP mode. In this way, the mobile system we consider in this invention is "heterogeneous" in terms of IPMM. In the description below a UE with multi-access capabilities that is accessing an IP network is referred to as a mobile host, while the LMA or HA is referred to generally as a mobility anchor.

PMIP and CMIP each have different characteristics that the Mobile Network Providers (MNPs) need to consider. Network-based PMIP is advantageous in that the MNP retains control and also because it results in less mobility signaling as well as ensuring location privacy (i.e. ensuring that a third party is unable to learn the geographical location the UE. On the other hand, client-based CMIP is advantageous over PMIP in that it can handle the multi-access environment in a simpler way.

Considering the above, in order to make most efficient use of network resources, the mobile system needs to handle both flow movement (i.e. moving IP flow from one interface to another) and IPMM mode change (i.e. changing IPMM mode from one to another). However the way that this is currently carried out is less than optimal.

For example, in the 3GPP Systems Architecture Evolution (SAE), the mode of IPMM is determined based on the type of access network that the UE is visiting. That is, when the UE is attached to a 3GPP access network it is considered to be on its home network and thus CMIP is inactivated. On the other hand, when the UE is attached to a non-3GPP access network it is considered to be on a foreign network and the UE may be operated either in the CMIP mode or the PMIP mode. One method to execute IPMM mode change is to rely on CMIP movement detection. The problem with this approach is that PMIP is activated only when the UE returns to the home network. This means that use of PMIP is limited to within the 3GPP access network and the use of CMIP is mandated whenever the UE is attached to a non-3GPP access network. It would be preferable for IPMM selection to be made independently of the type of access network. For instance, it should be possible for the IPMM selection mechanism to choose PMIP even in a non-3GPP access network.

The exchange of information between nodes (i.e. network entities and/or UEs) is referred to as an IP flow. Flow movement refers to an action to move an IP flow from one interface to another without impacting on the applications to which the IP flow relates. Prior to the flow movement, an access selection needs to be made to establish the identity of the new interface through which the IP flow will be directed. Current practice is for this to be performed by a network element dedicated for access selection, which is referred to as a policy engine. In client-based IPMM (CMIP), flow movement can be performed by the means of primary care-of address (CoA) selection. That is, each CoA is bound to a given wireless access network and thus a change of primary CoA leads to execution of flow movement. Multiple Care-of Address Registration for Mobile IPv6 (Monamiθ - see R. Wakikawa et al., "Multiple Care-of Addresses Registration," draft-ietf-monami6-multiplecoa-09.txt, August 2008) can be a candidate solution for access selection. However, Monamiθ is only applicable for CMIP.

Moreover, in the case of network-based IPMM (PMIP), an additional functional component (hereafter referred to as flow movement module) is required. Note that moving an IP flow from one interface to another would normally cause disruption of communication as the communication endpoint (IP address) of the UE needs to be changed upon a movement This issue is known as a PMIP Multi-Access problem (see 'Multiple Interfaced Mobile Nodes in NetLMM' M. Jeyatharan, C. Ng, V. Devarapalli, J. Hirano - hjJIIϊidMliL^^ and there have been some proposals for addressing this, as described for example in PCT/EP2008/065357. In any case, the flow movement module needs to interact with the policy engine to obtain policies for flow movement. This means that the policy engine needs to interface with both the user's CMIP and the flow movement module. The CMIP module is incorporated in the UE (as well as in the user's Home Agent server). Hence the design of the policy engine becomes more complex. It is an objective of the present invention to alleviate the problems of IPMM selection and access selection described above. It is a further objective to provide a solution which removes the dependency on CMIP for IPMM selection, and which provides an integrated mechanism for both access selection and IPMM selection.

Summary

According to a first aspect of the present invention there is provided a method of access selection for a mobile host in an IP communications environment. The method includes defining a path list that includes a plurality of paths. A path comprises a locator of a mobility anchor in a mobile core network and a locator chain comprising one or more locators of interfaces in the mobile host. A path from the path list is selected as a primary active path for providing the mobile host with IP connectivity to the mobile core network.

Embodiments my further comprise changing the primary active path from the selected path to another path in the path list.

Embodiments my further comprise making a mobility management selection between client-based mobility management and network-based mobility management.

The primary active path selection and/or the mobility management selection may be made by the mobile host. Alternatively, the primary active path selection and/or the mobility management selection may be made by the mobile core network.

The primary active path selection and/or the mobility management selection may be made by both the mobile host and the mobile core network and in the event of each selecting a different active path or mobility management the selection made by the mobile core network may be used. Additionally, the selection made by the mobile core network may be used except when the selection is made on the basis of information that is only available to the mobile host, in which case the selection made by the mobile host may be used. Preferably, defining the path list includes exchanging locator information between the mobile host and the mobility anchor. More preferably, the method further comprises exchanging an updated path list between the mobile host and the mobility anchor. Further, the mobile host and the mobility anchor may exchange a locator list for the mobile host, the locator comprising a list of locators associated with each interface in the mobile host, and wherein the locators associated with inactive paths are virtual locators. The mobile host and mobility anchor may also exchange an interface list, indicating which interfaces in the mobile host are physical interfaces and which are virtual interfaces.

The locator information may be exchanged and/or updated in accordance with an ID/Locator separation mechanism, such as Site Multihoming by IPv6 Intermediation, SHIM6, or Host Identity Protocol, HIP. Preferably, when the ID/Locator separation mechanism is SHIM6, the exchange of the path list comprises: sending a SHIM6 I2 message from the mobile host to the mobility anchor, the I2 message including a list of locators of interfaces in the mobile host; calculating paths based on the list of locators to generate the path list; and including the path list in a SHIM6 R2 message sent from the mobility anchor to the mobile host. Preferably, when the ID/Locator separation mechanism is SHIM6, an updated path list is exchanged between the mobile host and the mobility anchor by way of an update request message. The method may further comprise changing the active path from the selected path to another path in the path list by way of an update request message.

In embodiments wherein at least one of the interfaces in the mobile host is a virtual interface, and at least one of the paths in the path list includes a locator of the virtual interface, the at least one path comprises a tunnel between the mobile host and an evolved packet data gateway, ePDG, in the mobile core network. The at least one path may comprise an IPsec tunnel or a Dual Stack Mobile IPv6, DSMIPv6, path.

It is an advantage that a means is provided for enabling path management in mobile networks. By the means of path selection, the mobility anchor can instruct an IP transformation chain to be applied to the user IP traffic. The mobile host then becomes able to configure its IP sub-layers (e.g., DSMIPv6, IPsec). Hence dynamic configuration of the IP stack becomes possible. It is a further advantage that IP flows can be moved from one interface to another without any impact to applications. In other words, if the IP address of the mobile host is changed as a consequence of flow movement, the application can continue IP transactions with the same IP address (identifier) of the mobile host.

It is a further advantage that the multiplexing and de-multiplexing of IP packets are performed inside the local mobile system (mobility anchor and the mobile host) and thus the presence of address switching mechanism (e.g. SHIM6) is kept transparent to the remote peer side.

According to a second aspect of the present invention there is provided a mobile terminal for accessing a mobile telecommunications network. The mobile terminal includes a plurality of communications interfaces through which data traffic is transferred to/from the terminal. The mobile terminal is configured to obtain a path list that includes a plurality of paths, wherein a path comprises a locator of a mobility anchor in a mobile core network and a locator chain comprising one or more locators of the interfaces. The mobile terminal is further configured to select a path from the path list as a primary active path to achieve IP connectivity to the mobile core network.

According to a third aspect of the present invention there is provided a network node in a mobile telecommunications core network. The network node is configured as a mobility anchor for a mobile terminal, wherein the mobile terminal includes a plurality of interfaces. The mobility anchor calculates a path list that includes a plurality of paths, wherein a path comprises a locator of the mobility anchor and a locator chain comprising one or more locators of the interfaces in the mobile host.

Brief Description of the Drawings

Figure 1 is a schematic illustration of a mobile IP network in which an embodiment of the present mechanism is performed.

Figure 2 is a more detailed schematic illustration of a mobile IP network of the type shown in Figure 1.

Figure 3 is a schematic illustration of peer-to-peer connectivity of an IP communication. Figure 4 is an illustration of a number of variants in the signaling involved in establishing a SHIM6 context.

Figure 5 is a schematic illustration of the functional components of a mobile host and a mobility anchor. Figure 6 is a signal flow diagram illustrating a SHIM6 context establishment.

Figure 7 is a signal flow diagram illustrating the general principle involved in a dynamic path update.

Figure 8 is a signal flow diagram of a particular example of a dynamic path update in the mobile IP network of figure 1.

Figure 9 is a flow chart illustrating steps for implementing an embodiment of the present mechanism.

Detailed Description

In the mobile networks described herein, it is assumed that a mobile host is equipped with multiple interfaces. It is also assumed that the IP mobility management is done either by a client-based IP mobility protocol such as DSMIPvθ or Mobile IPv6, or by a network-based IP mobility protocol such as Proxy Mobile IPv6. The 3GPP SAE is an example of mobile network to which the solution can be applied. A new concept of "path" is introduced, which indicates a way of transferring user traffic between the mobility anchor (e.g. PDN-GW) and the mobile host or UE. A path may be defined by, or at least includes, a pair of (1 ) a locator of the mobility anchor and (2) a locator chain of the mobile host. A locator chain refers to a sequence of locators. Herein, a locator may be an IP address, but it can also represent an IP address which is not in an active state. Such an inactive IP address is referred to as a "virtual locator." A virtual locator can turn into a normal (i.e. active) IP address when an activation procedure is taken (e.g. a DSMIPv6 home address is activated when the home registration procedure is taken).

Figure 1 shows an example of a mobile network where the proposed mechanism is employed on a mobility anchor 12 located in a mobile core network 10, and mobile host 14. In this example, the mobility anchor 12 is a PDN-GW and the mobile host 14 is a 3GPP UE. The PDN-GW 12 serves both as a Home Agent (HA) and as a Local Mobility Anchor (LMA) for mobile hosts (3GPP UEs) in accordance with the 3GPP specification TS 23.402. The mobile core network 10 also includes an evolved packet data gateway (ePDG) 13, the purpose of which will be described later on. Note that the network supports both client-based IPMM (i.e. CMIP) and network-based IPMM (i.e., PMIP). In CMIP the mobile host 14 operates as a CMIP client and establishes an IP- in-IP tunnel with the mobility anchor 12 over the S2c interface (see Figure 2). In PMIP the mobile host 14 is not involved in any procedures for IPMM but it simply operates as a plain IP host.

In this example the mobile host 14 is equipped with 3 physical interfaces (IF1 , IF2 and IF3), each having different characteristics. In addition, the mobile host 14 has the potential to use virtual interfaces. In this example, IF4 is a virtual interface for

DSMIPvθ and IF5 is a virtual interface for IPsec. Note that the mobile host 14 is assigned a different PMIP prefix for each wireless interface. As shown in Figure 1 , there are 5 available locators (each denoted as a circle) on the mobile host 14 (3GPP UE) and each will be employed in a different path.

In this example, there are access networks employing three different types of access technology: a 3GPP access network 16, a trusted non-3GPP access network 17, and un-trusted non-3GPP access network 18. A Serving Gateway 15a operates as a Mobile Access Gateway (MAG) in the 3GPP access network 16. The trusted non- 3GPP access network 17 includes an Access Router (AR) that also operates a MAG 15b. These MAGs 15a, 15b operate as Access Routers, handle mobility signaling messages on behalf of the mobile host 14, and maintain the IP-in-IP tunnels to route IP packets sent to/from the mobile host (over S5/S2a/S2b interface - see Figure 2). The un-trusted non-3GPP access network includes an Access Router 19, while the other functions of a MAG are provided by the ePDG 13 in the mobile core network 10 for this access network.

Figure 2 illustrates an example of a mobile network similar to that of Figure 1 , except that more detail of the network entities, interfaces between entities and connectivity are shown. Equivalent entities are given the same reference numerals as Figure 1. As shown in Figure 2, the mobile core network 10 also includes a Home Subscriber Server

(HSS) 20, a Mobility Management Entity (MME) 22, and a Policy Control and Rules

Function (PCRF) 24. In addition the Serving Gateway (S-GW) 15a is shown as part of the mobile core network 10 in Figure 2, rather than being in the 3GPP access network 16 as in Figure 1 , while the 3GPP access network 16 includes the entity 26 referred to as eNodeB. The interfaces shown in Figure 2 include Gx, Gxa, Gxb, Gxc, S1 -MME, S1 -U, S2a, S2b, S2c, S5, S6, S1 1 , SWn, SWu and LTE-Uu.

Referring again to Figure 1 , the mobility anchor 12 and the mobile host 14 implement the following functions: path management; dynamic path update; and ID/Locator switching. These functions are integrated in an ID/Locator separation mechanism inside the IP stack, for example SHIM6 (see E. Nordmark, M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6," internet-draft, draft-ietf-shim6-proto-1 1.txt, December 2008), or HIP (see R. Moskowitz, P. Nikander, "Host Identity Protocol (HIP) Architecture," RFC 4423, May 2006). The embodiments described below focus on an implementation using SHIM6, but as would readily be recognized by the skilled person, the principles may be implemented using other mechanisms, such as HIP.

The mobility anchor 12 and the mobile host 14 conduct a negotiation, in which a locator list of each node is exchanged and a path list is managed. Once a path is selected either by the network (i.e., the mobile operator) or by the mobile host 14, the mobile host 14 can be connected with the mobile core network 10 in accordance with the defined path. The path can be dynamically updated either by the network 10 or by the mobile host 14. In essence, the mechanism enables: (1 ) flow movement and (2) selection of a mode of IP mobility management in an integrated way.

Table 1 - 3 show the conceptual data that are managed by the mobile host 14 and the mobility anchor 12.

Table 1 : Path List

Table 2: Locator List

Table 3: Interface List

Table 1 shows an example path list between the mobility anchor 12 and the mobile host 14. The path list is a data structure managed by the mobile host 14 and the mobility anchor 12. A path is a way of transferring user IP traffic between the mobile host 14 and the mobility anchor 12, and in a simple form specifies a pair of locators wherein user traffic is exchanged between the pair of locators. Examples of such a path are P1 , P2 and P3 shown in Table 1 , with X1 the locator of the mobility anchor (PDN-GW) 12 and L1 , L2 and L3 respectively the locators of the mobile host 14.

However, when tunneling is involved in the transfer of user traffic, either end of the path may be represented by a chain of locators. Such a locator chain indicates that there is an association between adjacent locators. Examples of paths with locator chains are P4 and P5 in Table 1. Path P4, when activated, is a path where the mobile host 14 establishes an IPsec tunnel with the ePDG 13. The IPsec tunnel includes an inner locator (IP address), which in this instance is L5 and an outer locator, which is L3. L3 is bound to interface IF3 (wmxO) as indicated in Table 2 and 3. In the case of P5, two tunnels are involved: a DSMIPvθ tunnel and an IPsec tunnel. Locator L4 represents the DSM IPv6 home address and locator L5 represents the care-of address. L5 is also the locator of the inner address of the IPsec tunnel and L3 the locator of the outer address (as for P4).

In Table 1 , the status indicates if the path is active or not. An active path is one that is currently ready for transferring IP packets. For a path to be "active" the locators of the mobility anchor 12 and the mobile host 14 are all in "active" status. Hence P1 is the only active path in this example. When a path becomes entirely useless, for example when a locator included in the path has been removed from the locator list, the status of the path is set to obsolete. An obsolete path may be kept in the path list of the mobile host and/or the mobility anchor because it may subsequently be useful to reduce the computational cost for path calculation.

Table 2 shows a corresponding Locator List for the mobile host 14. A locator list is a data structure managed by the mobile host 14 and the mobility anchor 12. This locator list is similar to one defined in the standard SHIM6. The only difference is that a locator could be a virtual IP address. A virtual IP address is indicated as "inactive" status in the locator list and corresponds to a locator of an inactive interface and is therefore only in an inactive path in the path list. An inactive locator represents an IP address that does not currently exist, but which is available when required. For instance, L2 in Table 2 is inactive because the associated interface (i.e., IF2) is inactivated at the moment. However, if IF2 is subsequently activated, an IP address for this will be assigned to the mobile host 14. Availability of a virtual IP address is determined by information such as coverage information of a given wireless access network and/or geographical location information of the mobile host 14. When the availability of a locator is lost (e.g. the mobile host moves to outside the coverage of wireless access), the locator is completely removed from the locator list.

Table 3 shows a corresponding Interface List for the mobile host 14. An interface list is another data structure managed by the mobile host 14 and the mobility anchor 12. There are two principal types of interface - a physical interface and a virtual interface - as indicated in the third column in Table 3.

The mobility anchor and mobile host maintain a list of paths, locators and interfaces as shown in Tables 1 to 3. From the access selection perspective, P1 is bound to a wireless interface named IF1 , P2 is bound to IF2, and P3, P4 and P5 are bound to IF3. As shown in the Tables, only path P1 is active. Normally a single path is selected and used as a communication path between the mobile host and the mobility anchor. However, it is also possible to select and use different paths for different applications provided that the system employs the simultaneous multi-access mechanism. In that case there may be more than one active path. An example of Simultaneous Multi- Access would be if an application, App-A, chooses Path-1 while another application, App-B, chooses Path-2. Such operation is possible provided that the mobile host and the user's home agent server maintain a policy database for mapping of applications and selected paths. Note that the IPMM mode (CMIP or PMIP) will be based on the active path that has been selected as the primary active path between the mobile host and the mobility anchor. The path selection mechanisms described herein can be integrated with a Simultaneous Multi-Access system.

Figure 3 will be used to illustrate the fundamental principles of the operation of SHIM6. SHIM6 is a protocol for enabling multi-homing support for the IPv6 hosts. As shown in Figure 3 two peers 31 , 32 (referred to as Hosti and Host2 respectively) communicate over the internet 33. Hosti has two interfaces 34, 35, with respective identifiers as shown, while Host2 has an interface with the identifier IP1 HOST2. Hosti 31 uses a first interface 34 with identifier IP1 HOST1 for IP flows via a first Internet Service Provider (ISP1 ) 36 and uses its second interface 35 for IP flows via a second Internet Service Provider (ISP2) 37, which includes communications with Host2 32.

SHIM6 is designed in a host-centric way such that signaling and context management is solely performed by the host itself. In SHIM6, the communicating peers (Hosti 31 and Host2 32) conduct negotiation, referred to as SHIM6 context establishment, to create a context in which bindings of Identifier and Locators of each peer 31 , 32 are stored. An example of a SHIM6 context for the peers 31 , 32 of Figure 3 is:

Identifier of Host 2: {IP1JHOST2} Locator of Host 2: {IP1JHOST2}

Identifier of Host 1 : {IP1JHOST1}

Locator of Host 1 : {IP1JHOST1 , IP2JHOST1}

Primary Locator of Host 1 : {IP2JHOST1}

A particular advantage of SHIM6 is that even if a communicating peer changes its IP address during the communication, the session can be maintained uninterrupted by updating the locator information. In the mechanism of the present embodiments, the way of establishing context is different from the existing SHIM6 variants in that SHIM6 context establishment is performed entirely by one of the communicating peers, in association with its local mobile core network. Figure 4 shows variants of SHIM6. The variant labeled (1 ) in the figure is the plain SHIM6, in which the SHIM6 context is established between a first peer H1 accessing a local network 41 and a second peer H2 accessing a remote network 42. The variants labeled (2) and (3) are examples of Proxy SHIM6, in which the SHIM6 context is established between the peers via a SHIM6 proxy 43 in the remote network 42. In variant (3) there is also a further SHIM6 proxy 44 in the local network, which participates in the context establishment. The variant labeled (4) is an example of the present mechanism, in which a SHIM6 context is established between the first peer H1 and a SHIM6 proxy 44 in the local network 41. This application of SHIM6 remains completely transparent to the remote network 42 and second peer H2.

Figure 5 shows the functional components and conceptual data structures in the mobile host 14 and mobility anchor 12 required for the present mechanism. The three functional components depicted are sub-functions of an ID/Locator separation mechanism 51 , and include: an ID/Locator Switching function 52, a Path Management function 53, and a Locator Management function 54. The three conceptual data structures maintained by the mobile host 14 and the mobility anchor 12 are those described above with reference to Tables 1 to 3 - i.e. a Path List 55, Locator List 56, and Interface List 57. The Locator List 56 is primarily managed by the Locator Management function 54. However, it is also affected by the ID/Locator Switching function 52. Note that the Path Management function 53 and the Path List 55 are new features not included in a normal ID/Locator separation mechanism such as SHIM6. Figure 5 also shows a Mobile IP (MIP) module in the mobility anchor 12 and mobile host 14 and an IPsec module in the mobile host 14. Either, or both, of these are used to manipulate the Locator List and the Interface (I/F) list to update the status of the virtual interfaces and the associated locators. There is no IPSec module in the mobility anchor 12 because the end-point for an IPSec tunnel is the ePDG 13, not the mobility anchor 12.

Path management comprises two procedures: a procedure referred to herein as path negotiation to negotiate paths between the mobile host 14 and the mobility anchor 12, and a procedure referred to herein as dynamic path update to dynamically update the primary active path. Thus, path negotiation is used to maintain a list of paths between the mobile host 14 and the mobility anchor 12 and, in the embodiments described below takes place during the SHIM6 context establishment between the mobile host 14 and the mobility anchor 12. The selection of a path as the primary active path is performed either by the mobility anchor 12 or the mobile host 14, depending on whether the IPMM is CMIP or PMIP. Note that, in practice, selection of a path as the primary active path results in selection of both the access type and IPMM protocol. In some embodiments the mobility anchor 12 may send a signal to the mobile host 14 to change the path. More details of dynamic path update are described further below.

ID/Locator switching is performed by the mobility anchor 12 and mobile host 14. One of the IP addresses assigned to the mobile host 14 is chosen as an "identifier" which is associated with a locator. The mapping between the identifier and locator can be dynamically updated without any impact on applications. The ID/Locator switching remains transparent to the remote peer side of the communication.

Figure 6 shows the procedure of a SHIM6 context establishment which takes place at the initial attachment of the mobile host 14 to the mobile network. In this case, the mobile host 14 is the initiator and the mobility anchor 12 is the responder in a negotiation to establish a SHIM6 context. The procedures at steps 601 to 604 are the same as standard SHIM6. These include: the initiator (mobile host 14) allocating a context tag at step 601 , sending an 11 message to the responder (mobility anchor 12) at step 602, the responder calculating a validator at step 603 and returning a R1 message to the initiator at step 604. At step 605 the mobile host 14 receives the R1 message and completes the validation of this in accordance with the standard SHIM6 procedure, generating its locator list and calculating a cryptographically generated address (CGA) signature. At step 606 the mobile host 14 sends an I2 message to the mobility anchor 12. The procedures then continues through steps 607 to 609 in processing I2 and R2 messages in a manner that is modified in the present mechanism.

At step 607, when the responder (mobility anchor 12) receives the I2 message from the initiator (mobile host 12), it first processes the message as per the SHIM6 specification, which includes validating the I2 message, verifying the CGA signature, allocating a responder's context tag and generating a responders locator list. In addition, the responder takes the following new procedures. Firstly, at step 608, the responder generates a locator list for the mobile host. This is done based on knowledge of the access networks and the capabilities of the initiator (mobile host 14). For instance, the responder (mobility anchor 12) may know the geographical location of the mobile host, (e.g. from a Global Positioning System), and may have data regarding the access networks in that area. In that case, the responder updates the locator list of the initiator so that appropriate interfaces are provided for the available access networks. For example, in the set-up of Figure 1 and Table 2, the responder (mobile anchor 12) updates the locator list by including additional locators L2 and L3. Note that locators such as L2 and L3 cannot be identified by the initiator itself because, normally, the mobile host 14 has no information about the characteristics of the access network prior to the attachment.

At step 609, after the locator list of the mobile host 14 has been updated, the responder (mobility anchor 12) calculates the paths based on the locator lists of the mobile host 14 and the mobility anchor 12. Any suitable procedure for generating paths may be used, an example being to consult an external policy store where policies about access selection and IP mobility management are stored.

At step 610 the responder (mobile anchor 12) sends an R2 message to the initiator (mobile host 14). This includes the locator list of the initiator, generated at step 608, and the path list calculated at step 609. At step 61 1 , when the initiator has received the R2 message from the responder, it first processes the message as in the standard SHIM6 specification, including storing the responder's locator list. In addition, the initiator takes the following procedures that are new in this mechanism.

At step 612, the initiator updates its own locator list according the locator list provided by the responder. In this way the initiator becomes armed with a list of locators that are potentially available. Next, at step 613, the initiator extracts and stores the path list from the R2 message. After the completion of processing of the R2 message, a SHIM6 context pair is established between the initiator (mobile host 14) and the responder (mobility anchor 12). The path list and locator list that each has stored is the same, and thereafter the initiator and the responder maintain these so that the way of transferring user traffic can be specified as part of the path selection. Each path in the path list is characterized by both access type and mode of IPMM. In other words, when a path is selected, then the access type and IPMM protocol to be used are also selected. For instance, in the example of Table 1 , the following modes of IPMM will be used when those paths are selected as active paths (P1 : PMIP), (P2: PMIP), (P3, none), (P4, PMIP), (P5, CMIP). Note that P3 is not associated with any IPMM protocol and it is considered to be a plain IP (as indicated in Table 2). Thus P3 on its own cannot be selected as there is no IP mobility support.

Once the path list has been established and stored in the mobile host 14 and mobility anchor 12, a path can be dynamically updated. A typical trigger for a path update is a movement of the mobile host (e.g. to a different access network). The signaling is performed by an exchange of SHIM6 Update Request and Update Acknowledgement messages as shown in Figure 7. In this example, it is assumed that the responder (i.e., mobility anchor 12) detects a need for path update (step 701 ) and thus sends an Update Request message to the initiator (mobile host 14) at step 702. The Update Request message includes the new path list, which indicates the new path to be selected as the primary active path. At step 704 the initiator returns an Update Acknowledgement to confirm that the update has been made. Note that the Update Request and Update Acknowledgement messages may be sent in the opposite directions. When the need for the path update is detected by the initiator (mobile host) the Update Request message invoking a dynamic path update is sent by the initiator to the responder.

Figure 8 shows an example of dynamic path update in more detail, when one of the paths involved in the update includes a tunnel. In this example, the mobility anchor 12 triggers a dynamic path update, requesting a change of primary active path from P1 to P4 in the network scenario shown in Figure 1 and Table 1 Tables 1 to 3. At the beginning (801 ) the mobile host 12 is using P1 for handling user traffic. At step 802 the mobility anchor 12 detects a need for and triggers the dynamic path update. At step 803 the- mobility anchor 12 sends an Update Request message to the mobile host 14. The path list included in the Update Request message indicates that a new path (P4) is preferred over the current path (P1 ). After the mobile host 14 has received the Update Request message, it processes this at step 804, updating its locator list and path list, and at step 805 sends the Update Acknowledgement message to the mobile anchor 12. Then, at step 806 the mobile host 14 takes procedures to make the new path (P4) available. According to the path list, the locator list, and the interface list, P4 is an IPsec tunnel to the ePDG 13. To complete the setting up of an IPSec tunnel, the mobile host 14 identifies that an IKEv2 negotiation needs to be conducted to establish a security association with the ePDG 13. At step 807 the mobile host 14 initiates an IKEv2 negotiation. In this procedure the ePDG 13 operates as a mobile access gateway (MAG) and performs a proxy binding registration with the mobility anchor 12 at step 808. At step 809 the mobile host establishes the IPsec security association (SA) and updates the active path to P4, making L5 and L3 active locators, to establish the IPsec tunnel via the IF3 interface. Meanwhile, at step 810, the mobility anchor 12 updates its PMIPvθ binding information. Thereafter, at 81 1 , the user traffic flows via the path P4. In this example the dynamic path update invokes a movement from a 3GPP access network (e.g. LTE) to an untrusted non-3GPP access network.

As a consequence of the path update, the path lists, locator lists and interface lists, that were originally as specified in Tables 1 -3, and stored at the mobile host 14 and the mobility anchor 12 have changed. The principal difference is that updated lists will indicate that path P4 is selected as the primary active path.

The mechanism described above provides a means for the mobility anchor 12 and the mobile host 14 to carry out both access selection and IPMM selection. However, there is a possibility of a conflict in the selection made by the mobility anchor and mobile host. For instance, the mobile host may select a path named P1 while the mobility anchor may select different path named P2 for a given IP flow. To resolve such conflicts, in principle, the mobile operator shall override the access/IPMM selection made by the mobile host 14. However, there are some exceptional situations where the mobile host 14 selection may be accepted. One such exception is when the mobile host 14 makes the access/IPMM selection based on information which is only known by the mobile host itself. For instance, the mobile host UE is always aware of the radio quality (e.g. signal-to-noise ratio, SNR) of each wireless access. Also, when link connectivity over the selected access path and network is suddenly lost, it is preferable for the UE to make the decision about the access/IPMM selection in order to quickly recover the IP connectivity. In such cases, the mobile host's selection may override the access/IPMM selection made by the mobility anchor in the event of a conflict.

Although the mechanism described above defines paths that are characterized by a locator or chain of locators, other information may also be used for path characterization to enhance the access selection process. For instance, in a system where Quality of Service (QoS) support is needed in the transport network between the mobile host and mobility anchor, QoS parameters may be used for path characterization. In other words, information which indicates that a QoS class should be applied for a given IP flow can be added to the parameters that characterize a path.

As mentioned above, the mobile host and/or the mobility anchor may retain an obsolete path in the Path List. An obsolete may be restored by changing the status from 'obsolete' to 'active' or 'inactive' if it is confirmed that the path is valid. Such a procedure to restore an obsolete path may be advantageous to reduce the computational cost for path calculation. Also, additional information about an obsolete path may be retained in the Path List, which may later be used to indicate the network scenario when that path was valid. For example, the additional information may include geographical location information (e.g. longitude and latitude) of the mobile host when the path was last active, and this may provide a useful indication to determine when, or whether, it is appropriate to restore the obsolete path.

Figure 9 illustrates the steps in implementing the present mechanism. At step 901 the mobile host attaches to the mobile network. At step 902 the mobile host and mobility anchor commence a context establishment, for example the SHIM6 context establishment as described above, including exchanging the 11 , R1 and I2 messages (as described above with reference to Figure 6. At step 903, the locator lists are generated and the paths calculate to obtain the path list. At step 904, the context establishment is completed (e.g. with the SHIM6 R2 message). At step 905, the locator lists and path lists are stored by the mobile host and mobility anchor. At step 906 the primary active path is selected, as a consequence of which the access type and the mode of IPMM are selected.

Once the primary active path has been selected the mobile host can continue to exchange IP traffic over the selected path, as indicated at step 907. However, as shown at step 908, there is detected a need for a path update (depending on the mode of IPMM selected, this may be initiated by the mobile host or by the network). When this occurs, at step 909 a new path is selected from the path list to become the primary active path. At step 910 an update request is sent. Depending on the selected mode of IPMM, this may be sent from the mobile host to the mobility anchor (for CMIP), or from the mobility anchor to the mobile host (for PMIP). At step 91 1 , the mobile host implements the selection of the primary active path by activating the appropriate interface(s).