Scenarios
Urban
Urban scenarios are perhaps the most common application where traffic can be offloaded from the backhaul
infrastructure. We analyze two scenarios in this case:
- Pedestrian and Vehicular Mesh
This scenario resembles an urban environment where nodes can only move along the grid (streets). Due to the large number
of users, mobile network operators (MNO) turned to small cell densification to cope with the increase in traffic. For our simulations,
half of the nodes are pedestrians (moving at 1 m/s) and half are vehicles (moving at 13 m/s). Node count and simulation area were
calculated using the framework in Constructing MANET Simulation Scenarios That Meet Standards. There is one base station
located at the center of the grid that is used only when end-users cannot fetch the requested content from neighboring nodes.
The following table summarizes the simulation parameters:
| Parameter |
Value |
| Node Count |
25, 50, 75, and 100 |
| Area |
500 x 500 m2 |
| Radio Access Technology |
IEEE 802.11g and LTE |
| Communication Range |
100 m (WiFi), to base station (LTE) |
| Node's cache |
1, 5, 50, 100 kB |
| Cache Policy |
LRU |
| Data Payload |
1 kB |
| Total Contents |
1,000 |
- Vehicular Cloud
Following the findings in Streaming content from a vehicular cloud,
we implemented the concept of a vehicular cloud where utility vehicles serve as data mules to assist end-users in fetching content.
In our implementation, nodes move according to the Manhattan-Grid model. First, the vehicular nodes randomly request contents from
the backhaul network to fill up their caches (i.e., a node will sequentially request as many contents as it can store in its cache,
with the first requested content being randomly selected), then consumer nodes request contents from the vehicular cloud.
If that request times out, pedestrians retransmit to the cellular network. In this scenario, the only communication allowed is
device-to-vehicle and device-to-infrastructure. We vary the number of utility vehicles from 25 to 100 nodes in increments of 25,
while the number of pedestrians remain static at 25 nodes. Moreover, we evaluate the effects that different cache sizes on the
vehicular node has on the network. The expectation is that as the number of vehicular nodes increase, pedestrians will be able
to fetch more contents from them. Similarly, as vehicle's cache size increase, the pool of contents available to pedestrians
will be greater. The following table summarizes the simulation parameters:
| Parameter |
Value |
| Pedestrian nodes |
25 |
| Vehicular nodes |
25, 50, 75, and 100 |
| Area |
500 x 500 m2 |
| Radio Access Technology |
IEEE 802.11g and LTE |
| Communication Range |
100 m (WiFi), to base station (LTE) |
| Node's cache |
50, 100, 150, 200 kB |
| Cache Policy |
LRU |
| Data Payload |
1 kB |
| Total Contents |
1,000 |
Large crowds
Another common application where the infrastructure is pressured is large crowds, e.g., protests, sport events,
or any other event where a swarm of users, much greater than what the network was provisioned to, move to
a specific area. For instance, in The next-generation in-stadium experience,
the authors reported that terabytes of data were transfered via cellular networks (AT&T, Verizon, and Sprint) by in-stadium
fans during the 2015 Superbowl.
- Sport events
We developed a scenario where spectators at an arena are able to watch on-demand replays, reducing the load on the
infrastructure. Our scenario comprises of 200 users in one section of a stadium. Users can communicate with the LTE base
station (in this case a femtocell) as well as other users in the same stands to fetch contents. The replay videos have a
total duration of 20 seconds each, segmented into 2-second chunks (following the MPEG-DASH standard).
The chunk size is 100 kB. We leave the question of fetching different quality levels for future work. In total, five replay
videos are requested by all users, with the video segments being requested in order. However, each user will start requesting
the videos at a random time within a short interval (10 seconds). The reason for this interval is two-fold: in reality,
not all spectators request videos at the same time; second, by using slightly different times, nodes can take advantage of
caching.
