9.2 A Contemporary View of User Mobility

9.2 A Contemporary View of User Mobility

Current user mobility support mechanisms can be divided into two categories: personal mobility and terminal (device) mobility. Personal mobility refers to users' ability to access network services from any terminal at any location. Thus, personal mobility management schemes enable the network to identify end users, as their point and method of access change.

Terminal mobility refers to the networks' ability to provide support for handover between networks for mobile devices as they change point of access while still maintaining connectivity.

9.2.1 Terminal Mobility

Terminal mobility support can be handled at different layers in the DOD reference model, starting from the link layer and finishing at the application layer.

In the existing cellular networks and emerging 3G networks, mobility is handled at the link layer. In doing so, the mobility is handled entirely by the access network and transparent to the outside. However, managing mobility at this level can only be done as long as the terminal stays within the same access network technology. If it were to attach to a different type of access network, the mobility management would fail.

Generally speaking, mobility management can be better optimized the lower in the protocol stack. However, the lower the layer, the more specialization is required, with the ensuing increases in complexity and limitations in scope. Therefore, there is a trade-off between optimization, complexity, and functionality that has to be considered when deploying terminal mobility.

In future all-IP mobile networks, the trend is to use a combination of link layer and network layer mobility management to provide ubiquitous access and global roaming. The cellular industry is currently deploying link layer tunneling solutions for cellular networks and the IETF (Internet Engineering Task Force) currently supports a network layer solution, Mobile IP, ^[2] as the global mobility management scheme.

9.2.1.1 Network Layer Mobility

The current form of IP, IPv4, cannot support terminal mobility. The cause of the problem is the double meaning of IP addresses, which can be interpreted as both the endpoint identifier and the topological location of a terminal. Unfortunately, the initial IP design did not take mobility into account. The initial design was made with the idea that in connectionless IP networks, it is necessary to deploy a hierarchical addressing scheme ^[3] to make routing simpler and more manageable. This solution allows routers to only maintain routing information about the local topology and to use a fallback forwarding mechanism for all traffic destined outside this local topology. Although such an addressing scheme provides a scalable solution for routing data across large internetworks, there is a serious implication with locking the topological knowledge to only local routers. Should a host move from its local network to a foreign location, the foreign routers would not have any rules for forwarding traffic to the host. Therefore, it will use the fallback mechanism to forward the traffic toward the local network specified in the terminal's address, and even if the local routers know which foreign network a host is attached to, they cannot forward the traffic there because the foreign routers would only return the traffic back to them.

In mobile environments, users can freely move from one network to another and therefore this restriction on address usage is violated. One possible solution is to assign a new IP address to the mobile terminal when it arrives at a new subnet. This approach, however, can create problems in the transport and application layers, where an IP address serves as part of an endpoint identifier. For instance, a TCP connection is identified by the source/destination addresses and port numbers. If any one of these four components in the identifier changes, the ongoing TCP connection will be broken. For a UDP data session destined to a mobile host, it is possible to update its endpoint address whenever the mobile host moves. Despite its feasibility, such an arrangement implies that user applications need to be mobility aware. Unfortunately, it is unlikely that this global awareness of user mobility will become a reality in the near future.

Because IP addresses contain implicit location information, in order to support terminal mobility at the network layer, either the IP forwarding mechanism needs to be changed or the addressing scheme has to be modified. There are three primary alternatives to achieving this goal.

1. IP encapsulation (tunneling): This process involves the technique of encapsulating a packet, including the header, as data inside another packet. Because the header of the new packet, i.e., the tunnel header, has a topologically correct IP address, this packet can follow the standard IP routing mechanisms and reach the IP subnet where the mobile terminal is attached. This method has been widely studied and adopted as the data-forwarding mechanism in the IETF Mobile IP. ^[4]

2. Loose source routing: As an option in an IP packet header, loose source routing enables the sender to perform address translation operations. The source generates a list of addresses of intermediate routers it wants the packet to pass on its way to the destination, with the last entry being the current address of the mobile terminal. When building a normal IP packet, the destination field is filled with the address of the mobile terminal. When using loose source routing, this field is assigned instead the first entry in the address list. When the packet reaches this node, the destination address is replaced with the next address from the list. This process is repeated until the packet reaches the mobile terminal. This function has been carefully integrated in IPv6 using a routing extension header, which avoids current problems in IPv4 with regard to security and performance. ^[5]

3. Dynamic per-host routing: In this routing scheme, the destination IP address is used as a terminal identifier only, removing its association with the terminal's current location. Packets are forwarded on a hop-by-hop basis from a gateway over special dynamically established paths to the terminal. The forwarding entries at each router along the path are refreshed periodically using update messages sent from the terminal. This category of packet forwarding has been proposed lately in some micro-mobility architectures, which we will discuss later in this chapter.

The main difference between these three routing schemes is the way location information is placed. In the case of tunneling, it is embedded within the packet payload; with loose source routing, it is provided in the packet header; and in dynamic host routing, it is maintained in the forwarding table of each intermediate router.

9.2.1.2 Mobile IP

The current supported IETF standard for terminal mobility in the Internet is called Mobile IP. In this approach, a fixed terminal (corresponding host, CH) that wants to communicate with another host (mobile host, MH) is unaware if the other host is in its home network or is away in a different (foreign) network. This transparency is provided by using two network agents, one located at the mobile host's home network (home agent, HA) and the other located on the visited network (foreign agent, FA). These mobility agents (i.e., HA and FA) and the MH cooperate with each other and perform mobility management without any other modifications to the network. The functionality of Mobile IP can be roughly divided into three components (Figure 9.1): (1) location registration, (2) packet forwarding, and (3) handover detection.

Figure 9.1: Mobile IP components.

9.2.1.2.1 Location Registration

Mobile IP adopts a simplistic approach to location management. For example, in Mobile IP there is no terminal paging algorithm. Instead a location update is executed every time a mobile host arrives at a new subnet. In addition, Mobile IP does not use databases to store user location information, but performs location updates by creating or modifying a mobility binding at the HA. When a mobile host moves to a foreign network, it registers with the FA on that network and obtains a care-of address (COA). The mobile host then updates its current COA, possibly via the current FA, by sending a registration request message to its HA. After receiving this message, the HA associates the mobile host's home address with its current COA via a binding cache. This mobility binding is automatically deleted from the HA if the lifetime of the binding expires without receiving any new registration from the mobile host.

9.2.1.2.2 Packet Forwarding

The packets destined to a mobile host are always forwarded to this mobile host's home network because the CH is not assumed to be mobility aware. In the case that the mobile host is currently away, the HA intercepts the packets, encapsulates them based on its binding cache and relays them to the FA currently serving the mobile host (the COA). When these packets arrive at the FA, it decapsulates them and forwards them to the mobile host via the local link layer technology.

It is worth noting that packets in the reverse direction can be delivered in two different ways, depending on the level of security the foreign network implements (see Figure 9.1). If routing is independent of source address within the foreign network, the mobile host can send packets directly to the CH. This routing asymmetry between the corresponding and mobile hosts is known as "triangular routing." On the other hand, if source-filtering routers are installed in the network (i.e., the routers check the source address of packets for correctness), they will drop all packets originating from the mobile host because its source address is topologically incorrect. One possible solution to this problem is to establish a reverse tunnel from the mobile host to its HA so that all tunneled packets bear a correct source address. ^[6] When these packets arrive at the HA, they will be decapsulated and forwarded to the CH.

9.2.1.2.3 Handover Detection

Using a tunneling mechanism, the HA can easily reroute mobile connections to the current location of a mobile host provided its binding cache is up-to-date. Mobile IP specifies some generic mechanisms for mobile hosts to discover FAs without assistance from the link layer. In essence, the FA advertises its availability through periodically transmitted router advertisements. The mobile host can detect that it has moved from one subnet to another in one of two ways. First, the mobile host can use the lifetime field of an FA advertisement to refresh its association with that FA. If the lifetime expires before receiving another advertisement, the mobile host will attempt to register with a new agent. Second, the mobile host can compare the subnet prefixes of agent advertisements. If the prefixes differ from the current care-of address, the mobile host will assume that it has moved.

It is worth noting that because agent advertisements are either broadcast or multicast in nature, they cannot be transmitted too often as they consume radio resources. In the older Mobile IP specification, ^[7] the maximum frequency of advertisement is only once per second, but in the revised version ^[8] this limit is lifted (i.e., unspecified), and FAs can be discovered by a link layer protocol.

9.2.2 Personal Mobility

Presently, "all-in-one" mobile devices are being introduced in the marketplace. These devices integrate diverse network accesses and general purpose operating systems so they can be used both as cellular phones and as hyper-portable computers. Even if these devices are versatile and convenient, it is unlikely that they will satisfy a user's every need. Existing devices such as desktop PCs are difficult to completely replace with such a mobile device due to the difference in power constraints, screen size, and CPU capability, etc. Therefore, rather than relying on a single device for all activities, users will continue to use several devices for different purposes.

With a combination of fixed and mobile devices, terminal mobility support alone will not be sufficient to address user mobility as the user is moving and switching between different devices. Therefore, personal mobility will be of fundamental importance in future communications.

Personal mobility support has not been addressed as much as terminal mobility and, as a consequence, it is not as well defined as the role of terminal mobility. To date, two distinct roles have emerged together constituting a user's networked presence. The first area addresses user location and means of contact; the second area addresses the issues associated with personalizing a user's presence and describing the user's operating environment. Therefore, the area can be defined as personalization.

In traditional telecommunications systems, devices (or telephones) have been identified through a hierarchical numbering scheme. It has been possible to map the ID of the device to its current point of attachment, and therefore make the device reachable using this scheme, even if mobile. Similarly, personal mobility management schemes need a mechanism for allowing users to change their point of presence while still being reachable.

The user has to use a globally unique identifier for the scheme to work. The identifiers have to be resolvable to identify an anchor point for personal information retrieval. Possible candidates are, for example, telephone numbers, e-mail addresses or URLs. Consider an e-mail address such as <[e-mail]>. From this address it is possible to extract the user name (user) and the anchor point (domain.com).

With personalization, the presence information can be used for a number of purposes by the user, network services, and peers. For example, the presence information can be used to identify the device where the user currently can be reached. Different peers can obtain different results according to the user's preferences so that, for example, some peers can reach the user for personal communication whereas other users will obtain an alternative device such as an answering machine or e-mail inbox. Another use of presence information is to obtain the characteristics of the device the user is currently using to determine if some means of communication is possible. For example, capability information can be used to determine if the user device is capable of displaying video or whether only voice communication is possible.

Despite the fact that personal mobility and presence has not yet been thoroughly investigated, a couple of systems for supporting personal mobility have been standardized: Universal Personal Telecommunication (UPT) ^[9] by the ITU-T and Session Initiation Protocol (SIP) ^[10] by the IETF.

9.2.2.1 Universal Personal Telecommunication

UPT provides access to telecommunications services while allowing personal mobility. It enables each UPT user to initiate and receive calls on the basis of a personal, network-transparent UPT number across multiple networks, regardless of the type of terminal or geographical location.

In the architecture (Figure 9.2), the user has a personal UPT number subscribed to a UPT service provider. Each UPT service provider maintains a UPT service provider database that tracks the location of a user through registrations. A UPT user can register with the database at either a fixed or wireless terminal. To support service provider portability of UPT numbers, a UPT global database registers the UPT service provider for each assigned UPT number. When a UPT user changes UPT service provider, the new service provider can notify the UPT global database administrator to update the database.

Figure 9.2: The architecture of UPT.

A UPT user may register to separately receive incoming calls and originate outgoing calls at any specified terminal according to a service profile. The service profile includes identification and authorization information that can be used to allow or disallow making or receiving calls from a UPT terminal.

9.2.2.2 SIP

Session Initiation Protocol (SIP) was developed to assist in establishing, maintaining, and terminating advanced telephone services between two or more users across the Internet. It is part of the IETF standards process and is modeled on HTTP. The protocol supports personal mobility by providing the capability to each called party at a single, location-independent address.

SIP is based on client/server architecture. The main entities are user agent (UA), the SIP proxy server, the SIP redirect server and the registrar.

The user agents are the SIP endpoints. They operate as clients when initiating requests and as servers when responding to requests. A UA can communicate with another UA directly or via an intermediate server, and also store and manage the states of a call. SIP intermediate servers can act as proxy or redirect servers with the following functions: (1) proxy servers forward requests from the user agent to the next SIP server or user agent within the network; (2) proxy servers can maintain information for billing and accounting purposes; and (3) redirect servers respond to client requests and inform them of a requested server's address.

The final entity in the SIP architecture is the SIP registrar. The UA sends a registration message to the SIP registrar when the user location needs to be updated. The registrar stores the registration information in a location service via a non-SIP protocol and sends an appropriate response back to the user agent.

When a user (caller) wants to place a call to another user (callee), the process is initiated by the caller issuing an invite request. The request contains enough information for the callee to join the session. There are two possible sequences of events in issuing the invite request. If the caller knows the address of the callee, the invite request is sent directly the caller's UA; otherwise the invite request is sent to a SIP server (Figure 9.3).

Figure 9.3: Call establishment with SIP servers.

The type of SIP server determines its response to the caller's invite request. If the server is a SIP proxy server, it will try to resolve the callee's location and forward the request to callee's UA; however, if it is a SIP redirect server it will return the location of the callee to the caller after the location resolution process, which enables the caller to send the invite request directly to the callee. When locating the callee, a SIP server can proxy or redirect the call to additional servers until the callee is located.

Once the request has arrived at the callee, several options are available. In the simplest case, the callee will be notified that a call has arrived. For example, the phone rings. If the callee answers the call, the callee's UA will respond to the invite and establish a connection; if the callee declines the call, the session can be redirected to other entities such as a voice mail server or another user.

SIP has two additional significant features. The first is a SIP proxy server's ability to split incoming calls so that several extensions can be run concurrently. This feature is useful if a callee may potentially be at two different locations. The second feature is the protocol's ability to return different media types in response to requests. For example, when a caller is contacting a collee, the SIP server that receives the connection request can return the caller an interactive Web page instead of a busy tone.

In the following sections, we will give a brief overview of other proposals for supporting personal mobility.

9.2.2.3 Personal Mobility Systems that Support User Location

The following presence systems have been designed to support user location management, including UPT and SIP.

• The Mobile People Architecture (MPA) ^[11] attempts to enable users to be contacted from anywhere, using a variety of communications media, such as e-mail, telephones, and instant messages. This is facilitated by identifiers called personal online IDs (POID), together with a personal proxy located at the user's home network. The POID provides a way of uniquely identifying the user, and the personal proxy takes care of the user's movement, preferences, and any required protocol and content conversions. As all call signaling is required to go through the personal proxy, the location of the user and the device that she is currently using can be hidden from other users.

• ICEBERG ^[12] provides similar functionality to MPA. However, it was primarily designed to integrate different types of networks with the Internet. This enables, for example, the user with a cellular device to be contacted by others on the Internet and vice versa. Under such circumstances, content needs to be adapted to suit the characteristics of the user's network. This is performed by ICEBERG Point of Presence (iPOP). Because it is based on the Ninja clustering platform, ^[13] it provides an execution environment, where adaptation libraries can be downloaded and configured on demand.

9.2.2.4 Personal Mobility Systems that Support Personalization

The following architectures were designed to support personalization:

• NetChaser ^[14] is a mobile-agent-based framework that is designed to support personal mobility in accessing three Internet services: HTTP, e-mail, and FTP. The mobile agents in NetChaser form a wrapper layer between the applications (Internet clients and servers) and the network. They assist the users by following them when they change working terminals. Interaction with the user is achieved by using a Web browser.

• Secure and Open Mobile Agent (SOMA) is an architecture where mobile agents are used as middleware to support mobile computing, which includes both terminal and personal mobility. ^[15] Personal mobility is supported in this architecture through the use of user virtual environment (UVE). The UVE service lets users connect to the Internet at different locations while maintaining the personal configurations indicated in their user profiles.

• In the Telecom Research Programme (TELEREP), a mobile-agent-based architecture to support mobility was introduced. ^[16] The architecture uses various mobile agents to perform different tasks. A user agent (UA) acts on the user's behalf when the user moves between different networks and controls the other agents. The application agent (AA) and the data agent (DA) maintain the user's applications and data by moving them close to the user. Finally, the profile agent (PA) stores the user's profiles. When a user moves from the home network, all the above-mentioned agents will migrate as well, carrying with them the applications, data, and profiles. This allows the user to access applications and data locally.

• Using the technique of application migration, Takashio and coworkers introduced a framework called follow-me Desktop, or f-Desktop. ^[17] In this framework, the context of so-called follow-me applications is mobile. The follow-me applications can be implemented using mobile agent technologies. When a user changes terminal, the user's applications are "frozen." The frozen applications are transmitted across the network to the user's new terminal and resume their execution there.

• None of the above-mentioned personal mobility architectures support both user location and personalization. The Integrated Personal Mobility Architecture (IPMOA) ^[18] addressed this issue by introducing an overlay network that caters for various personal mobility services such as interpersonal communications (location support), customized Internet services, remote application execution, and file synchronization (personalization support).

^[2]Perkins, C., Ed., "IP Mobility Support for IPv4," IETF RFC 2002, Oct. 1996.

^[3]Ford, P., Rekhter, Y., and Braun, H.-W., Improving the routing and addressing of IP, IEEE Network, May 1993.

^[4]Perkins, C., Ed., "IP Mobility Support for IPv4," IETF RFC 2002, Oct. 1996.

^[5]Deering, S. and Hinden, R., "Internet Protocol, Version 6 (IPv6) Specification," IETF RFC 2460, Dec. 1998.

^[6]Montenegro, G., "Reverse Tunneling for Mobile IP," IETF RFC 2344, May 1998.

^[7]Perkins, C., Ed., "IP Mobility Support for IPv4," IETF RFC 2002, Oct. 1996.

^[8]Perkins, C., Ed., "IP Mobility Support for IPv4," IETF RFC 3220, Jan. 2002.

^[9]"Principles of universal personal telecommunication (UPT)," ITU-T Recommendation F.850, Mar. 1993.

^[10]Rosenberg, J. et al., "SIP: Session Initiation Protocol," Internet Engineering Task Force (IETF) Internet draft, Feb. 2002.

^[11]Maniatis, P. et al., The Mobile People Architecture, Mobile Computing and Communications Review, July 1999.

^[12]Wang, H. et al., ICEBERG: An Internet-core network architecture for integrated communications, IEEE Personal Communications, Aug. 2000.

^[13]The Ninja Project, http://ninja.cs.berkeley.edu/.

^[14]Distefano, A. and Santoro, C., "NetChaser: Agent Support for Personal Mobility," IEEE Internet Computing, March–April 2000, 74–79.

^[15]Bellavista, P., Corradi, A., and Stefanelli, C., Mobile agent middleware for mobile computing, IEEE Computer, 34 (3), 73–81, 2001.

^[16]Thanh, D. et al., Using Mobile Agent Paradigm in Mobile Communications, Ericsson Conference Software Engineering, 1999.

^[17]Takashio, K., Soeda, G., and Tokuda, H., A Mobile Agent Framework for Follow-Me Applications in Ubiquitous Computing Environment, International Conference on Distributed Computing Systems Workshop, 2001.

^[18]Thai, B. et al., Integrated personal mobility architecture: a complete personal mobility solution, MONET Journal on Personal Environment Mobility in Multi-Provider and Multi-Segment Networks, submitted, 2002.