TECHNOLOGY PREREQUISITES FOR PROPOSED MOBILITY SOLUTION

Transcription

1 42 CHAPTER 3 TECHNOLOGY PREREQUISITES FOR PROPOSED MOBILITY SOLUTION 3.1 INTRODUCTION This chapter gives an overview of technologies that are relevant and complementary to the handover mechanism proposed in this thesis. The key technologies, used in the development of VHDMC, is based on the parameters from multiple layers of the protocol stack. Section 3.2 presents the overview of stream control transmission protocol (SCTP), and the most critical deficiencies of TCP. The two most important features of SCTP, mulihoming and mulistreaming are discussed in sections and respectively. Further, the capabilities and features of the new transport protocol SCTP that is pertinent to the work proposed, is described. SCTP dynamic address reconfiguration and SCTP partial reliability extension are also discussed. Section 3.3 introduces a new transport layer protocol for wireless channels based on SCTP, called Wireless SCTP Extension (WiSE). Also, the mixed wired and wireless simulation scenario for WiSE, SCTP and TCP protocol are given. Section 3.4 presents a description of Media Independent Handover Function (MIHF) and its standard IEEE It also illustrates the MIHF services such as Media Independent event Services, Media Independent Command Services and Media Independent Information Services, MIH protocol model and MIH Communication model. Finally a summary of each chapter has been presented.

2 STREAM CONTROL TRANSMISSION PROTOCOL (SCTP) Due to lower cost and simpler management requirements, IP networks are becoming increasingly popular for transporting voice and are steadily replacing the traditional Public Switched Telephone Network (PSTN). However, creating a successor to the PSTN is quite complicated as it is more than just transmitting voice streams, and also requires further signalling and service functionality. According to Ong et al(1999), the Signaling System #7 (SS7) network is a separate complementary network that transports all of the signalling, routing and billing information required by the PSTN in a reliable and timely manner. A similar mechanism is required for VoIP networks. Till the introduction of SCTP in 2000, IP networks employed either TCP or UDP for data transmission. UDP is a stateless and connectionless protocol with no support for re-transmissions making it unreliable and hence unsuitable for the transport of signaling messages. Originally, the IETF assessed the suitability of TCP as a transport protocol for telephony signaling messages. However, on further analysis, several short-comings have been identified. Among them, the most critical deficiencies are mentioned below: TCP provides byte-stream delivery, It means that the bytes are received exactly, in the same order as they are transmitted by the sender. Also, message boundaries are not maintained and therefore many applications need to do a message framing as they require a message-oriented delivery. Message-oriented deliveries maintain message boundaries by dividing the data into logically distinct units. TCP s strict byte-ordered delivery mechanism can cause significant delays due to packet loss or packets arriving out of sequence. This is known as Head of Line Blocking (HoLB). TCP is vulnerable to Denial of Service (DoS) attacks as a result of the way connection requests are handled. An attacker may send a flood of connection request messages from forged addresses. For each received request, the server creates a half open TCP connection, sending an acknowledgment packet and

3 44 waiting for a reply. As the source addresses are forged, no reply is ever received. The increasing number of connection requests eventually saturates the number of available connections at the server, thus preventing legitimate users from obtaining connection. TCP does not support multihoming, thus preventing it from having the redundancy required for high-availability applications such as telephony signaling. Unfortunately, since neither UDP nor TCP can meet the stringent delay and reliability requirements for the transport of signaling messages, another protocol is needed. Initially attempts were made to modify and enhance the performance of TCP to meet the various requirements. However, since it required significant and difficult changes, the idea was abandoned. This led to the development of SCTP. SCTP was proposed by the IETF in October 2000 as RFC2960 (Stewart et al 2000), and updated by RFC3309 (Stone et al 2002) and made obsolete by RFC4960 (Stewart 2007). A transport protocol was devised for telephony signaling messages which inherited many of the core features of TCP, such as congestion control and re-transmission while overcoming many of its limitations. During development, Ong and Yoakum (2002), Jr.Caro et al (2003) Fu and Atiquzzaman (2004) realized that SCTP could be used in other areas different from signaling and hence did not want to limit the scope of the protocol. With this in mind, SCTP was moved from the Signaling Transport (SIGTRAN) working group of the IETF to the Transport Area Working Group (TSVWG). SCTP is only the third transport layer protocol to be ratified by the IETF. Two of the most important features of SCTP are multihoming and multistreaming, both of which will be discussed in greater detail in Sections and Multihoming is the ability of an association to span multiple IP addresses. An association in SCTP is analogous to the manner in which IP addresses can be bonded to separate IP interfaces in a TCP connection. This allows a sender to

4 45 transmit through different IP addresses providing a high level of redundancy and fault tolerance. Multistreaming allows independent streams of data to be transmitted across a single association with no reliance on the delivery order of packets in other streams. Multi-streaming is used in SCTP to solve the TCP problem of HoLB that arises as a result of TCP s strict byte ordered delivery Multihoming Multihoming is a technique that helps to increase the redundancy and reliability of a network connection by allowing each host to have two or more network layer connections. Figure 3.1 Multi-Homed SCTP Host

5 46 Unlike TCP, SCTP offers native support to multi-homing by allowing a host to bind multiple IP addresses to a single association, an example of which is shown in figure 3.1. In this example, each endpoint has two physical links and the two network layer interfaces are bound to a single association. When an association is setup between a client and server, the client informs the server of all the IP addresses through which it is reachable using the INIT chunk address parameters. Likewise, the server informs the client of all its IP addresses by specifying them in the INIT-ACK chunk. If no addresses are specified in the address parameter, the source address of each chunk is used. During setup, one of the IP addresses at each endpoint is defined as the primary address. All communication to that endpoint is routed to its primary address, until a failure is detected or an upper layer specifically requests the use of an alternate IP. If a path failure is detected, SCTP will redirect traffic to an alternate address specified in the association, if available. Although the multihoming ability of SCTP is currently used only for redundancy and failover, some work has been done by Casetti and Gaiotto (2004), Iyengar et al (2006) on allowing load balancing and concurrent multipath transfer to increase performance Path monitoring - The SCTP heartbeat mechanism Each SCTP endpoint has a list of one or more peer endpoint IP addresses, however only one of these addresses, the primary address, is used to send and receive data. During this period, the SCTP maintains a list of the reachable state of each of the alternate peer endpoint addresses. This is done using a keep alive mechanism known as the heartbeat mechanism. A control data chunk called a heartbeat chunk is sent periodically every heartbeat interval, the interval being a user/application definable time. When a heartbeat chunk is received by an endpoint, the packet is processed and a heartbeat acknowledgment chunk is sent back. Each heartbeat chunk contains a time stamp of when it was

6 47 sent. The time difference between transmission and receipt of the acknowledgment can be used to estimate the Round Trip Time (RTT) between the endpoints. If six consecutive data or heartbeat chunks timeout without being acknowledged, that peer address is marked as being unreachable and an alternate address is dynamically selected. If the peer address belongs to the primary, this process is known as failover Multistreaming Multistreaming allows a single association to be broken up into a number of unidirectional channels, with data within one stream being handled independent of all other streams. Data order is preserved within each stream using Stream Sequence Number (SSN). This means that HoLB can occur within each unique stream. However, between streams, no order is preserved and the congestion control is managed on a per destination basis allowing SCTP to avoid the HoLB problem of TCP by re-transmitting lost packets into an alternate stream. Figure 3.2 shows an example of a multistreamed association. Two streams exist between Host A and B while only one exists between Host B and A. The number of streams in both directions is negotiated during association setup with each stream being identified using a Stream Identifier (SI). An example of application of SCTP multistreaming is in web browsing. Each object within a webpage can be transmitted via a different stream. This eliminates HoLB of any particular object from interferring with other webpage objects, thereby speeding up transfer.

7 48 Figure 3.2 Multistreamed SCTP Association SCTP Packet Format SCTP packets are made up of an SCTP common header followed by data units known as chunks. The header specifies validation and association parameters, whereas SCTP chunks carry the control information and user data. The basic SCTP packet structure is shown in Figure 3.3. The source header element of an SCTP packet is made up of the following parts: Source and Destination Port Numbers - These specify both the sender and receiver endpoint SCTP port numbers. Used in conjunction with the IP addresses of each endpoint, they are used to uniquely identify the particular association to which a packet belongs. Verification Tag - This value is used to ensure that a packet belongs to the current incarnation of an association, preventing stale packets from being accepted as part of the existing association. They also provide a certain level of security, preventing an attacker from injecting data into an existing association using IP address spoofing.

8 49 Checksum - The checksum provides a transport layer check of data integrity covering the SCTP common header and all the chunks within the packet. SCTP chunks act as the building blocks of an SCTP packet, with each chunk being self contained and of uniform size and format. This approach allows a single SCTP packet to carry multiple data and control chunks with the only restriction in packet size ie, the Maximum Transmission Unit (MTU) of the path. Each chunk must have a uniform size of 32 bits and any chunk exceeding the 32 bit boundary must be padded to the next 32 bit word boundary. As shown in Figure 3.3, each chunk must specify a chunk type. A total of 256 different chunk types can be specified with only 16 types defined in the standard SCTP, leaving 240 that may be used to extend SCTP's functionality. A few examples of the most common chunks are shown in Table 3.1. Table 3.1 Example SCTP Chunk Types Chunk Type 0x00 0x01 0x04 Chunk Name DATA INIT HEARTBEAT Description Carries User Data. Used to initialise an SCTP association, INIT-ACK chunk expected in response. A keep alive chunk periodically sent to Alternative addresses specified in an association. Expects a HEARTBEAT-ACK in response.

9 50 Figure 3.3 SCTP Packet Format SCTP - Dynamic Address Reconfiguration In the original variant of SCTP, the primary IP address can be changed to an alternate address only if it is included in the set of available addresses exchanged during association setup. Therefore, a node must have an IP address with any network in advance that it may potentially connect to. Clearly this would not be the case for a wireless mobile node. To address this, the Dynamic Address Reconfiguration (DAR) extension to SCTP was developed (Stewart et al 2007). Using DAR, addresses can be dynamically added and deleted from an association. To accomplish this, DAR extension defines a new chunk type called an ASCONF chunk. The ASCONF chunk contains an IP address and a parameter specifying whether the IP is to be added, deleted or changed to be the primary. This chunk can be transmitted by either endpoint to inform its peer of IP addresses through which it is reachable. On reception of an ASCONF chunk, the receiver must respond with an ASCONF-ACK chunk on

10 51 successfully carrying out the change specified in the ASCONF chunk. This process can be done dynamically during an active association and is a key feature for allowing SCTP to be used in a mobile environment SCTP - Partial Reliability Extension Although basic SCTP without any extensions can support randam message delivery, it is not suitable for the transport of real time applications such as VoIP. This is due to the TCP based re-transmission mechanisms, which can lead to a head of line blocking on a per stream basis, thereby resulting in unacceptable delays. An extension to SCTP called PR-SCTP by Stewart,R., et al (2004) eliminates this problem by allowing SCTP to provide varying levels of reliability to upper layer protocols (provided that both endpoints support the extension). The PR-SCTP extension allows SCTP to provide UDP-like packet delivery while preserving the TCP friendly congestion control mechanisms of SCTP. To achieve this, PR-SCTP allows the sender to specify a Time-to-Live (TTL) parameter on a per message basis. The TTL parameter defines the duration for which the sender should attempt to transmit the message. If the TTL parameter expires before the message has been acknowledged, the SCTP drops the message and stops re-transmission. Essentially, PR-SCTP allows the sender to define how persistent the transport layer will be at attempting to deliver each message. In standard SCTP, the cumulative ACK point of a receiver is moved forward only when new data is received. However as PR-SCTP allows packets to be abandoned, further signaling is required. When the TTL parameter of a packet expires, the sender must inform the receiver to move its cumulative ACK point forward so that the packet will not be reported missing in future acknowledgments. This is done using a new chunk type, called a Forward-TSN chunk. This allows a sender to signal the receiver in order to adjust the cumulative ACK point forward without receiving new data. This extension allows SCTP to support real time applications with congestion control but

11 52 without suffering from the delays caused by HoLB that normally make TCP and standard SCTP unsuitable for such applications. 3.3 WIRELESS SCTP EXTENSION (WiSE) A new suite of protocols that handles multihoming is being worked upon by the IETF, featuring the Stream Control Transmission Protocol (SCTP). SCTP can deal with multiple interfaces and it inherits from TCP its congestion control scheme; unfortunately, it also inherits TCP's limitations when dealing with unreliable, highly variable radio channel conditions. Aiming at overcoming these limitations and developing a multihomed transport layer protocol for wireless channels, Fracchia et al (2007) proposed a new transport layer protocol based on SCTP and called it WiSE (Wireless SCTP Extension). The basic idea of WiSE is, to combine a new improved congestion control and the multihoming feature to optimize resource utilization while guaranteeing service continuity. The WiSE congestion control mechanism discriminates losses due to congestion from losses due to channel conditions and reacts accordingly by properly reducing the generated traffic only when needed, i.e., when congestion is detected. A modification of the SCTP multihoming capabilities allows WiSE to better exploit the various available resources, so that the network performance and the quality of service can be improved. The results presented in the paper prove that WiSE is a promising alternative to existing transport layer protocols and can help in deploying networks that exploit the co-existence of multiple access technologies, to the end user, both efficiently and transparently. New, improved versions of SCTP have been proposed in several multihoming/multipath scenarios. These approaches can be classified in to two categories: best path selection and load splitting over multiple paths. Kashihara et al (2004), provides an interesting approach to best path selection using packetpair bandwidth estimation and Round Trip Time (RTT) measurements an approach which is similar in spirit to the proposed one. According to Ma et al

12 53 (2004), multihoming is to be applied within a UMTS/WLAN overlay architecture to improve throughput performance. It can also be successfully used by a mobile station to exploit an association over multiple WLANs at the same time, reducing the latency caused by a handoff that Meriem Kassar et al (2008) showed to be around ms. Approaches based on load balancing aim at splitting the load of a connection among the available paths, possibly involving different access technologies. Initially, studied by Iyengar (2004) within the framework of standard SCTP, load splitting is further investigated in Argyriou and Madisetti (2004), where an RTT comparison algorithm is used to replace the simplistic timeout-based selection used by a standard SCTP. A refined solution, implementing path monitoring through loss rate and delay, is explained by El Al et al (2004). Shi et al (2004) propose a similar SCTP load sharing enhancement: Load is split among different paths according to the congestion window, loss probability, and RTT on each path, while bandwidth estimation and delivery time prediction are shown by Fiore and Casetti (2005) to be a viable approach for load balancing with minimal reordering delay. Finally, Guo et al (2004) describes the design space of multihoming load balancing systems and also discusses the tradeoffs involved in load balancing and fail-over implementation strategies, presenting quantitative performance measurements collected on a commercial multihoming load balancing system. Essential to SCTP modifications in multihoming scenarios (for both the best path selection and the load splitting over multiple paths approaches) is, the splitting of congestion control functions and variables over each path: Some architectural changes have already been identified in a paper by Guanhua et al (2004). WiSE and SCTP experiments are run on the two-path topology in the right part of Figure 3.4. Every wireless station is connected to the Internet via two different APs, thus exploiting multihoming. At the beginning of each simulation, path #1, reported in the figure for one station, is chosen as the primary path. However, it could become the secondary path later on. TCP experiments are run on the single-path topology in the left part of Figure 3.4, since TCP cannot handle multiple interfaces.

13 54 Figure 3.4 Mixed wired-wireless simulation scenario for WiSE, SCTP, and TCP protocols 3.4 MEDIA INDEPENDENT HANDOVER FUNCTION The IEEE working group recently finalized the first standard for dealing with handovers in heterogeneous networks, also called Media- Independent Handovers (MIH). The standard IEEE (A3.7) 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 within the range and executing intelligent heterogeneous handovers, based on their respective capabilities and current link conditions. After introducing the IEEE reference model, the MIH services and examples that highlight the benefits of employing the Media-Independent Handover Services standard in heterogeneous networks, are presented. Considering the diversity of networked applications using mobile devices, knowledgeable network resource planning and operation is needed, calling for a framework that allows users 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 clients can use the

14 55 cellular network or WLAN access on demand. Currently, this process can only be done manually: users have to search for available access networks and choose which one to attach, 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 within range and were given the means to control their network connectivity, then a wide range of possibilities would have been 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 handoff decision-making processes, such as, say, mobility managers. Mäkelä and Pentikousis (2007) have proposed several cross-layer frameworks for enhancing the efficiency of handover decision makers, but none of them has been formally standardized or widely accepted so far. What is needed is, a standard framework that attract ample support from major vendors and operators, and which can be deployed incrementally Introducing IEEE Figure 3.5 illustrates the development of the IEEE standard. The working group was initiated in 2004 (A3.9) and the latest draft version of the standard was accepted as a new standard by the IEEE-SA Standards Board in November The standard was published in January It is anticipated that actual deployment of the standard will take place at the earliest in late

15 56 Figure 3.5 Timeline of the IEEE Standardization Effort IEEE , 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 IEEE Reference Model IEEE facilitates a variety of handover methods, including both hard handovers and soft handovers. A hard handover, also known as "breakbefore-make" handover, typically implies an abrupt switching between two access points, base stations, or, PoAs. Soft handovers require the establishment of a connection with the target PoA, while still routing the traffic through the serving PoA. In soft ("make-before-break") handovers, mobile nodes remain briefly connected with two PoAs. It should be noted, 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 pre-buffering can be accommodated during the 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.

16 57 The main design elements of IEEE can be classified into three categories: (i) a framework for enabling transparent service continuity while handing over between heterogeneous access technologies (ii) a set of handover-enabling function and (iii) a set of Service Access Points (SAPs) Framework for enabling transport service IEEE specifies a framework that enables transparent service continuity while a mobile node switches between heterogeneous accesses technologies. The consequences of a particular handover need to be communicated and considered early in the process, 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 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 to the network selecting an entity that prevents a planned handover. On the other hand, increasing delay, jitter, or packet-loss rates in the currently serving network, may degrade the QoS throughout the network.

17 58 IEEE also allows for the reception of dynamic information about the performance of the serving network and other networks in the given range. In other words, IEEE provides methods for the continuous monitoring of available access conditions. However, IEEE does not specify any methods for collecting this dynamic information at the link layer Handover enabling functions IEEE 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. 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 point SAPs with associated primitives between the MIHF and MIHUs (MIH_SAP) give MIHUs access to the following services that the MIHF provides: The Media-Independent Event Service (MIES) provides event reporting, for example, dynamic changes in link conditions and also provides event reporting on the link status, and link quality. Events can be both local and remote. Remote events are obtained from a peer MIHF entity.

18 59 The Media-Independent Command Service (MICS) enables MIHUs to manage and control the parameters related to link behavior and handovers. MICS provides a set of commands for accomplishing this, which are given in section Commands can be both local and remote. The information obtained with MICS is dynamic. The Media-Independent Information Service (MIIS) allows MIHUs to receive static information about the characteristics and services of the serving network and other available networks in the given range. This information can be used to make decision on which handover target to be chosen and also to make preliminary preparations for a handover. Figure 3.6 illustrates the general features of IEEE , which 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, , , and (A3.8)), as well as those defined by the Third- Generation Partnership Project (3GPP) and Third-Generation Partnership Project 2 (3GPP2 (A3.10)). Besides these, IEEE specifies a media-independent SAP (MIH_NET_SAP), which provides transport services for Layer 2 (L 2 ) and Layer 3 (L 3 ) MIH message exchange with remote MIHFs. Functions over the LLC_SAP are not specified in IEEE

19 60 Figure 3.6 The IEEE Reference Model Figure 3.7 represents the direction of messages 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. Figure 3.7 MIHF Services

20 61 Figure 3.8 illustrates an example topology where different wireless networks overlap. Imagine that the multi-access mobile device user watches a high bit-rate IPTV channel as he/she moves in this area. Three wireless access technologies are considered in this example: Wi-Fi (IEEE ), WiMAX (IEEE ), and 3G/UMTS (3GPP). In this example, it is assumed that all networks and the mobile device are IEEE compatible and that the Wi-Fi area is covered by several PoAs, as would be the case in a campus- or citywide deployment. Figure 3.8 Example Topology with Heterogeneous Overlapping Wireless Access Networks 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.7. The responses to Link commands are sent to MIHUs as indications. MIHUs can use command services to determine the status of

21 62 different links in a uniform manner, and can control each interface accordingly, aiming for optimal connectivity. MICS defines the following set of commands that enable MIHUs to configure, control, and obtain information from the lower layers: MIH commands can be directed to lower layers residing at both local and remote MIHF entities. They originate from the upper layers and are directed towards the MIHF. Similarly, with MIH events, MIH commands can be both remote and local. MIH commands are typically used for network selection and handover management because they allow the upper layers to initialize, prepare, and execute handovers. MIH commands are also used to configure custom thresholds for link parameters. As mentioned previously, when set thresholds are crossed, MIHUs get the corresponding notifications through Link Parameter events. Link commands originate from the MIHF and are sent to lower layers in order to control their operation. Link commands can be issued only locally. Nevertheless, Link commands can be executed on behalf of local MIHUs, which could act on information received from a remote peer. Link commands are often initiated by MIHUs. For example, an MIHU can issue the command MIH_Get_Link_Parameters, which when received by the local MIHF will lead to the generation of a remote Link_Get_Parameters Link command. In this way, the MIHF can acquire the current parameter values of active link(s) for MIHU, and then deliver this information to the requesting MIHU. Note that MICS provides dynamic information about different link parameters, in contrast with MIIS, which is described in the next section, which can report only static information. 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

22 63 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 and is classified into three groups: General Information and Access Network-Specific Information; PoA-Specific Information; and Other Information, which includes vendor- and networkspecific 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, details of connection establishment (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 the PoA available in the access network and location of the PoA and its address, supported data rates, PHY and MAC layer types, and channel parameters that can optimize link layer

23 64 connectivity. Some additional information related to higher-layer services and individual capabilities of particular PoAs may also be included. 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.7). An MIHF could have access to an information server in its IEEE 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 is directed to the peer MIHF, residing in the visited PoS, which can then access the visited PoS information server. Information queries can often be answered locally, based on the information gathered from previous queries and by pre-provisioning, from the information server. Information Elements and their relationships are captured in an Information Service scheme which, in turn, defines the information structure. IEEE specifies that information to be presented across different technologies should be in a standardized, common, and open format, such as XML or Type Length Value (TLV).

24 Service Management In order to use and provide MIHF services, MIHF entities need to be configured appropriately. IEEE 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 beacons, or mediaindependent 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 network entity. In this case, only the IEEE network entity addressed should respond to these request messages. MIH registration is a symmetric procedure by which two peer MIHFs authenticate and 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-

25 66 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. It should be noted that event sources may not be necessarily capable of providing all the 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 MIH 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 3.9 illustrates the MIH protocol header indicating the corresponding bit length for each field in parentheses.

26 67 Figure 3.9 MIH Protocol Header The Version field in the MIH frame header specifies the version of the MIH protocol used. The two Ack fields are for acknowledgment purposes. 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. It might be recalled 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 which MIHF service class (MIES, MICS, MIIS, or Service Management) that the particular message belongs to. The Operation code (Opcode) specifies whether the message is a request, response, or indication. The Action Identifier (AID) is related to 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.

27 68 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 acknowledgment. The payload part contains service-specific messages encoded in TLV format. The first two TLVs in the payload part (not shown in Figure 3.9) should be the Source Identifier and Destination Identifier, which are of the same data type as the MIHF ID. Every MIHF must have a unique MIHF ID, which may be assigned to it at the time of configuration. 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 3.10 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 exchange. Figure 3.10 MIH Protocol Frame Structure The sender MIHF can set the ACK-Req field to instruct the receiver to return an acknowledgment with ACK-Rsp bit set. The MIH Message ID and Transaction ID must be the same in the request message and its acknowledgment. An acknowledgment message may carry no payload. It has to be noted that, despite employing these two ID fields, the MIH protocol does not

28 69 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 SUMMARY In this chapter, an overview of technologies pertinent to the seamless mobility solution proposed in this thesis was given. Specifically, an overview of SCTP, WiSE and MIHF was presented because the proposed solution leverages these technologies. The most critical deficiencies of TCP and UDP and the problems associated with using TCP were also mentioned. Transport layer protocols, SCTP and WiSE were discussed, giving particular emphasis to the multihoming and multistreaming capabilities. Finally, MIHF and its services, protocols and handover execution principles were discussed. Certain aspects of the technologies discussed in this chapter are again discussed in section 4.3 as they relate to the design and implementation of Vertical Handoff Decision Making Controller (VHDMC). VHDMC uses the multihoming features of WiSE to provide a seamless handover mechanism for calls in heterogeneous wireless networks.