by Esa Piri and Kostas Pentikousis, VTT Technical Research Centre of Finland
Popular mobile devices now ship with several integrated wired and wireless network interfaces. Personal Digital Assistants (PDAs) and smartphones, for example, are increasingly supporting communications through both cellular technologies and Wireless LANs (WLANs); laptops typically come with built-in Ethernet, Wi-Fi, and Bluetooth . As multiaccess devices proliferate, we move closer to a network environment that is often referred to as "beyond 3G" (B3G). Key success factors for cellular third-generation (3G) communications include better cell capacities, increased data rates, transparent mobility within large geographical areas, and global reachability. For B3G, the next frontier lies beyond transparent mobile connections within the same access technology because users will expect to be globally reachable anytime, anywhere, and remain "always best-connected" (ABC) . In order to select the best possible connectivity option (anytime, anywhere), mobile devices and access networks will have to work together in order to enable users to take full advantage of all available options.
The IEEE 802.21 working group (see www.ieee802.org/21) recently finalized the first standard for dealing with handovers in heterogeneous networks, also called Media-Independent Handovers (MIH) . The standard is expected to allow mobile users (and operators) to take full advantage of overlapping and diverse access networks. It provides a framework for efficiently discovering networks in range and executing intelligent heterogeneous handovers, based on their respective capabilities and current link conditions. This article aims to serve as a primer for those interested in the IEEE 802.21 standard. After introducing the IEEE 802.21 reference model, we present the MIH services and provide illustrative use cases that highlight the benefits of employing the Media-Independent Handover Services standard in heterogeneous networks.
Mobile and Wireless
The widespread success of 3G technologies [4,5] is evidenced by the rapid increase in the amount of data traffic over cellular networks in recent years. In Sweden, for example, the total amount of mobile data traffic leapt tenfold from just over 203 TB in 2006 to 2191 TB in 2007 . This trend is expected to continue unabated with the deployment of High-Speed Packet Access (HSPA) and Long-Term Evolution (LTE) in the coming years. Of course, the amount of traffic over cellular networks is only a proportion of the traffic that originates from or terminates at WLANs worldwide. Campuswide deployments of WLANs are becoming the norm in developed countries, and we even find citywide WLANs, as in the case of the city of Oulu, Finland (see www.panoulu.net).
Finally, many anticipate that mobile WiMAX  deployments will significantly affect telecommunications markets. In short, we are moving toward a far more heterogeneous network access environment than the one users and operators face today, with multiple overlapping mobile and wireless networks with diverse characteristics.
Multiaccess Devices in Heterogeneous Networks
As communication environments become more complex because of the diversity of network access technologies that support, for example, different access rates and Quality of Service (QoS) levels, users expect more from their wireless operator. Mobile devices, once featuring tiny screens, extremely limited processing and storage capacities, and narrowband connectivity , now pack capabilities that just a few years ago were typical of high-end laptops. This scenario has allowed users to increasingly depend on mobile devices for e-mail and Instant Messaging (IM), but also for making Voice over IP (VoIP) calls, listening to streaming Internet radio, and watching online videos.
With respect to user mobility patterns, campuswide Wi-Fi users typically spend most of their connection time attached to a small set of access points located within a small radius [9,10]. This situation is not surprising, because Wi-Fi was originally designed and subsequently deployed mainly as an extension to wired infrastructures. In the future, however, we anticipate that multiaccess devices will employ different network interfaces to attach to different access networks, establishing multiple parallel connections over 3G/Universal Mobile Telecommunications Service (UMTS) and Wi-Fi, for example. With global reachability and ABC mechanisms in place, mobile devices will be able to selectively connect to different access networks depending on certain criteria. Keep in mind that from a conventional, IP-centered point of view, changing the Point of Attachment (PoA) calls for mobility management actions [11,12,13], although in practice there may be no physical mobility whatsoever.
Given the diversity of networked applications running on mobile devices, knowledgeable network resource planning and operation is needed, in turn calling for a framework that allows users and their applications to state their network access preferences. This framework should also allow operators to steer terminal access patterns aiming at maximizing resource usage and increasing user satisfaction. For instance, podcasts can be downloaded only when connected to an uncongested WLAN, but web, map/navigation, and e-mail clients can use the cellular network or WLAN access on demand. Currently, this process can only be done manually: users need to be watchful for available access networks and choose which one to attach to based on very rudimentary information such as signal quality. If mobile nodes could collect timely and consistent information about the state of all available networks in range and were given the means to control their network connectivity, then a whole range of possibilities would become available.
In order to optimize the use of available network resources, mobile nodes need to be able to collect information about numerous heterogeneous networks in a generic and standardized way, irrespective of the underlying network access technology. The collected information, both dynamic and static, can then be used by handover decision-making processes, such as, say, mobility managers. Mobility managers can be enhanced versions of Mobile IP (MIP) [11,12,13], proprietary solutions, or other proposals stemming from recent research, such as . Researchers in the area have proposed several cross-layer frameworks for enhancing the efficiency of handover decision makers (see [14,15] and the references therein), but none of them has been formally standardized or is widely accepted so far. What is needed is a standard framework that can attract ample support from major vendors and operators, and can be deployed incrementally.
Introducing IEEE 802.21-2008
Figure 1 illustrates the progress toward the IEEE 802.21-2008 standard. The working group was initiated in 2004, and the latest draft version of the standard was accepted as a new standard by the IEEE-SA Standards Board in November 2008 . The standard was published in January 2009. It is anticipated that actual deployment of the standard will take place at the earliest in late 2009–2010.
IEEE 802.21-2008, also known as Media-Independent Handover Services, features a broad set of properties that meet the requirements of effective heterogeneous handovers. It allows for transparent service continuity during handovers by specifying mechanisms to gather and distribute information from various link types to a handover decision maker. The collected information comprises timely and consistent notifications about changes in link conditions and available access networks.
Note that the scope of IEEE 802.21-2008 is restricted to access technology-independent handovers. Intratechnology handovers, hand- over policies, security mechanisms, media-specific link layer enhancements to support IEEE 802.21-2008, and Layer 3 (L3) and upper-layer enhancements are outside the scope of IEEE 802.21-2008. This article summarizes the salient points of , which henceforth is referred to as IEEE 802.21.
The IEEE 802.21 Reference Model
IEEE 802.21 facilitates a variety of handover methods, including both hard handovers and soft handovers. A hard handover, also known as "break-before-make" handover, typically implies an abrupt switch between two access points, base stations, or, generally speaking, PoAs. Soft handovers require the establishment of a connection with the target PoA while still routing traffic through the serving PoA. In soft ("make-before-break") handovers, mobile nodes remain briefly connected with two PoAs. Note, however, that depending on service requirements and application traffic patterns, hard handovers may often go unnoticed. For example, web browsing and audio/video streaming with prebuffering can be accommodated when handing over between different PoAs in the range of one network by employing mechanisms that allow transferring the node connection context from one PoA to another quickly.
The main design elements of IEEE 802.21 can be classified into three categories: a framework for enabling transparent service continuity while handing over between heterogeneous access technologies; a set of handover-enabling functions; and a set of Service Access Points (SAPs).
Transparent Service Continuity
IEEE 802.21 specifies a framework that enables transparent service continuity while a mobile node switches between heterogeneous access technologies. The consequences of a particular handover need to be communicated and considered early in the process and, clearly, before the handover execution. In soft handovers, it is crucial that service continuity, during and after the handover, is ensured without any user intervention. To this end, IEEE 802.21 specifies essential mechanisms to gather all necessary information required for an affiliation with a new access point before breaking up the currently used connection. Interactive applications, such as VoIP, are typically the most demanding in terms of handover delays, and high-quality VoIP calls can be served only by soft handovers. On the other hand, video streaming can accommodate hard handovers, as long as the vertical break-before-make handover delay does not exceed the application buffer interval delay. In the case of hard handovers, handover preparation signaling can initiate the connection context transfer from the serving PoA to the target PoA beforehand.
For instance, lack of the required level of QoS support or low available capacity in a candidate access network may lead the network selecting entity to prevent a planned handover. On the other hand, for example, increasing delay, jitter, or packet-loss rates in the currently serving network may degrade the perceived QoS throughout the network, or only for a particular application, triggering the mobility manager to start assessing the potential of candidate target access networks and subsequently initiate an IEEE 802.21-assisted handover.
IEEE 802.21 also allows the reception of dynamic information about the performance of the serving network and other networks in range. In other words, IEEE 802.21 provides methods for continuous monitoring of available access conditions. However, IEEE 802.21 does not specify any methods for collecting this dynamic information at the link layer.
IEEE 802.21 defines a set of handover-enabling functions, which are specified with respect to existing network elements in the protocol stack, and introduces a new logical entity called Media-Independent Handover Function (MIHF). The MIHF logically resides between the link layer and the network layer. It provides, among others, abstracted services to entities residing at the network layer and above, called MIH Users (MIHUs). MIHUs are anticipated to make handover and link-selection decisions based on their internal policies, contextÃ‚Â¸ and the information received from the MIHF. To this end, the primary role of the MIHF is to assist in handovers and handover decision making by providing all necessary information to the network selector or mobility management entities. The latter are responsible for handover decisions regardless of the entity position in the network. The MIHF is not meant to make any decisions with respect to network selection.
Service Access Points
SAPs with associated primitives between the MIHF and MIHUs (MIH_SAP) give MIHUs access to the following services that the MIHF provides:
Figure 2 illustrates the general reference model of IEEE 802.21. The scope of IEEE 802.21 includes only the operation of MIHF and the primitives associated with the interfaces between MIHF and other entities. A single media-independent interface between MIHF and MIHU (MIH_SAP) is sufficient.
On the other hand, there is a need for defining a separate technology-dependent interface, which is specific to the corresponding media type supported, between the MIHF and the lower layers (MIH_LINK_SAP).
The primitives associated with the MIH_LINK_SAP enable MIHF to receive timely and consistent link information and control link operation during handovers. For example, the currently supported link layers include wired and wireless media types from the IEEE family of standards (for example, 802.3, 802.11, 802.15, and 802.16), as well as those defined by the Third-Generation Partnership Project (3GPP) and Third-Generation Partnership Project 2 (3GPP2). Besides these, IEEE 802.21 specifies a media-independent SAP (MIH_NET_SAP), which provides transport services for Layer 2 (L2) and Layer 3 (L3) MIH message exchange with remote MIHFs. Functions over the LLC_SAP are not specified in IEEE 802.21.
Figure 3 presents the messages directions of each MIHF service class, including both local and remote events and commands. The MIHF can subscribe to particular sets of events from a peer MIHF. Remote commands are initiated by local MIHUs and are conveyed to the peer MIHF through the local MIHF. Finally, MIIS information can be obtained through queries to the local database and to remote Information Servers.
IEEE 802.21 Illustrated
Figure 4 illustrates an example topology where different wireless networks overlap. Imagine that the multiaccess mobile device user watches a high-bitrate IPTV channel as she moves in this area. Three wireless access technologies are considered in this example: Wi-Fi (IEEE 802.11), WiMAX (IEEE 802.16), and 3G/UMTS (3GPP). In this example, we assume that all networks and the mobile device are IEEE 802.21-compatible and that the Wi-Fi area is covered by several 802.11 PoAs, as would be the case in a campus- or citywide deployment.
Figure 5 illustrates the network access environment as perceived by a mobile device in the area. The figure depicts three snapshots, indicating the overlapping networks in range at different locations. In order to deliver the IPTV stream transparently, for each of the available access networks we need to consider their effective available bandwidth, the associated cost per traffic unit, the terminal speed, the cell coverage area, the level of QoS support it can provide, and so on. Using information made available through the MIHF, we can determine which should be the next target access network.
In Phase I, the mobile node has two network access options. It can use a free and open Wi-Fi network or connect to the cellular operator's 3G/UMTS network. Note that opting to use the latter may, for instance, depend on the charging scheme of the operator. If subscribers pay based on traffic volume, one would assume that the free Wi-Fi network is a better option. On the other hand, as flat-rate plans become more popular, 3G may be a better option with its extended coverage and QoS guarantees. The IEEE 802.21 MIIS can provide this type of information, allowing for automation in dynamic access selection.
In Phase II, as the user moves, the device goes through a cellular technology handover from 3G/UMTS to Enhanced Data rates for GSM Evolution (EDGE) . At the same place, the public Wi-Fi network is still available and a new WiMAX network has just been detected. Assume that EDGE is not sufficient for delivering the IPTV stream. If in Phase I the network selection process opted for using the cellular network, then in Phase II the client application will experience significant degradation in service if it continues to use the EDGE access network. A vertical handover to the Wi-Fi or the WiMAX network should be considered. In contrast, if the mobile node first chose to stream the IPTV channel over the Wi-Fi access network, then it may need to reassess the situation based on events and link parameter reports using MIES and MICS, as we explain in the following sections. For example, an information query can reveal whether the WiMAX network is operated by a partner Internet Service Provider (ISP), and what the roaming cost would be.
Finally, in Phase III, the coverage area of the public Wi-Fi network ends. Through IEEE 802.21 services we find out that the only available networks are the roaming partner WiMAX and the home cellular network that is now offering 3G service.
The environment with several overlapping networks described previously and illustrated in Figures 4 and 5 is already a reality today in many places, and it is widely anticipated to be prevalent in the future. Next, we examine the three services defined by IEEE 802.21, namely MIES, MICS, and MIIS.
Media-Independent Event Service
Events indicate or predict changes in the state and transmission behavior of physical, data link, and logical link layers. In general, events are triggers for initiating candidate network discovery and handover procedures. The events defined in IEEE 802.21 are categorized as either Link Events or MIH Events, depending on their origin. Link events emanate from the link layers, whereas MIH events emanate from the MIHF and can be both remote and local. Local events propagate from lower layers to upper layers through the MIHF. Remote events occur at the protocol stack of another network entity and are transmitted from a peer MIHF to the local MIHF, as illustrated in Figure 3.
The Media-Independent Event Service (MIES) currently supports five types of events: MAC and PHY State Change events, Link Parameter events, Predictive events, Link Handover events, and Link Transmission events. A short introduction to the event types and corresponding events follows.
MAC and PHY State Change events correspond to state changes in MAC and physical (PHY) layers. The most characteristic events in this category are Link_Up and Link_Down events, which are generated when a Layer 2 connection with an access point is established or is torn down, respectively. Another event, called Link_Detected, indicates that a PoA has been detected but no affiliation is established yet.
Link Parameter events relate to changes in Layer 2 parameters. A Link_Parameters_Report can be sent when a MIHU has set thresholds for certain parameters. For example, a MIHU can set thresholds for the Received Signal Strength Indicator (RSSI) on IEEE 802.11 links, so that when a threshold is crossed proper action can be taken. A Link_Parameters_Report is also used for issuing periodical notifications about link conditions. Based on Link Parameter events, a MIHU can initiate the handover candidate discovery process, or trigger applications to adapt to changing link conditions.
Predictive events inform about the probability of dramatic (negative) changes in link characteristics in the near future. For example, if strong decay in signal strength is observed, this decay may indicate imminent loss of link connectivity. Predictive events may include temporal information about when the actual event is expected to occur and what its presumed likelihood is. A Link_Going_Down event, for instance, may trigger a MIHU to consider possibilities for handing over to other available networks in range.
Link Handover events indicate the occurrence of Layer 2 handovers. The Link_Handover_Imminent event serves as a notification for an imminent handover, whereas a Link_Handover_Complete event reports the successful change of PoA. These events emanate from the link layer and are based solely on local Layer 2 information.
Link Transmission events show the transmission status of individual higher-layer Protocol Data Units (PDUs) at the link layer. Upper layers can, for example, adapt to data loss during a handover by improving buffer management based on Link Transmission events. These events may allow future upper-layer implementations to identify lost packets and recover without waiting for the expiration of retransmission timers.
Currently, for example, in the case of an ongoing session over TCP, the occurrence of a handover may have dramatic effects in performance. With IEEE 802.21, MIHUs can be informed about individual packets that have already been delivered to the sending buffer of the MAC layer but were not successfully transmitted before the handover occurred. In other words, the MAC layer outgoing buffer may contain TCP segments that cannot be delivered through the wireless network to the peer at the other end of the TCP connection. These segments were not successfully delivered from the local Automatic Repeat-reQuest (ARQ) module over the first hop, but are still buffered and cannot be transmitted because there is no link connectivity. In this case, TCP could use the information from Link Transmission events that identifies which packets need to be resent through the new access network, as illustrated in Figure 6 for packet numbers 1 and 2. Note, however, that IEEE 802.21 does not define any identifier for reliable packet identification, only the size of the packet ID (2 bytes), and it is up to the implementer to determine how different messages will be locally identified.
Media-Independent Command Service
The Media-Independent Command Service (MICS) enables higher layers to control the stream of events originating from lower layers. Commands can originate from MIHUs (MIH commands) or from the MIHF (Link commands) and the destination can be the MIHF or any lower layer, respectively, as shown in Figure 3. The responses to Link commands are sent to MIHUs as indications. MIHUs can use command services to determine the status of different links in a uniform way, and control each interface accordingly, aiming for optimal connectivity. MICS defines the following set of commands that enable MIHUs to configure, control, and get information from the lower layers:
Media-Independent Information Service
The Media-Independent Information Service (MIIS) facilitates handovers through a unified set of mechanisms that the MIHF can use to discover and obtain static (or rarely changing) information about networks in the vicinity of a multiaccess node. In other words, MIIS allows mobile nodes to check for available networks in range while using their currently active access network. MIIS information exchange occurs at the link layer (Layer 2) or network layer (Layer 3), so that all necessary information related to link layer or higher-layer services is collected before a mobile node authenticates with a new PoA.
MIIS defines a set of Information Elements (IEs) that are indispensable for network selection, classified into three groups: General Information and Access Network-Specific Information; PoA-Specific Information; and Other Information, which includes vendor- and network-specific details. The types of information handled by MIIS are solely related to handover decisions and conformance to the affiliation with the new PoA. Information relevant for assessing candidate networks by the handover machinery includes connection establishment details, such as PoA address and location; which security mechanisms are supported in a given access network; and what QoS guarantees can be provided.
General Information Elements and Access Network-Specific Information Elements give a general overview of neighboring networks. Information Elements may include, for instance, a list of available networks and their associated operators, roaming agreements and costs, and security and QoS support. For instance, user policies, defined at higher layers, may dictate that if a given access network operator charges users based on their traffic volume, then the network selector entity should not consider the corresponding access when a high-bitrate service, such as IPTV, is active.
PoA-Specific Information Elements refer to each PoA available in the access network and report PoA location and addressing information, supported data rates, PHY and MAC layer types, and channel parameters that can optimize link layer connectivity. Some additional information related to higher-layer services and individual capabilities of particular PoAs may be included as well. For instance, an advanced mobility manager on the mobile node can use the information about the geographical position of a PoA and compare it with the current or expected node location based on its mobility patterns. With careful planning and by taking advantage of this information, mobile nodes may be able to reduce the number of handovers and optimize the use of network resources.
MIIS provides mechanisms for issuing and responding to queries for Information Elements. Such information may reside in a separate server or in a local information database at the mobile node (see Figure 3). An MIHF could have access to an information server in its IEEE 802.21-enabled Point-of-Service (PoS) range from which it can obtain information regarding the home PoS and possibly other PoSs, such as those of roaming partners. If the home information server is not able to provide any information regarding the visited network, an MIIS query can be directed to the peer MIHF, residing in the visited PoS, which can access the visited PoS information server. Information queries can often be answered locally, based on information gathered from previous queries and by preprovisioning, for example, from the information server.
Information Elements and their relationships are captured in an Information Service schema which, in turn, defines the information structure. IEEE 802.21 specifies that information that is to be presented across different technologies should be in a standardized, common, and open format, such as XML or Type Length Value (TLV).
In order to use and provide MIHF services, MIHF entities need to be configured appropriately. IEEE 802.21 defines three service management functions: MIH capability discovery, MIH registration, and MIH event subscription.
MIHF may discover other MIHF entities and their capabilities using the MIH capability discovery procedure. Depending on the information obtained from this procedure, the local MIHF can determine which peer MIHFs it should register with. The MIH capability discovery function uses the MIH protocol (introduced in the following section) at Layer 2 or Layer 3, and media-specific Layer 2 broadcast messages are allowed. For example, an MIHF can listen to media-specific broadcast messages, such as IEEE 802.11 beacons, or media-independent Layer 2 MIH_Capability_Discover broadcast messages, because an MIHF entity residing in the network may announce its existence and capabilities periodically. MIHF can also send MIH_Capability_Discover request messages using multicast or unicast to detect peer MIHFs in a solicited way. For instance, MIHF can send a request by unicast for obtaining the capabilities of a specific IEEE 802.21 network entity. In this case, only the IEEE 802.21 network entity addressed should respond to these request messages.
MIH registration is a symmetric procedure by which two peer MIHFs authenticate and can then communicate with each other in a more trusted manner. After MIH registration is completed, the two peer MIHF entities can symmetrically request services from their registered peer. Note that MIH registration is not necessary for obtaining some level of support from a peer MIHF. However, by registering and authenticating, peer MIHFs typically will get access to much more extensive information. That is, although the MIHF residing on the mobile node may be able to access information services from the network-side MIHFs without registration and authentication, the available information may be only a subset of that provided after authenticating.
Finally, MIH event subscription enables MIHUs to subscribe to a particular set of events provided by MIES from the local or peer MIHF. Event subscription from a peer MIHF requires registration and knowledge about its capabilities. The subscription contains only the list of events the MIHU is interested in. Note that event sources may not be necessarily capable of providing all events that the subscriber is interested in subscribing to. Each subscription request is matched by a confirmation message from the event source indicating the events approved for subscription.
Media-Independent Handover Protocol
The Media-Independent Handover Protocol (MIHP) specifies the rules and services for unified communication between peer MIHFs. The protocol defines the message format, header, and encoding format and is meant to be used solely for communicating with peer MIHF entities. For internal communication no particular encoding is dictated.
MIH protocol messages can be carried over Layer 2 management frames, Layer 2 data frames, or over Layer 3/IP transport. Note that cellular technologies do not provide Layer 2 transport without changes in their protocol stack.
The MIH protocol messages, or frames, comprise a header part and a TLV-encoded payload part. The MIHF frame header consists of eight octets. Figure 7 illustrates the MIH protocol header indicating the corresponding bit length for each field in parentheses.
The Version field in the MIH frame header specifies the version of the MIH protocol used. The two Ack fields are for acknowledgement purposes and are discussed later in the article. The Unauthenticated Information Request (UIR) flag indicates that the response message may be sent with a limited length because of the nature of unauthenticated message exchange. Recall that when an MIHF issues requests without registering first with its peer, it may receive less information than if it had registered earlier. If this flag is set, then the information included in the response message may not reflect the complete information available to registered MIHFs. The More Fragments (M) and Fragment Number (FN) fields are used in message fragmentation.
The MIH Message ID field comprises three subfields. The Service Identifier (SID) field indicates the MIHF service class (MIES, MICS, MIIS, or Service Management) that this message belongs to. The Operation code (Opcode) specifies whether the message is a request, response, or indication. The Action Identifier (AID) is related with and scoped by the SID. For instance, if the SID indicates MIES, AID points to the actual event type. The Variable Load Length field contains the total length of the variable, TLV-encoded payload carried by this message frame.
The MIH protocol messages use the Transaction ID and MIHF ID fields as identifiers, but only the former is included in the header. The Transaction ID field is an identifier that helps to match each request, response, or indication message with its acknowledgement.
The payload part contains service-specific messages encoded in TLV format. The first two TLVs in the payload part (not shown in Figure 7) should be the Source Identifier and Destination Identifier, which are both the same data type as the MIHF ID. Every MIHF must have a unique MIHF ID, which may be assigned to it at configuration time. The MIHF ID shall be invariant and could be, for example, a Fully Qualified Domain Name (FQDN) or Network Access Identifier (NAI). The MIHF ID is used during the MIH registration phase and is appended to the payload part of every message requiring endpoint identification. In broadcast messages, the Destination Identifier TLV is defined as zero length. Figure 8 shows the message structure consisting of the MIH Protocol header, source and destination identifiers, and service-specific TLVs. In TLV encoding, the Type field (1 octet) denotes the parameter type, the Length field (variable octets) indicates the length of the Value field, and the Value field (variable octets) carries the actual value of the parameter.
Acknowledging MIH messages is not mandatory. Still, the MIH protocol does support the use of acknowledgements to ensure reliable message exchange. The sender MIHF can set the ACK-Req field to instruct the receiver to return an acknowledgement with ACK-Rsp bit set. The MIH Message ID and Transaction ID must be the same in the request message and its acknowledgement. An acknowledgement message may carry no payload. Note, however, that despite employing these two ID fields, the MIH protocol does not specify any further mechanisms for reliable authentication or shielding message exchanges from third parties.
MIH Communication Model
The MIHF communication model specifies different MIHF roles and their communication relationships, such as supported transport mechanisms and service classes. The assigned MIHF roles depend on their location in the network. For example, an MIHF on a mobile node can communicate directly with network-side entities called MIH PoSs using Layer 2 or Layer 3 communication. MIH PoSs may include the serving PoA or candidate PoAs. Network-side MIHFs can communicate with each other at Layer 3 or above using the MIH protocol, introduced in the previous section.
Let us revisit the example use case of IEEE 802.21 illustrated in Figures 4 and 5. Figure 9 presents the IEEE 802.21 message exchanges in mobile- and network-initiated handover procedures in the case where the mobile node hands over from a Wi-Fi to the 3G cellular network (between Phase II and Phase III in Figure 5) and then hands over to a WiMAX network (Phase III in Figure 5). First, during the discovery of handover candidate PoAs, the mobile node MIHF employs MIIS to gather static information about the surrounding networks. The request is issued over the currently used Wi-Fi access. This information is obtained from the information server that may reside in a different network than the one currently in use.
After receiving the response to its Information Request, the mobile node initiates the handover process by querying about the availability of resources in the networks it is interested in. These requests are sent through the serving PoS (Wi-Fi-PoS in Figure 9), which disseminates the requests to the MIH PoSs of the candidate networks (3G-PoS and WiMAX-PoS in Figure 9). The response indicating the capabilities of the two candidate networks is returned to the mobile node MIHF from the serving PoS. After receiving this information, an MIHU on the mobile node decides which network to hand over to, based on policies and the output of its network selection algorithms. Then a Handover Commit Request message is sent, and after the candidate network has made its final commitment for the handover (and the appropriate resources are reserved successfully), the mobile node establishes a Layer 2 connection with the PoA in the area of the candidate PoS, that is, the 3G-PoS in our example case. Following this successful intertechnology handover, the resources used in the previous link can optionally be released. In the case where no resources are explicitly reserved, this step is skipped.
As we progress in the timeline of our example case, the network-side MIHU initiates a handover to the WiMAX network. This handover could be, for example, the result of observing congestion in the cellular network that indicates that a new PoS should be found for the mobile node. The serving PoS (3G-PoS) collects information about networks in the range of the mobile node from the Information Server. Upon determining that a suitable WiMAX candidate network that can serve the mobile node exists, the 3G-PoS triggers a network-initiated handover. First, the serving PoS requests permission from the mobile node to proceed with the handover. If the mobile node does not object, the serving PoS proceeds with the rest of the handover procedure, which is similar to the mobile-initiated handover described previously except that it is handled by a network entity.
As illustrated in the example, the handover decision and target assessment constitute a multiphase process where the assistance of IEEE 802.21 is essential. However, the actual handover execution is outside the scope of the standard. This section briefly describes how handovers can be carried out by MIP with the cooperation of IEEE 802.21. After choosing the target network by capitalizing on the IEEE 802.21 services, the mobile node establishes a new connection with the handover target network while still routing traffic through the currently serving network. The mobile node obtains a Care-of Address (CoA) for this new link from the IP address space of the target network. The CoA is an IP address assigned to the new link of the mobile node and is used while connected to the visiting network . With MIPv4, the CoA is provided by a Foreign Agent (FA) in the visited network, which also acts as a router for the mobile node . With MIPv6, the Foreign Agent is not needed  and the CoA is obtained directly, say, for example, from a Dynamic Host Configuration Protocol (DHCP) sever. The mobile node can obtain the IP address of the DHCP server in the target network through the IEEE 802.21MIIS.
In MIP, each mobile node has a Home Agent (HA), which routes the traffic of the mobile node. After successfully affiliating with a PoA in the target network, the mobile node notifies the Home Agent of the CoA by performing a binding update. In a bidirectional tunnel mode, the Home Agent establishes an IP-IP tunnel between the Home Agent and the Foreign Agent (MIPv4) or the Home Agent and the mobile node CoA (MIPv6). This mode does not require any binding updates on the Correspondent Node (CN). In other modes, either the uplink traffic of the mobile node is sent directly to the Correspondent Node using the CoA as source address, or all bidirectional communication between the Correspondent Node and the mobile node uses the CoA only. In the first case, traffic from the Correspondent Node to the mobile node travels through the Home Agent, but in the latter case there is no need for the Home Agent detour. However, these modes need address binding at the Correspondent Node and are in practice less frequently used than the bidirectional tunnel mode.
Figure 10 illustrates a situation where a link with the Wi-Fi PoA is broken down by the mobile node and the IPv6 traffic between the Correspondent Node and the mobile node, now employing IEEE 802.21-enabled 3G network, travels through the tunnel between Home Agent and the mobile node.
Layer 3 handover executions based on RFC 3344  and RFC 3775  may often exceed the typical handover delay budgets, thus introducing gaps in connectivity that are perceptible at the application layer. Recent standardization efforts have focused on decreasing handover delays by enhancing MIP so that it can provide for transparent mobility management for both IPv4  and IPv6 [17,18]. The proposed enhancements either reduce the amount of signaling or allow the mobile node to configure the new Layer 3 connection before reassociating with the new network. In this context, IEEE 802.21 can provide the essential information for preestablishing the connection based on media-independent Layer 2 link detection events as well as static address information from the target network.
Summary and Outlook
We presented an overview of the IEEE 802.21 Media-Independent Handover Services standard. We anticipate that its adoption in the near future will allow for better network resource usage and permit multiaccess devices to select the network access best suited for their communication needs. After motivating the needs for a standard to cope with heterogeneous network handovers, we introduced the IEEE 802.21 Reference Model and the MIH Services. We briefly presented the MIH Protocol, although a more thorough description calls for a separate overview article. Finally, we illustrated network operation when IEEE 802.21 is adopted using example use cases featuring both network- and terminal-initiated intertechnology (or vertical) handovers.
We expect that in the future, when IEEE 802.21-2008 is widely deployed, there will be significant efforts to further amend and extend it in order to provide for even better services. In fact, because security mechanisms are outside the scope of the base IEEE 802.21 standard, the work on defining a security-related extension to IEEE 802.21 (IEEE P802.21a) has already begun. Moreover, another amendment (IEEE P802.21b) that deals with handovers with downlink-only technologies, such as Digital Video Broadcasting (DVB), has also been introduced (see www.ieee802.org/21 for more information about the amendments). Nevertheless, it remains uncertain whether vendors will stand by this promising standard and incorporate it in future products and solutions.