WO2008037474A2

WO2008037474A2 - Method for supporting flow mobility in a network

Info

Publication number: WO2008037474A2
Application number: PCT/EP2007/008429
Authority: WO
Inventors: Julien Abeille; Joao Girao; Telemaco Melia
Original assignee: Nec Europe Ltd.
Priority date: 2006-09-27
Filing date: 2007-09-27
Publication date: 2008-04-03
Also published as: WO2008037474A3

Abstract

A method for supporting flow mobility in a network, wherein a user is operating a terminal and wherein the user is registered to the network under said terminal, wherein the identity of the user's terminal is combined with physical network devices thereby constituting a virtual terminal comprising one or more interfaces, is characterized in that an interface of the virtual terminal, upon attachment to the network via an Access Router (AR), is registered with a Mobility Anchor (MA) using a tuple of identifiers wherein an identifier (IF-ID) of said interface being associated to the identity of the user's terminal as virtual terminal identifier (VT-ID).

Description

METHOD FOR SUPPORTING FLOW MOBILITY IN A NETWORK

The present invention relates to a method for supporting flow mobility in a network, wherein a user is operating a terminal and wherein the user is registered to the network under said terminal, wherein the identity of the user's terminal is combined with physical network devices thereby constituting a virtual terminal comprising one or more different interfaces.

The increasing complexity being perceived in next generation mobile networks, with multi-mode terminals always best connected, with multiple types of network available, both operator and community supported, has brought mobility issues into a central role for the future networks. In this context, there are large initiatives that address the multiple aspects of mobility. The EU-funded project "Daidalos" is one such project, addressing architecture for future networks. Starting from current trends discussed in standardization organizations, the Daidalos architecture is a major breakpoint from traditional approaches in IP networks. Some of the related technologies include mobility management approaches (such as MIP, HMIP, HIP and NETLMM), session mobility approaches (such as SIP mobility) and identity management approaches (such as Liberty Alliance, SAML, etc).

Another aspect that is to be observed is that users are becoming more and more detached from their physical devices/terminals. While it is true in IP networks today that a user is comprehended by the network as the device it owns, the pervasive component in current research tells a different story. People will not only own multiple devices, from PDAs to laptops and even powerful body-ware and in- body sensor networks, but also interact with public devices which enhance the user's experience depending on his context and preferences.

By way of example, as regards traditional identity architectures, it is to be referred to UMTS networks in which the concept of user and terminal is separated by means of the SIM card. This allows users of these networks to use different terminals by introducing in them their SIM cards, so that the network recognize the particular user (subscription) and deal with her appropriately. Also, it is possible in some terminals to include more than one SIM card so different identities can be used from the terminal. A typical scenario is that the same user has a personal identity and a professional identity.

However, there are some limitations in this solution. First, the terminals are restricted to UMTS technology. And second, the simultaneous use of the identity is very restricted. Insofar, there is need for an environment of heterogeneous technologies and a real identity centered solution in which a user can use several terminals simultaneously, and different users can share the same terminal.

Traditional host mobility considers the terminal as the end user device running several applications and sending/receiving data flows to/from a peer located in the network (e.g. Internet). Lately the availability of multimode devices capable of sending/receiving data flows at the same time from different paths extended the mobility concepts enabling users to select preferred wireless/wired interfaces for specific applications. The concept of such "virtual terminals" composed by several physical devices has already been proposed, e.g. by Fu, et al. in "A framework for device capability on demand and virtual device user experience", IBM Journal of Research and Development, vol. 48, number 5/6, 2004, p. 635-648. However, all such approaches known in prior art prove to be disadvantageous in that no seamless handling of the devices is possible in mobile environments.

It is therefore an object of the present invention to improve and further develop a method and a system of the initially described type for supporting flow mobility in a network in such a way that a virtual terminal is seamlessly supported in mobile environments without the mobility architecture requiring modifications in the correspondent node and requiring only minimum support from the application side.

In accordance with the invention, the aforementioned object is accomplished by a method comprising the features of claim 1. According to this claim such a method is characterized in that an interface of the virtual terminal, upon attachment to the network via an Access Router, is registered with a Mobility Anchor wherein an identifier (IF-ID) of said interface is associated to the identity of the user's terminal as virtual terminal identifier (VT-ID). It is to be noted that the term "flow" in the context of the present application is to be understood in a broad sense and may include, but is not limited to, sessions, multimedia flows, video and/or audio streams, etc. The term "virtual terminal" refers to a set of terminals bound by the identifier of the user. A virtual terminal may be built from any single authentication point of the user and may be extended to any device which recognises the user's permissions and authentication credentials. Once a virtual terminal is built, for the network and the architecture proposed, it acts as if it was one single device.

According to the invention, it has been recognized that a seamless management of the interfaces of the virtual terminal can be achieved by using a tuple of identifiers. It is provided that, upon detection of (layer two) attachment of an interface of the virtual terminal, the Access Router registers a new VT-ID/IF-ID tuple and prepares respective routing states in the associated Mobility Anchor. This may be done in a network based fashion. The identifier tuple comprises the identity of the user's terminal as virtual terminal identifier (VT-ID) as well as the identifier (IF-ID) of said interface. Such registration enables data traffic to be routed to any specific interface on the virtual terminal. The interface identifier IF-ID may be e.g. the MAC address of the interface.

By introducing the concept of virtual devices associated together with the described identity management concept, a user can instantiate several virtual identities depending on the desired service. Via this mechanism the virtual terminal is enabled being multi-homed (i.e. in the case the different identities are able to send/receive data at the same time). Through the deployment of enhanced network-based mobility mechanisms the network "sees" always a single mobile device whether the device is one single physical device or is a "virtual device" (e.g. several physical devices). In this case the identification of the single flows associated to one of the identities composing the virtual device may be derived from the identity framework.

In other words, the movement of a user is treated as person in a seamless way. The user's identifier binds the virtual terminal together and identifies the user, rather than the devices, as the anchor for application end-points. These end-points can move as the physical devices where they are attached or from one interface to another in the virtual terminal. Since these interfaces can correspond to different physical devices, an architecture is proposed which allows a person to be mobile, independent of his physical manifestations in the network.

Advantageously, the mobility management is split in a local level and in a global level. In particular, it is made use of a mobility architecture, called MobiSplit. This MobiSplit architecture is described in detail in J. Abeille et al, "MobiSplit: a scalable approach to emerging mobility networks", MobiArch'06, December 2006 which is incorporated herein by reference. The base element of this architecture is the splitting of mobility management in two domains, Local Mobility Domain (LMD) and Global Mobility Domain (GMD), assuming the IP protocol as basic architecture element. The splitting is done according administrative domain considerations. Seamless handovers and multi-technology local domains are also supported.

It may be provided that the physical devices which constitute the virtual terminal are located within the same LMD. Multi-homing may then be managed in the LMD which offers various advantages. It allows access operators to manage the mobility of visiting mobile nodes (MNs) inside their domain without depending on an external operator. In particular, an access provider can optimize the use of its resources by using the best interface/technology to provide connectivity to the MN, according to the MN's preferences, but also to the general situation of the network. The network can for example decide to move a flow to a different interface on the MN in order to make room for additional users. As regards the LMDs, one can envision that an enterprise or home forms an LMD where mobility and multi- homing is handled.

According to a preferred embodiment, a transfer of flows between interfaces of the virtual terminal is supported by means of a layer 3, network-based mobility mechanism. The mobility mechanism may include any known such protocol, in particular the NetLMM protocol which is currently being designed by the IETF NetLMM Working Group and which is described in detail in H. Levkowetz et al., "NetLMM Protocol", draft-giaretta-netlmm-dt-protocol-OI , September 2006. According to a further preferred embodiment, the mobility mechanism may include multi-homing extensions at IP level and below.

Advantageously, the underlying mobility mechanism allows mobility of the physical devices/interfaces which constitute the virtual terminal between different Access Routers. As regards such interface handover, it may be provided that upon attachment of the interface to a new access router (after for instance a change in the link layer) the new Access Router signals the Mobility Anchor the identifier of the virtual terminal, i.e. VT-ID, and the identifier of the interface, i.e. IF-ID. Consequently, the Mobility Anchor understands that this is still an identity of the same virtual terminal moving and it updates routes for respective data delivery. The mobility mechanism may be applied either to all interfaces constituting the virtual terminal or only to a specific part of the virtual terminal.

As regards an enhanced user experience it may be provided that the physical devices are dynamically discovered by the user's terminal. In particular, this device discovery phase may be carried out by making use of a protocol according to IEEE 802.21 standard or SIP based service discovery protocols (SDP). As regards a high flexibility it may be provided that the physical devices include devices which are owned by the user as well as devices the user does not (currently) own, for instance public devices like e.g. wall speakers, video screens, printer, etc. Interaction may take place with any devices which are part of the infra-structure, and for which the user may potentially have to pay. It is even possible that the user swaps his devices with others. All these interactions can be performed without ever terminating the user's running flows/sessions and without the user's communication peers knowledge.

The physical devices the user's terminal has discovered and which the user is entitled to access may pre-register with a common point in the network, in particular with an Information Data Base. This common point in the network may be used by the protocol stack to query about surrounding devices. A distributed approach may also be used.

Once the initial authentication and discovery protocols are completed, it may be provided that the user proceeds with the configuration of the devices which he wants to become part of his virtual terminal. By either using the network, or in a peer-to-peer fashion, one mobile terminal may configure another to receive part or all of the flows it is currently receiving. To this end a new Care of Address (CoA) may be set up in this terminal which matches the CoA of the user in the LMD. This process is inline with a multi-homing process. Once this is done and the tunnel established to a Local Mobility Anchor (LMA), the transport and application levels are configured. Depending on the actual application and transport protocols involved different parameters must be passed from one terminal to another. While it is trivial to configure the receiving end of an RTP (Real-Time Transport Protocol) stream, where the transport level parameters are reduced to a port number and possibly the current sequence number, the process to transfer a connection oriented transport protocol, such as TCP, is highly dependent on the actual transport and application.

Once the target devices, i.e. the devices the user chooses to be part of the virtual terminal, are configured the user can finally redirect the IP flow from his terminal to any of the new devices. This operation, which is typically considered as part of SIP mobility, can be carried out as part of the normal mobility mechanism. In environments where mobility management is network based the network can transfer flows from one point of attachment to another without requiring the terminal to perform address reconfiguration. By combining multi-homing extensions for network-based mobility schemes with identity management capabilities, the user is enabled to be connected to several physical devices while the network still believes it is the same device. Furthermore, since the access network implements network based mobility schemes, the flow handover operation is transparent to peers in the Internet. Primitives for keeping the same address on several devices/interfaces and virtual identity identifiers may be provided for the required support.

More specifically, a flow handover operation between two interfaces of the virtual terminal is performed by the way of signaling between the user's terminal and a flow policy entity. It is to be noted that the flow policy entity needs to be discovered. This entity could be for example part of the AAA infrastructure or any other backend for policy control. The information could be static; in this case filtering criteria could be downloaded in the Mobility Anchor during network attachment. Alternatively, information could be more dynamic. In this case the user device may run a protocol to update information in a data base. In both cases the Mobility Anchor is then able to apply such criteria and to route the traffic to the respective target device.

It is to be noted that flows can be moved across heterogeneous devices using the same mechanisms as for handovers or session mobility. Only one signaling protocol is required and the multi-homing support makes the identity mobility management transparent outside the Local Mobility Domain.

There are several ways how to design and further develop the teaching of the present invention in an advantageous way. To this end, it is to be referred to the patent claims subordinate to patent claim 1 on the one hand and to the following explanation of a preferred embodiment of the invention by way of example, illustrated by the figure on the other hand. In connection with the explanation of the preferred embodiment of the invention by the aid of the figure, generally preferred embodiments and further developments of the teaching will we explained.

In the drawings:

Fig. 1 is a schematic diagram illustrating the principles of the NetLMM architecture,

Fig. 2 is a schematic illustration showing the relation between the user's identity, physical devices and network according to one aspect of the present invention,

Fig. 3 is a high level message sequence chart of a user interface registration according to one embodiment of the present invention,

Fig. 4 is a high level message sequence chart of a device discovery operation according to one embodiment of the present invention, Fig. 5 is a high level message sequence chart of a public interface registration according to one embodiment of the present invention,

Fig. 6 is a high level message sequence chart of a flow handover procedure according to one embodiment of the present invention, and

Fig. 7 is a high level message sequence chart of an interface registration handover procedure according to one embodiment of the present invention.

Fig. 1 gives an overview of the NetLMM architecture, which constitutes a preferred network based localized mobility management approach on which the method according to the present invention may be based. More specifically, Fig. 1 shows the entities involved in NetLMM. The Local Mobility Anchors (LMAs) are routers defining the edge between the NetLMM domain, i.e. the Local Mobility Domain (LMD), and the core network, i.e. the Global Mobility Domain (GMD). The Mobility Access Gateways (MAGs) are the Access Routers for mobile nodes (MN). The NetLMM operation is located between MAGs and LMAs. No mobility specific involvement of the MN is needed: the movement of the MN is perceived by the network through standard L2 operation.

When the MN first attaches to the network, it obtains an IP address from a prefix owned by the LMA, and routes to the MN (which are indeed prefix routes, as NetLMM assigns a prefix per MN) are configured in the LMA and the MAG. Upon movement of the MN, the routes are updated in the LMA and the MAGs involved (previous MAG and new MAG). As long as the MN remains in the same NetLMM domain, it keeps the same IP address.

The forwarding method used between the MAG and the LMA can be IPv6 in IPv6 tunnelling, General Routing Encapsulation (as described e.g. in D. Farinacci et al, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000) or Multi Protocol Label Switching (as described e.g. in E. Rosen et al, "Multiprotocol Label Switching Architecture", RFC 3031 , January 2001 ). Such forwarding methods allow the use of standard routers on the path between the MAGs and LMAs: this considerably reduces the signaling in the LMD and avoids the extensive use of resources (routing tables) in the intermediate nodes.

The NetLMM protocol can be used in conjunction with a global mobility protocol, to handle mobility between local domains. It only supports reactive handover and does not consider the support for multiple technologies within the same LMD.

From Fig. 2 one can obtain how two users can share devices and combine devices to enhance their interaction with the network and services. Furthermore, Fig. 2 also depicts how the different levels can be managed by different operators, including the physical world and user movement in the virtual terminal domain.

More specifically, Fig. 2 shows two different users A and B, wherein user A operates a mobile phone and user B operates a PDA. As regards the integration and usage of further physical (public) devices, user A has chosen a laptop, a smart phone and a printer to join his virtual terminal. User B on the other hand has also chosen the laptop and the printer and, in addition, a wall screen to become part of his virtual terminal. All devices are part of the same LMD and may attach via Access Points AP to the Access Routers of the LMD.

In this context it is to be noted that the present invention does not make any restrictions on the number of CoAs per interface nor in the number of users per terminal. Thus, it may be that more than one virtual terminal is composed of, at least partially, the same devices. The handling of conflicts and application management is an application dependent issue. However, there is no overlap in ports or addresses since the CoA of a user in the LMD is the address to which packets are addressed and this address is shared by all devices which are part of the virtual terminal. Also, different users use different CoAs even when sharing a physical terminal

As already mentioned above, it is assume that a MN can have more than one interface active at the same time. The multi-homing is managed in the LMD which offers various advantages. It allows access operators to manage the mobility of visiting MNs inside their domain without depending on an external operator. In particular, an access provider can optimize the use of its resources by using the best interface/technology to provide connectivity to the MN, according to the MN's preferences, but also to the general situation of the network. The network can for example decide to move a flow to a different interface on the MN in order to make room for additional users. In the following an addressing scheme, the signaling required to map flows to interfaces, and the way we handle the routing inside the LMD are described.

To hide the multi-homing from the core network, all the interfaces on the MN will use the same IP address. A new NetLMM identifier (the interface identifier IF-ID, in addition to the MN-ID) is defined, to make this possible. When a MN activates a new interface, the LMA knows the NetLMM prefix assigned to this interface should be the same as for all the interfaces of the MN. Without this new identifier, when a MN activates a new interface, the LMA would think the MN is performing a handover. The MN will use the same suffix as on the other interfaces and therefore configure the same IP address on all active interfaces.

The MN and the LMA must agree on the mapping between flows and interfaces, so the uplink and downlink traffic belonging to the same flow follow the same path. To this end the MN may choose the interface for the traffic it initiates, and the LMA may choose the interface for the traffic initiated in the core network. This is not very restrictive, as the normal procedure for intra-LMD network or mobile initiated handovers can be afterwards used to move a flow from one interface to another.

As regards routing, in the downlink case, the LMA receives the traffic. This traffic is always destined to the same IP address. The LMA has to check the flow identity (as an example, the flow could be identified by the source address and source and destination ports in the packet), and it forwards the traffic to the AR which the MN's interface is attached to. In the uplink case, for each flow, the MN chooses the interface agreed on with the LMA. It is to be noted that in the case a MobiSplit architecture is employed, that address is not used for routing inside the LMD. In fact, the routing is done using the (eventually implicit) tunnel to the AR. For this reason, it is not a problem if the address is duplicated. The LMA can choose the interface in which the MN will receive the traffic just by using the appropriate tunnel.

It is to be noted that some problems may appear in a situation in which two interfaces of the MN are attached to the same AR. However, to overcome this problem, one can envision the use of destination option headers in the packets, from the LMA to the MAG.

Fig. 3 depicts the necessary steps to attach a virtual identity to the network. Upon layer two attachment, either wired or wireless, the Access Router AR registers a new VT-ID/IF-ID tuple in the Local Mobility Anchor LMA. VT-ID denotes the (global) identifier of the virtual terminal, whereas IF-ID denotes the identifier which is specific to the interface to be registered and which may be the MAC address of the interface. Based on the registration the Access Router prepares appropriate routing states in the Local Mobility Anchor LMA (in a network based fashion). Data traffic can now be routed to a specific interface on the virtual terminal.

Fig. 4 illustrates the discovery phase. In this phase it is assumed that the user is operating a terminal and that he has already authenticated and proven his identity and is registered to the network under this one device. While operating this terminal, or under the user's personalization rules, the user makes use of service discovery protocols (like e.g. 802.21 protocols or SIP based SDPs) to find other devices in the same LMD. The services provided by these devices (e.g. video display, speakers) are then matched for compatibility with the applications the user is currently running (or will run in the future). Once this process is completed the terminal will have a list of devices which the user is entitled to access and also their compatibility with the user's needs.

Fig. 4 represents the actual message flow during this phase. According to the specific case shown, the protocol assumes the devices pre-register with a common point in the network which is used by the protocol stack to query about surrounding devices. Such common point in the network may be a local network server, or more specifically an Information Data Base, as shown in Fig. 4. Once the discovery phase is completed, the user can proceed in the configuration of target devices (e.g. wall speakers, video screen) which he wants to become part of his virtual terminal. This is shown in Fig. 5. In the first step the user device signals the target public interface the required configuration. Transport of such information could happen via end to end protocols or simply by remote procedures calls.

More specifically, the configuration phase begins by setting up a new CoA in the virtual terminal which matches the CoA of the user in the LMD. Once this is done and the tunnel is established to the LMA, the transport and application levels are configured. Depending on the actual application and transport protocols involved different parameters must be passed from one terminal to another.

Fig. 6 illustrates a flow handover operation in which an IP flow is redirected from a previous interface of the virtual terminal to a new interface of the virtual terminal. In the beginning of this process the traffic for a certain flow, which is denoted F1 , is between the previous interface and the LMA. To redirect the flow, a certain signaling, for instance SAML/XACML or Diameter, is performed between the user's terminal and some Flow Policy Entity. This entity may be for example part of the AAA infrastructure o any other backend for policy control. Upon a respective signaling between the Flow Policy Entity and the LMA, the LMA prepares new routing states for flow F1 to perform handover and, consequently, the traffic for flow F1 is redirected to flow between the new interface and the LMA. It is to be noted that this handover, which is typically considered as part of SIP mobility, is here regarded as part of the normal mobility mechanism. Furthermore, it is to be noted that flows may be moved across heterogeneous devices using the same mechanisms as for handovers or session mobility. Only one signaling protocol is required and the multi-homing support makes the identity mobility management transparent outside the LMD.

Fig. 7 finally shows how standard interface handover may happen. Upon attachment to the new access router (after for instance a change in the link layer) the new Access Router AR signals the Local Mobility Anchor LMA the identifier of the virtual terminal (VT-ID) together with the identifier of the interface (IF-ID). The Local Mobility Anchor LMA understands this is still an identity of the same virtual terminal which is moving. Consequently, the LMA updates routes for data delivery and the traffic after having performed the handover will flow between the LMA and the new Access Router AR.

Many modifications and other embodiments of the invention set forth herein will come to mind the one skilled in the art to which the invention pertains having the benefit of the teachings presented in the foregoing description and the associated drawings. Therefore, it is to be understood that the invention is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

C l a i m s

1. Method for supporting flow mobility in a network, wherein a user is operating a terminal and wherein the user is registered to the network under said terminal, wherein the identity of the user's terminal is combined with physical network devices thereby constituting a virtual terminal comprising one or more interfaces, c h a r a c t e r i z e d i n that an interface of the virtual terminal, upon attachment to the network via an Access Router (AR), is registered with a Mobility Anchor (MA) using a tuple of identifiers wherein an identifier (IF-ID) of said interface being associated to the identity of the user's terminal as virtual terminal identifier (VT-ID).

2. Method according to claim 1 , wherein the mobility management is split in a Local Mobility Domain (LMD) and in a Global Mobility Domain (GMD).

3. Method according to claim 2, wherein the physical devices which constitute said virtual terminal are located within the same Local Mobility Domain (LMD).

4. Method according to any of claims 1 to 3, wherein a transfer of flows between interfaces of the virtual terminal is supported by means of a layer 3, network-based mobility mechanism.

5. Method according to claim 4, wherein said mobility mechanism includes multi-homing extensions.

6. Method according to claim 4 or 5, wherein said mobility mechanism allows mobility of the physical devices and interfaces, respectively, which constitute the virtual terminal, between different Access Routers (AR).

7. Method according to any of claims 4 to 6, wherein an interface handover between two Access Routers is performed by the new Access Router (AR) signaling the virtual terminal's identifier (VT-ID) as well as said interface's identifier (IF-ID) to the Mobility Anchor (MA).

8. Method according to any of claims 4 to 7, wherein said mobility mechanism is applied to only a part of the virtual terminal.

9. Method according to any of claims 1 to 8, wherein said physical devices are dynamically discovered by the user's terminal, in particular by making use of a protocol according to IEEE 802.21 standard or SIP based service discovery protocols.

10. Method according to claim 9, wherein said physical devices discovered by the user's terminal pre-register with a common point in the network, in particular with an Information Data Base.

11. Method according to any of claims 1 to 10, wherein said physical devices include public devices not owned by the user.

12. Method according to any of claims 1 to 11 , wherein the user is enabled to configure the physical devices which constitute the virtual terminal according to his preferences and application requirements.

13. Method according to any of claims 1 to 12, wherein a flow handover operation between two interfaces of the virtual terminal is performed by way of signaling between the user's terminal and a flow policy entity.

14. Method according to claim 13, wherein the flow policy entity is implemented as part of the underlying AAA infrastructure.

15. Method according to claim 13 or 14, wherein the signaling is performed on the basis of SAML (Security Assertion Markup Language) and/or extensible Access Control Markup Language (XACML) and/or by using the Diameter protocol.