LowMIPv6: A Framework for Mobile IPv6 for the Low Capable Ubiquitous Device Mustafa Hasan, Ali Hammad Akbar, Shafique Ahmad Chaudhry, Hamid Mukhtar and Ki-Hyung Kim Division of Information and Computer Engineering, Ajou University, Korea Email: {hasan. hammad, shafique, hamid, kkim86 }@ajou.ac.kr

Abstract Low capable device such as Wireless Sensor Network are becoming increasingly important because of their reduced cost and a range of real world military and other real world applications. IP connectivity to WSNs has enabled ubiquity of devices such as IP based Ubiquitous Sensor Networks (IP-USNs). Many exciting application make it more important to provide mobility beyond it local vicinity, which demands ubiquitous mobility. Definition of a framework for the mobility of such low power and constrained networks is a crucial problem. In this paper we have propose architecture for seamless mobility for the low capable devices with IPv6 connectivity, LowMIPv6. In that process, we have analyzed the possible ubiquitous mobility for those low capable devices with real scenario simulation. Thus we provided the framework, which is interoperable with all types of IP networks and is thus the first step towards Ubiquitous mobility.

1. Introduction IP enable low capable ubiquitous devices are a low cost, low power communication network that provides wireless connectivity in applications with relaxed throughput requirements. Considering the inherent low resources characteristics, providing mobility support to this kind of low capable devices brings in many new challenges, because the seamless mobility is a very resource taking function to work with. The signaling cost in mobility is not suitable for those low capable resource constrained devices. Thus it’s really important to design a mechanism with

very low signaling overhead to support those battery driven low power devices. Modern advances have enabled the Internet connectivity to the mobile nodes but the situation takes another shape when a partial or whole network moves together. Personal Area Networks and Body area networks are examples of such networks. Host mobility protocols like MIP and MIPv6 are not sufficient to handle network mobility because of two major reasons. First, all the nodes may not have enough resources to run these complex protocols. Second, handoff can make a lot of congestion for its network, especially in Ad-Hoc networks. This situation demands for new architectures for network mobility. In order to provide network mobility, deployment of an entity called Mobile Router (MR) [5] is a basic solution to the problem. This concept is proposed by Network Mobility (NEMO) Working Group [6] of Internet Engineering Task Force IETF [7] and has been followed by a number of industrial and research projects. NEMO Basic Support Protocol (BSP) [8] provides a mechanism to provide seamless connectivity to the networks and nodes through MR, which only support the group mobility. There are many scenarios in ubiquitous mobility, which are not supported by NEMO group mobility. NEMO has some limitation on its route optimization, which adds additional tunneling cost, which are not desired for the Ubiquitous mobility for resource constrain devices [13]. It requires some dynamic solution to provide a ubiquitous mobility, which support all possible mobility scenarios. In this paper we present a framework for seamless mobility for IPv6 enable low capable devices for its possible mobility scenario considering the

PAN, BAN, VAN and Ad-Hoc networks. Our proposed solution for the Ubiquitous mobility reduced the signaling cost over the network, processing cost for the individual components, network congestion inside the local networks of the low cable device to increase devices lifetime and improve the overall signaling cost. In this paper, we discussed about some of the background of IP mobility (2). After that we analyze the possible mobility scenario for the low capable devices (3). Followed by, our approaches to solve the problem, where we define designing goals, modification of current approached and solution (4). After that we modeled our solution with simple deterministic method (5) and then simulate our model with common values for the mobility to analyze the performance (6) of our proposed solution and followed by the related research work (7). We end with conclusion and future directions (8).

2. Background 2.1. Mobile IPv6 Mobile IPv6 [2] was proposed by the Internet Engineering Task Force (IETF). In MIPv6, each mobile node (MN) is assigned two addresses i.e. Home address ( HoA) and care of address (CoA). The former is assigned to a MN within its home network, whereas the latter is assigned at the current network of the node. The HoA and CoA are associated through a binding which is done at the mobile node’s home agent (HA). When a node moves from one network to another it updates its current location through binding its home address to the current care of address through a binding update (BU). Unlike Mobile IPv4 in Mobile IPv6 route optimization is also possible where a MN can directly communicate with any corresponding node (CN) using it’s care of address by sending it a Binding Update. 2.2. NEMO The objective of the is to provide permanent Internet connectivity to all mobile network nodes via their permanent IP addresses as well as maintain ongoing sessions as the mobile network changes its point of attachment to the Internet.

Existing protocols such as MIP and MIPv6 that provide host mobility support are not sufficient due to two reasons. Firstly, not all devices in a mobile network may be sophisticated enough to run these complex protocols. Secondly, once a device has attached to the MR on a mobile network, it may not see any link-level handoffs even as the network moves. This protocol runs on the MR and its Home Agent (HA) and uses the same mechanisms as the host mobility protocols. NEMO requires the MR to act on behalf of the nodes within its mobile network. The NEMO BSP does not provide the router optimization, which can increase the tunneling cost.

3. Mobility Scenarios and Classifications The following scenario comprises two views, micro- and macro, each aimed at highlighting distinctive variants of mobility. Consider a military application, involving ground combat scenario, wherein troops are belonging to different command authorities. The troops in PAN ‘A’ are connected to the internet via the mobile router and the IP-gateway. Similarly, the nodes in PAN ‘B’ are connected to the Internet through the PAN coordinator and the IP-gateway. In the macroview, there are two IP-gateways. Initially, PAN ‘A’ and PAN ‘B’ are connected to IPgateway I, while sometime at the later stage, these two PANs move to IP-gateway II, generating some unique mobility scenarios. Throughout all the scenarios (×) refers to the leaving point and (•) is the new location. Intra-PAN node mobility: Consider PAN ‘A’, wherein each soldier is operating within his designated position. When a soldier moves to new location, it must be communicated to the mobile router (or PAN coordinator) so that routing may be facilitated. Inter-PAN node mobility of IP-USN: When the soldier moves from PAN ‘A’ to PAN ‘B’, a handover is needed in this case and the prefix of the node also changes. Router Mobility: In this scenario the router can be mobile, while there are multiple mobile routers which can serve the purpose of efficient routing and fault tolerance.

Figure 1: Possible Mobility Scenario

Network Mobility: In this mobility scenario, the

mobile router along with its associated nodes migrates from one IP-gateway to the other. The handover is handled by the router and is transparent to all its subordinate nodes. The scenario is quite similar to NEMO. Special case: Nodes Mobility in sleep mode: In sensor networks the nodes can periodically go to sleep state in order to save energy and increase the network lifetime. Therefore Intra-PAN node mobility and Inter-PAN node mobility scenarios need to consider this characteristic too.

4. Approach In this section we shall mention the design goal that must be considered in our architecture. After that, we shall discuss our protocols architecture and different aspect of our architecture. 4.1. Designing Goals Reduced Energy consumption of Mobile Nodes: Our protocol targeted to support the little sensor node with huge energy constrain because of its

nature. So, our protocol must highlight the energy issues of each mobile sensor node. Thus, we need to reduce the signaling overhead for the individual mobile sensor. In the mean time, we have to concentrate on the overall network burden [8]. Thus we need to care about the bandwidth consumption at the time of location update and location refreshment. Lightweights: We need to have a lightweight protocol to accommodate in the sensor nodes. Sensor nodes have huge limitation on its processing ability and memory capability considering the usual nodes, because of its application, use and cost. Thus, the needed protocol should not be over burden by complex mechanism which cannot be supported by the general sensor node. Support Available Mobility Scenario: In our scenario analysis we define some possible scenario. Thus our protocol architecture needs to support the available global mobility scenarios. We need to support individual sensor global mobility to the group sensor mobility. Even Sensor Node can be in the energy saving mode like sleep mode or off mode. These things also need to be taken care in our protocol. In our scenario we can have mobility aware and unaware nodes, so we need to have solution for both kind of nodes and support both.

Support existing protocols: For the IP mobility, we need to find out a solution which supported the standard [9]. Thus, MIPv6 is the proven standard for IP device mobility, thus we need to find out solution basis on the existing technology. In MIPv6, it has always been suggested that corresponding nodes modification or improvement is always hard because of its nature. But it is relatively easy to modify the functionality of the home agent and the mobile node itself. Thus, we need to give an attention to modifying those components, while designing new protocol. The network mobility (NEMO) is a good candidate for the low cable devices mobility, because of its exemption from the 2nd layer handoff, thus the designing protocol need to have support for the NEMO, which can give us further extended benefits for the low capable devices in energy consumption. Authentication and Security: For mobile device authentication is a big issue, because in mobility scenario there is more probability of hacking [9]. Also the security is another issue which needs to deal with to have a real world solution. Thus, our protocol need the have proper mechanism to support the authentication and security. Scalability: Design should be scalable in every point. Design should not have extravagant assumption. The solution should be feasible

4.2.1. Mobile Ubiquitous Nodes, Negotiation Agent (MUNNA)

This middleware delegation agent, MUNNA is usually resides in the IP-USN gateway along with the MIPv6 router or mobile router. Its main function is to maintain a delegation table which is specially design to support the mobility of sensor nodes. MUNNA has the capability of generating some special signal and can handle with some special functionality of recognizing signals.

Figure 2: Basic Structure Overview

4.2. Protocol Architecture In this section we define our protocol architecture. We named our Protocol as Low Mobile IPv6, LowMIPv6. Where we basically define a mobility supported middleware for the Mobile Sensor Nodes, also we define some extra signaling format and some extra functionality. We named our middleware as Mobile Ubiquitous Nodes, Negotiation Agent (MUNNA), which assist the Mobile Sensor Nodes, by taking its entire functional load. In the Figure2, we depict the overview of our LowMIPv6, which is designed on the basis of MIPv6 standard with some modification to fit low device environment. Our protocol will act like NEMO when it will move in a group. In our solution, the nodes can move in group or the PAN can move together. In the following figure, we have shown the mobility of our LowMIPv6.

4.2.2. Delegation Table

The  delegation  table  is  design  such  a  way  to  support  our  protocol  in  efficient  way.  Here  the  table  entities  will  be  sorted  by  the  home  agents  address  and  corresponding  nodes  address.  The  following table shows its format.  Table 1: Delegation Table Example Format Home Address

Home Agent Address

3ffe:200:8:1 ::C 5ffe:210:8:1 ::C

3ffe:210:8:1:: C 3ffe:220:EE:1 ::C

Correspondi ng Nodes Address 3afe:210:8:1 ::C 3bfe:202:8:1 ::C

Life Tim e 15 20

Statu s

Flags

Activ e Sleep

A/H/ K A/K

Home Address: This is the Mobile Sensor Nodes global address, which is also known as the Home Address. This is the address which is registered in the Home Agent at the time of deployment.

Home Agent Address: This is the Address of the Home Agent, which is the registered home for the Mobile sensor nodes. Corresponding Nodes Address: This address is the address of active CN associated with the Mobile Sensor nodes. Binding Life time: This is a special life time for the Mobile sensor nodes binding refreshment. Statues: This field will indicate the current status of a Mobile sensor node. Flag: Further associated Flag values to incorporate special functionality. 4.2.3. Changed Signaling format

In this section we define our additional signaling format, which are slightly different from the usual MIPv6 signaling. In this signaling list there is no addition message format for the corresponding node. In Route solicitation Message: In this protocol the route solicitation message will include the Home agent address to specify the home agent for the further association. Route Advertisement Message: Router Advertisement Message will generated by the MUNNA when it will get the challenge from message from the Home Agent and it will put extra information of challenges with the Route Advertisement Message. Network and Node Authentication Message: NNAM will be generated by the MUNNA to authenticate the node and the network together with the Home Agent. Challenge Message: Challenge Message is a special encryption message which will be generated by the Home Agent in the reply of the NNA message. Secrete of the challenge is only know by the home agent and the node. But in that process as a middleware it will authenticate the router as well as a valid entity to work as a delegator. Solve Message: Solve message is the reply of the Challenge by the Home Agent. BU with solve Message format: Binding update message will include solve to authorize the Mobile Node and it’s with the Home Agent. CN initiation Message: This message will send by the MN to initiate the communication with a particular CN.

Status Message: It is a special kind of single send to the MANNA by the Mobile sensor node to declare its status change. This signal will occur only it wants to change its status. For example, when any Active mobile sensor node wants to go to the sleep/off state, it will let the MANNA know about its status change. 4.3. LowMIPv6 Description Assumption: 1. Access Router is capable enough to

maintain Delegation Table: In our design we assumed that MUNNA will reside along with the MIPv6 capable mobile router and with the low capable devices router stack to incorporate all the functionality. 2. Home Agent and Mobile Node have special Challenge Based Authorization Mechanism, Which is a very simple and lightweight mechanism for the Low capable device. This can be priorities with the level of application it is using for. 3. For the security we assume that there will be low version IPSec (ECC based IPSec), will be working according to the capability of low devices. 4. For the movement detection, low version of router advertisement like MIPv6 is activated, where the router advertisement depend on the particular low cable device standard is using. 4.3.1. Mobile Node in Home Agent

Like the other MIPv6 node, the low capable devices need to have a home agent. Low capable mobile node (LowMN) will register its home address, with specifying itself as a low capable device. Thus, the home agent (HA) maintains its identity for the mobility support with some initial secrete for authentication purpose. 4.3.2. Mobile Node in foreign Network Initial Association and Delegation: 1. While LowMN

moves into the foreign network, it detects the change of its networking using the prefix advertisement. LowMN will response with the Router Solicitation Message with HA (RSMHA), which will help the access router to distinguish the LowMN from the other usual mobile node of MIPv6 capability. In that consequence, the access router forwards the device activity to the MUNNA for further mobility association and delegation activities.

2. When MUNNA gets the LowMN, it updates it’s the nodes care-of-address and home address in the delegation table in the sorted order with the home address. The care-off-address is generated by autoconfiguration with it source MAC address and home address prefix. 3. After that, MUNNA sends Network and node Authentication message (N2AM), to the home agent for the authentication of itself to support the delegation on behalf of the LowMN and at the same time authenticate the node itself. 4. When home agent get the N2MA, its checks authentication for the LowMN and response with a Challenge Message (CM) to solve using the initial secrete at the time of registration. 5. As soon as MUNNA gets the CM from the home agent it sends the router advertisement with the Challenge to be solve. In that case the challenge format is put into the option bits of the router advertisement message. 6. After getting the RA LowMN auto-configure its care-of-address and also solve the problem with some simple function and acknowledge with the solution. 8. When MUNNA gets the solution, it makes the Binding Update (BU) message with solution and sends it to the Home agent. Home agent authenticates LowMN and MUNNA using the correct solution and registers the current MUNNA and the LowMN care-of-address (CoA). After that it acknowledges the MUNNA and MUNNA acknowledge the LowMN. After that the MUNNA gets the control over the LowMN further operations. Route Optimization: 1. LowMN sends the CN initiation message with current CN list to start the data transfer. 2. MUNNA updates its CN list in delegation table and wait for a random time with probability analysis of the group mobility. If more than one node is moving for the same purpose, it will have the same home agent and same corresponding nodes. And it has more probability that low capable devices with move together as a group or as the form of a PAN. Thus PAN’s nodes have the more probability to be from the same home agent and working with the same corresponding nodes. 3. After a random time, MUNNA get the nodes with same corresponding node and home agent. MUNNA will perform the return routibility test for the corresponding nodes. Actually it make this

process will be aggregated for the common nodes and work at the same time. 4. After the Return routibility test, MUNNA will acknowledge the individual node. 4.3.3. Sleep state association

1. When Mobile Node change its state to the Sleep state or off state, its send the status change message to the MN. 2. MUNNA incorporates this message with the delegation table. When binding life it will be finished and need to send binding refreshment message for the HA and CN, MUNNA will take action according. 4.4. Corresponding signaling LowMIPv6

Figure 3: MIPv6 Signaling TimeLine

Figure 4: LowMIPv6 Signaling TimeLine

The timeline diagram Figure 3, shows the MIPv6 signaling in the possible scenario. Here the diagram

shows the route optimization scenario as well and figure 4 shows the comparison with our framework LowMIPv6.

5. Analytical Model To evaluate the performance of our system, we model the overall latency in MIPv6 and we compare latency with our LowMIPv6 overall latency model. For our analysis we used some symbol and notation which are summarized above. In our analysis, also we modeled the Energy consumption of individual Mobile Nodes in Mobility condition for both case. 5.1. MIPv6 Mobility latency Cost MIPv6 mobility cost includes the overall location update latency and total binding refreshment cost, which can be determine using the following simple deterministic methods [1][18][19]. 5.1.1. Location Update Cost

Location update cost involves the binding update cost for Home Agent (HA) and binding update cost for the Corresponding node (CN). Binding update latency for HA: Binding update cost for Home Agent includes the, Movement Detection Delay " " : This is the time required by the MN to detect the Mobility. IP CoA configuration Time “ " : Time to configure the Care of Address. Binding registration time “ " : Time Need for the binding update in the home Agent [18]. If we consider the total handoff latency for the binding update in home agent can represent by ( ), which is the sum of the first 3 aforementioned latency component.

Movement Detection is sum of two individual : This is the components: Link switching delay, time delay pertaining to the re-association. Link local IPv6 configuration delay, : This is the time between the first time that the MN encounters a new link by receiving neighbor advertisement [20]. Thus   the movement detection time is, IPv6 CoA Configuration Delay: We define the CoA configuration time ( ) as the time commencing from the moment of the receipt of a route advertisement to the moment that Duplicate Address Detection (DAD) and the update of the routing table

has completed. For the stateless IPv6 address autoconfiguration ( ) is comprised of the following delay components:     4     Binding Registration Time: The Binding registration time ( ) is defined as the transmission delay incurred during registration of the MN CoA with its HA.       2 1 2         Binding update latency for the CN: The route optimization time “ " is defined as the transmission delay incurred during registration of the MN bindings with the CN that is furthest away in two distinct cases depending on the mode of security affected in the BU registration process:         4 1 4     2 1 2         6 1 6           Thus we can say the Binding update cost of the , corresponding nodes can be represented by ( which is equal to the Route optimization cost. Thus   6 1 6           Thus the Overall Location update latency for MIPv6: According to our mobility model given in the last section the average binding update cost can be derived as (We use the fluid flow mobility model, probability of, = ).         5.1.2. Binding Refreshment Cost

Let the binding lifetime for the HA and CN in MIPv6 be ̃ and ̃ respectively. Then the average binding refresh cost in MIPv6 can be derived as follows:  

 

        ̃ ̃ Here, is the ratio of an MN’s average binding time for the CNs to its average domain residence time.



Table 2: Used Notation in Equations

  . Where ∆ means an MN’s average ∆ domain residence time, and represents the binding time for the i-th CN, Which has been recorded in an MN’s binding update list during its average domain residence time. Also, n means the number of all the CNs recorded in the MN’s binding update list during its average domain residence time. Thus ∑  

 

  ̃

 

 



Symbols     

   

   

  RTT 

̃

Thus the Total singling cost of MIPv6 is the sum of the total handoff cost and total binding refreshment cost.       

We used the same model to analyze the LowMIPv6 and find out the deterministic model: 5.2.1. Location Update Cost Binding update latency for HA: In LowMIPv6

Architecture, we have added the functionality of the ubiquitous node negotiation models.   Here Movement Detection,       IPv6 CoA Configuration Delay 4     2

   

2  

 

   

5.2. LowMIPv6 Mobility latency Cost

Binding update latency for the CN:



 

                       

2

 

   

4

   

1

       

Meaning  Average Number of hopes between the  Delegation Agent Router to the Home Agent.  Average Number of hopes between the  Delegation Agent Router to the corresponding  Node.  Per hope location update message transmission  cost.  Per hope location update message transmission  cost for the wireless Ad hoc network.  Proportionality constant of signaling cost over  wireless link.  Mobile Nodes subnet Resident time.  Router Transmission time,  means the  round Trip time from Mobile node to the  Corresponding Node.  Transmission time   means the  Transmission time from Mobile node to the  Corresponding Node.  Average binding update cost by MIPv6.  Average number of the CNs when an MN moves  into/out of a given domain  Movement Detection Delay: This is the time  required by the MN to detect the Mobility.  P CoA configuration Time: Time to configure the  Care of Address.  Binding registration time: Time Need for the  binding update in the home Agent.  Energy required for transmitting packet  Energy required for receiving packet  Per hope location update message transmission  Energy cost for the wireless Ad hoc network.  Proportionality constant of signaling energy cost  over wireless link.  Energy required for mobility detection  Energy required for Care‐of‐Address Association  Energy required for binding registration  Energy required for Binding update association  with Home Agent  Energy required for Binding update association  with Corresponding Node  Energy cost for the binding‐Refreshment  Probability of Node being in reduced power state  Probability of Node being in Active state  Probability of Node being in off state 

     

 

6

1

 

 2

   

 

Now for the combined Biinding updatee in the CN, let l C and HA is  . Let thhe the number of common CN . U of CN is rep presented by  Combine BU Thus 6 1   2        2             Overall Locaation update la atency for Low wMIPv6

 

 

 

 

nt Cost 5.1.2. Binding Refreshmen

∑  

 

 

̃

 



 

 

̃

Thus the Tootal singling cost c of MIPv66 is the sum of o the total handoff co ost and tootal bindin ng refreshment cost.        5.3. MIPv6 Energy Costt In this sectioon we analyzzed the energyy consumptioon by the indiviidual node wh hile maintainiing mobility. bile Nodes Total T Powerr consumptioon MIPv6 Mob for Mobilitty Scenario:: The powerr consumptioon with be thhe sum of energy requuired for thhe movement detection, d caree-of-address association a annd binding registration energ gy cost. Thus     2  2    3  4  3  3 Total Energgy cost on MN M for the MIPv6 M handofff,       Total Energgy cost on MN M for the MIPv6 M Bindin ng Refreshmen nt,        

 

Total Energy mobillity, 

cost   

in

the  

Proceess

of

5.4. LowMIPv6 L E Energy Cosst MIPv6 Moobile Nodees Total Power LowM consu umption for Mobility M Scen nario The power p consum mption of thee LowMIPv66, can be definee as,     2  2       Total Energy cost on MN for f the Low wMIPv6       handooff, Total Energy cost on MN for f the Low wMIPv6 Binding Refreshm ment    

 

 

 , Where,

is the proobability

co-effficient when in i power saving mode. (0 0 1 Total Energy cost in the Proceess      mobillity, 

of

6. Nu umerical Results For thhe Ubiquitouus Sensor neetwork mobillity, our designning goal waas to make a resource constrain c solutioon. And wee provide a resource constrain c solutioon handling all major mobility m scenaarios. In our evaluation e wee simulate our o analytical model with the typical values v of ouur identified variable [1][200][26]. In our o analysis,, we comppare the perforrmance of energy e consumption in Mobile nodes in normal MIPv6 M and SeenMIPv6 moodel. We have some excitinng results. Thhan we comppare the overalll signaling latency. Wee also meassure the signalling load on handoff and binding refreeshment. We analyze a the performance p of combine HOTICOTI protocol and also the energy saving mechaanism benefitt we some excciting results. MNss' Energy in Siggnaling 20 10 0

MN's Process Burden 5000 0

Group Mobility 5.45 5.448 5.446 1

2

3

4

Number Moves In group

7. Related Works To the best of our knowledge, there is not enough research literarily available on the global mobility of IP based Wireless Sensor network. Our research is bipartite involving the Mobile IPv6 analysis and support for investigation of mobility in sensor network. MIPv6 provides support for mobility, but it requires a minimalist signaling which is battery-exhausting for, if we consider it is a sensor node, it’s really hard to fit. If we consider the NEMO, its reduce some of the signaling cost and 2nd layer handoff, but it increase the overhead for the tunneling purpose [1],[7]. To reduce the packet overhead due to the tunneling several techniques has been proposed. There are some effort has been made to solve those problem [2][3][4]. But, all those effort rarely focused low capable device issues.

8. Conclusion In our architecture, we try to provide a general mobility solution for small and constrained devices. In the process we analyzed possible mobility scenarios. This paper presents LowMIPv6 for seamless mobility management of IP-based USN. The architecture emphasizes on reduction of communication cost in order to increase the network lifetime.

9. References

[1]. Henrik Petander, Eranga Perera, Student Member, IEEE, Kun-Chan Lan, Member, IEEE, and Aruna Seneviratne, Member, IEEE. “Measuring and Improving the Performance of Network Mobility Management in IPv6 Networks”, IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL. 24, NO. 9, SEPTEMBER 2006. [2]. Eranga Perera, Student Member, IEEE , Aruna Seneviratne, Member, IEEE, and Vijay Sivaraman, Member, IEEE,” OptiNets: An architecture to enable optimal routing for network mobility”, 2004 International Workshop on Wireless Ad-Hoc Network. [3]. Abu S Reaz, Pulak K Chowdhury, Mohammed Atiquzzaman, William Ivancic, “Signalling Cost Analysis of SINEMO: Seamless EndtoEnd Network Mobility” [4] H. Ohnishi, K. Sakitani, and Y. Takagi, “HMIP based route optimization method in a mobile network,” Oct. 2003, draft-ohnishinemo-rohmip- 00.txt. [5] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert, “Network mobility (NEMO) basic support protocol,” Internet RFC: RFC3963, Jan. 2005. [6] K.-C. Lan, E. Perera, H. Petander, L. Libman, C. Dwertmann, and M. Hassan, “MOBNET: The design and implementation of a network mobility testbed,” in Proc. 14th IEEE Workshop on Local and Metropolitan Area Netw., Crete, Sep. 2005, pp. 1–6. [7] Debashis Saha, Amitava Mukherjee, Iti Saha Misra, Mohuya Chakraborty, “Mobility Support in IP: A Survey of Related Protocols”, IEEE Network • November/December 2004. [8] Pulak K Chowdhury, William Ivancic, “SINEMO: An IP-diversity based Approach for Network Mobility in Space”, 2nd IEEE International Conference on Space Mission Challenges for Information Technology (SMC-IT'06). [9] Karen Wang, Baochun Li, "Group Mobility and Partition Prediction in Wireless Ad-hoc Networks," Proceedings of IEEE International Conference on Communications, Vol. 2, pp. 1017-1021, Apr. 2002 [10] Hyung-Jin LIM, Dong-Young Lee, Tae-Kyung KIM, Tai-Myoung Chung, “ A Model and Evaluation of Route Optimization in Nested NEMO environment. [11] RFC 3963, “NEMO Basic Support” [12] Robert C. Chalmers and Kevin C. Almeroth, “A Mobility Gateway for Small-Device Networks”, Percom 2006. [13] U. J onsson, F. Alriksson, T. Larsson, P. Johansson, and G. Maguire. MIPMANET - mobile IP for mobile adhoc networks. In Proceedings of Workshop on Mobile Ad Hoc Networking (MobiHOC'00), Boston, MA, USA, Aug. 2000. [14] Ki-Sik KONG†a), MoonBae SONG†, KwangJin PARK†, and Chong-Sun HWANG, “A Comparative Analysis on the Signaling Load of Mobile IPv6 and Hierarchical Mobile IPv6: Analytical Approach ”, IEICE TRANS. INF. & SYST., VOL.E89–D, NO.1 JANUARY 2006. [15] Sun-Jong Kwon, Seung Yeob Nam, Ho Young Hwang, and Dan Keun Sung, “Analysis of a Mobility Management Scheme Considering Battery Power Conservation in IP-Based Mobile Networks” , IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 53, NO. 6, NOVEMBER 2004. [16] Stefan Galli, Anthony McAuley, Raquel Morera, “AN ANALYTICAL APPROACH TO THE PERFORMANCE EVALUATION OF MOBILITY PROTOCOLS: THE OVERALL MOBILITY COST CASE” [17] Abu S Reaz, Pulak K Chowdhury, Mohammed Atiquzzaman, William Ivancic, “Signalling Cost Analysis of SINEMO: Seamless EndtoEnd Network Mobility”, IEEE Conference. [18] Noseong Park, Daeyoung Kim, Jihoon Park , Yoonmee Doh, “Subnetwork Mobility Analysis in Wireless Sensor Networks”, ©2005 IEEE. [19] D. Estrin, R. Govindan, J. Heidemann, and S. Kumar. Next century challenges: Scalable coordination in sensor networks. In Proceedings of Mobicom'99, Seattle, WA, USA, Aug. 1999.

LowMIPv6: A Framework for Mobile IPv6 for the Low ...

Abstract. Low capable device such as Wireless Sensor ... IP connectivity to WSNs has enabled ubiquity of .... Internet connectivity to all mobile network nodes.

538KB Sizes 1 Downloads 191 Views

Recommend Documents

mCrash: a Framework for the Evaluation of Mobile ...
Mobile Devices. The philosophy for mobile devices has been evolving towards ..... when the object was used as an argument in a method call. Nevertheless .... 1783-1784, 10th Annual Conference on Genetic and Evolutionary. Computation ...

mCrash: a Framework for the Evaluation of Mobile ...
The SNB provides a standard architecture for monitoring ..... eCrash: a Framework for Performing Evolutionary Testing on Third-Party Java Components. In Proc.

A Framework for Low-Communication 1-D FFT
Nov 10, 2012 - Abstract—In high-performance computing on distributed- memory systems, communication often represents a significant part of the overall ...

Strato: A Retargetable Framework for Low-Level ... - Research at Google
optimizers that remove or hoist security checks; we call .... [2, 3]. One way to enforce CFI is to insert IDs ... CFI in a way similar to the original implementation [3],.

A Java Framework for Mobile Data Synchronization
file systems, availability is more important than serializability. .... accumulate a list of newly inserted objects, and listen for completion of the receiving phase to ...

The IPv6 Routing Protocol for Low-power and Lossy ...
Abstract. We study the behavior of the IPv6 Routing Protocol for. Low-power and Lossy Networks (RPL) under network par- titions, failures that are notoriously difficult to handle. Our work combines experiments in simulators and on a ∼100- node test

A Proposed Framework for Proposed Framework for ...
approach helps to predict QoS ranking of a set of cloud services. ...... Guarantee in Cloud Systems” International Journal of Grid and Distributed Computing Vol.3 ...

Mobile-ATM: A Low Cost Mobile Payment System for ...
Mobile-ATM: A Low Cost Mobile Payment System for. Developing Countries .... telephone line or directly via a leased line, which is expensive. In addition to that ...

fine context, low-rank, softplus deep neural networks for mobile ...
plus nonlinearity for on-device neural network based mobile ... translation. While the majority of mobile speech recognition ..... application for speech recognition.

BILL-LEGS: Low Computation Emergent Gait System for Small Mobile ...
computation Emergent Gait System (BILL-LEGS) was developed as a solution to some of these issues. This method borrows heavily from Cruse's original design ...

Optimized Lightweight Thread Framework for Mobile Devices ...
are two software approaches to adjust the stack size: • Changing system ..... understanding the detailed interactions among threads to ana- lyze the purpose of ...

Multicast based fast handoff in Hierarchical Mobile IPv6 ...
Handoff-Aware Wireless Access Internet Infrastructure. (HAWAII) [15]. ... home agent by sending another BU that specifies the binding between its home address ...

Are you ready for IPv6? - GitHub
Page 5 .... IPv6 Support in Boost.Asio. Resolver: ○ Obtain endpoints corresponding to host and service names. ○ Usually uses DNS ...

IPv6 Transition for VzW
Each device will have Two IP Addresses. – VoIP (v6 Always On). – Internet/ASP (v6 or v4) ... competence. • Training is critical. – Academic. – Web-based classes.

Developing a Framework for Decomposing ...
Nov 2, 2012 - with higher prevalence and increases in medical care service prices being the key drivers of ... ket, which is an economically important segmento accounting for more enrollees than ..... that developed the grouper software.

A framework for consciousness
needed to express one aspect of one per- cept or another. .... to layer 1. Drawing from de Lima, A.D., Voigt, ... permission of Wiley-Liss, Inc., a subsidiary of.

A GENERAL FRAMEWORK FOR PRODUCT ...
procedure to obtain natural dualities for classes of algebras that fit into the general ...... So, a v-involution (where v P tt,f,iu) is an involutory operation on a trilattice that ...... G.E. Abstract and Concrete Categories: The Joy of Cats (onlin

Microbase2.0 - A Generic Framework for Computationally Intensive ...
Microbase2.0 - A Generic Framework for Computationally Intensive Bioinformatics Workflows in the Cloud.pdf. Microbase2.0 - A Generic Framework for ...

A framework for consciousness
single layer of 'neurons' could deliver the correct answer. For example, if a ..... Schacter, D.L. Priming and multiple memory systems: perceptual mechanisms of ...

A SCALING FRAMEWORK FOR NETWORK EFFECT PLATFORMS.pdf
Page 2 of 7. ABOUT THE AUTHOR. SANGEET PAUL CHOUDARY. is the founder of Platformation Labs and the best-selling author of the books Platform Scale and Platform Revolution. He has been ranked. as a leading global thinker for two consecutive years by T

Developing a Framework for Evaluating Organizational Information ...
Mar 6, 2007 - Purpose, Mechanism, and Domain of Information Security . ...... Further, they argue that the free market will not force products and ...... Page 100 ...

A Framework For Characterizing Extreme Floods for ...
The Bureau of Reclamation is now making extensive use of quantitative risk assessment in support of dam safety decisionmaking. This report proposes a practical, robust, consistent, and credible framework for characterizing extreme floods for dam safe