iMASH Application Session Handoff of Constant Bit Rate Traffic

1. iMASH Application Session Handoffof Constant Bit Rate Traffic CS 215 Presentation Glenn Glazer Jing Gu

2. Mobile Host (MH) Mobile Host (MH) Mobile Host (MH) Traditional Cellular Handoff Application Server (AS) Base Station Base Station Wired link Wired or Wireless link

3. Disadvantages ofTraditional Cellular Handoff • Do not know ahead of time where MH will be. Leads to prefetching and predictive approaches. • Does not allow for change of MH. • Does not allow for change of base station for reasons other than mobility, for example changing for load balancing or QoS improvements.

4. Mobile Host (MH2) iMASH Handoff Single Middleware Server Case Application Server (AS) Routing Layer Middleware Server (MWS) Mobile Host (MH1)

5. Advantages of a Single MWS • Allows for change of client with no impact on legacy AS. • Relieves AS of routing duties, thus increasing throughput of AS. • Service discovery replaces mobile prediction. The MH already has a list of known other MH to handoff to and selects one. The MWS simply redirects the stream of traffic.

6. iMASH Handoff - Putting it all together Multiple Middleware Servers Case AS Proxy MWS1 MWS2 MH1 MH2 MH3 MH4

7. Advantages of Multiple MWS • Allows scalability by distributing work among MWS. • Now service discovery allows not only the choice of MH, but the choice of MWS based on various metrics besides distance, such as QoS or load balancing. • Lightweight routing protocol does less work than AS and relieves AS of performing routing duties.

8. MH MH MH MH MWS MWS MH MH MH MH MH MH MWS MWS MH MH MH MH Simulation Setup • GloMoSim 2.0 • 100x100 meter field • 1 AS • 4 MWS wired to AS and each other • Experimental variable is the number of MH, all wireless AS

9. Experimental TrialsDesigned to demonstrate scalability Hold the number of MWS fixed at four • Cellular handoff only • iMASH handoff only • Cellular handoff assumes GPS clients • Want to measure latency and number of handoffs as the number of mobile hosts increases.

10. Experimental Trials (Con’t) • In the no iMASH handoff case, straight CBR traffic was sent as the nodes moved around. • In the no cellular handoff case, the transmission power was increased so that the mobile node was always in range of its MWS. • This is because we are experimenting on performance, not fault tolerance or packet loss. Clearly, though, this argues that incorporating cellular handoff is going to be required for scalability.

11. Multiple Middleware Server iMash Handoff Protocol • Based on CBR (Constant Bit Rate) application provided by GlomoSim 2.0 • Split one hop CBR stream into two hops (server  middleware server  client) • Message delivery event driven • Introduce new communication protocol for iMash client/middleware/server configuration • Feasible for both iMash handoff and cellular handoff

12. Multiple Middleware Server iMash Handoff Protocol(con’t) • Four application message types • APP_HF_CBR_DATA • CBR Packet • APP_HF_CBR_MWS_INFO_REQ • Request for middleware address of a client • APP_HF_CBR_MWS_INFO • Middleware server address • APP_HF_CBR_HANDOFF_REQ • Request for middleware server address

13. Multiple Middleware Server iMash Handoff Protocol(con’t) APP_HF_CBR_DATA APP_HF_CBR_MWS_INFO_REQ APP_HF_CBR_MWS_INFO APP_HF_CBR_HANDOFF_REQ AS Proxy MWS1 MWS2 MH1 MH2 MH3 MH4

14. Multiple Middleware Server iMash Handoff Protocol(con’t) • Initialization • HFCBR server starts up independently • Proxy is close to server and here regarded as part of server • Behavior on sending/receiving application message • HFCBR Server: Server sends middleware server information request to client with necessary initialization parameters.

15. Multiple Middleware Server iMash Handoff Protocol(con’t) • HFCBR Client: On receiving middleware server information request • If there’s no corresponding client structure on node, then start up a new HFCBR client • Otherwise, find the corresponding client structure* In both case, client replies with middleware server information message to the request source -*request source can only be a middleware server in this case

16. Multiple Middleware Server iMash Handoff Protocol(con’t) • HFCBR Server: On receiving a middleware information message, server starts sending packets to the middleware in message • Only happens once before the first packet being sent out • HFCBR Middleware Server: On receiving a packet • If corresponding middleware server structure could not be found, start up a new one for the session • Otherwise, get the corresponding middleware server structure

17. Multiple Middleware Server iMash Handoff Protocol(con’t) • Redirect the packet towards the client of the session according to information in the message • HFCBF Client: On receiving a packet from its middleware server, if it’s the first packet coming in, the client issues a handoff request to its middleware server with a randomly chosen target after random delay

18. Multiple Middleware Server iMash Handoff Protocol(con’t) • HFCBR middleware server: On receiving a handoff request, sending middleware server information request to the handoff target • HFCBR middleware server: On receiving a middleware information message from handoff target • If the middleware server in message is the same as itself, redirect packets of the session to the handoff target • Otherwise, send middleware information message to server

19. iMash Handoff Experiment Application Settings • Traditional CBR application • CBR <From> <To> <Number Items> <Item Size> <Interval> <Start Time> <End Time> <To> <From> • 8 client nodes moving at up to 10m/s for 60 seconds in a 100x100m field • Application server sent 1,024 byte packets to each client every .021 seconds for 60 seconds • No packet loss

20. iMash Handoff Experiment Application settings (con’t) • iMash Handoff-enabled CBR • HFCBR <From> <To> <Number Items> <Item Size> <Interval> <Start Time> <End Time> <To> <From> • 8 client nodes moving at up to 10m/s for 60 seconds in a 100x100m field • 4 stationary middleware server, each corresponding to 2 moving mobile host • Application server sent 1,024 byte packets to each client every .021 seconds for 60 seconds • No packet loss

21. CBR Handoff CBR Execution Time (s) 13.8860 15.8830 Average Server Throughput 390178 390231 iMash Handoff Experiment Results • More execution time • Similar through put on application server • Additional control messages do not count much

22. iMash Handoff Experiment Conclusion (con’t) • Advantages • Enable seamless handoff between clients • Enable content adaptation for different clients on middleware server • Overhead of handoff on server is low (simple redirection) • Totally distributed solution, not sensitive to mobile host amount • Disadvantages • Not a fully wireless solution (server/any middleware server can access any mobile host) • Server to client delay is larger

23. iMash Handoff Experiment Conclusion (con’t) • Improvement space • Middleware discovery strategy • Introduce a global client-middleware server pairs list, or • Multicast middleware server information request when necessary from the demanding middleware server to all other middleware servers • Take content adaptation delay into account • More experiment needed

24. Mobility Model • Strictly Euclidean metric. Node hands off to another node if the distance to the new MWS is 90% or less of the distance to the current MWS. • Handoff is represented by a change in the global routing table. This involves n-1 calls to the routing update function and two packets to be sent (one to each MWS) to correct the routing table from their perspective.

25. Mobility Results • 8 client nodes moving at up to 20m/s in a 100x100m field for 60 minutes models a fairly high degree of mobility. • No packet loss here, either. • The four MWS handled an average of 16,833 handoffs or around 4.68 handoffs per second. While much more testing needs to be done, with more clients, this may show that the distributed solution reduces the impact on each MWS and on the AS and thus demonstrates scalability.

26. Future Work Merge these models together to create a truly heterogeneous handoff environment