| 77 | | 2. Update [[BR]] |
| 78 | | (1) Mobile node updates binding to local GNRS server: constant latency [[BR]] |
| 79 | | (2) Local GNRS server hash K times and then sends binding to K grids: routing latencies from local GNRS server to K grids (for simplicity, latency is proportional to the distance between grids) [[BR]] |
| 80 | | (3) K grids reply acknowledgements: routing latencies from K grids to original local GNRS server (for simplicity, this latency is proportional to the distance between grids) [[BR]] |
| 81 | | update latency T1 = (1) + biggest in (2) + biggest in (3) [[BR]] |
| 82 | | or update latency T1 = (1) + biggest in (2) (since after (2), GNRS server is able to answer query) [[BR]] |
| | 77 | 2. Update [[BR]] |
| | 78 | (1) Mobile node updates binding to local GNRS server: constant latency. [[BR]] |
| | 79 | (2) Local GNRS server hash K times and then sends binding to K grids: routing latencies from local GNRS server to K grids (for simplicity, latency is proportional to the distance between grids) [[BR]] |
| | 80 | (3) K grids reply acknowledgements: routing latencies from K grids to original local GNRS server (for simplicity, this latency is proportional to the distance between grids) [[BR]] |
| | 81 | update latency T0 = (1) + biggest in (2) + biggest in (3) [[BR]] |
| | 82 | or update latency T0 = (1) + biggest in (2) (since after (2), GNRS server is able to answer query) [[BR]] |
| 84 | | 3. Query [[BR]] |
| 85 | | (1) Node sends query message to its local GNRS server: constant latency [[BR]] |
| 86 | | (2) Local GNRS server A hash K times and pick the nearest grid B to send query message: assume routing latency is proportional to the distance between A and B. [[BR]] |
| 87 | | (3) B return binding message to A: routing latency is same as latency in (2). [[BR]] |
| 88 | | query latency T2 = (1) + (2) + (3) [[BR]] |
| | 84 | 3. Query [[BR]] |
| | 85 | (1) Node sends query message to its local GNRS server: constant latency [[BR]] |
| | 86 | (2) Local GNRS server hashes K times and pick the nearest grid to forward query message: assume routing latency is proportional to the distance between the two grids. [[BR]] |
| | 87 | (3) The nearest grid's router returns binding message to the node: routing latency is same as latency in (2). [[BR]] |
| | 88 | query latency T1 = (1) + (2) + (3) [[BR]] |
| 90 | | 4. Delivery failure due to node moving [[BR]] |
| 91 | | Assume traffic is from service provider's static server C to mobile node D, router E is D's original grid router, router F is D's new grid router after move. [[BR]] |
| 92 | | (1) While generating updates, check node D every minute to see whether an update need to be generated. Therefore the gap between update events is multiple minutes. After receiving an packet successfully from service server, mobile node will reply an ACK to the server. Therefore, in simulation, two scenarios are possible: a) Move after ACK: D replies an ACK and then move to another grid, delivery of the next packet from C will fail due to the move. b) Move before ACK: D moves to another grid while receiving a packet, so the transmission of the packet will terminate and router E will send query to its GNRS server. As a result, the delay for discovering delivery failure is determined by the transmission mechanism. [[BR]] |
| 93 | | (2) The routing delay of packets transmission from C to E depends on the routing infrastructure, link quality and status, routing strategy used, etc. For simplicity, assume this delay T3 is some constant. [[BR]] |
| 94 | | (3) Packets, which are sent from C to router E (D's original grid router) during the update latency period T1, can not be delivered to D successfully. E holds the packets and queries C's binding every T4 seconds (T4 > T2). Latency in this stage is T5 = T2 + (k-1)T4 (k is the times of E's query ). [[BR]] |
| 95 | | (4) Packet then reroute from router E to router F (D's new grid router). This delay T6 can simply set to proportion to the distance between E and F as in (2). [[BR]] |
| | 90 | 4. Multimedia application (mobile client to static server): event list is pre-generated before [[BR]] |
| | 91 | Assumption: mobile node A, service provider's static server B, A's original grid router C, A's original grid GNRS server D, A's new grid router E, A's new grid GNRS server F. [[BR]] |
| 97 | | latency due to delivery failure <= T1 + T5 + T6 ("<" is possible when D sends out update and C's router sends out query for D at the same time, in this case T1 and T2 have overlap) [[BR]] [[BR]] |
| | 93 | (1) Mobile node A sends query message for B to its local GNRS server D, query delay is T1. [[BR]] |
| | 94 | (2) A sends service request with binding information to B, the latency is T2. [[BR]] |
| | 95 | T2 is proportion to the distance between A and B (approximately distance between C and B + constant distance from A to C) [[BR]] |
| | 96 | (3) B sends chunk/packets to A at the original grid T3. [[BR]] |
| | 97 | T3 is same as T2 (routing delay from B to A) [[BR]] |
| | 98 | (4) chunk/packets delivered successfully, time is T4. [[BR]] |
| | 99 | a) Transmission delay T5: T5 = chunk size / transmission rates [[BR]] |
| | 100 | b) A sends ACK to B: T6, same as T2 (assume stop & wait transmission) [[BR]] |
| | 101 | T4 = T5 + T6 (T4 may vary since T2 may change for different chunk as A is moving) [[BR]] |
| | 102 | (5) chunk/packets delivery fails: reroute, delay is T7. [[BR]] |
| | 103 | a) delay of discovering the failure: T4 [[BR]] |
| | 104 | b) latency of A's update: T0 (during T4, A might start updating its binding, so T0 and T4 may overlap) [[BR]] |
| | 105 | c) latency of query for A's new binding: T1 [[BR]] |
| | 106 | d) delay of routing from B to A: T3 [[BR]] |
| | 107 | T7 <= T4 + T0 + T1 + T3 [[BR]] |
| 99 | | Future optimization / analysis: [[BR]] |
| 100 | | (1) In multimedia on demand application, mobile node D sends service request message to service provider server D encapsulated binding information <GUID, NA> so that D can directly send media file to C's NA without sending query to GNRS server. We can analyze the delay of the two strategies in the scenario : a) D use C's NA carried by the service request directly, therefore decrease the query delay; but the risk is that C moves to another grid and therefore increase the reroute delay; b) after receive service request, D still query GNRS server for C's NA. [[BR]] |
| | 109 | Total service time T = T1 + T2 + T3 + sum of chunk # of T4 + sum of reroute # of T7 [[BR]] |
| | 110 | |
| | 111 | 5. Peer-to-Peer application (between two mobile nodes): event list is pre-generated before, bidirectional communication [[BR]] |
| | 112 | Assumption: mobile node A and B, A's original grid router C, A's original grid GNRS server D, A's new grid router E, A's new grid GNRS server F, B's original grid router G, B's original grid GNRS server H, B's new grid router I, B's new grid GNRS server J. [[BR]] |
| | 113 | |
| | 114 | (1) Mobile node A initiate the communication. A sends query message to its local GNRS server D for B, query delay is T1. [[BR]] |
| | 115 | (2) A sends a packet (the first packet carries A's binding information) to B. The latency is T2. [[BR]] |
| | 116 | T2 is proportion to the distance between A and B (approximately distance between the two grids + distance from mobile nodes to local routers) [[BR]] |
| | 117 | (3) Packet from A to B delivered successfully, time is T3. [[BR]] |
| | 118 | a) Transmission delay T4: T4 = packet size / transmission rates [[BR]] |
| | 119 | b) A sends ACK to B: T5, same as T2 (assume stop & wait transmission) [[BR]] |
| | 120 | T3 = T4 + T5 (T3 may vary since T5 may change for different chunk as A is moving) [[BR]] |
| | 121 | (4) Packet delivery fails: reroute, delay is T6. [[BR]] |
| | 122 | a) delay of discovering the failure: T3 [[BR]] |
| | 123 | b) latency of A's update: T0 (during T3, A might start updating its binding, so T0 and T3 may overlap) [[BR]] |
| | 124 | c) latency of query for A's new binding: T1 [[BR]] |
| | 125 | d) delay of routing from B to A: T2 [[BR]] |
| | 126 | T6 <= T3 + T0 + T1 + T2 [[BR]] |
| | 127 | |
| | 128 | (1) -(4) are traffic from A to B. Traffic from B to A (similar to (2)-(4)) might exist at the same time but seldom. [[BR]] [[BR]] |
| | 129 | |
| | 130 | |
| | 131 | Future optimization / analysis: [[BR]] |
| | 132 | (1) In multimedia on demand application, mobile node D sends service request message to service provider server D encapsulated binding information <GUID, NA> so that D can directly send media file to C's NA without sending query to GNRS server. We can analyze the delay of the two strategies in the scenario : a) D use C's NA carried by the service request directly, therefore decrease the query delay; but the risk is that C moves to another grid and therefore increase the reroute delay; b) after receive service request, D still query GNRS server for C's NA. [[BR]] |
