Transition probability matrix generation:

1. convert timestamp to serial number and then sort
   
2. divide area into grids
   
3. loop: for each taxiid, find current grid & next grid, fill into grid matrix (row is current grid #, column is next grid #)
   
4. get probability matrix by normalizing grid matrix

---

Update generation:

1. set parameters, such as time period (1 day / 1440 mins), GUID (from 1 to 4000), grid number, longitude and latitude range
   
2. initialize the taxi matrix ( GUID | current grid | timestamp), assign current grid according to location matrix which keeps density information about the taxi location, set timestamp to 0
   
3. in every min (timestamp + 1), check every GUID whether it generates update
   
4. compute destination grid number through transition probability matrix (convert to probability CDF matrix); if it is different from source grid number, then generate an update
   
5. write | event type | GUID | source | destination | timestamp | into output file
   

---

table TAXIDATA has all data loaded, table TAXI1 loads only the first data file

table contents are as below
CREATE TABLE TAXIDATA
(
ID NUMBER(10) CONSTRAINT TAXIDATA_ID NOT NULL,
TAXIID NUMBER(7),
LONGITUDE NUMBER(9,6),
LATITUDE NUMBER(8,6),
SPEED NUMBER(3),
ANGLE NUMBER(3),
DATETIME TIMESTAMP(6),
STATUS NUMBER(1),
EXTENDSTATUS NUMBER(1),
REVISED NUMBER(1),
PRIMARY KEY(ID) )
TABLESPACE USERS;

---

The picture shows 10k entries chosen from the first data file. The covered area is longitude from 121.2 to 121.8 and latitude from 31 to 31.5. The area is divided into 10*10 grids, which is 100 grids in total.

---

Discussion:

1. model traffic and speed
   
2. network topology layout
   
3. integrate update and query generation; GNRS performance evalution
   

---

Modeling steps:
1.initialize grids: each grid has a GNRS server, distribute taxies according to location matrix from SUVNet, insert mapping information into GNRS servers (K copies, including local GNRS server and K-1 servers in other grids).
2.generate updates list(according to transition probability matrix) and lookups list(according to modified zipf law), updates and lookups are interleaved in an ascending order of timestamp.
3.update: each update has K copies, one stored in local GNRS, other K-1 copies stored in other GNRS servers which is decided by hash function. Update latency is the distance between local grid and farthest grid of K-1 servers.
4.lookup: hash GUID at local GNRS server, lookup latency is the distance between local grid and nearest grid of K servers.
5.examine each update/lookup in the order of timestamp, calculate average update/lookup latency.

6. application example: multimedia on demand system, peer-to-peer (texting/call) communication
   

(1) multimedia on demand system:

Node A sends a query to local GNRS server for service provider B's GUID; GNRS server returns B's network address; A sends service request to B; B sends media file of size x MB (chunked into k packets)to A, A acknowledge each packet received successfully; A moves to another grid (based on transition probability matrix) during the media file transmission, B fails to receive ACK during to A's change of network address; B queries its local GNRS server for A's network address, if B finds A's network address updated, it sends packets to the new address.

Data to be measured: update / query latency due to A's moving during the media file transmission

(2) peer-to-peer commnuication

Node A and B are mobile nodes. There is a packet flow between A and B. Measure the update / query delay due to their movements.

---

Simulation designs:

1. Initialization
   

(1) Topology

--- Grid setting, e.g. 5 by 5;
--- Infrastructure setting, includes GNRS server, Base station, router. Assume each grid has one GNRS server, one BS, one router. Also assume full connectivity.
--- Device deployment: mobile nodes deployment follow location matrix from SUVNet.
--- Routing strategy for mobile client - static server and mobile client - mobile client communication pattern.

(2) Parameter list

--- Lookup latency
--- Update latency
--- Routing latency (distribution)
--- Application related parameters: file size distribution for multimedia on demand application and peer-to-peer communication application, packet size, transmission time

2. Update
   

(1) Mobile node updates binding to local GNRS server: constant latency
(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)
(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)

update latency T1 = (1) + biggest in (2) + biggest in (3)
or update latency T1 = (1) + biggest in (2) (since after (2), GNRS server is able to answer query)

3. Query
   

(1) Node sends query message to its local GNRS server: constant latency
(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.
(3) B return binding message to A: routing latency is same as latency in (2).

query latency T2 = (1) + (2) + (3)

4. Delivery failure due to node moving
   

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.
(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.
(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.
(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 ).
(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).

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)

Future optimization / analysis:
(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.