CNS: Content-oriented Notification Service
for Managing Disasters
(Extended Materials)
Jiachen Chen∗ , Mayutan Arumaithurai∗ , Xiaoming Fu∗ and K. K. Ramakrishnan†
∗
University of Göttingen, Germany, † University of California, Riverside, U.S.A.
Abstract
Disaster management critically depends on timely and efficient communication. To better deal
with an incident, authorities from different services (e.g., fire, police) and jurisdictions need to work
together in a new dynamically created team, different from their original organizational/administrative hierarchy. Unfortunately, existing solutions (e.g., IP, or traditional telephony) are not wellsuited to deal with such group communication due to the dynamic binding between roles and
individuals, and mobility. A significant burden is placed on administrators to just establish and
maintain necessary channels, distracting them from restoring order. To make things worse, since
senders do not know which individual(s) to send to, information cannot reach the right people,
delaying rescue efforts.
We propose CNS, leveraging the benefits of ICN to provide the essential communication
for efficiently managing disasters. We first design a namespace enabling dynamic creation and
evolution of incident related (sub-)namespaces to represent roles of first responders assigned to
the disaster. This allows first responders to receive the appropriate information on a timely basis,
with senders addressing the recipients based on their roles. Predefined namespace templates for
disaster types minimize management overhead for establishing communication. We also find the
need for a new enhanced forwarding rule to support such a recipient hierarchy.
We have developed a prototype demonstrating feasibility and efficiency. With the help of
large-scale simulations and real-world disaster traces, we compare CNS with an IP-based solution.
CNS can significantly reduce network load and latency in addition to the qualitative benefits of
simplified operations, appropriate prioritization and security.
This material is an extension to the original paper that describes the extended features and
more detailed evaluation preparation and results.
1
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
Contents
I
Support for IP and MobilityFirst
I-A
CNS over IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I-B
CNS over Other ICNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
II
Detailed Evaluation
II-A
Revisit – London Bombing . . . . . . . . . . . . . .
II-B
Lab Test Bed Evaluation . . . . . . . . . . . . . . .
II-B1
Data Set . . . . . . . . . . . . . . . . . . .
II-B2
Evaluation Results . . . . . . . . . . . . .
II-C
Trace Driven Simulation . . . . . . . . . . . . . . . .
II-C1
Data Set . . . . . . . . . . . . . . . . . . .
II-C2
Communication using Content Hierarchy .
II-C3
Communication using Recipient Hierarchy
4
4
5
5
6
7
7
7
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
References
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
2
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
I. Support for IP and MobilityFirst
This section discusses how to deploy CNS over other platforms like IP, NetInf or MobilityFirst. As
we mentioned in the paper, although we use NDN as an example, CNS is an application-layer design
and is able to support different kinds of underlay architectures with proper (minor) adjustments.
A. CNS over IP
The first architecture we are looking at is IP – the most widely deployed architecture nowadays.
As suggested by [1], [2], the ICN can be used as an overlay of IP at the beginning of the deployment
– only the end hosts and some core nodes (e.g., RPs) are ICN nodes. With more users adopt the
ICN semantics, more ICN nodes can be added into the network for efficiency and scalability.
Work in [2] also suggested to use IP multicast to improve the efficiency of one-to-many communication in ICN. It is particularly useful in the communication among the first-responders in a disaster
where most of the traffic is multicast (broadcast among a group of people). The name spaces can
be mapped onto IP multicast addresses (e.g., .../Emergency/AldgateExplosion/FireBrigade 7→
224.0.0.5). By subscribing to proper names (or Content Descriptors, CDs), the application joins
the corresponding multicast groups and the users can get messages accordingly.
The security and the data integrity can be achieved by enforcing rules on the access points.
Since the data packets are signed by the provider using their private keys, and the keys can be
hierarchically verified, the first hop (ICN) routers can decide the priority of a data based on the fact
if the certificate can be rooted back to .../Emergency. On a disaster with infrastructure failure, we
assume that all the routers know how to verify the .../Emergency name space, that is enough to
decide the priority of the messages even when the router is not linked to the backbone. Messages
can also be encrypted using the ABE [3] (where each name space entry can be an attribute) so that
only the certified users can decrypt the messages.
B. CNS over Other ICNs
We also realize that there exist other ICNs like NetInf [4] and MobilityFirst [5]. Of course, we
can try to build an NDN overlay on those architectures similar to IP, but we argue that since
these architectures already separates data/node identity from their locations, we can have a more
light-weight modification to adapt CNS to those architectures.
We suggest to map each node in the name space onto a Globally Unique IDentity (GUID) in
MobilityFirst or a self-certifying name in NetInf. To enable the recipient and content hierarchy (e.g.,
making a call to anyone dealing with the disaster, or sending messages to everyone in the police
team, or listening to an emergency call of Logistics and every sub-topic), we can either use multiple
subscription or have multiple names in the packet.
The multiple subscription solution requires the responders listen to multiple names. E.g., a policeman dealing with triage in Aldgate Bombing need to listen to .../AldgateBombing, .../AldgateBombing/Police and .../AldgateBombing/Police/Triage. When someone sends messages (can
either be Interests or Publications) to everyone dealing with the bombing (.../AldgateBombing)
or everyone in the police team (.../AldgateBombing/Police), he can also receive them.
The multiple names solution requires senders to place more names (or CDs) in the packet header,
but it does not need the listeners listen to multiple names. E.g., a policeman dealing with triage
in Aldgate Bombing only needs to listen to .../AldgateBombing/Police/Triage now, but a commander sending messages to all the policeman dealing with Aldgate Bombing will have to place
.../AldgateBombing/Police, .../AldgateBombing/Police/Triage, .../AldgateBombing/Police/Evacuation, etc. in the header.
Note that the multiple subscription solution will end up having more states (FIB or ST entries) in
the network which might affect the scalability of the architecture, and the multiple names solution
will cause the senders place more names in the data which might affect the convenience of the sender
3
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
...
Emergency
CasualtyBureau
GovernmentNews
...
FireBrigade
Bishopsgate
SnowHill
Commander
Hospital
...
...
EmergencyCall
London
Police
WoodStreet
...
Regional
Local
Incidents
...
AldgateBombing
Ambulance
Police
Commander
PerimeterEstablishment
FireBrigade
...
Triage
...
Evacuation
CommandPost
Fig. 1: Example of CNS name space.
and cause more traffic in the network. Therefore, we appeal to support hierarchical semantics in the
network architecture to reduce the cost for supporting such systems.
II. Detailed Evaluation
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
Here, we present both qualitative and quantitative analysis of CNS. To start with, we revisit the
first 30 minutes of the London bombing scenario and present how CNS could have helped to handle
the situation. Then, with the help of a prototype of CNS that we deployed in our lab test bed and a
synthetic data trace, we prove the feasibility of implementing and deploying CNS and the efficiency
of the proposed recipient hierarchy. A real world topology with a real world trace is simulated in
our own simulator (widely used in previous works [2], [6]–[8]) for a comparison between MobileIP [9]
(architecture used nowadays) and CNS.
A. Revisit – London Bombing
Here we provide a more detailed version of dealing with London Bombing (Aldgate Site) using
CNS. The name space is shown in Fig. 1. The event time line is acquired from [10].
• 8:51 First call of 999, incident aware
The civilian dials the emergency number, the application automatically uses name .../Emergency/EmergencyCall. At this time, no one knows what happened exactly, no incident name
space is added. But the emergency center would request the local police to check the site. The
request is sent to name .../London/Police/BTP. (British Transport Police)
• 8:55 BTP officer on scene
• 8:56 Fire Brigade called to a fire and explosion at Aldgate
BTP officer reports back and the incident is confirmed. The incident management center would
receive the report from BTP and instantiate a bomb incident (or explosion incident) with name
AldgateExplosion under Incidents. To avoid name collision, time stamp can be used in the
name (e.g., AldgateExplosion200507070856). The management center would generate keys
and give them to fire department with a call for unit to Aldgate. The messages are sent via
.../London/FireBrigade/Commander.
• 8:57 4 Fire Brigade units deployed
Fire Brigade commander send deploy command and the keys to .../London/FireBrigade/Bishopsgate. These units would listen to .../Incidents/AldgateExplosion/FireBrigade.
4
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
8:59 Network control center of London Underground asks emergency services to
check Aldgate, Edgware and King’s Cross
The disaster management center creates name spaces for Edgware and King’s Cross (Aldgate
already exists). New deploy commands are sent similar to fire brigade in Bishopsgate.
• 9:01 BTP requested Ambulance to tend to 3-4 walking wounded
BTP officers can report situation directly to the disaster management commander via .../Incidents/Aldgate/Commander. With CNS, since the central controller already knows it is an
explosion (although it might not be aware of a bomb), according to the template, it should
have already dispatched some ambulance units.
• 9:05 London Fire Brigade declared a major incident
The major incident can be declared via .../Emergency/GovernmentNews (to all the civilians),
and via .../AldgateExplosion (to all the officers dealing with the incident).
• 9:07 BTP identified 25 walking wounded, some of whom were badly injured
BTP reports the situation to the incident commander or to the ambulance commander in the
incident. More ambulances can be mobilized.
• 9:07 F London Ambulance Service Emergency Planning Manager advised Central
Ambulance Control to place hospitals on major incident standby, identify safe RP
(Rendezvous Point) in case of CBRN (Chemical, Biological, Radiological or Nuclear)
risk
Nearby hospitals should have been added shortly after the incident name space is created (∼10
minutes ago); The commands will be sent to .../Incidents/Hospitals/Local.
• 9:08 BTP declares a major incident.
With CNS, different departments only need to declare major incident once (as suggested by
[10]), no duplicate declaration needed.
• 9:10 City of London Police recognize explosion caused by a bomb, declare a major
incident.
New status will be reported to the commander. The commander can add extra function names
to the incident based on the bomb incident plan.
• 9:14 F First ambulance arrives at Aldgate. Explosion reported.
Status report sent via .../Incidents/AldgateExplosion/Ambulance.
• 9:19 F BTP formally requested assistance from MPS (Metropolitan Police Service).
MPS belongs to a higher level, in the command chain. They can be reached directly under
.../Emergency or even a name space above based on the real world situation.
• 9:24 F Major incident declared by London Ambulance Service
No duplicate declaration needed with CNS.
We can see that, CNS gives the commanders better flexibility and convenience in the communication. Since all the messages are prioritized (with name prefix .../Emergency), the officers will not
be affected by the large amount of civilian traffic. These benefits can improve the communication
among the officers. Different departments do not need to declare a major incident separately. The
units that are mis-dispatched can be corrected easily. The status exchange can be more efficient and
therefore the top commander can dispatch resources more efficiently according to the severeness of
the situation.
•
B. Lab Test Bed Evaluation
1) Data Set: Our lab test bed comprises of 6 physical machines that are used as routers and are
connected by links with a 100M bps bandwidth and 10ms delay. We use a single server to emulate 63
users and these users can dynamically link (with 50M bps bandwidth and 5ms delay) to any of the
six routers based on their movement pattern. The topology is shown in Fig. 2. The probability of
when they move is based on a uniform distribution of an interval between 2s to 120s. The users form
5
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
Link Settings
R4
Server
Type
router-router
router-endhost
R1
R3
Bandwidth
100M bps
50M bps
Delay
10ms
5ms
R2
R6
R5
Fig. 2: Lab test bed topology.
3 191
3 207
3
3
3
3 213
3
3
3 221
3 220
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
3
3
3
3
3
3
3
3
3
3
3
317 325 362 339 332 328 360 292 360 338 338 311 275 319 320 332
10
1
w/o
8
0.8
Recipient
0.6
6
w/o
0.4
4
Recipient
0.2 Report No. IFI-TB-2015-04, ISSN 21611-1044. – August 18, 2016
Technical
0
0
3 9 15 21 27 33 39 45 51 57 63
3 9 15 21 27 33 39 45 51 57 63
3 9 15 21 27 33 39 45 51 57 63
w/o
Recipient
# of Messages (×100)
(a) Aggregate network load
Loss (100pkts)
80
60
40
20
0
Delay (s)
Load (Gb)
Fig. 3: Recipient hierarchy (# of receivers, # of msgs) in lab test bed evaluation.
# of Messages (×100)
(b) Average delay
# of Messages (×100)
(c) Message loss
Fig. 4: Evaluation result of CNS (w/ and w/o recipient hierarchy) in test bed.
a 3-level quad tree recipient hierarchy and each node in the tree has 3 users. The total simulation
duration is 70 minutes including 4,390 reconnections in total. The total # of messages exchanged is
Technical Report No. IFI-TB-2015-04, ISSN
Technical
1611-1044.
Report–No.
August
IFI-TB-2015-04,
18, 2016
ISSN
Technical
1611-1044.
Report– No.
August
IFI-TB-2015-04,
18, 2016
6, 300 and the size of each message ranges from 1-99 packets (1,500 bytes per packet). Each message
is assigned to a user (sender) and each sender can choose to multicast the message either to his
own department (i.e., a node he is listening to) or to a subordinate department (i.e., a child node).
Messages are sent based on a uniform distribution for a total period of 60 minutes (first message
is sent at minute 5). The responsibility hierarchy and the # of messages on each node is shown in
Fig. 3.
2) Evaluation Results: In Fig. 4, we compare the two variants of CNS (with and without recipient
hierarchy) in terms of the total-traffic, # of packet loss and delay for varying # of messages. Our
results show that CNS with recipient hierarchy has:1) lower total traffic since only one copy of the
message is sent from the sender (see Fig. 4a); 2) much lower delay since fewer packets go through
the RP, thereby facing a smaller queuing delay (see Fig. 4b); and 3) lower packet loss rate since the
solution is able to better aggregate the subscriptions (see Fig. 4c). Through the packets captured
by Wireshark, we see that the computation overhead for per-packet forwarding is <2%. The results
show that the recipient hierarchy is a cost-worthy enhancement to ICN. But note that the result
does not mean that content hierarchy is not efficient. The problem appears since we try to support
6
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
TABLE I: Link bandwidth settings.
Link Type
ISP - ISP
ISP - Domain
ISP - HA/RP
Domain - Router
Router - EndHost
Router - Mobile
Bandwidth
100 M bps
100 M bps
100 M bps
10 M bps
100 M bps
50 M bps
Delay
10 ms
5 ms
10 ms
2 ms
2 ms
5 ms
recipient hierarchy with content-hierarchy logic (it is a mismatch). Both of them are needed in a
complete communication framework.
C. Trace Driven Simulation
Now we simulate CNS with a real-world trace
1) Data Set: We use a real world data set, namely the emergency messages that were sent in the
aftermath of the Haiti earthquake [11], [12]. However, since Haiti’s network topology is not available,
we used San-Francisco’s topology [13].
The topology consists of 232 routers (as shown in Fig. 5a). We distributed these routers into 5
overlapping ISPs, and with each ISP having 5 non-overlapping domains (as shown in Fig. 5). In
the case of MobileIP, we set up one home agent for each ISP at its root node. In the case of CNS,
we have just one RP in the whole network. The link parameters are shown in Table I. We used
relatively low bandwidth links (100M bps per inter-ISP link) since it is just for emergency traffic.
Router processing is set to line speed and Home-Agent processing for redirecting packets is 2ms and
location modification is 5ms. Also note that though the data set is not large, our solution can scale
according to other real world needs.
Haiti’s message data set consisted of only a subset of the actual messages sent, i.e. it had 3,131
messages of the total that were sent in the first month after the earthquake. The time-distribution
of the messages are shown in Fig. 6c. Therefore, in order to scale it up, we used these messages and
squeezed them into a 1 hour trace to emulate the situation of a large number of messages being
sent in the immediate aftermath of a disaster (shown in Fig. 6d). The # of packets (each of 1,500
bytes) per message were obtained by dividing the message size by 50. The messages in the data set
have the latitude and longitude of their origin (shown in Fig. 6a). We mapped these messages into
the San-Francisco map by performing linear transformation and scaling it. The result is shown in
Fig. 6b. Since the dataset is small, we can imagine this to be a small-scale disaster (e.g., highway
bomb). Each emergency message is sent by an end-host linked to the router nearest to the messages’
origin (i.e. based on the message’s latitude and longitude).
The movements of the receivers are based on the San-Francisco cab data trace [14]. The data trace
contains the location of ∼500 cabs recorded periodically in between 2008/05/17 and 2008/06/11.
We assume the cabs have uniform motion between the two records and they will link to the nearest
router in Fig. 5a (note that the routers in the topology have at least 500 meter distance among each
other). Since the reconnection pattern repeats on a daily basis as shown in Fig. 7a, we randomly
picked one day (2008/05/28, Wednesday) as our movement trace. The # of reconnections per minute
is shown in Fig. 7b. We observed that there were 494 cabs in action on this day. Since our message
dataset is compacted to 1 hour, we divided the 1 day cab movement into 24 sub-traces to study the
effects of an emergency (e.g., a bomb detonation) at different time periods to correspond to different
movement patterns and load.
2) Communication using Content Hierarchy: The Haiti message dataset is already separated into
a hierarchy consisting of 8 major categories (e.g., urgencies, urgency logistics, public health, etc.)
7
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
with each category consisting of several sub-categories. The total # of categories is 36, and each
message can belong to multiple categories. We configure each receiver to listen to 1 category, i.e.
the cabs are seen as first responders moving around to help people and they could receive requests
to answer emergency calls.
We compare CNS to MobileIP (Fig. 8) in terms of the # of message losses, aggregate network
load and latency. Our results illustrate that CNS has a significantly lower loss rate (Fig. 8a), lower
network load (Fig. 8b) and lower delay (Fig. 8c) as compared to MobileIP, regardless of which hour
the disaster occurs. This is due to the fact that MobileIP relies on unicast, which results in more
traffic, longer latency (path stretch), and congestion at the 5 home-agents. Moreover, in the case of
MobileIP, the end-host cannot fetch the content from a neighbour who also received that data. Note
that MobileIP consumes 6 times the network load compared to CNS and causes unacceptable delay
(>200s).
On the other hand, CNS can aggregate the subscriptions, lower the probability of message loss
(when you are near a specialist who is also subscribing to the channel or a upper-level channel, your
subscription can work just within 1 hop) and ensure that there is less congestion on the RP even
though there is only one RP compared to 5 home-agents.
3) Communication using Recipient Hierarchy: Finally, we use the Haiti message dataset as a basis
to emulate the information exchange among the authorities to study the benefits of the proposed
recipient hierarchy as compared to content hierarchy. We build a recipient hierarchy containing 6
levels and assign the messages and cabs into the recipient hierarchy randomly.
In Fig. 9, we compare CNS with vs. without recipient hierarchy using the same metrics that we
used to analyze content hierarchy. We can observe that CNS with recipient hierarchy has a slightly
lower loss rate due to improved aggregation. But more importantly, CNS with recipient hierarchy
outperforms the other variant in terms of aggregate network load (almost half) and latency (by up
to 80%) due to its improved design. Solutions such as those proposed in [2], [7], [8] can be used to
increase the number of RPs and load balance among them in order to handle a larger magnitude
of load, thereby benefitting both the variants. But, in this evaluation, we show the difference in
performance in the presence of just one RP to highlight the benefit of the proposed CNS with
recipient hierarchy. These results also confirm the lab testbed based results shown in § II-B.
References
[1] Van Jacobson, Diana K Smetters, James D Thornton, Michael F Plass, Nicholas H Briggs, and Rebecca L
Braynard. Networking Named Content. In CoNext, 2009.
[2] Jiachen Chen, Mayutan Arumaithurai, Xiaoming Fu, and K. K. Ramakrishnan. Coexist: Integrating Content
Oriented Publish/Subscribe Systems with IP. In ANCS, 2012.
[3] Vipul Goyal, Omkant Pandey, Amit Sahai, and Brent Waters. Attribute-based Encryption for Fine-grained
Access Control of Encrypted Data. In CCS. ACM, 2006.
[4] Bengt Ahlgren, Matteo D’Ambrosio, Marco Marchisio, Ian Marsh, Christian Dannewitz, Börje Ohlman, Kostas
Pentikousis, Ove Strandberg, René Rembarz, and Vinicio Vercellone. Design Considerations for a Network of
Information. In ReArch, 2008.
[5] Arun Venkataramani, James F Kurose, Dipankar Raychaudhuri, Kiran Nagaraja, Morley Mao, and Suman
Banerjee. MobilityFirst: A Mobility-Centric and Trustworthy Internet Architecture. SIGCOMM CCR, pages
74–80, 2014.
[6] Jiachen Chen, Mayutan Arumaithurai, Lei Jiao, Xiaoming Fu, and K. K. Ramakrishnan. COPSS: An Efficient
Content Oriented Pub/Sub System. In ANCS, 2011.
[7] Jiachen Chen, Mayutan Arumaithurai, Xiaoming Fu, and K. K. Ramakrishnan. G-COPSS: A Content Centric
Communica- tion Infrastructure for Gaming. In ICDCS, 2012.
[8] Mayutan Arumaithurai, Jiachen Chen, Edo Monticelli, Xiaoming Fu, and Kadangode K Ramakrishnan.
Exploiting ICN for Flexible Management of Software-Defined Networks. In ICN, 2014.
[9] Charles E Perkins. Mobile IP. Communications Magazine, 35(5):84–99, 1997.
[10] London Assembly, July Review Committee, Richard Barnes, et al. Report of the 7 July review committee. Greater
London Authority, 2006.
[11] Wikipedia. Timeline of relief efforts after the 2010 Haiti earthquake. http://en.wikipedia.org/wiki/Timeline_
of_relief_efforts_after_the_2010_Haiti_earthquake.
8
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
[12] datahub.
Haiti Crisis Map.
http://datahub.io/dataset/ushahidi/resource/81d058a8-173a-49d9-8ce94edf5e7cafc9.
[13] Feixiong Zhang, Chenren Xu, Yanyong Zhang, K. K. Ramakrishnan, Shreyasee Mukherjee, Roy Yates, and
Thu Nguyen. EdgeBuffer: Caching and Prefetching Content at the Edge in the MobilityFirst Future Internet
Architecture. In WoWMoM, 2015.
[14] Michal Piorkowski, Natasa Sarafijanovic-Djukic, and Matthias Grossglauser. Dataset of Mobility Traces of Taxi
Cabs in San Francisco, USA. http://crawdad.org/epfl/mobility/20090224/, February 2009.
9
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
ISP1
Dom1
ISP2
ISP3
ISP4
(a) Routers in all ISPs
Dom2
Dom3
Dom4
ISP5
Dom1
Dom5
Dom1
Dom2
Dom3
Dom4
(b) Routers in ISP1
Dom2
Dom3
Dom4
Dom5
Dom5
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044.
Technical
– August
Report
18, 2016
No. IFI-TB-2015-04, ISSN 1611-1044. –
Dom1
(c) Routers in ISP2
Dom2
Dom3
Dom4
Dom5
Dom1
(d) Routers in ISP3
Dom2
Dom3
Dom4
Dom5
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044.
Technical
– August
Report
18, 2016
No. IFI-TB-2015-04, ISSN 1611-1044. –
(e) Routers in ISP4
(f) Routers in ISP5
Fig. 5: San Francisco Router Topology.
10
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044.
Technical
– August
Report
18, 2016
No. IFI-TB-2015-04, ISSN 1611-1044. –
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
(a) Messages in Haiti (original)
(b) Messages in San Francisco (modified)
1
0.8
0.8
0.6
0.6
CDF
CDF
1
0.4
0.4
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – AugustTechnical
18, 2016 Report No. IFI-TB-2015-04, ISSN 1611-10
0.2
0
0.2
0
4
8
12
16
20
24
28
0
32
Days since 2010/01/12
0
10
20
30
40
50
60
Minutes since time 0
(c) Messages in Haiti (original)
(d) Messages in San Francisco (modified)
Fig. 6: Messages transformation Haiti 7→ San Francisco, on space and time.
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August
18, 2016
Technical
Report No. IFI-TB-2015-04, ISSN 1611-104
11
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
2
11 W
10 T
09 M
08 S
07 S
06 F
05 T
04 W
03 T
02 M
6/01 S
31 S
30 F
29 T
28 W
27 T
26 M
25 S
24 S
23 F
22 T
21 W
18 S
20 T
0
19 M
1
5/17 S
Movements (×1000)
3
Date (M/DD Day)
(a) # of cab reconnections per 10 minutes in the whole data set
Movements (×100)
3
2
1
0
Technical Report No. IFI-TB-2015-04, ISSN 1611-1044. – August 18, 2016
0
1
2
3
4
5
6
7
8
9
10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Time (hr)
(b) # of cab reconnections per min on 2008/05/28 (Wednesday)
MobileIP
CNS
0
4
8
12
16
Start Hour
(a) Message loss
20
440
231
Technical
1611-1044. – August 18, 2016
430 Report No. IFI-TB-2015-04, ISSN229
MobileIP
MobileIP
227
420
CNS
CNS
80
.049
75
.048
70
.047
0
4
8 12 16 20
0
4
8 12 16 20
Delay (s)
2.5
2
1.5
1
0.5
0
Load (Gb)
Loss (×1000)
Fig. 7: Cab movement data trace.
Start Hour
Start Hour
(b) Aggregate network load
(c) Average delay
Fig. 8: Simulation result of content hierarchy (Note different scale for Load and Delay).
Loss
80
40
0
0
4
416
24
Technical Report No. IFI-TB-2015-04,
Technical
ISSN 1611-1044.
Report–No.
August
IFI-TB-2015-04,
ISSN
Technical
1611-1044.
Report–No.
August
IFI-TB-2015-04,
18, 2016
41418, 2016
w/o
23
412
Recipient
w/o
85
12.5
Recipient
83
11.5
81
8 12 16 20
0
4
8 12 16 20
0
4
8 12 16 20
Recipient
Start Hour
(a) Message loss
Delay (ms)
w/o
120
Load (Gb)
160
Start Hour
(b) Aggregate network load
Start Hour
(c) Average delay
Fig. 9: Simulation result of recipient hierarchy (Note different scale for Load and Delay).
12
TechnicalReport
ReportNo.
No.IFI-TB-2015-04,
IFI-TB-2015-04,
ISSN1611-1044.
1611-1044.
– August
2016 ISSN
Technical
Technical
ISSN
Report –No.
August
IFI-TB-2015-04,
18,18,
2016
1611-1044.
August
18, 2016
Technical
Report–No.
IFI-TB-2015-04,