- Email: [email protected]
Mobile multi-access IP: a proposal for mobile multi-access management in future wireless IP networks
Computer Networks 47 (2005) 577–592 www.elsevier.com/locate/comnet
Mobile multi-access IP: a proposal for mobile multi-access management in future wireless IP networks Su¨leyman Altuntasß, Buyurman Baykal
*
Electrical Engineering, Middel East Technical University, 06531Ankara, Turkey Received 3 November 2003; received in revised form 17 November 2003; accepted 29 March 2004 Available online 8 December 2004 Responsible Editor: I.F. Akyildiz
Abstract As the wireless networking technologies advance rapidly, providing mobile users with roaming freely in heterogeneous wireless access domains, the need for multi-access arises. This paper introduces the Mobile Multi-Access Management Architecture (MMA-IP) for IP-based future wireless networks. MMA-IP enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. In order to handle multi-access operations, MMA-IP defines a new special mobility agent, called Multi-Access Agent (MAA). The MAA is the first point for incoming packets destined to the mobile node. Upon reception of these packets, MAA routes them via different access domains according to the mobileÕs preferences. MMA-IP allows mobile nodes to indicate their preferences in the form of preference messages and these preferences are stored in MAA for use in multi-access decisions. It is also noted that this concept paper intends to shed light on future improvements on IP in 4G networks. 2004 Elsevier B.V. All rights reserved. Keywords: Multi-access; Mobile IP; 4G; Heterogeneous network; Mobility agent; Home agent (HA); Foreign agent (FA); Care-of address (CoA)
1. Introduction Mobile IP [1–4] is the current standard for mobility management in IP-based networks. Mobile IP supports mobility management by intro-
*
Corresponding author. Tel.: +90 312 210 4582. E-mail address: [email protected] (B. Baykal).
ducing two entities, the Home Agent (HA) and the Foreign Agent (FA). Each Mobile Node (MN) in Mobile IP is statically assigned a HA and a corresponding home address. As it moves, the MN is dynamically assigned a FA and a corresponding care-of address. The packets destined to the MN are captured by its HA and tunneled to its current FA. The FA then decapsulates those packets and forwards them directly to the MN.
1389-1286/$ - see front matter 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2004.03.036
578
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
However, there is a common recognition that the Mobile IP protocol should be enhanced to meet the requirements of next generation wireless networks. Mobile users of future networks will be in the coverage area of more than one access domain at the same time and they will desire to utilize multiple access domains simultaneously or to switch between different access domains. These capabilities are generally referred to as ‘‘multiaccess’’. In the current Mobile IP, a mobile user can maintain simultaneous bindings, but these bindings can only enable it to receive the duplicate copy of every data packet at each registered careof-address. Hence, the current Mobile IP protocol lacks any multi-access support. We present the basics and operational details of the Mobile Multi-Access Management Architecture (MMA-IP) for future wireless networks. MMA-IP is a multi-access management architecture, which enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. MMA-IP assumes the usage of Mobile IP in the backbone as interdomain mobility (or so-called macromobility) management protocol and offers multiple care-of addresses (CoA) for supporting Mobile IP in multi-access operations. So as to handle multiaccess operations, MMA-IP defines a new special mobility agent, called Multi-Access Agent (MAA). The MAA is the first point for incoming packets destined to the mobile node. Upon reception of these packets, MAA routes them via different access domains according to the mobileÕs preferences. MMA-IP allows mobile nodes to indicate their preferences in the form of preference messages and these preferences are stored in MAA for use in multi-access decisions.
of multiple access domains at the same time in 4G environments. The 4G vision will let mobile users seamlessly handoff between these different access technologies, which have overlapping coverage areas. Fig. 1 shows a sample of a future 4G network environment with several overlapping wireless access domains. As the mobile node (MN) moves, it crosses into various access domains of different characteristics. For instance, at point A, the mobile node is in the coverage area of a Satellite network, a GPRS network, and two different WLANS. At point B, on the other hand, the mobile node can use a Satellite network, a GPRS network, and a Bluetooth network. In future networks, the mobile users should be able to use multiple access domains simultaneously or switch from using one access domain to another seamlessly. Each access domain has some specific characteristics of its own. Some, for instance offer a large coverage area, while others offer high data rates. Some access domains are more suitable for image transmission while the others perform better for voice communications. Therefore, being able to use multiple access domains, the mobile users of future networks should be able to switch between different access domains according to their specific needs. They may also use multiple access domains simultaneously for different application types. A mobile user, for example, may use a WLAN for his image transmission, and concurrently use a GPRS network for his voice communication. Mobile users, who need the fastest possible communication, may even divide a single stream between different access domains, so that
2. Concept of operations of multi-access in future wireless networks The aim of future wireless networks is to provide the mobile users with a completely IP based access to the information infrastructure by using a wide variety of access technologies. This is true especially for the fourth generation (4G) networks in which mobile users will be in the coverage area
Fig. 1. A sample of future 4G network environment.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
579
they can use them in parallel to achieve the best possible performance. What is explained above brings about the concept of ‘‘multi-access’’ in future wireless networks. Multi-access can be defined as the ability to use multiple network interfaces in a single terminal, either by simultaneously routing different data flows to or from the mobile terminal through different access domains, or, by switching between different access domains. Although, in some texts, simultaneous usage of different access domains is referred to as ‘‘simultaneous multi-access’’ and switching between different access domains as only ‘‘multi-access’’, we adapt the convention in this paper that both kind of operations are called ‘‘multi-access’’. The reason for this is that the ability of using different access domains also implicitly includes the capability of switching between them. Hence, throughout the paper, multi-access term will be used to refer to the ability of synchronously utilizing multiple access domains, and switching between them. A complete multi-access system should meet the following requirements:
oversee and monitor the operations of access domain gateway agents and mobile nodes, and hence, it can easily control and manage the multi-access operations. This special agent should store all the mobile nodesÕ multi-access and QoS specifications and the status of gateway agents, so that it can use them in its multi-access decisions. Multi-access capability brings about some difficulty in mobility management. With multi-access, the inter-domain mobility management should now take into account mobility between different access domains, so-called vertical handoffs, and what is more important, the inter-domain mobility management should now consider concurrent use of different access domains, which is drastically different than vertical handoffs. This second item again, favors the use of a special network node overseeing all the gateway nodes, for the multiaccess operations. If such a special multi-access agent is utilized, the multi-access will ease the paging of mobile nodes in the hybrid network infrastructure. Such a special agent will have more than one access domain to page the mobile node.
• It should provide the mobile users with the ability to use different access domains simultaneously. The users may use different access domains for different application types, for different source or destination addresses or for different source or destination networks. • It should allow the mobile users to specify their required QoS specifications and utilize the available network interfaces under the light of those QoS specifications. For instance, to achieve the fastest possible communication, the mobile user may be able to divide his incoming or outgoing data flow between the available network interfaces so that he can use them in parallel to obtain the best performance. • It should allow the mobile users to switch between different access domains.
3. Related work
The above stated requirements lead us to the need of a network node, or a special network agent, which is hierarchically in a higher level than the mobile node and all the gateway agents of each access domain. By this way, this special agent can
Relatively little work has been published on architectures enabling multi-access in future wireless networks. One approach to multi-access in heterogeneous network architectures is the NOMAD system [5]. In this system, the mobile node controls and manages the multi-access operations. Every time a mobile node acquires a care-of address through one of its interfaces, it is required to issue a binding request to the respective binding agent. A binding agent can be any Mobile IP entity that can maintain bindings, such as a HA, GFA, or even a CN. The mobile node is required to include in its binding request a list of filters that indicate which flows are associated with the registered care-of address. By this way, the mobile node specifies what type of flows, or flows coming from which addresses or domains are to be conveyed through a specific access domain. Ref. [6] introduces a new extension to MIPv6 to allow hosts to direct inbound flows individually to certain preferred interfaces. The extension is called
580
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
On the other hand, some companies have recently started to produce multi-access enabled devices. Ericsson and TelenorÕs UMTS + WLAN terminal and NokiaÕs GPRS + HSCD + WLAN PC card are examples of such devices.
per-flow movement in MIPv6. Per-flow movement is defined as the splitting of inbound traffic to be received on different addresses. Using this extension, a MN would be able to move one flow to another interface while maintaining the reception of other flows on the current interface. There is also very recent work being done by EricssonÕs NomadicLab & HUT. The project is called SIMA (Simultaneous multi-Access Mobile IPv6). The idea in SIMA is very similar to that introduced in [6] and can be viewed in [7]. The SeaMoby Working Group (WG) [8] tries to perform a context transfer when a mobile changes its point of attachment. The working group claims that although the protocol used to actively redirect the IP packet flows during a change in a mobileÕs point of attachment is handled by the Mobile IP WG, there is a need for preserving the context of its active IP flows. The IP flow context that might be useful to transfer could include, but not be limited to security context, policy, QoS (diffserv or intserv as needed) header compression, and accounting/AAA information. The SeaMoby WG will analyze the requirements and tradeoffs for the goal of transferring context information from a mobileÕs old access to the new access device. Depending on the results of the requirements analysis, the SeaMoby WG will develop a protocol (or start from an existing protocol such as Contract Net Protocol (CNP) or the IEEEÕs 802.11f) to transfer the context information for a session.
4. A solution to multi-access management in IP-based networks: MMA-IP 4.1. MMA-IP basics MMA-IP assumes the usage of Mobile IP in the backbone as inter-domain mobility management protocol and offers multiple CoAs for supporting Mobile IP in simultaneous usage of or switching between multiple hybrid access domains. MMAIP allows any kind of access-domain as long as they are connected to the Mobile IP backbone by some kind of a Foreign Agent. Fig. 2 shows the basic MMA-IP architecture and its elements. Inside these access domains, any intra-domain mobility management protocol, such as HAWAII [9–11], Cellular IP [12,13], MIP-RR [14] or HMIPv6 [15] may be utilized. The point is that the access domain should be connected to the Mobile IP backbone by a mobility agent. This mobility agent could be a FA (Foreign Agent), a GFA (Gateway Foreign Agent), or any other MA (Mobility Agent), such as the domain root router of HAWAII, all of which are referred to
CN
CN MAA
Multi-Access CoA
Virtual Connections
ADFA
Access Domain CoA
ADFA
ADFA
Access Domain 1
MN Access Domain 2
Fig. 2. Basic MMA-IP architecture.
Access Domain CoA
Access Domain 3
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
as Access Domain Foreign Agent (ADFA) in MMA-IP terminology. MMA-IP handles multi-access by defining a new mobility agent, called Multi-Access Agent (MAA). The MAA is different from other ADFAs in that it is hierarchically in a higher level in the backbone. The MAA is the first point for data flow redirection. In this aspect, it is similar to a MIP FA or MIP-RR GFA that the data packets destined to the MN are tunneled to the MAA. The MAA establishes virtual connections with the ADFAs that the MN attaches, and use them simultaneously to re-tunnel packets. The MAA takes into account the MNs preferences in simultaneous usage of different ADFAs, meaning different access domains. MMA-IP offers two different CoAs: • Multi-Access Care-of Address (MACoA): This address is the one to which all the packets destined to the MN are tunneled. The MN registers its MACoA with its HA or CNs. • Access Domain Care-of Address (ADCoA): This address identifies the address of the ADFA that connects an access domain to the Mobile IP backbone. This address is actually the usual MIP Foreign Agent CoA. The MN registers its ADCoAs with its MAA so that it can simultaneously use a bunch of MNs ADCoAs to send packets.
4.2. MMA-IP operation When the Mobile Node (MN) first moves into an access domain, it acquires an Access Domain Care of Address from the Access Domain Foreign Agent (ADFA) of that domain. As stated, the ADFA is the gateway of the domain, which connects the access network to the Mobile IP backbone, and the Access Domain CoA is the MIP CoA in the classical sense. After registration of the ADCoA with the ADFA, the ADFA dynamically assigns a MAA to the MN. By this way, a virtual connection between the ADFA and the MAA is established. The MN then registers with the MAA and gets a MACoA. This MACoA will be the address to
581
which all the packets destined to the MN will be tunneled in the Mobile IP backbone. The MN registers its MACoA with its HA and CNs. When the MN tries to register with the assigned MAA, the MAA first explores whether it is the optimum MAA for the MN or not. Here, the optimality is related to the location of the MAA. Ideally, the MAA should be in such a location that the total routing cost of packets sent from the HA and all CNs through each and every combination of the ADFAs is minimized. Since the MAAs are placed in certain routers, this ideal case cannot be realized. However, the MAAs can be placed in optimal locations close to the ideal case. By virtue of its characteristics, a MAA is the best source to figure out the optimum MAA for a MN. Nevertheless, an ADFA should first assign a MAA to the MN. In MMA-IP, an ADFA first assigns one of its closest MAAs to the MN. After that, the MAA assigned by the ADFA performs an analysis on whether it is the optimal MAA for the MN or there is a better MAA in terms of optimality. The MN gets connected to its optimum MAA according to the first assigned MAAÕs decision. In registering with the MAA, the MN also informs it about its ADCoA that it acquired from the ADFA. On the other hand, the MAA creates an entry in its database and includes the new MACoA of the MN together with its home address in the entry. In this database, mobile nodes will be identified by their home addresses; in other words, home addresses of the mobile nodes will be the primary keys of this database. In order that the MAA will direct packets to the MN by using its multiple points of attachment simultaneously, it will need the MNs preferences about the usage of networks. For this, after registering with the MAA, the MN will communicate with it about its preferences. These preferences are also stored in the MNs entry of the database kept in the MAA. MMA-IP defines preference messages to inform the MAA about the MNs preferences. Each unique preference is sent to the MAA in a single preference message. A preference message has two parts; the first part defines the specifications about the data on which some preferences are made and
582
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
the second part indicates the preference. The MAA stores MNs preferences in its database and use them in re-tunneling messages to the MNs one or more of ADFAs. The preference messages will be explained in later sections. After acquiring its MACoA and specifying its preferences, the MN registers its MACoA with its HA and CNs. From this point on, the HA or the CNs will tunnel packets to the MAA, which then re-tunnels the packets simultaneously to different ADFAs according to MNs preferences. MMA-IP also enables the preferences to be sent to HA or CNs so that, an additional MAA functionality can be established in HA or CNs. By this ADFA
MN
way, the HA or CNs can directly tunnel the packets to the specified ADFAs. However, MMA-IP assumes the usage of a MAA as mandatory, if multi-access is to be utilized. The extra functionality established in HA or CNs is only an addition to the usual MAA. This will be explained in later sections. Fig. 3 shows the MMA-IP message flow when a mobile node first moves into an access domain. If the MN moves concurrently to a new access domain, while it is in connection with one or more domains, it first acquires a new access domain CoA (ADCoA) from the new ADFA. This time, the MN informs the ADFA about its MAA, so MAA
HA or CNs
1 2
3 4
5
6 7 8 9
1. MN gets the ADFA Advertisement. 2. MN sends a registration request to the ADFA. 3. The ADFA allocates an ADCoA for the MN and sends it in its registration reply. 4. The ADFA dynamically assigns a MAA to the MN. 5. MN sends a registration request to the MAA. 6. MAA accepts MNs request and allocates a MACoA to the MN. 7. MN sends MAA its ADCoA. 8. MN sends MAA its preferences. 9. MN registers its MACoA with its HA or CNs. Fig. 3. MMA-IP messaging when a MN first moves into a domain.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
that the ADFA does not assign a new MAA. Instead, the old MAA tries to find out whether it is in an optimum location after the new ADFA has been added to the set of ADFAs of the mobile. If it is in an optimum location, the MAA approves the registration and the new ADFA establishes a virtual connection with it. Otherwise, a MAA handoff need may arise. The MAA handoff will be explained later. Assuming that the MAA approves the new ADFA, the MN contacts with the MAA and informs it about its new ADCoA. The new ADCoA is now added to the MNs entry in MAA database. In this registration with the MAA, the MN does not perform a registration with its HA or CNs, because for them, it has still the same MACoA. Fig. 4 shows the MMA-IP message flow when the mobile node crosses into a new access domain. In order that the MAA has an up to date list of all the available ADFAs that can be used for the MN, in each registration with its MAA, the MN will tell the MAA about all its current access domain CoAs (ADCoAs). When the MAA gets a tunneled packet, it will decapsulate it, see to which home address it is directed, find which MN it corresponds to, find out which access domain CoAs are possible and decide
New ADFA
MN
583
which one or ones to use, and then form a tunnel again, in which to address is the corresponding ADFA address (access domain CoA). When the ADFA gets the tunneled packet, it will decapsulate it, and will send it to the MN according to its intra-domain mobility management protocol, whichever it uses. If the MN does not want to use multi-access, or it has only one access domain, it will inform its access domain ADFA about this situation, so that the ADFA will not assign a MAA to it. By this way, the MN is not registered with a MAA and will directly register its access domain CoA with its HA and CNs. In that case, the HA or the CNs will directly tunnel all the packets to the ADFA as in the usual MIP case. While using just one access domain in the above stated way, if MN moves into a new access domain, it will then get a dynamic MAA connection from the new ADFA and inform its new MAA about its both ADCoAs and preferences. If, on the other hand, the MN performs an access domain handoff, so that in hands over from the current access domain to another, it will acquire a new ADCoA and a new assigned MAA just like as if it first moves into an access domain.
MAA
HA or CNs
1 2 3
4 5
1. MN gets the advertisement of the new ADFA. 2. MN sends a registration request to the ADFA, and states its current MAA. 3. The ADFA approves the current MAA, allocates an ADCoA for the MN and sends it in its registration reply. 4. MN sends MAA the list of its ADCoAs. 5. MN sends MAA its new preferences. Fig. 4. MMA-IP messaging when the MN crosses into a new domain (no MAA handoff).
584
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
4.3. Simultaneous multi-access and preference messages in MMA-IP A mobile user can utilize multiple access domains synchronously using MMA-IP. Today, there are various wireless network types, with different characteristics. Some, for instance, offer a high coverage area, while the others offer a high data rate along with a relatively small coverage area. It is apparent that this diversity among wireless networks will drastically increase with the future 4G networks. Consider a user having a GPRS, a WLAN, and a Satellite connection at the same time. He may wish to transfer an image via the WLAN, due to its high speed, but at the same time, he may wish to send his voice data through the GPRS connection, since it is the most suitable network type for voice communication. If, on the other hand, he wishes to communicate with a party, on a ship in the Pacific Ocean, for instance, he has to use the satellite connection also. The MMA-IP allows him to use all the networks synchronously. With MMA-IP, he can also switch the routing of a data flow from one access domain to another. He may simply switch the image transfer from WLAN to GPRS at his desire. All this capability is actually done through the use of MAA. The MAA, knowing the userÕs stated wishes, routes all the incoming data through the corresponding interfaces. At userÕs desire, it may also switch from one interface to another. Consider another user having two different WLAN and a single GPRS connection. Assume that this user wishes to get the fastest connection to send data. Obviously, by using all the interfaces in parallel, we can send the data in the fastest possible way. MMA-IP enables this user to distribute his data flow to all the available interfaces in such a way that the effective bandwidth is increased. The natural question to ask is: How does the MAA can know the wishes of the user? This is achieved by MMA-IP preference messages. A mobile user in MMA-IP is expected to define his preferences and inform the MAA about those preferences in the form of preference messages. In a preference message, the user may direct the
MAA to use a specific network interface for a specific application type (image for instance), or for a specified source address (the party in Pacific Ocean, for instance). Another user may require the MAA to utilize all the available interfaces to achieve the best possible performance. A MMA-IP preference message is composed of two parts. The first part is called DataSpec and defines the specifications about the data on which some preferences are made. The second part is called To-Do and indicates the preference. 1. DataSpec Part: This part specifies one or more of the following about the data: • Type: Specifies the type of the data such as image, voice, data, real-time data, or nonreal time data. • Source IP address: Specifies one or more source IP addresses. Both IPv4 and IPv6 addresses are allowed. • Source Network: Specifies one or more source networks. A source network is indicated by a range of source IP addresses. • Source Port Number: Specifies one or more source port numbers. • Source Port Range: Specifies one or more source port number ranges. • Protocol: Specifies on or more protocols. Corresponding numbers for several protocols are indicated in [16]. 2. To-Do Part: This part indicates what to do with the specified data. This part may include one of the following: • Access Domain CoA (ADCoA): Specifies one or more ADCoAs to be utilized. • Access Domain: Specifies one or more access domains to be utilized. An access domain is indicated by a range of ADCoAs. • Primary Importance: Tells MAA to assign primary importance, meaning that if there are limited resources and the service to be supplied to this data coincides with another, prefer this one. • Secondary Importance: Tells MAA to assign secondary importance, meaning that if there are limited resources and the service to be supplied to this data coincides with another, prefer the other one.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
585
Formation of a preference message by integrating the DataSpec and To-Do parts allows a user to easily specify his preferences. For instance, a user can easily tell the MAA to use a specific access domain for incoming image data. Another user may direct the MAA to perform the fastest possible communication for real-time data. The MAA stores MNs preferences in its database and use them in re-tunneling messages to MNÕs one or more of ADFAs. The preferences stored in the MAAÕs database may become obsolete. A preference is marked as obsolete in two ways:
that domain and gets a new ADCoA from the ADFA. It then registers this new ADFA with its MAA. This process is actually explained in Section 4.2. If the new access domain is more suitable than the previous access domains for some data flow, the mobile changes its preferences and sends them to the MAA. Upon reception of the new preferences, the MAA will evaluate the access domains and switch using the more suitable access domain for the corresponding data flow. According to its preferences, the mobile also starts to utilize the new network interface so that an ADFA handoff is accomplished.
1. A time-out period elapses. 2. A new preference with the same DataSpec field from the same MN has arrived.
4.4.1.3. Mobile leaves coverage of an access domain. If, as moving, the mobile gets out of coverage of an access domain, there may arise a need for an ADFA handoff. This situation can be further divided into two cases: The mobile may enter a new access domain after getting out of scope of the previous one, or there may not be a new access domain so that the mobile is with its previous multi-access domains. If the mobile enters a new domain after getting out of scope of the previous one, the situation is actually very similar to the one explained in the previous Section 4.4.1.2. The mobile changes its preferences according to the new situation. It will simply distribute its current data flow coming through the out of coverage access domain between the new access domain and the access domains that it has been in the coverage simultaneously. The mobile, for instance may transfer all the previous data flow to the new access domain, or it may possibly decide not to use it and distribute the data flow to the old access domains that it has been in the coverage. According to its decision, the mobile prepares new preferences, and send them in the form of preference messages to the MAA. If, on the other hand, the mobile does not cross into a new access domain after it gets out of scope of one of its previous access domains, it will simply transfer the data flow through the out of coverage access domain to one or more of its other access domains. The mobile, according to its decision, again prepares new preferences and sends them to the MAA in the form of preference messages.
4.4. Handoffs in MMA-IP 4.4.1. ADFA handoffs In MMA-IP, the switching need between different access domains may arise in three cases: either the mobileÕs preferences change, or the mobile crosses into a new access domain, or it gets out of coverage of an access domain. We analyze all three cases separately. In this section, we generally assume that the mobile is under the coverage area of more than one access domain in any case. 4.4.1.1. MobileÕs preferences change. While using a set of wireless access domains readily, if the mobile somehow decides to change its preferences, it updates its entry in MAA by sending new preference messages replacing the previous preferences. According to the new preferences, if a need to use a different access domain arises, the MAA simply routes the data packets through those new access domains. In the reverse direction, of course, the mobile may also change the access domains through which it sends the outgoing data. By this way, the mobileÕs data flow is transferred from one access domain to another. 4.4.1.2. Mobile crosses into a new access domain. While moving, if the mobile crosses into a new access domain, it first registers with the ADFA of
586
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
The handoff process and the corresponding preliminary work start with the event that the old MAA decides that it is no more in an optimal routing point. The MAA will then, by knowing all the ADFAs that the MN sees, find a new optimum MAA. The old MAA will then inform the MN about the nonoptimality of itself, and notify it about the new optimal MAA. Following that, the MN will decide whether it will perform a handoff or not, and tell its decision to its old MAA. All this work is preliminary, and during this, the data flow is maintained through the old MAA and old virtual connections. The new ADFA, on the other hand, may be used directly by CNs or the HA. If as a result of the preliminary work, the MAA decides that the usage of some of the old ADFAs with the new MAA may cause routing inefficiencies, the MN will have to use them by directly sending preferences to the corresponding CNs or the HA. If the MN accepts handoff, it will first handle the ADFAs, which will not use the new MAA. For this, it will send preferences to the corresponding CNs or the HA, so that the data to be sent through them are directly tunneled to the ADFAs, not to the new MAA. After that, the old MAA will send all the data about the MN, including its preferences, to the new MAA. In other words, the old MAA will send the entry for the MN in its database to the new
4.4.2. MAA handoffs As the MN moves, if it comes across a new access domain (a new ADFA), it will get a CoA from that ADFA and if the current MAA approves its optimality, it will register the new ADFA with its MAA so that a virtual connection is established. If the old MAA is in a location, which is inefficient to use with the new ADFA, the old MAA, will find this out, and does not approve the connection. In that case, there are two choices for the MN: 1. It will stay with the old MAA and old ADFAMAA virtual connections. However, the new ADFA will not connect to the old MAA. The MN may only utilize this ADFA by sending preferences to its HA or CNs in which it states to use the new ADFA for some specifications. 2. The MN will perform a MAA handoff, so that all the previous ADFAs are now connected to the new MAA, if possible. However, in MMA-IP, the MAA handoff process needs some preliminary work to be performed in both MAAs, meaning that the MN cannot perform a MAA handoff right away, if it comes across an ADFA, which necessitates a MAA handoff. Before the MAA handoff, the MN should use the new ADFA as in item 1 above, during the stated preliminary work. The MAA handoff process is illustrated in Fig. 5.
CN
HA
MAA 1
MAA 2 ADFA
ADFA ADFA
ADFA
ADFA
MN
Fig. 5. MAA handoff process.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
MAA. By this way, the MN is registered to the new MAA. The old MAA also tunnels all the incoming data for the MN to the new MAA. The MN will then register the address of the new MAA with its HA and all the CNs. This will complete the MAA handoff process. Fig. 6 shows the MMA-IP message flow when a MAA handoff occurs. Note that this type of handoff is usually referred to as ‘‘break before make’’. A similar ‘‘make before break’’ type of handoff could be developed such that MAA operation is not interrupted.
MN
4.5. Hierarchical MAA extension to MMA-IP (H-MMA-IP) In the proposed MMA-IP architecture, a mobile node communicates through multiple access domains by using a unique MAA. All the multiaccess operations of the mobile are handled by this MAA. An exception to this is that the mobile node can assign MAA functionality to the HA or CNs so that they can manage multi-access according to the MNs preferences sent to them. However, this method is only efficient when it is certain that
New ADFA Old MAA New MAA Old ADFAs HA or CNs 1 2 3
4 5 6
7
8 9 10
12
587
11
13 14 15
1. MN gets the advertisement of the new ADFA. 2. MN sends a registration request to the new ADFA. In this request, MN indicates its current MAA. 3. The ADFA allocates an ADCoA for the MN and sends it in its registration reply. 4. The new ADFA communicates with the mobile’s current MAA, and informs it about the mobile’s registration. 5. The MN updates the list of ADCoAs in the MAA. 6. The old MAA, by knowing the ADCoAs, finds a new optimum MAA and informs the MN about the new MAA. 7. The old MAA also informs the old ADFAs about the new MAA. 8. The MN tells its handoff decision to the old MAA. 9. The MN sends preferences to HA or CNs to use the old ADFAs which are not to be used with the new MAA. 10. The MN tells the old MAA that it is ready for the handoff. 11. The old MAA sends all the data about the MN to the new MAA. 12. The old MAA tells MN to handoff. 13. MN sends a registration request to the new MAA. 14. The new MAA registers the MN and assigns a new MACoA. 15. The MN registers its new MACoA with its HA or CNs.
Fig. 6. MMA-IP MAA handoff messaging.
588
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
In H-MMA-IP, the mobile node normally uses a unique MAA, as usual. The MN decides to use a hierarchical MAA architecture if it cannot find a single optimal MAA for all of its ADFAs. Consider the MN in Fig. 7. Suppose that it initially communicates with the ADFA1 through MAA2, which is its unique MAA. When the MN crosses into the access domain 2, it gets a new ADCoA from there but MAA2 becomes nonoptimal to use with ADFA2. If the MN decides to perform a MAA handoff, this time MAA3, the only possible MAA to perform a handoff to, will be nonoptimal to use with ADFA1. In either case, the MN will have to use one of the access domains by assigning MAA functionality to its HA or CNs through preference messages. Since it can never use both access domains with a single MAA, the mobile node will never take advantage of the special multi-access agent concept. To overcome this, after a time-out period elapses by using MAA2 and getting continuous nonoptimalities from ADFA and MAA combinations, the MN decides to use a hierarchical MAA architecture where MAA1 will be hierarchially higher than MAA2 and MAA3. The details of operation can be established similar to ordinary MMA-IP case.
a specific source will send a specified data flow through a specific access domain. In such a case, there is no need for the MAA to take part in the multi-access operation, and the CN or HA will directly tunnel the data flow to the ADFA of the specified access domain. Assigning MAA functionality to the HA or CNs is also useful when the MAA becomes nonoptimal to use with a new ADFA and a MAA handoff has not performed yet. In such a case, the only way to use the new ADFA is through assigning MAA functionality to the HA or CNs by sending preference messages to them. Using a unique MAA to control multi-access functions, together with assigning MAA functionality to the HA or CNs when needed, is the most efficient method for managing multi-access operations. However, there may be cases in which the mobile node is permanently, or for long periods, connected to two ADFAs, for which, it is not possible to find a single optimal MAA. In such a case, the mobile node should permanently use one of the ADFAs with its corresponding MAA, and use the other through assigning MAA functionality to the HA or CNs. Hence, the advantages that the MAA offers cannot be utilized. To handle this problem, a hierarchical MAA extension to MMAIP can be proposed. In the hierarchical MAA extension to MMA-IP (H-MMA-IP), we propose to use only two hierarchical MAA levels. Fig. 7 illustrates the architecture of the H-MMA-IP.
5. Discussions on MMA-IP performance The MAA is key to the multi-access operations of the MMA-IP. It is hierarchically in a higher
CN
HA
MAA 1
MAA 2
MAA 3
ADFA 1
Access Domain 1
ADFA 2
MN
Access Domain 2
Fig. 7. Hierarchical MAA extension to MMA-IP.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
may occur. This situation may occur if one of the access domains is for example a satellite domain. In such a case, a hierarchical MAA structure may be utilized. Assigning additional MAA functionality to HA or CNs is another solution to this problem. The MAA utilization provides a proficient location management and paging functionality to the MMA-IP architecture. By virtue of its characteristics, the MAA can easily locate a specific mobile connected to it. The MAA has more than one access domain to page the mobile node. Assigning the control of multi-access operations to a special agent, MAA also allows new systems and access domains to be easily integrated to the architecture and permits the system capacity to be readily expanded. Other multi-access solutions, which give the multi-access control to the mobile node, cannot achieve the flexibility present in MMA-IP. In NOMAD [5], for instance, the mobile node is responsible for managing multi-access operations. Since the mobile node cannot oversee the other nodes like the MAA does, it loses the stated advantages. In addition to this, assigning so much functionality on the mobile terminal will cause it to consume more power, which is relatively scarce in a mobile terminal. Such functionality also
level than the ADFAs and the MN, so that it can easily oversee and control them. Owing to its position, the MAA can also be aware of the other network characteristics and status such as congestion or overloading. The MAA has a database in which it stores the mobileÕs current ADFAs and their preferences. In this database, the mobiles are identified according to their home addresses, meaning that the home address is the primary key for this database. Using the home address as a primary key is very meaningful, since the home addresses of the mobiles are unique. As stated previously, the MAA should be placed geographically in an optimum location so that the total routing and traveling cost of sent packets from the HA and all CNs through each and every combination of the ADFAs is minimized. In MMA-IP, we generally assume that the MAAs and the ADFAs are physically close to each other. Fig. 8 shows the MMA-IP architecture for example in some region of the New York City. There are several ADFAs belonging to different access domains. As seen in the figure, the MAAs controlling these ADFAs are located physically very close to them. If one of the ADFAs is located in a distant position, routing inefficiency
Tokyo
Paris
CN
CN
CN
Istanbul
London
HA
MAA ADFA
ADFA
589
MAA
ADFA
MN
ADFA ADFA
NewYork Manhattan
Fig. 8. Sample MMA-IP architecture in New York City.
590
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
requires the mobile terminal to have a good processing capability and a high memory storage, which again, in general, cannot be available in every mobile terminal. It should be noted here that, the multi-access functionality of the MAA could be distributed among the MAA, ADFA and the MN. However, MAA should be used for all this functionality due to the above stated advantages. In some cases, it may be necessary to disable the MAA and directly use the ADFA as the first point for redirection. This need may arise when the mobile has a single access domain to use. In this case, it will be inefficient to use the MAA because the only thing that it will do is to relay the incoming packets to the ADFA and nothing more. MMA-IP is a QoS aware multi-access management system. The MAA and the preference messages are MMA-IPÕs key features, enabling its basic QoS support. A mobile can easily send its specifications in the form of preference messages to the MAA. The MAA can then perform its multi-access management activities by taking into account mobileÕs QoS specifications. The MMA-IP architecture can be easily integrated to the DiffServ and IntServ architectures so that proven QoS structures are utilized with multiaccess. As an option, the MAA may inform the mobile about the neighboring ADFAs approval of its handoff and also about their QoS support and performance of meeting its preferences. By this way, before getting out of the old access domain and crossing into the new access domain, the mobile can evaluate its alternatives. Since the mobile is currently utilizing multiple access domains simultaneously, and assuming that it will get out of the coverage area of only one of them, instead of transporting the streams to the new access domains, the mobile can alternatively transport them to the other old access domains that it is using currently. The mobile can do this by just changing its preferences with the MAA and it can do this safely before it gets out of coverage of the current access domain, and before crossing into the new access domain. In informing the mobile about the neighboring ADFAs approval status, the MAA may also tell the mobile that there are some gaps be-
tween the access domains, if any. Knowing this fact, the mobile may decide to transfer its streams vertically to other access domains that it currently uses in its multi-access operations, or it may decide to halt the flow of those streams until it crosses into the next access domain. The major disadvantage of MAA is that it forms a potential single point of failure. If somehow the MAA gets down, a MAA handoff may be performed and the successive multi-access operations can be handled, but the data stored in the down MAA may be lost. However, the same story is applicable to the whole Mobile IP architecture that all the FAs and HAs are prone to the single point of failure. The risk of being affected by the getting down of MAA can be handled by introducing some redundancy to the network. In other words, a sleeping MAA, which backups the original one, can be held, and it can take over the job when the original MAA gets down or ADFAs can take over temporarily the responsibilities of the MAA. Another disadvantage of MAA usage may arise when one of the ADFAs is located physically far away from the MAA. In MMA-IP, we assume that the MAA and ADFAs are located close to each other, so that routing flows from MAA through different ADFAs cause minimal routing inefficiency. If one of the ADFAs is located far away from the MAA, routing the flows from MAA through that ADFA will result in a routing inefficiency. Such a remote ADFA may occur in satellite access domains. Such routing inefficiency may be overcome by utilizing hierarchical MAA extension to MMA-IP (H-MMA-IP), or by assigning additional MAA functionality to HA or CNs, so that the data flow to be transmitted through the remote ADFA is directly sent to the ADFA, not to the MAA. The MAA functionality may also require significant hardware and software updates to the intermediate routers where MAAs operate. Finding the optimum location for a MAA may sometimes take up excessive time, causing delays in the MMA-IP operation. Also, processing network layer packets in MAAs would introduce delays in routing. To minimize these effects, the network layer software used in MAAs may need
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
high processing power, meaning that the routers, on which MAA functionality is to be installed, should be equipped with powerful processors. There are many open issues to develop in a multi-access management system that uses MMA-IP, among which are (i) how mobility speed and patterns affect performance, (ii) efficient handoff management, (iii) to find a suitable optimality criterion for MAA location and fast computation of it, (iv) efficient ways of encapsulation and decapsulation of multi-access IP packets, (v) policies to distribute flows among multiple interfaces, (vi) QoS implications of multi-access.
[11]
[12]
[13]
[14]
[15]
6. Conclusions In this paper, we have introduced an architecture proposal for multi-access management in IPbased future wireless networks. MMA-IP enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. This concept paper is intended to stimulate discussions on the roadmap to future improvements of the IP in 4G networks.
References [1] C. Perkins, IP Mobility Support, RFC 2002 IETF, October 1996. [2] C. Perkins, Mobile IP: Design Principles and Practice, Addison-Wesley Longman, Reading, MA, 1998. [3] C. Perkins, Mobile IP, IEEE Commun. 35 (5) (1997) 84– 99. [4] C. Perkins, IP Mobility Support for IPv4, revised draftietf-mobileip-rfc2002-bis-08.txt, IETF, September 2001. [5] N.A. Fikouras et al., Filters for Mobile IP Bindings (NOMAD) draft-nomad-mobileip-filters-02.txt, July 2002. [6] H. Soliman, K. El Malki, C. Castelluccia, Per-flow movement in MIPv6 draft-soliman-mobileip-flow-move01.txt, IETF, November 2001. [7] NomadicLab, Ericsson, Available from. [8] Seamoby Working Group, Available from . [9] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli, IP Micromobility support using HAWAII, draft-ietf-mobileip-hawaii-01.txt, IETF. [10] R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, L. Salgarelli, IP-based access network infrastructure for next-
[16]
591
generation wireless data networks, IEEE Pers. Commun. 7 (4) (2000) 34–41. R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, HAWAII: A domain-based approach for supporting mobility in widearea wireless networks, in: Proceedings of the International Conference on Networking Protocols (ICNP), Available from, 1999. A. Campbell, J. Gomez, C.-Y. Wan, S. Kim, Z. Turanyi, A. Valko, Cellular IP, draft-ietf-mobileip-cellularip-00.txt, IETF, January 2000. T. Campbell, J. Gomez, A. Valko, An overview of cellular IP, in: IEEE Wireless Communications and Networking Conference (WCNC), September 1999. E. Gustafsson, A. Jonnson, C. Perkins, Mobile IPv4 regional registration, draft-ietf-mobileip-reg-tunnel-09.txt, June 2004, in preparation. H. Soliman, C. Castelluccia, K. El Malki, L. Bellier, Hierarchical MIPv6 mobility management (HMIPv6), draft-ietf-mipshop-hmipv6-03.txt, IETF, October 2004, in preparation. J. Reynolds, J. Postel, Assigned Numbers, RFC 1700, STD 2, IETF, October 1994.
Su¨leyman Altuntasß was born in Isparta, Turkey. He received his B.Sc. (High Hons.) and M.Sc. degrees in Electrical and Electronics Engineering from Bilkent University and Middle East Technical University, Ankara, Turkey, in June 1999 and January 2003, respectively. He is currently a Ph.D. student in Electrical and Electronics Engineering Department, Middle East Technical University, Ankara, Turkey. He also works as a software engineer in MilSOFT Software Technologies, Ankara, Turkey. His current research interests include next-generation wireless networks, distributed processing systems and middleware-centric systems.
Buyurman Baykal received his B.Sc. (High Hons.) degree in Electrical and Electronics Engineering from Middle East Technical University in 1990; M.Sc. (Distinction) and Ph.D. degrees in 1992 and 1995 from Imperial College of Science, Technology and Medicine, all in Electrical and Electronics Engineering. Dr. Baykal has research and teaching interests in speech processing, signal processing for telecommunications, and communication networks. He has extensive experience both in the theory and applications of adaptive signal processing techniques to communication applications such as acoustic echo cancellation, noise reduction, channel equalization and digital receiver design through self-conducted research and industry-funded research projects. He conducts research and implementation work on low bit rate speech coding and content based indexing of audio signals. He is also involved in
592
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
communication network research with particular interest in network design aspects, wireless networks and network management issues. Dr. Baykal is an Associate Editor of Computer Networks (Elsevier Science), Sensor Letters (American Scien-
tific Publishing), a past Associate Editor of the IEEE Transactions on Circuits and Systems Part II—Analog and Digital Signal Processing (TCAS-II). He authored and co-authored over 50 technical papers.
Mobile multi-access IP: a proposal for mobile multi-access management in future wireless IP networks Su¨leyman Altuntasß, Buyurman Baykal
*
Electrical Engineering, Middel East Technical University, 06531Ankara, Turkey Received 3 November 2003; received in revised form 17 November 2003; accepted 29 March 2004 Available online 8 December 2004 Responsible Editor: I.F. Akyildiz
Abstract As the wireless networking technologies advance rapidly, providing mobile users with roaming freely in heterogeneous wireless access domains, the need for multi-access arises. This paper introduces the Mobile Multi-Access Management Architecture (MMA-IP) for IP-based future wireless networks. MMA-IP enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. In order to handle multi-access operations, MMA-IP defines a new special mobility agent, called Multi-Access Agent (MAA). The MAA is the first point for incoming packets destined to the mobile node. Upon reception of these packets, MAA routes them via different access domains according to the mobileÕs preferences. MMA-IP allows mobile nodes to indicate their preferences in the form of preference messages and these preferences are stored in MAA for use in multi-access decisions. It is also noted that this concept paper intends to shed light on future improvements on IP in 4G networks. 2004 Elsevier B.V. All rights reserved. Keywords: Multi-access; Mobile IP; 4G; Heterogeneous network; Mobility agent; Home agent (HA); Foreign agent (FA); Care-of address (CoA)
1. Introduction Mobile IP [1–4] is the current standard for mobility management in IP-based networks. Mobile IP supports mobility management by intro-
*
Corresponding author. Tel.: +90 312 210 4582. E-mail address: [email protected] (B. Baykal).
ducing two entities, the Home Agent (HA) and the Foreign Agent (FA). Each Mobile Node (MN) in Mobile IP is statically assigned a HA and a corresponding home address. As it moves, the MN is dynamically assigned a FA and a corresponding care-of address. The packets destined to the MN are captured by its HA and tunneled to its current FA. The FA then decapsulates those packets and forwards them directly to the MN.
1389-1286/$ - see front matter 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2004.03.036
578
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
However, there is a common recognition that the Mobile IP protocol should be enhanced to meet the requirements of next generation wireless networks. Mobile users of future networks will be in the coverage area of more than one access domain at the same time and they will desire to utilize multiple access domains simultaneously or to switch between different access domains. These capabilities are generally referred to as ‘‘multiaccess’’. In the current Mobile IP, a mobile user can maintain simultaneous bindings, but these bindings can only enable it to receive the duplicate copy of every data packet at each registered careof-address. Hence, the current Mobile IP protocol lacks any multi-access support. We present the basics and operational details of the Mobile Multi-Access Management Architecture (MMA-IP) for future wireless networks. MMA-IP is a multi-access management architecture, which enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. MMA-IP assumes the usage of Mobile IP in the backbone as interdomain mobility (or so-called macromobility) management protocol and offers multiple care-of addresses (CoA) for supporting Mobile IP in multi-access operations. So as to handle multiaccess operations, MMA-IP defines a new special mobility agent, called Multi-Access Agent (MAA). The MAA is the first point for incoming packets destined to the mobile node. Upon reception of these packets, MAA routes them via different access domains according to the mobileÕs preferences. MMA-IP allows mobile nodes to indicate their preferences in the form of preference messages and these preferences are stored in MAA for use in multi-access decisions.
of multiple access domains at the same time in 4G environments. The 4G vision will let mobile users seamlessly handoff between these different access technologies, which have overlapping coverage areas. Fig. 1 shows a sample of a future 4G network environment with several overlapping wireless access domains. As the mobile node (MN) moves, it crosses into various access domains of different characteristics. For instance, at point A, the mobile node is in the coverage area of a Satellite network, a GPRS network, and two different WLANS. At point B, on the other hand, the mobile node can use a Satellite network, a GPRS network, and a Bluetooth network. In future networks, the mobile users should be able to use multiple access domains simultaneously or switch from using one access domain to another seamlessly. Each access domain has some specific characteristics of its own. Some, for instance offer a large coverage area, while others offer high data rates. Some access domains are more suitable for image transmission while the others perform better for voice communications. Therefore, being able to use multiple access domains, the mobile users of future networks should be able to switch between different access domains according to their specific needs. They may also use multiple access domains simultaneously for different application types. A mobile user, for example, may use a WLAN for his image transmission, and concurrently use a GPRS network for his voice communication. Mobile users, who need the fastest possible communication, may even divide a single stream between different access domains, so that
2. Concept of operations of multi-access in future wireless networks The aim of future wireless networks is to provide the mobile users with a completely IP based access to the information infrastructure by using a wide variety of access technologies. This is true especially for the fourth generation (4G) networks in which mobile users will be in the coverage area
Fig. 1. A sample of future 4G network environment.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
579
they can use them in parallel to achieve the best possible performance. What is explained above brings about the concept of ‘‘multi-access’’ in future wireless networks. Multi-access can be defined as the ability to use multiple network interfaces in a single terminal, either by simultaneously routing different data flows to or from the mobile terminal through different access domains, or, by switching between different access domains. Although, in some texts, simultaneous usage of different access domains is referred to as ‘‘simultaneous multi-access’’ and switching between different access domains as only ‘‘multi-access’’, we adapt the convention in this paper that both kind of operations are called ‘‘multi-access’’. The reason for this is that the ability of using different access domains also implicitly includes the capability of switching between them. Hence, throughout the paper, multi-access term will be used to refer to the ability of synchronously utilizing multiple access domains, and switching between them. A complete multi-access system should meet the following requirements:
oversee and monitor the operations of access domain gateway agents and mobile nodes, and hence, it can easily control and manage the multi-access operations. This special agent should store all the mobile nodesÕ multi-access and QoS specifications and the status of gateway agents, so that it can use them in its multi-access decisions. Multi-access capability brings about some difficulty in mobility management. With multi-access, the inter-domain mobility management should now take into account mobility between different access domains, so-called vertical handoffs, and what is more important, the inter-domain mobility management should now consider concurrent use of different access domains, which is drastically different than vertical handoffs. This second item again, favors the use of a special network node overseeing all the gateway nodes, for the multiaccess operations. If such a special multi-access agent is utilized, the multi-access will ease the paging of mobile nodes in the hybrid network infrastructure. Such a special agent will have more than one access domain to page the mobile node.
• It should provide the mobile users with the ability to use different access domains simultaneously. The users may use different access domains for different application types, for different source or destination addresses or for different source or destination networks. • It should allow the mobile users to specify their required QoS specifications and utilize the available network interfaces under the light of those QoS specifications. For instance, to achieve the fastest possible communication, the mobile user may be able to divide his incoming or outgoing data flow between the available network interfaces so that he can use them in parallel to obtain the best performance. • It should allow the mobile users to switch between different access domains.
3. Related work
The above stated requirements lead us to the need of a network node, or a special network agent, which is hierarchically in a higher level than the mobile node and all the gateway agents of each access domain. By this way, this special agent can
Relatively little work has been published on architectures enabling multi-access in future wireless networks. One approach to multi-access in heterogeneous network architectures is the NOMAD system [5]. In this system, the mobile node controls and manages the multi-access operations. Every time a mobile node acquires a care-of address through one of its interfaces, it is required to issue a binding request to the respective binding agent. A binding agent can be any Mobile IP entity that can maintain bindings, such as a HA, GFA, or even a CN. The mobile node is required to include in its binding request a list of filters that indicate which flows are associated with the registered care-of address. By this way, the mobile node specifies what type of flows, or flows coming from which addresses or domains are to be conveyed through a specific access domain. Ref. [6] introduces a new extension to MIPv6 to allow hosts to direct inbound flows individually to certain preferred interfaces. The extension is called
580
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
On the other hand, some companies have recently started to produce multi-access enabled devices. Ericsson and TelenorÕs UMTS + WLAN terminal and NokiaÕs GPRS + HSCD + WLAN PC card are examples of such devices.
per-flow movement in MIPv6. Per-flow movement is defined as the splitting of inbound traffic to be received on different addresses. Using this extension, a MN would be able to move one flow to another interface while maintaining the reception of other flows on the current interface. There is also very recent work being done by EricssonÕs NomadicLab & HUT. The project is called SIMA (Simultaneous multi-Access Mobile IPv6). The idea in SIMA is very similar to that introduced in [6] and can be viewed in [7]. The SeaMoby Working Group (WG) [8] tries to perform a context transfer when a mobile changes its point of attachment. The working group claims that although the protocol used to actively redirect the IP packet flows during a change in a mobileÕs point of attachment is handled by the Mobile IP WG, there is a need for preserving the context of its active IP flows. The IP flow context that might be useful to transfer could include, but not be limited to security context, policy, QoS (diffserv or intserv as needed) header compression, and accounting/AAA information. The SeaMoby WG will analyze the requirements and tradeoffs for the goal of transferring context information from a mobileÕs old access to the new access device. Depending on the results of the requirements analysis, the SeaMoby WG will develop a protocol (or start from an existing protocol such as Contract Net Protocol (CNP) or the IEEEÕs 802.11f) to transfer the context information for a session.
4. A solution to multi-access management in IP-based networks: MMA-IP 4.1. MMA-IP basics MMA-IP assumes the usage of Mobile IP in the backbone as inter-domain mobility management protocol and offers multiple CoAs for supporting Mobile IP in simultaneous usage of or switching between multiple hybrid access domains. MMAIP allows any kind of access-domain as long as they are connected to the Mobile IP backbone by some kind of a Foreign Agent. Fig. 2 shows the basic MMA-IP architecture and its elements. Inside these access domains, any intra-domain mobility management protocol, such as HAWAII [9–11], Cellular IP [12,13], MIP-RR [14] or HMIPv6 [15] may be utilized. The point is that the access domain should be connected to the Mobile IP backbone by a mobility agent. This mobility agent could be a FA (Foreign Agent), a GFA (Gateway Foreign Agent), or any other MA (Mobility Agent), such as the domain root router of HAWAII, all of which are referred to
CN
CN MAA
Multi-Access CoA
Virtual Connections
ADFA
Access Domain CoA
ADFA
ADFA
Access Domain 1
MN Access Domain 2
Fig. 2. Basic MMA-IP architecture.
Access Domain CoA
Access Domain 3
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
as Access Domain Foreign Agent (ADFA) in MMA-IP terminology. MMA-IP handles multi-access by defining a new mobility agent, called Multi-Access Agent (MAA). The MAA is different from other ADFAs in that it is hierarchically in a higher level in the backbone. The MAA is the first point for data flow redirection. In this aspect, it is similar to a MIP FA or MIP-RR GFA that the data packets destined to the MN are tunneled to the MAA. The MAA establishes virtual connections with the ADFAs that the MN attaches, and use them simultaneously to re-tunnel packets. The MAA takes into account the MNs preferences in simultaneous usage of different ADFAs, meaning different access domains. MMA-IP offers two different CoAs: • Multi-Access Care-of Address (MACoA): This address is the one to which all the packets destined to the MN are tunneled. The MN registers its MACoA with its HA or CNs. • Access Domain Care-of Address (ADCoA): This address identifies the address of the ADFA that connects an access domain to the Mobile IP backbone. This address is actually the usual MIP Foreign Agent CoA. The MN registers its ADCoAs with its MAA so that it can simultaneously use a bunch of MNs ADCoAs to send packets.
4.2. MMA-IP operation When the Mobile Node (MN) first moves into an access domain, it acquires an Access Domain Care of Address from the Access Domain Foreign Agent (ADFA) of that domain. As stated, the ADFA is the gateway of the domain, which connects the access network to the Mobile IP backbone, and the Access Domain CoA is the MIP CoA in the classical sense. After registration of the ADCoA with the ADFA, the ADFA dynamically assigns a MAA to the MN. By this way, a virtual connection between the ADFA and the MAA is established. The MN then registers with the MAA and gets a MACoA. This MACoA will be the address to
581
which all the packets destined to the MN will be tunneled in the Mobile IP backbone. The MN registers its MACoA with its HA and CNs. When the MN tries to register with the assigned MAA, the MAA first explores whether it is the optimum MAA for the MN or not. Here, the optimality is related to the location of the MAA. Ideally, the MAA should be in such a location that the total routing cost of packets sent from the HA and all CNs through each and every combination of the ADFAs is minimized. Since the MAAs are placed in certain routers, this ideal case cannot be realized. However, the MAAs can be placed in optimal locations close to the ideal case. By virtue of its characteristics, a MAA is the best source to figure out the optimum MAA for a MN. Nevertheless, an ADFA should first assign a MAA to the MN. In MMA-IP, an ADFA first assigns one of its closest MAAs to the MN. After that, the MAA assigned by the ADFA performs an analysis on whether it is the optimal MAA for the MN or there is a better MAA in terms of optimality. The MN gets connected to its optimum MAA according to the first assigned MAAÕs decision. In registering with the MAA, the MN also informs it about its ADCoA that it acquired from the ADFA. On the other hand, the MAA creates an entry in its database and includes the new MACoA of the MN together with its home address in the entry. In this database, mobile nodes will be identified by their home addresses; in other words, home addresses of the mobile nodes will be the primary keys of this database. In order that the MAA will direct packets to the MN by using its multiple points of attachment simultaneously, it will need the MNs preferences about the usage of networks. For this, after registering with the MAA, the MN will communicate with it about its preferences. These preferences are also stored in the MNs entry of the database kept in the MAA. MMA-IP defines preference messages to inform the MAA about the MNs preferences. Each unique preference is sent to the MAA in a single preference message. A preference message has two parts; the first part defines the specifications about the data on which some preferences are made and
582
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
the second part indicates the preference. The MAA stores MNs preferences in its database and use them in re-tunneling messages to the MNs one or more of ADFAs. The preference messages will be explained in later sections. After acquiring its MACoA and specifying its preferences, the MN registers its MACoA with its HA and CNs. From this point on, the HA or the CNs will tunnel packets to the MAA, which then re-tunnels the packets simultaneously to different ADFAs according to MNs preferences. MMA-IP also enables the preferences to be sent to HA or CNs so that, an additional MAA functionality can be established in HA or CNs. By this ADFA
MN
way, the HA or CNs can directly tunnel the packets to the specified ADFAs. However, MMA-IP assumes the usage of a MAA as mandatory, if multi-access is to be utilized. The extra functionality established in HA or CNs is only an addition to the usual MAA. This will be explained in later sections. Fig. 3 shows the MMA-IP message flow when a mobile node first moves into an access domain. If the MN moves concurrently to a new access domain, while it is in connection with one or more domains, it first acquires a new access domain CoA (ADCoA) from the new ADFA. This time, the MN informs the ADFA about its MAA, so MAA
HA or CNs
1 2
3 4
5
6 7 8 9
1. MN gets the ADFA Advertisement. 2. MN sends a registration request to the ADFA. 3. The ADFA allocates an ADCoA for the MN and sends it in its registration reply. 4. The ADFA dynamically assigns a MAA to the MN. 5. MN sends a registration request to the MAA. 6. MAA accepts MNs request and allocates a MACoA to the MN. 7. MN sends MAA its ADCoA. 8. MN sends MAA its preferences. 9. MN registers its MACoA with its HA or CNs. Fig. 3. MMA-IP messaging when a MN first moves into a domain.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
that the ADFA does not assign a new MAA. Instead, the old MAA tries to find out whether it is in an optimum location after the new ADFA has been added to the set of ADFAs of the mobile. If it is in an optimum location, the MAA approves the registration and the new ADFA establishes a virtual connection with it. Otherwise, a MAA handoff need may arise. The MAA handoff will be explained later. Assuming that the MAA approves the new ADFA, the MN contacts with the MAA and informs it about its new ADCoA. The new ADCoA is now added to the MNs entry in MAA database. In this registration with the MAA, the MN does not perform a registration with its HA or CNs, because for them, it has still the same MACoA. Fig. 4 shows the MMA-IP message flow when the mobile node crosses into a new access domain. In order that the MAA has an up to date list of all the available ADFAs that can be used for the MN, in each registration with its MAA, the MN will tell the MAA about all its current access domain CoAs (ADCoAs). When the MAA gets a tunneled packet, it will decapsulate it, see to which home address it is directed, find which MN it corresponds to, find out which access domain CoAs are possible and decide
New ADFA
MN
583
which one or ones to use, and then form a tunnel again, in which to address is the corresponding ADFA address (access domain CoA). When the ADFA gets the tunneled packet, it will decapsulate it, and will send it to the MN according to its intra-domain mobility management protocol, whichever it uses. If the MN does not want to use multi-access, or it has only one access domain, it will inform its access domain ADFA about this situation, so that the ADFA will not assign a MAA to it. By this way, the MN is not registered with a MAA and will directly register its access domain CoA with its HA and CNs. In that case, the HA or the CNs will directly tunnel all the packets to the ADFA as in the usual MIP case. While using just one access domain in the above stated way, if MN moves into a new access domain, it will then get a dynamic MAA connection from the new ADFA and inform its new MAA about its both ADCoAs and preferences. If, on the other hand, the MN performs an access domain handoff, so that in hands over from the current access domain to another, it will acquire a new ADCoA and a new assigned MAA just like as if it first moves into an access domain.
MAA
HA or CNs
1 2 3
4 5
1. MN gets the advertisement of the new ADFA. 2. MN sends a registration request to the ADFA, and states its current MAA. 3. The ADFA approves the current MAA, allocates an ADCoA for the MN and sends it in its registration reply. 4. MN sends MAA the list of its ADCoAs. 5. MN sends MAA its new preferences. Fig. 4. MMA-IP messaging when the MN crosses into a new domain (no MAA handoff).
584
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
4.3. Simultaneous multi-access and preference messages in MMA-IP A mobile user can utilize multiple access domains synchronously using MMA-IP. Today, there are various wireless network types, with different characteristics. Some, for instance, offer a high coverage area, while the others offer a high data rate along with a relatively small coverage area. It is apparent that this diversity among wireless networks will drastically increase with the future 4G networks. Consider a user having a GPRS, a WLAN, and a Satellite connection at the same time. He may wish to transfer an image via the WLAN, due to its high speed, but at the same time, he may wish to send his voice data through the GPRS connection, since it is the most suitable network type for voice communication. If, on the other hand, he wishes to communicate with a party, on a ship in the Pacific Ocean, for instance, he has to use the satellite connection also. The MMA-IP allows him to use all the networks synchronously. With MMA-IP, he can also switch the routing of a data flow from one access domain to another. He may simply switch the image transfer from WLAN to GPRS at his desire. All this capability is actually done through the use of MAA. The MAA, knowing the userÕs stated wishes, routes all the incoming data through the corresponding interfaces. At userÕs desire, it may also switch from one interface to another. Consider another user having two different WLAN and a single GPRS connection. Assume that this user wishes to get the fastest connection to send data. Obviously, by using all the interfaces in parallel, we can send the data in the fastest possible way. MMA-IP enables this user to distribute his data flow to all the available interfaces in such a way that the effective bandwidth is increased. The natural question to ask is: How does the MAA can know the wishes of the user? This is achieved by MMA-IP preference messages. A mobile user in MMA-IP is expected to define his preferences and inform the MAA about those preferences in the form of preference messages. In a preference message, the user may direct the
MAA to use a specific network interface for a specific application type (image for instance), or for a specified source address (the party in Pacific Ocean, for instance). Another user may require the MAA to utilize all the available interfaces to achieve the best possible performance. A MMA-IP preference message is composed of two parts. The first part is called DataSpec and defines the specifications about the data on which some preferences are made. The second part is called To-Do and indicates the preference. 1. DataSpec Part: This part specifies one or more of the following about the data: • Type: Specifies the type of the data such as image, voice, data, real-time data, or nonreal time data. • Source IP address: Specifies one or more source IP addresses. Both IPv4 and IPv6 addresses are allowed. • Source Network: Specifies one or more source networks. A source network is indicated by a range of source IP addresses. • Source Port Number: Specifies one or more source port numbers. • Source Port Range: Specifies one or more source port number ranges. • Protocol: Specifies on or more protocols. Corresponding numbers for several protocols are indicated in [16]. 2. To-Do Part: This part indicates what to do with the specified data. This part may include one of the following: • Access Domain CoA (ADCoA): Specifies one or more ADCoAs to be utilized. • Access Domain: Specifies one or more access domains to be utilized. An access domain is indicated by a range of ADCoAs. • Primary Importance: Tells MAA to assign primary importance, meaning that if there are limited resources and the service to be supplied to this data coincides with another, prefer this one. • Secondary Importance: Tells MAA to assign secondary importance, meaning that if there are limited resources and the service to be supplied to this data coincides with another, prefer the other one.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
585
Formation of a preference message by integrating the DataSpec and To-Do parts allows a user to easily specify his preferences. For instance, a user can easily tell the MAA to use a specific access domain for incoming image data. Another user may direct the MAA to perform the fastest possible communication for real-time data. The MAA stores MNs preferences in its database and use them in re-tunneling messages to MNÕs one or more of ADFAs. The preferences stored in the MAAÕs database may become obsolete. A preference is marked as obsolete in two ways:
that domain and gets a new ADCoA from the ADFA. It then registers this new ADFA with its MAA. This process is actually explained in Section 4.2. If the new access domain is more suitable than the previous access domains for some data flow, the mobile changes its preferences and sends them to the MAA. Upon reception of the new preferences, the MAA will evaluate the access domains and switch using the more suitable access domain for the corresponding data flow. According to its preferences, the mobile also starts to utilize the new network interface so that an ADFA handoff is accomplished.
1. A time-out period elapses. 2. A new preference with the same DataSpec field from the same MN has arrived.
4.4.1.3. Mobile leaves coverage of an access domain. If, as moving, the mobile gets out of coverage of an access domain, there may arise a need for an ADFA handoff. This situation can be further divided into two cases: The mobile may enter a new access domain after getting out of scope of the previous one, or there may not be a new access domain so that the mobile is with its previous multi-access domains. If the mobile enters a new domain after getting out of scope of the previous one, the situation is actually very similar to the one explained in the previous Section 4.4.1.2. The mobile changes its preferences according to the new situation. It will simply distribute its current data flow coming through the out of coverage access domain between the new access domain and the access domains that it has been in the coverage simultaneously. The mobile, for instance may transfer all the previous data flow to the new access domain, or it may possibly decide not to use it and distribute the data flow to the old access domains that it has been in the coverage. According to its decision, the mobile prepares new preferences, and send them in the form of preference messages to the MAA. If, on the other hand, the mobile does not cross into a new access domain after it gets out of scope of one of its previous access domains, it will simply transfer the data flow through the out of coverage access domain to one or more of its other access domains. The mobile, according to its decision, again prepares new preferences and sends them to the MAA in the form of preference messages.
4.4. Handoffs in MMA-IP 4.4.1. ADFA handoffs In MMA-IP, the switching need between different access domains may arise in three cases: either the mobileÕs preferences change, or the mobile crosses into a new access domain, or it gets out of coverage of an access domain. We analyze all three cases separately. In this section, we generally assume that the mobile is under the coverage area of more than one access domain in any case. 4.4.1.1. MobileÕs preferences change. While using a set of wireless access domains readily, if the mobile somehow decides to change its preferences, it updates its entry in MAA by sending new preference messages replacing the previous preferences. According to the new preferences, if a need to use a different access domain arises, the MAA simply routes the data packets through those new access domains. In the reverse direction, of course, the mobile may also change the access domains through which it sends the outgoing data. By this way, the mobileÕs data flow is transferred from one access domain to another. 4.4.1.2. Mobile crosses into a new access domain. While moving, if the mobile crosses into a new access domain, it first registers with the ADFA of
586
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
The handoff process and the corresponding preliminary work start with the event that the old MAA decides that it is no more in an optimal routing point. The MAA will then, by knowing all the ADFAs that the MN sees, find a new optimum MAA. The old MAA will then inform the MN about the nonoptimality of itself, and notify it about the new optimal MAA. Following that, the MN will decide whether it will perform a handoff or not, and tell its decision to its old MAA. All this work is preliminary, and during this, the data flow is maintained through the old MAA and old virtual connections. The new ADFA, on the other hand, may be used directly by CNs or the HA. If as a result of the preliminary work, the MAA decides that the usage of some of the old ADFAs with the new MAA may cause routing inefficiencies, the MN will have to use them by directly sending preferences to the corresponding CNs or the HA. If the MN accepts handoff, it will first handle the ADFAs, which will not use the new MAA. For this, it will send preferences to the corresponding CNs or the HA, so that the data to be sent through them are directly tunneled to the ADFAs, not to the new MAA. After that, the old MAA will send all the data about the MN, including its preferences, to the new MAA. In other words, the old MAA will send the entry for the MN in its database to the new
4.4.2. MAA handoffs As the MN moves, if it comes across a new access domain (a new ADFA), it will get a CoA from that ADFA and if the current MAA approves its optimality, it will register the new ADFA with its MAA so that a virtual connection is established. If the old MAA is in a location, which is inefficient to use with the new ADFA, the old MAA, will find this out, and does not approve the connection. In that case, there are two choices for the MN: 1. It will stay with the old MAA and old ADFAMAA virtual connections. However, the new ADFA will not connect to the old MAA. The MN may only utilize this ADFA by sending preferences to its HA or CNs in which it states to use the new ADFA for some specifications. 2. The MN will perform a MAA handoff, so that all the previous ADFAs are now connected to the new MAA, if possible. However, in MMA-IP, the MAA handoff process needs some preliminary work to be performed in both MAAs, meaning that the MN cannot perform a MAA handoff right away, if it comes across an ADFA, which necessitates a MAA handoff. Before the MAA handoff, the MN should use the new ADFA as in item 1 above, during the stated preliminary work. The MAA handoff process is illustrated in Fig. 5.
CN
HA
MAA 1
MAA 2 ADFA
ADFA ADFA
ADFA
ADFA
MN
Fig. 5. MAA handoff process.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
MAA. By this way, the MN is registered to the new MAA. The old MAA also tunnels all the incoming data for the MN to the new MAA. The MN will then register the address of the new MAA with its HA and all the CNs. This will complete the MAA handoff process. Fig. 6 shows the MMA-IP message flow when a MAA handoff occurs. Note that this type of handoff is usually referred to as ‘‘break before make’’. A similar ‘‘make before break’’ type of handoff could be developed such that MAA operation is not interrupted.
MN
4.5. Hierarchical MAA extension to MMA-IP (H-MMA-IP) In the proposed MMA-IP architecture, a mobile node communicates through multiple access domains by using a unique MAA. All the multiaccess operations of the mobile are handled by this MAA. An exception to this is that the mobile node can assign MAA functionality to the HA or CNs so that they can manage multi-access according to the MNs preferences sent to them. However, this method is only efficient when it is certain that
New ADFA Old MAA New MAA Old ADFAs HA or CNs 1 2 3
4 5 6
7
8 9 10
12
587
11
13 14 15
1. MN gets the advertisement of the new ADFA. 2. MN sends a registration request to the new ADFA. In this request, MN indicates its current MAA. 3. The ADFA allocates an ADCoA for the MN and sends it in its registration reply. 4. The new ADFA communicates with the mobile’s current MAA, and informs it about the mobile’s registration. 5. The MN updates the list of ADCoAs in the MAA. 6. The old MAA, by knowing the ADCoAs, finds a new optimum MAA and informs the MN about the new MAA. 7. The old MAA also informs the old ADFAs about the new MAA. 8. The MN tells its handoff decision to the old MAA. 9. The MN sends preferences to HA or CNs to use the old ADFAs which are not to be used with the new MAA. 10. The MN tells the old MAA that it is ready for the handoff. 11. The old MAA sends all the data about the MN to the new MAA. 12. The old MAA tells MN to handoff. 13. MN sends a registration request to the new MAA. 14. The new MAA registers the MN and assigns a new MACoA. 15. The MN registers its new MACoA with its HA or CNs.
Fig. 6. MMA-IP MAA handoff messaging.
588
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
In H-MMA-IP, the mobile node normally uses a unique MAA, as usual. The MN decides to use a hierarchical MAA architecture if it cannot find a single optimal MAA for all of its ADFAs. Consider the MN in Fig. 7. Suppose that it initially communicates with the ADFA1 through MAA2, which is its unique MAA. When the MN crosses into the access domain 2, it gets a new ADCoA from there but MAA2 becomes nonoptimal to use with ADFA2. If the MN decides to perform a MAA handoff, this time MAA3, the only possible MAA to perform a handoff to, will be nonoptimal to use with ADFA1. In either case, the MN will have to use one of the access domains by assigning MAA functionality to its HA or CNs through preference messages. Since it can never use both access domains with a single MAA, the mobile node will never take advantage of the special multi-access agent concept. To overcome this, after a time-out period elapses by using MAA2 and getting continuous nonoptimalities from ADFA and MAA combinations, the MN decides to use a hierarchical MAA architecture where MAA1 will be hierarchially higher than MAA2 and MAA3. The details of operation can be established similar to ordinary MMA-IP case.
a specific source will send a specified data flow through a specific access domain. In such a case, there is no need for the MAA to take part in the multi-access operation, and the CN or HA will directly tunnel the data flow to the ADFA of the specified access domain. Assigning MAA functionality to the HA or CNs is also useful when the MAA becomes nonoptimal to use with a new ADFA and a MAA handoff has not performed yet. In such a case, the only way to use the new ADFA is through assigning MAA functionality to the HA or CNs by sending preference messages to them. Using a unique MAA to control multi-access functions, together with assigning MAA functionality to the HA or CNs when needed, is the most efficient method for managing multi-access operations. However, there may be cases in which the mobile node is permanently, or for long periods, connected to two ADFAs, for which, it is not possible to find a single optimal MAA. In such a case, the mobile node should permanently use one of the ADFAs with its corresponding MAA, and use the other through assigning MAA functionality to the HA or CNs. Hence, the advantages that the MAA offers cannot be utilized. To handle this problem, a hierarchical MAA extension to MMAIP can be proposed. In the hierarchical MAA extension to MMA-IP (H-MMA-IP), we propose to use only two hierarchical MAA levels. Fig. 7 illustrates the architecture of the H-MMA-IP.
5. Discussions on MMA-IP performance The MAA is key to the multi-access operations of the MMA-IP. It is hierarchically in a higher
CN
HA
MAA 1
MAA 2
MAA 3
ADFA 1
Access Domain 1
ADFA 2
MN
Access Domain 2
Fig. 7. Hierarchical MAA extension to MMA-IP.
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
may occur. This situation may occur if one of the access domains is for example a satellite domain. In such a case, a hierarchical MAA structure may be utilized. Assigning additional MAA functionality to HA or CNs is another solution to this problem. The MAA utilization provides a proficient location management and paging functionality to the MMA-IP architecture. By virtue of its characteristics, the MAA can easily locate a specific mobile connected to it. The MAA has more than one access domain to page the mobile node. Assigning the control of multi-access operations to a special agent, MAA also allows new systems and access domains to be easily integrated to the architecture and permits the system capacity to be readily expanded. Other multi-access solutions, which give the multi-access control to the mobile node, cannot achieve the flexibility present in MMA-IP. In NOMAD [5], for instance, the mobile node is responsible for managing multi-access operations. Since the mobile node cannot oversee the other nodes like the MAA does, it loses the stated advantages. In addition to this, assigning so much functionality on the mobile terminal will cause it to consume more power, which is relatively scarce in a mobile terminal. Such functionality also
level than the ADFAs and the MN, so that it can easily oversee and control them. Owing to its position, the MAA can also be aware of the other network characteristics and status such as congestion or overloading. The MAA has a database in which it stores the mobileÕs current ADFAs and their preferences. In this database, the mobiles are identified according to their home addresses, meaning that the home address is the primary key for this database. Using the home address as a primary key is very meaningful, since the home addresses of the mobiles are unique. As stated previously, the MAA should be placed geographically in an optimum location so that the total routing and traveling cost of sent packets from the HA and all CNs through each and every combination of the ADFAs is minimized. In MMA-IP, we generally assume that the MAAs and the ADFAs are physically close to each other. Fig. 8 shows the MMA-IP architecture for example in some region of the New York City. There are several ADFAs belonging to different access domains. As seen in the figure, the MAAs controlling these ADFAs are located physically very close to them. If one of the ADFAs is located in a distant position, routing inefficiency
Tokyo
Paris
CN
CN
CN
Istanbul
London
HA
MAA ADFA
ADFA
589
MAA
ADFA
MN
ADFA ADFA
NewYork Manhattan
Fig. 8. Sample MMA-IP architecture in New York City.
590
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
requires the mobile terminal to have a good processing capability and a high memory storage, which again, in general, cannot be available in every mobile terminal. It should be noted here that, the multi-access functionality of the MAA could be distributed among the MAA, ADFA and the MN. However, MAA should be used for all this functionality due to the above stated advantages. In some cases, it may be necessary to disable the MAA and directly use the ADFA as the first point for redirection. This need may arise when the mobile has a single access domain to use. In this case, it will be inefficient to use the MAA because the only thing that it will do is to relay the incoming packets to the ADFA and nothing more. MMA-IP is a QoS aware multi-access management system. The MAA and the preference messages are MMA-IPÕs key features, enabling its basic QoS support. A mobile can easily send its specifications in the form of preference messages to the MAA. The MAA can then perform its multi-access management activities by taking into account mobileÕs QoS specifications. The MMA-IP architecture can be easily integrated to the DiffServ and IntServ architectures so that proven QoS structures are utilized with multiaccess. As an option, the MAA may inform the mobile about the neighboring ADFAs approval of its handoff and also about their QoS support and performance of meeting its preferences. By this way, before getting out of the old access domain and crossing into the new access domain, the mobile can evaluate its alternatives. Since the mobile is currently utilizing multiple access domains simultaneously, and assuming that it will get out of the coverage area of only one of them, instead of transporting the streams to the new access domains, the mobile can alternatively transport them to the other old access domains that it is using currently. The mobile can do this by just changing its preferences with the MAA and it can do this safely before it gets out of coverage of the current access domain, and before crossing into the new access domain. In informing the mobile about the neighboring ADFAs approval status, the MAA may also tell the mobile that there are some gaps be-
tween the access domains, if any. Knowing this fact, the mobile may decide to transfer its streams vertically to other access domains that it currently uses in its multi-access operations, or it may decide to halt the flow of those streams until it crosses into the next access domain. The major disadvantage of MAA is that it forms a potential single point of failure. If somehow the MAA gets down, a MAA handoff may be performed and the successive multi-access operations can be handled, but the data stored in the down MAA may be lost. However, the same story is applicable to the whole Mobile IP architecture that all the FAs and HAs are prone to the single point of failure. The risk of being affected by the getting down of MAA can be handled by introducing some redundancy to the network. In other words, a sleeping MAA, which backups the original one, can be held, and it can take over the job when the original MAA gets down or ADFAs can take over temporarily the responsibilities of the MAA. Another disadvantage of MAA usage may arise when one of the ADFAs is located physically far away from the MAA. In MMA-IP, we assume that the MAA and ADFAs are located close to each other, so that routing flows from MAA through different ADFAs cause minimal routing inefficiency. If one of the ADFAs is located far away from the MAA, routing the flows from MAA through that ADFA will result in a routing inefficiency. Such a remote ADFA may occur in satellite access domains. Such routing inefficiency may be overcome by utilizing hierarchical MAA extension to MMA-IP (H-MMA-IP), or by assigning additional MAA functionality to HA or CNs, so that the data flow to be transmitted through the remote ADFA is directly sent to the ADFA, not to the MAA. The MAA functionality may also require significant hardware and software updates to the intermediate routers where MAAs operate. Finding the optimum location for a MAA may sometimes take up excessive time, causing delays in the MMA-IP operation. Also, processing network layer packets in MAAs would introduce delays in routing. To minimize these effects, the network layer software used in MAAs may need
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
high processing power, meaning that the routers, on which MAA functionality is to be installed, should be equipped with powerful processors. There are many open issues to develop in a multi-access management system that uses MMA-IP, among which are (i) how mobility speed and patterns affect performance, (ii) efficient handoff management, (iii) to find a suitable optimality criterion for MAA location and fast computation of it, (iv) efficient ways of encapsulation and decapsulation of multi-access IP packets, (v) policies to distribute flows among multiple interfaces, (vi) QoS implications of multi-access.
[11]
[12]
[13]
[14]
[15]
6. Conclusions In this paper, we have introduced an architecture proposal for multi-access management in IPbased future wireless networks. MMA-IP enables mobile users to utilize multiple access domains synchronously and to switch between different access domains. This concept paper is intended to stimulate discussions on the roadmap to future improvements of the IP in 4G networks.
References [1] C. Perkins, IP Mobility Support, RFC 2002 IETF, October 1996. [2] C. Perkins, Mobile IP: Design Principles and Practice, Addison-Wesley Longman, Reading, MA, 1998. [3] C. Perkins, Mobile IP, IEEE Commun. 35 (5) (1997) 84– 99. [4] C. Perkins, IP Mobility Support for IPv4, revised draftietf-mobileip-rfc2002-bis-08.txt, IETF, September 2001. [5] N.A. Fikouras et al., Filters for Mobile IP Bindings (NOMAD) draft-nomad-mobileip-filters-02.txt, July 2002. [6] H. Soliman, K. El Malki, C. Castelluccia, Per-flow movement in MIPv6 draft-soliman-mobileip-flow-move01.txt, IETF, November 2001. [7] NomadicLab, Ericsson, Available from
[16]
591
generation wireless data networks, IEEE Pers. Commun. 7 (4) (2000) 34–41. R. Ramjee, T. La Porta, S. Thuel, K. Varadhan, HAWAII: A domain-based approach for supporting mobility in widearea wireless networks, in: Proceedings of the International Conference on Networking Protocols (ICNP), Available from
Su¨leyman Altuntasß was born in Isparta, Turkey. He received his B.Sc. (High Hons.) and M.Sc. degrees in Electrical and Electronics Engineering from Bilkent University and Middle East Technical University, Ankara, Turkey, in June 1999 and January 2003, respectively. He is currently a Ph.D. student in Electrical and Electronics Engineering Department, Middle East Technical University, Ankara, Turkey. He also works as a software engineer in MilSOFT Software Technologies, Ankara, Turkey. His current research interests include next-generation wireless networks, distributed processing systems and middleware-centric systems.
Buyurman Baykal received his B.Sc. (High Hons.) degree in Electrical and Electronics Engineering from Middle East Technical University in 1990; M.Sc. (Distinction) and Ph.D. degrees in 1992 and 1995 from Imperial College of Science, Technology and Medicine, all in Electrical and Electronics Engineering. Dr. Baykal has research and teaching interests in speech processing, signal processing for telecommunications, and communication networks. He has extensive experience both in the theory and applications of adaptive signal processing techniques to communication applications such as acoustic echo cancellation, noise reduction, channel equalization and digital receiver design through self-conducted research and industry-funded research projects. He conducts research and implementation work on low bit rate speech coding and content based indexing of audio signals. He is also involved in
592
S. Altuntasß, B. Baykal / Computer Networks 47 (2005) 577–592
communication network research with particular interest in network design aspects, wireless networks and network management issues. Dr. Baykal is an Associate Editor of Computer Networks (Elsevier Science), Sensor Letters (American Scien-
tific Publishing), a past Associate Editor of the IEEE Transactions on Circuits and Systems Part II—Analog and Digital Signal Processing (TCAS-II). He authored and co-authored over 50 technical papers.