2E1512 - Wireless Networks - Project Report Do-It-Yourself-Radio: an Ad-Hoc User Centric Solution all the Way Down from Content Creation to Broadcast Distribution The Royal Institute of Technology Radio Communication Systems Lab Students:
Nicolas Debernardi Markus J¨ager Jean-Christophe Laneri Malek Sraj
Advisor:
Pietro Lungaro
June 11, 2005
Abstract
User-deployed networks present a promising approach for the provision of mobile podcasting services at low infrastructure and maintenance costs. In this report, user-to-user communication (multihopping) is considered to improve overall system performances as well as to reduce infrastructure costs. The performance of three specific podcasting services with different ’live’ behaviors are investigated by means of simulations. For each service, we analyze the improvements offered by the introduction of multihopping in function of the access point and user densities; comparisons between services are drawn. It is shown that multihopping provides a significant gain in terms of service performance, or dually, in terms of infrastructure cost. As a result, this networking strategy shows a great potential, and appears to be a good candidate for future practical low-cost infrastructure deployments.
Contents
Table of Contents
vi
List of Figures
vii
Introduction 1 System Definition 1.1 Infrastructure . . . . . . . . . 1.2 Environment . . . . . . . . . 1.2.1 Mobility Model . . . . 1.2.2 Propagation Model . . 1.3 Downlink Access Protocol . . 1.4 Peer to Peer Access Protocol
1
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
3 3 3 3 4 4 5
2 Context, Parameters and Performance Evaluation 2.1 Fixed Parameters: Multihopping Capability . . . . . 2.2 Design Parameter: Time Offset . . . . . . . . . . . . 2.3 Performance Measures . . . . . . . . . . . . . . . . . 2.3.1 Cost of a System Configuration . . . . . . . . 2.3.2 Relative Gain of Multihopping . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
7 7 8 9 9 10
3 Service Definitions 3.1 Service 1: Playlist . . . . . . . . . . . . . . . . 3.2 Service 2: Talk Show . . . . . . . . . . . . . . . 3.3 Service 3: Playlist plus News . . . . . . . . . . 3.4 Service-independent Performance Improvements
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
11 11 12 12 14
4 Simulation Results 4.1 Service 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Simulation Parameters and Implementation Aspects . . . . 4.1.2 Service Cost Improvements Offered by Multihopping . . . . 4.1.3 Infrastructure Cost Improvements Offered by Multihopping 4.2 Service 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Simulation Parameters and Implementation Aspects . . . . 4.2.2 Service Cost Improvements Offered by Multihopping . . . . 4.2.3 Infrastructure Cost Improvements Offered by Multihopping 4.3 Service 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Simulation Parameters and Implementation Aspects . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
15 15 15 16 16 19 19 19 20 22 22
. . . .
. . . .
. . . .
4.3.2 4.3.3
Service Cost Improvements Offered by Multihopping . . . . . . . . . . . . . . . . . 22 Infrastructure Cost Improvements Offered by Multihopping . . . . . . . . . . . . . 22
Conclusion and Future Work
25
Bibliography
27
List of Figures
1.1
Rate model for base-station to user and user to user transmission . . . . . . . . . . . . . .
5
2.1 2.2 2.3
Connection distance between users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multihopping efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relation between time offset and time without sound . . . . . . . . . . . . . . . . . . . . .
7 8 9
3.1 3.2 3.3 3.4 3.5 3.6 3.7
Definition of service 1 . . . . . . . . . . . . . . . . Playlist consumption considering different offsets in Definition of service 2 . . . . . . . . . . . . . . . . Success and failure in service 2 . . . . . . . . . . . Definition of service 3 . . . . . . . . . . . . . . . . Sample event flow in service 3 . . . . . . . . . . . . File availability and consumption in service 3 . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
11 11 12 12 13 13 13
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10
Relation between time offset and failure time for service 1 . . . . . . Iso-Cost density couples for service 1 when multihopping is disabled Iso-Cost density couples for service 1 when multihopping is enabled . Improvements offered by multihopping in service 1 . . . . . . . . . . Improvements offered by multihopping in service 2 . . . . . . . . . . Iso-Cost density couples for service 2 when multihopping is disabled Iso-Cost density couples for service 2 when multihopping is enabled . Improvements offered by multihopping in service 3 . . . . . . . . . . Iso-Cost density couples for service 3 when multihopping is disabled Iso-Cost density couples for service 3 when multihopping is enabled .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
17 17 18 18 20 21 21 23 24 24
. . . . . . service 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Introduction
Podcasting, a new way of distributing audio content via the Internet, has become increasingly popular recently. In this type of radio service, all audio content is created by the users themselves. Subscribers of podcasting services automatically download this listener-submitted content, which is published on certain websites, to their computers or portable devices as soon as new data is available. A further step of this approach of a do-it-yourself radio is taken within this project: it considers the distribution of the data independently of a public infrastructure via user-deployed networks. User-deployed networks are based on the sharing of private high speed access points in order to provide a common service to their subscribers. This new network paradigm of exploiting privately owned equipment for the provision of public services is seen as a promising approach for future mobile networks as it lowers the infrastructure and maintenance costs [1, 2]. However, it suffers in general from a ’spotty’ coverage and therefore continuous connections cannot generally be provided. As the key parameter to satisfy is always the user service perception, it is though possible to offer more delay tolerant applications (e.g. podcasting) under the assumptions that the sparsity of the infrastructure is hidden to the end users. This can be achieved by considering intelligent agents running on the mobile devices, communicating and exchanging data between each other. Thereby, the users themselves do not experience the sparsity. In order to increase the coverage without equipping additional access points, it has been proposed to allow end users to communicate with each other. This so-called multihopping usually designs an extension of the access point coverage using other mobile stations as ’relays’ [3]. In [4], a system is considered where users interested in the same data can share it between each other. In this way the desired information is spread epidemically from terminal to terminal when users meet. Within this project we extend the model of the networking paradigm given in [4] by analyzing the influence of both the user and access point densities on the user performance perception for specific podcasting radio services. Furthermore, a more appropriate mobility model considering pedestrians walking in an urban environment is implemented. Access points deliver popular content in small parts to the users located within a certain radius and the users subsequently share the missing parts among each other. Three different services, which differ in the broadcast strategy at the access points and the priority of the files, are considered. Whereas in [4] the authors did not focus on any particular type of service, the network we want to design must handle radio type services. Those services should basically emulate standard hertzian radio programs, or at least make the user feel so. A typical radio program has a very specific structure: most of the time only songs and music are broadcast, eventually interrupted by human speech (news flashes or animator transitions). The user is mainly interested in hearing the speech interruptions on time and in order, but can accept rearrangements or even repetitions in the list of songs. Exploiting the relative
2
flexibility of the user concerning the order of the songs, we may be able to offer a service that a user will perceive as good, at a low cost for the network. The knowledge of the specificities of the service allows us to decrease the requirements on the network, without reducing the user-perceived performance. Problem Statement. In this project we analyze the feasibility of providing specific radio programs in sparse user-deployed networks with respect to user experience and infrastructure density. Furthermore, we quantify the impact of multihopping on the provision of such services. The main issues dealt with in this project can be summarized by the following set of questions: Can services characterized by a certain degree of live behavior (such as hertzian radio) be provided in a spotty coverage network? To what extent can the sparsity of the infrastructure be compensated by an opportunistic exchange of information between the users (multihopping)? How are infrastructure density, the gain introduced by multihopping and the service provision related to each other? The report is composed of four chapters: In Chapter 1 a description of the system model is given. Chapter 2 and 3 are devoted to the definition of services and their performance evaluation. Furthermore, some simulation-related parameters are introduced. The simulation results and their analysis are presented in Chapter 4. Finally, the project is summarized and future work issues are discussed.
Chapter
1
System Definition In this section we will describe how the system is structured as well as the different models used for mobility and communication.
1.1
Infrastructure
The wireless infrastructure is assumed to consist of randomly deployed W LAN access points1 according to a uniform distribution over an area A = 1 km2 . It is also assumed that the whole bandwidth W is available to be used by the public, without any bandwidth reserved neither to a specific group nor to the owner in case of a privately owned base-station. Furthermore, the base-stations are able to communicate with one another as well as with the primary data source, the server, through wired networks of ’infinite’ bandwidth 2 .
1.2
Environment
The environment is urban with a dense population and thus this will give rise to a high density of privately deployed wireless base-stations. The project is aimed at studying the different densities of the base-stations as well the density of the users who are using a certain service. Due to computational costs we limited our user-density to a maximum of 160/km2 . A major city such as Paris has a population density as high as 20000/km2 . Our studies, in such a case, take into account that less than 0.8 % of the population, within an area A, is using the services offered by the deployed base-stations. More users will simply utilize multihop communication better.
1.2.1
Mobility Model
The mobility model used is the same as the one used in [5]. It is similar to the model presented in [6], adapted to the pedestrian case. The movement of the users is described by three parameters; speed, relative change in direction, and the average distance that a user maintains in a particular direction. After a user moves a given distance in a certain direction the variables are recomputed. A new relative change in direction is generated from a Gaussian Mixture distribution: 1 From
this point on the term base-station will be used other words, we assume the network to have perfect knowledge of system state, thus it is able to take ideal decisions. Furthermore, the data does not suffer any delay on its way from the source to the base station 2 In
4
System Definition
fϕi (ϕi ) =
4 X
2
pk √
k=1
(ϕi −φk ) 1 2 e 2σϕ 2πσϕ
π π 4,−4,π
Whereby the variable φk = 0, has the probabilities presented in Table 1.1. σϕ represents the standard deviation of the normal distributions of all four directions. pφ1 0.5
pφ2 0.2
pφ3 0.2
pφ4 0.1
σϕ 0.3925
r (m) 100
v (m/s) 1.34
σv (m/s) 0.26
Table 1.1: Mobility model parameters
The distance for which the user stays in the same direction is Rayleigh distributed with 2
fri (ri ) =
ri ri − 2σ e r2 ri ≥ 0 σr 2
p where ri is the distance to be covered before a change in direction, σr = r 2/π is the standard deviation of r and r is the average distance the users stay in a specific direction. The velocity of a given user is recalculated whenever the user changes direction according to the following Rician distribution 2
fvi (vi ) =
2
vi − vi2σ+v2 vi v v I ( e ) vi ≥ 0 0 σv 2 σv 2
Defining vi as the speed of the user before a change in direction and σv as the standard deviation of v while v is the average speed at which the users are moving for a distance ri .
1.2.2
Propagation Model
Communication between the users and the base-stations will be simplified to line of sight (LOS) communication. A noise figure of 12 dB, a bandwidth W = 20 M Hz, and a noise spectral power density N0 = −174 dB/Hz are assumed, which corresponds to a noise power of N = −88.98 dB. This model has been proposed to model propagation of W LAN 802.11g operating in the 2.4 GHz frequency band [7]. This project is a first study and will be assessed in an ideal environment, thus interference will not be considered. The path loss is modeled according to a dual slope model depicted below. 40.2 + 20log10 (r) if r ≤ 8 m Lb (r) = 28.498 + 33log10 (r) if r ≥ 8 m Whereby r denotes the distance between the two communicating devices.
1.3
Downlink Access Protocol
The base-stations transmit at a constant power 3 of Pt = 20 dBm with perfect link adaptation. The largest range for a possible connection is assumed to be the range at which a rate of 1 M bps is achievable; to comply with the 802.11g rate bounds, a maximum rate of 54 M bps is set. The values for Pt and additional losses are the same as in [5]. Thus the achievable rate (Shannon bound) is computed as follows, Pr (r) being the received power at a distance r: 3 It has been shown in [8] that a constant power level can provide almost the same capacity as when using a power control scheme.
1.4 Peer to Peer Access Protocol
5
54 Rd (r) = W log2 (1 + 0
Pr N )
if r ≤ 12.4 m if 12.4 m ≤ r ≤ 57.3 m if r ≥ 57.3 m
The downlink access protocol is based on proximity and the need of the user. If two users are within the connection range of a base-station, connection priority is given to the user in need of certain files available at the base-station. However, if both users need these files, connection is established with the closest user. As long as the user is the closest and in need of files available at the base-station, the whole bandwidth is allocated to the connection. Files with priority are downloaded first, and files with the same priority are downloaded with no particular order. The randomness in the latter case will help enhance user to user communication. If the files are downloaded in a particular order most users will have the first few files, thus less peer to peer communication will occur and more dependence on the base-stations.
1.4
Peer to Peer Access Protocol
The users transmit at a constant power of Pt = 10 dBm with perfect link adaptation. Users are limited with 802.11g rate bounds. Hereafter, the largest range for communication is calculated in a similar fashion to the one for the base-station to user communication, using the propagation model in 1.2.2. Further computations for the value of D will be performed in 2.1. The maximum transfer rate is set to 54 M bps; thus, the achievable bit rate for peer to peer communication is computed as if r ≤ 5.33 m 54 RP 2P (r) = W log2 (1 + PNr ) if 5.33 m ≤ r ≤ D m 0 if r ≥ D m Figure 1.1 depicts Rd and RP 2P with D set to 28.5 m, where the rate is 1 M bps. 7
6
x 10
Base station to user (Rd) User to user (Rp2p) 5
Rate (bit/s)
4
3
2
1
0
0
10
20
30 Distance [ r ] (m)
40
50
60
Figure 1.1: Rate model for base-station to user and user to user transmission Users share files in a fully cooperative manner, i.e. all users can share all their files. It is evident that the users will remain in connection for a limited time due to the short connection range and mobility; thereafter using a protocol similar to the downlink access protocol is not feasible since a complete transfer of files between them will be rare in a user-dense environment. Competition will be high, in
6
System Definition
other words users will remain in connection for a shorter time because they will loose the ’closest user’ status frequently. Switching between users frequently will not allow a complete transfer of data. The latter being of critical importance, a solution is to keep the users connected to the closest user of interest and maintain the connection as long as they are within communication range. When exchanging files, if both users needed files, they will alternate exchanging these files. The first user to request data will be the first to receive the first file. Since we are not dealing with signaling details, this user will be chosen at random. Files with priority are exchanged first, and files with the same priority are exchanged with out a predefined order, for the same reason explained in the previous section.
Chapter
2
Context, Parameters and Performance Evaluation This chapter presents the parameters that are relevant for the services under study. Then, we use the chosen models to extract some results. Finally, the general evaluation procedure for all the services is defined.
2.1
Fixed Parameters: Multihopping Capability
The typical radio program we described in the Introduction suggests that the minimum non separable part of a radio program be a segment, where the term segment denotes either a complete song, a speech interruption or a complete short news session. From [9], we know that it is feasible to exchange MP3 files in a real infostation environment. In our application, we can expect a segment to be 3 minutes long, which is a usual value for a song broadcast by a commercial radio, and is reasonable for a news break or a short review. The playing rate is defined as in [9]: R = 64 Kbit/s, which is an acceptable audio quality for a radio service; this gives a total segment size of 11.52 M bit. We defined the time in contact by the time two users that get within a range D, stay at this distance, or closer: this concept is illustrated in Figure 2.1. Using the time in contact, and given the path loss and rate models (Shannon bound) defined in Section 1.2, we can derive a pessimistic approximation of the number of exchanged segments when two users meet. Using simulations, we derived the empirical
Figure 2.1: Illustration of the time two users stay within a certain range: a: they are far away; b: they are in range, c: they stay in range, d: they are about to disconnect, f: they are again far away. The users have been with a range D for a duration t4 − t2 s cumulative distribution of the contact time, for different values of D. Assuming that during the time in contact the users can communicate, we make the pessimistic assumption that they use the worst rate possible: the rate at the distance D. This leads to the Figure 2.2(a),
8
Context, Parameters and Performance Evaluation
where the empirical cumulative distribution of the minimum amount of data exchanged between the users is presented for different D. This distribution however, is computed given the users encounter each other: the larger the distance D we consider, the more often the users will meet. 1
100 Segment size: 11.5 Mbit
D= 5.33 m D= 8 m D= 10 m D= 15 m D= 28.5 m
0.9
50
0.8
Mean Rate of encounters (/min)
30
C.D.F. [%]
20
10
In the worst case, less than 20% of the encounters do not lead to an exchange of segments
5
3
D = 5.33m
0.7
0.6
0.5
0.4
0.3
0.2
D = 10m
2
D = 15m
0.1
D = 28.5m 1 6 10
7
8
10
10
9
10
0 20
40
Amount of data (bits)
(a) Empirical cumulative distribution of the minimum amount of data exchanged by users meeting at a distance D, given that they meet.
60
80
ρMS
100
120
140
160
(b) Mean rate of the meetings in min−1 .
Figure 2.2: Multihopping efficiency: minimum exchanged data during a meeting, and meeting rate, with D = 5.33, 8, 10, 15 and 28.5 m and user densities: ρM S = 40, 60, 80, 100, 120, 140 and 160 km2
It can be concluded that, with a segment size of 3 minutes, and for all the assumptions of Section 1.2 (propagation, rate and mobility models), at least 80 % of the encounters between users will lead to an exchange of at least one segment, for a distance D = 28.5m, and more than 99 % if D < 15 m. From this statement, we can deduce our system presents a reasonable multihopping capability: users close enough will be able to share a few segments, but exchanging a large number of segments like 100 is unlikely. Furthermore, communications between users, while providing good broadcasting performance, are really poor in comparison to what can be offered by a base-station. However, these values are conditioned by the fact users meet each other; Figure 2.2(b) presents the mean rate of the encounters , for different user densities (ρM S ) and different meeting distances (D). To deal with the trade-off between probability of meeting and number of files exchanged, we decided to reduce the communication range of the users down to 15 meters, which allows 99 % of the encounters to resut in an exchange and a mean rate of 0.4 encounters per minute: we want connections to be successful, i.e. at least one segment exchanged, and 15m is the smallest distance that satisfy this requirement; a smaller distance would however lead to a smaller expected connection time.
2.2
Design Parameter: Time Offset
In a sparse infrastructure, the so-called ’spotty’ coverage increases dramatically the propagation delay from the base-stations to the mobile stations. That is why it is not possible to start playing as soon as the data is available at the base-stations; data has first to be collected and then played. Thus, we only allow the users to start playing after a given time, the offset: from the time the data is available at the base station, the user has to wait Tof f before starting playing. In our study, Tof f will be a design parameter: we will define in Chapter 3 various services and the corresponding quality of service (QoS) measures. There exists a trade-off between the QoS for the users, and the offset: the larger the offset, the more users can be satisfied, but the larger the delay. We then
2.3 Performance Measures
9
consider a single performance target: the minimum Tof f so that 90% of the users satisfy the QoS defined for the specified service.
2.3
Performance Measures
We have defined Tof f , and set a target so that users are satisfied. But still, the value of Tof f depends on the expected QoS (e.g. time without anything to play). In order to study the goals mentioned in the Introduction, we need to have performance measures that depend only on the network configuration. We define two of these performance measures. The cost in time C, measured in seconds, which gives an idea of the absolute performance of a network (this will be motivated in section 2.3.1). We also define the gains of multihopping as the service gain ∆C and the infrastructure gain ∆BS; both give a measure of the improvement brought by the use of multihopping (the motive will be mentioned in section 2.3.2).
2.3.1
Cost of a System Configuration
Figure 2.3(a) displays for how long already received data can be played as a function of the time, for two different offsets. It appears that the time offset (Tof f ) and the time during which a user has nothing to play (Tf ail ) are related. It can be observed that varying Tof f impacts Tf ail ; here, increasing the time offset results in no failure periods, this is because for the higher Tof f we were able to acquire data before we have nothing to play anymore. This relation is linear: Tof f + Tf ail = k (while Tof f > 0 and Tf ail > 0) as illustrated by Figure 2.3(b). The reason behind this linear behavior can be attributed to the linear consumption of data. Increasing Tof f will allow the user to accumulate more data before starting to consume it, this will push the data consumption line in a parallel fashion and thus the intersection point with the time axis will be pushed further into the future. Increasing Tof f by dT will push the intersection point into the future by dT and thus reducing Tf ail by the same amount. 11 10 9 8
Tfail (s)
7
Time to play
6 5 4 3 2 1
Toff Toff’
Failure
t
(a) Influence of the offset on Tf ail : Tof f leads to a 0 failure, while Tof f is failure free. Time to play
0
0
1
2
3
4
5 6 Toff (s)
7
8
9
10
11
(b) Linear relation between Tof f and Tf ail . Tf ail = 0 ⇒ Tof f = C and Tof f = 0 ⇒ Tf ail = C
Figure 2.3: Relation between time offset and time without data to play.
For a given QoS, the intercept k is independent of the target value of the QoS: it characterizes the system, independently of the requirements. We will denote k as the cost of the network, and define it by: Toff C(ρM S , ρBS ) = Tof f + Ttf ail Toff’ Failure
We denoted by (ρM S , ρBS ) respectively the density if the base-stations and the density of the mobile stations, both per km2 ; this couple of densities is the system configuration.
10
Context, Parameters and Performance Evaluation
C(ρM S , ρBS ) can be interpreted as the total delay needed for content delivery, for a given network configuration (ρM S , ρBS ). It is then possible to split this time between Tof f and Tf ail in function of the service requirements, user wishes, etc. This higher level design decision is not considered in this work. This approach allows us to compare different services with different requirements, by comparison of the costs.
2.3.2
Relative Gain of Multihopping
The cost C will be estimated for several (ρM S , ρBS ), with multihopping (C M H ) and without multihopping (C SH ). The second performance measure we will consider is the gain ∆C introduced by multihopping, defined as, for a given (ρM S , ρBS ): ∆C(ρM S , ρBS ) = C M H − C SH The measure ∆C will be use to analyse how the use of multihopping increase the performance of different services, and compare these improvements between services, for a given infrastructure density. The dual way of considering the problem is to measure how much the infrastructure density can be reduced by increasing the user density. We define for this purpose ∆BS: ∆BS(ρM S , ρBS , C) =
arg min {ρBS /C SH (ρM S ,ρBS )=C}
(C SH (ρM S , ρBS )) −
arg min {ρBS /C M H (ρM S ,ρBS )=C}
(C M H (ρM S , ρBS ))
Chapter
3
Service Definitions In real life, many different types of radio shows with contents having different importance and specific performance requirements are imaginable. Within this project we distinguish between three different services as described in the following sections.
3.1
Service 1: Playlist 3min
Service 1 considers broadcasting of a certain number of songs, herein after referred to as a playlist, to the subscribers of the service. The complete playlist is pre-defined and therefore already at service start available at the base-stations. The order of the reception of the songs is not relevant to the users as they just want to continuously listen to music regardless of which song is played first. 3min
Simulations are performed for ten songs having a duration of three minutes each, corresponding to a total possible playtime of 30 minutes as shown in 30min Figure 3.1. 3min
Figure 3.1: Definition of service 1. Users listen to a playlist of ten songs. Figure 3.2 depicts a sample event flow for a specific user in service 1 whereby vertical lines correspond to the reception of files and inclined lines to the consumption respectively. The service is implemented in a way that the transmission of the files at the base-stations starts at time zero but the users start listening to the radio after a certain offset. It can be seen that choosing an appropriate offset can reduce or even avoid outage times. Time to play
Full playlist available at BS
0
t1 Toff
t2 Toff’
t3
t4
t5
t
Failure
Figure 3.2: Sample playlist consumption. Properly chosen offsets reduce failures. ti is the time at which the user receives the ith packet from either a base-station or another user.
12
Service Definitions
QoS criterion for service 1. Subscribers are not satisfied in case the service is interrupted and therefore the time users are not able to listen to music is the QoS criterion for this service.
3.2
Service 2: Talk Show
Neglecting the order of the received files as it is done in service 1 is appropriate if there is no correlation in the content of files. However, in talk shows or similar services the order of files is of highest importance. This is the main issue in service 2 (see Figure 3.3). In contrast to service 1, files are not known in advance as service 2 represents a ’live’ talkshow. A new packet becomes available at the base-stations every 3 min. 3min 1
2
3
4
5
6
Figure 3.3: Definition of service 2. Users listen to a talk show composed of 6 files whereby the order is 3min of importance. 1
2
3
4
5
6
7
8
9
10
Failures in service 2 occur in case a user finishes listening to a certain file but the new file is not received yet. If a packet with a playtime of 180 s is received td s too late, the user will listen to the last (180 − td ) s. However, the file will be skipped in case td > 180 s. This ensures a minimum outage time and the punctual start of the next file. Once again, introducing a certain offset reduces outages as the users have more time to receive the packets. Note that the time Tof f corresponds to the total delay in the system as late packets do not effect the start of the following packet. The overall procedure of service 2 is illustrated in Figure 3.4. Failure: packet 2 is received too late Toff
d1
t1
Success
td
d2
t2 d3
t3
d4
t
Figure 3.4: Success and failures in service 2. Choosing the offset is a trade off between delay and number of failures. di and ti are the times at which the ith packet is available at the base-station and received by the user respectively.
QoS criterion for service 2. QoS is defined according to the number of interruptions. In the performed simulations users accept at most one file to be received too late.
3.3
Service 3: Playlist plus News
Service 3 is a combination of the previous two services. Talks or news flashes having a high importance are broadcast in an interval of twelve minutes. Between these checkpoints, users listen to music whereby the order of the songs is not important. A radio show of 30 minutes composed of two news and eight songs is simulated as illustrated in Figure 3.5.
3min Toff
1
2 News
3.3 Service 3: Playlist plus News d1
3
failure
d2
t1
3min
Full playlist available at BS
1
13 t2 d3
News playing
t3
t
2
Figure 3.5: Definition of service 3. Users listen to regular news and music in between. t The objective of this service is to be able to listen to news in time Playlist and to always be able to play songs failure in between. Therefore, failures are experienced if these criteria cannot be met whereby it is distinguished between news and playlist failures as shown in Figure 3.6. In case a news packet is received too late, a song is played instead and the news packet is discarded. If no new song is available, the users experiences an outage of the playtime of one news flash (3 min). News failure
12min Toff
d2 t1
d1
t2
d3 News 1 playing
Full playlist available at BS
t
t3 d4 News 3 playing
Song played instead of news 2
t
Playlist failure
Figure 3.6: Sample event flow in service 3. The upper part of the figure shows the occurrence of failures in the reception of news, the lower one failures in playing music. di and ti are the times at which the ith news packet is available at the base-station and received by the user respectively. The complete playlist as well as the first packet of news are available at time zero at the base-station. Base-stations always only broadcast the latest news file and therefore, the news packet 1 is transmitted for the playtime of four packets (12 min) before a new news packet becomes available. The users start listening to the radio after a certain offset minimizing the failures of the service. The file scheduling and consumption is illustrated in Figure 3.7. Availability of playlist and news 1
Availability of news 2
Toff
12min
12min 1
2
d2
d1
t
Availability of playlist Figure 3.7: File availability and consumption. The total offset for news is Tof f plus the playtime of three songs. Availability of news Access Point
News 1
News 2
QoS criterion for service 3. The offset in this service is defined in order to fulfill two QoS criteria: first, users have to received1at least a predefined percentage of the news flashes in time and second, a d2 t certain total time in failure1 must not be exceeded. As there are only two news packets considered in 1 The
12min total time in failure is composed of the time users cannot listen to songs and news User
Toff
12min 1
2
t
14
Service Definitions
the simulations, the users do not accept a loss of this type of files at all and consequently the total time consists practically only of the time users cannot listen to music.
3.4
Service-independent Performance Improvements
The performance users experience in the specified services can be improved by exploiting the memory capabilities of today’s devices whereby the objective is always to reduce the number of failures. As the memory in today’s devices is not a critical issues any longer, it can be assumed that users are able to keep a huge amount of data on their devices. Considering this fact, subscribers of service 1 and 3 could repeat previously received songs during outage times. Assuming that the users save complete playlists of older radio shows on their devices, the song repertory is bigger and consequently it is ensured that a certain song is not repeated too often. In this way, listeners of service 2 can also insert songs of former playlists if no other data is available. A further possibility of increasing the performance is that subscribers of a certain radio service pre-fetch commercials which are automatically inserted in case of failures. By applying these proposals it is either possible to increase the user satisfaction at a constant basestation density or the reduce the network costs while keeping the users satisfaction at the same level. The multihopping paradigm analyzed within this project introduces an additional improvement as both the users satisfaction and the infrastructure cost can be enhanced in case the user density rises.
Chapter
4
Simulation Results In this chapter, we present our results and analysis in what concerns the services previously defined in Chapter 3. For each of these services, we give some implementation insights, and analyze the performance criteria defined in Section 2.3. For all services, we investigate a two dimensional domain in terms of base-station and user densities. In what concerns the base-station domain, assuming random deployment and ideal frequency issues, 95 % coverage can be obtained with ρBS = 290 [5]. In this Chapter, we consider densities such that ρBS < 100, which corresponds to the base-station density needed for a full coverage under ideal cell planning, interference and channel assignment1 [5]. The density of users in the system is dependent on contextual parameters. In fact, the number of users paying for the same service in a mall can be very high, whereas this number could drastically decrease when considering a traditional urban environment. In this Chapter, we consider densities such that ρM S < 160. In Section 4.1, we present a complete analysis of the results whereas in Sections 4.2 and 4.3, we focus on comparing services between each other.
4.1
Service 1
This service has been defined in Section 3.1. We discuss some implementation aspects and illustrate the linearity between time offset and failure time in Section 4.1.1. In Sections 4.1.2 and 4.1.3, we analyze the improvements offered by multihopping in terms of service cost (∆C), and infrastructure cost (∆BS).
4.1.1
Simulation Parameters and Implementation Aspects
In this scenario, a playlist composed of ten songs of 3 min each is available at the base-stations all the time; this is not a live program. The simulation time is 30 min; it is thus possible to cover the whole period in theory. Note that when simulating this service, we first compute when each user is able to receive each file (according to the rate model), the computation of the minimum time offset being done a posteriori. In other words, the file exchange policy between users is independent of the time offset. This point does not affect the results here: the order in which the files are received is not important. When defining the performance measure C in Section 2.3, we noted the linear relation between the time offset and the failure time. Figure 4.1 gives an illustration of this correlation for different density couples: the introduction of the cost performance measure allows a more general analysis of the service. 1 This
density is used as a reference point.
16
Simulation Results
Figures 4.2 and 4.3 present the minimal reachable cost C for different system configurations when disabling multihopping or not respectively. The data is presented in an Iso-Cost way, in order to evaluate the impact of multihopping. Note that when multihopping is disabled, the Iso-Cost lines are almost flat, i.e. independent of the user density (variations can be explained by the competition for the resources at the base-stations, but also by the variance of the results). In what follows, we analyze these results in terms of service cost and infrastructure cost.
4.1.2
Service Cost Improvements Offered by Multihopping
By comparing Figures 4.2 and 4.3, we see that by enabling multihopping, we allow a large number of configurations to integrate our set of possible costs (300 s to 1500 s). For example, when multihopping is disabled, no system configuration is acceptable for a base-station density less than 30, but if we enable multihopping, a base-station density of 10 becomes acceptable from a user density of 46. Here we can postulate that for any base-station density greater than or equal to one, there exists a user density that allows the service to be provided. Nevertheless, it is important to remind the reader that in this work, interference is not considered (see Section 1.2). In other words, the equivalence we are presenting here can be assumed to be optimistic. However, the relative gains ∆C and ∆BS offered by multihopping should not suffer from this assumption2 . For system configurations that are acceptable in both cases (multihopping enabled or not), it is interesting to evaluate the relative gain ∆C we can reach3 . This quantity is presented in Figure 4.4(a) for some base-station densities. The gain globally increases for all base-station densities with the number of users in the system but is smaller and flatter as the base-station density increases. In fact, if the number of base-stations is large, the users will rely more on the base-station to mobile transmissions than on the mobile to mobile transmissions4 . Note that, fixing the user density, the gain step between two base-station densities is not constant. In fact, the less the number of base stations, the greater is the gain.
4.1.3
Infrastructure Cost Improvements Offered by Multihopping
Figure 4.3 allows us to introduce a new notion: the equivalence between systems. In fact, if we take as an example the Iso-Cost line where C = 500 s, we see that the density couple (ρM S = 40,ρBS = 55) is equivalent to the density couple (ρM S = 140,ρBS = 30). What is interesting to note is that by moving from one point to the other, we decrease the number of base-stations by 45 %, which is not negligible. Figure 4.4(b) presents the variations of ∆BS for a cost C = 540 s5 . Another interesting analysis is to measure how much we need to increase the base-station and user densities to decrease the cost C by a fixed amount δc . From Figure 4.3, if we set for example δc to 200 s and increase the number of base-stations only, going to C = 1420 s to C = 1220 s can be done from the system configuration (ρM S = 40,ρBS = 13) to (ρM S = 40,ρBS = 16), but decreasing C = 500 s to C = 300 s requires moving from a system configuration (ρM S = 40,ρBS = 55) to (ρM S = 40,ρBS = 95). In other words, the percentage of infrastructure that needs to be added to the past configuration goes from 23 % to 72 %. Including more users in the system, we are able to decrease this infrastructure cost drastically.
2 Note here that the ratio between the powers used by base-stations and mobile-stations is 10. Furthermore, as random deployment is considered, decreasing the density of base-stations could result in a lower interference level. 3 When a configuration is acceptable in only one of the case (multihopping enabled), the gain could be defined as infinite. 4 Multihopping has initially been proposed in order to virtually extend the coverage area of sparse infrastructures. 5 In this analysis, the choice of cost values are taken so that ∆BS can appreciated for all user densities. The slopes of the Iso-Cost lines presented on Figure 4.3 being approximately equal, this analysis can be done without loss of generality.
4.1 Service 1
17
(BS=30,MS=40) 700
Time Offset so that 90 % of the users satisfy the Maximul Failure time (s)
Cost = 800 s
600
500 (BS=30,MS=120)
Cost = 550 s 400
300
(BS=80,MS=40)
200
Cost = 340 s Cost = 300 s 100 (BS=80,MS=120)
0
0
100
200
300 400 Maximum Failure Time (s)
500
600
Figure 4.1: Minimum reachable time offset (Tof f ) in function of the accepted failure time (Tf ail ) for some density couples.
100
300
340
340
90
340
380
380
380 420
420
80
420
460 70
420
460 500
500
ρBS
580
660 700
740 820
940
660 700
660 700 820
900 980
740
940
900 980
1060
1060
580
620
740 780
780
540
580
620
50
30
500
540
540
60
40
460
620
900 980
780 820 940 1060 1220
20
10 20
40
60
80
ρMS
100
120
140
160
Figure 4.2: Iso-Cost density couples when multihopping is disabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 300 s (for quantization reasons), and the maximal cost is set to 1500 s (as a comparison, the system is simulated during 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
18
Simulation Results
100
300 90 340
300
80
300
340 70
38 0
ρBS
60
460 500 540 50 5 80 62 0 66 40 0 740
110
0
20
900
102
0
142
0
10 20
340
42 0
380
940 1100 122
1020
0
40
340
460 500 540 580 620 700 660 740 78 860 8200
7 82800
30
300
38 0
420
60
80
420
380
460 500 54 580 0 62 0
460
420
500 540 580 620
700 660
900
940
860
100
ρ
740
700 660
78 8200 120
140
160
MS
Figure 4.3: Iso-Cost density couples when multihopping is enabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 300 s (for quantization reasons), and the maximal cost is set to 1500 s (as a comparison, the system is simulated during 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
70
600 ∆C(ρMS, 40) ∆C(ρMS, 60)
60
∆C(ρMS, 80)
500
∆C(ρMS,100) Interpolation, ∆C(ρ
MS
Interpolation, ∆C(ρ
, 80)
Interpolation, ∆C(ρ
,100)
MS
50
MS
∆ BS [%]
∆C(ρMS,ρBS)
, 40)
Interpolation, ∆C(ρMS, 60)
400
300
40
30 200
20
100
10
0 0
20
40
60
80 ρMS
100
120
140
160
(a) Cost improvement introduced when enabling multihopping in service 1
0
0
20
40
60
80 ρMS
100
120
140
160
(b) Infrastructure improvement introduced when enabling multihopping in service 1
Figure 4.4: Improvements offered by multihopping. Figure 4.4(a) presents the gain (in seconds) in terms of service (∆C). Figure 4.4(b) shows the gain in terms of infrastructure (∆BS), in percentage of the initial density of base-stations (60), and for a cost of 540 s .
4.2 Service 2
4.2
19
Service 2
This section presents an analysis of the results obtained for service 2 previously defined in Section 3.2. In Section 4.2.1, we explain implementation details for this service and define a simplified service cost, while in Sections 4.2.2 and 4.2.3 we analyze the gain obtained when introducing multihopping in terms of service cost and infrastructure cost respectively.
4.2.1
Simulation Parameters and Implementation Aspects
The principle of this service is to provide the users with a live-like news service that broadcast 3 minutes long files. The simulation time is 18 min (i.e. 6 files). Each file is available at certain instance and is kept available at the base-stations for the rest of the simulation time. It also can be exchanged between the users. The users receive the latest file first and the older ones following it, since the probability of having older files is less as time passes. In this service, we associate the cost C, defined previously in Section 2.3 as the minimum time offset (C = Tof f ). This is because for this particular service no failure time is tolerated. We consider the minimum C that can be obtained for no loss of packets. Tof f is calculated in a similar fashion as in Section 4.1.1, i.e. a posteriori. Since we require the files to be in order here, this might slightly influence the results; in fact the exchange of data between users does not take into account the time offset: some files, having a large delay, and thus considered too old, may still be transmitted when running the simulation. However, since we are not considering a large number of files, this will not be significant. Figures 4.2 and 4.3 present the minimal reachable cost C for different system configurations when disabling multihopping or not respectively. Here as well as in Section 4.1, the Iso-Cost lines are almost flat when multihopping is disabled.
4.2.2
Service Cost Improvements Offered by Multihopping
From Figures 4.6 and 4.7, as well as in Section 4.1.2, we can observe that multihopping permits a larger number of configurations that would satisfy the allowed cost range (300 s to 700 s). With multihopping disabled, the acceptable cost range can not be satisfied for a base-station density less than 80. Yet enabling multihopping, a base-station density of as low as 30 becomes acceptable, starting with a user density of 140. Another interesting point is to note the global higher costs compared to service 1, for a given system configuration, in what concerns service 2. In the case of service 1, the files are already available at the base-stations; when we have a high density of base-stations, the users will have enough data to start playing in less time than that for service 2. For service 2, the data is available at certain times (live-like) and not before; the users will thus need more time to get enough data to start playing, and as a result, the cost will increase. We evaluate ∆C for system configurations that are acceptable when multihopping is enabled and when it is not. ∆C can be noted in Figure 4.5(a). As in section 4.1.2, ∆C increases for all base-station densities with the number of users in the system. However, for the base-station density 100 we notice that in service 1 the improvement due to multihopping is less than that for service 2. Multihopping significantly reduces the delay of spreading the data once it is available. In service 1, all needed data is available once, at the start, and thus for high base-station densities the influence of multihopping is less as time progresses. As for service 2, we have different files available at different times, multihopping is utilized more frequently, and helps in reducing C.
20
Simulation Results
4.2.3
Infrastructure Cost Improvements Offered by Multihopping
The equivalence relation between systems that was explained in Section 4.1.3 is also applicable here: multihopping can still offer a reduction in infrastructure costs despite the strict requirements for this service as opposed to those in service 1. Figure 4.5(b) shows the gain in infrastructure as user density increases. Notice that we approximately have the same slope as in service 1; in other words, we are able to charactrize the impact of multihopping on the infrastructure, independently of the service. However, this impact is only possible after a certain threshold (dependent on the service) in what concerns the density of base-stations. We note a significant increase in the minimum number of basestations needed for service 2 to be provided. The reason behind this is due to the fact that service 2 has more restrictions on the time availability of data, the different files being time-correlated. This will require more dependence on base-stations and thus more base-stations are required to supply this service than for service 1.
60
250 ∆C(ρMS, 90) ∆C(ρMS,100) Interpolation, ∆C(ρMS, 90) 200
50
Interpolation, ∆C(ρMS,100)
40
∆ BS [%]
∆C(ρMS,ρBS)
150
30
100
20 50
10
0
0 0
20
40
60
80 ρMS
100
120
140
160
(a) Cost improvement introduced when enabling multihopping in service 2
0
20
40
60
80 ρMS
100
120
140
160
(b) Infrastructure improvement introduced when enabling multihopping in service 2
Figure 4.5: Improvements offered by multihopping. Figure 4.5(a) presents the gain (in seconds) in terms of service: (∆C). Figure 4.5(b) shows the gain in terms of infrastructure (∆BS), in percentage of the initial density of base-stations (92), and for a cost of 590 s
4.2 Service 2
21
100
530
530 560
590
590 620 650 680
90 620
80
560
560 590 620
620 650
650
70
ρBS
60
50
40
30
20
10 20
40
60
80
100
ρ
120
140
160
MS
Figure 4.6: Iso-Cost density couples when multihopping is disabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 300 s (for quantization reasons), and the maximal cost is set to 700 s (as a comparison, the system is simulated for 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
100
44 53
380
410
0
56 0
410
440
50
0 530
80
650
62
0
70
380
90
470
0
470
560
59
0
590
ρBS
62 0
0
500
590
65
0
50
44
530 560
620
60
47 0
500
530
560 590
620 650
40
68
0
30
20
10 20
40
60
80
ρMS
100
120
140
160
Figure 4.7: Iso-Cost density couples when multihopping is enabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 300 s (for quantization reasons), and the maximal cost is set to 700 s (as a comparison, the system is simulated for 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
22
4.3
Simulation Results
Service 3
Simulation results for service 3, which is defined in Section 3.3, and their analysis is presented in this section. Comparisons are drawn with service 1 and 2.
4.3.1
Simulation Parameters and Implementation Aspects
Service 3 is a combination of the previous two services as it is composed of two order-critical news flashes and a playlist of eight songs that are played in random order. The simulation time is 30 min. As in the previous simulations, the analysis of delayed packets, the outage duration and subsequently the computation of the minimum offset time is done a posteriori. An exchange policy taking into account the time offset is left for future works. As in service 1 the cost resulting from the sum of the time offset and the failure time is used. As there are not only high-priority packets (news) in this service, accepting some failure time is not a problem. As mentioned in Section 3.4, we can imagine that some songs are repeated or some commercials are played in case users do not have any song or news available. The system performance for service 3 without multihopping is presented in Figure 4.9. As for service 1 and 2 it can be seen that the curves are independent of the user densities. The infrastructure requirements are, similar to the results obtained in the multihopping scenario, higher than in service 1 but lower than in service 2. Figure 4.10 presents the minimal reachable cost C for different system configurations having multihopping enabled. As in the previous services, the number of required base-stations for a certain cost decreases with increasing users densities.
4.3.2
Service Cost Improvements Offered by Multihopping
By comparing Figure 4.9 and 4.10, it can be seen that for the given user densities and the analyzed service cost range (250 s to 700 s), a much wider range of base-stations densities is applicable having multihopping enabled. Without multihopping the minimum requirement to achieve costs below 700 s is ρBS = 60; with multihopping the service fulfilling the same performance requirements can be offered with much lower base-stations densities (ρBS = 20 for ρM S ≥ 120). The relative gain in service costs ∆C when enabling multihopping is depicted in Figure 4.8(a). As for the other services and due to the same reasons, the gain increases for higher user densities whereby the rise is more significant for low base-station densities. The gain obtained in service 3 is of course lower than service 2, but higher than in service 1. Service 2 allows the relative gain in cost to be linear in regards to the number of users; still, in service 3, only part of the task is to transmit news segments and thus the requirements are easier to fullfill6 . The improvement in service 3 is thus lower than in service 2, and in fact behaves as in service 1: it increases slowly with the mobile users density. However, it increases faster in service 3 than in service 1. Due to this reasons, the improvements in costs is for example for a base-station and user density of 100 as high as 80 s in service 3 compared to 65 s in service 1. In conclusion, one can state that multihopping helps the playlist-type services, but it improves even more the performance of the pseudo-live-type of services because of their strict requirements.
4.3.3
Infrastructure Cost Improvements Offered by Multihopping
Again from Figure 4.9 and 4.10 it can be seen that for a fixed service cost C the infrastructure requirements can be lowered significantly by enabling multihopping. In order to achieve for example a cost of C = 490 s, the required base-station density can be reduced from on average 75 per km2 without 6 Let us remind that in service 2 the requirements are not to lose any packet out of a total of 6 packets, in a time interval of 30 min; in service 3, we relax the number of unlosable packets to 2, over the same time interval.
4.3 Service 3
23
multihopping down to 30 for a user density of 160 having enabled multihopping. Figure 4.8(b) presents the gain in terms of infrastructure introduced by multihopping (∆BS) for C = 490 s. As the slopes are very similar for all cost in Figures 4.9 and 4.10, this gain is representative for other cost values as well. As mentioned in Section 4.2.3, this gain seems to be representative of the impact of multihopping in general, independently of the service. Again, let us note that this impact is only possible after a certain threshold (dependent on the service) in what concerns the density of base-stations. It is worth mentioning that a certain cost value in service 3 requires higher infrastructure densities than in service 1 (compare Figure 4.3) but significantly lower densities than in service 2 depicted in Figure 4.7. This behavior is in relation to the ratio rc of the number of news flashes and the total number of files offered in the service as well as to the availability duration of the news flashes. Service 1 and Service 2 are the extreme cases with rc = 0 and rc = 1 respectively. Service 3 represents a scenario with two news packets out of a total of ten files (rc = 51 ) and the required infrastructure density is therefore between these two services.
60
250 ∆C(ρMS, 70) ∆C(ρMS, 80) ∆C(ρMS, 90)
50
∆C(ρMS,100)
200
Interpolation, ∆C(ρMS, 70) Interpolation, ∆C(ρMS, 80) Interpolation, ∆C(ρMS,100)
∆ BS [%]
∆C(ρMS,ρBS)
40
Interpolation, ∆C(ρMS, 90)
150
30
100
20 50
10
0 0
20
40
60
80 ρMS
100
120
140
160
(a) Cost improvement introduced when enabling multihopping in service 3
0
0
20
40
60
80 ρMS
100
120
140
160
(b) Infrastructure improvement introduced when enabling multihopping in service 3
Figure 4.8: Improvements offered by multihopping. Figure 4.4(a) presents the gain (in seconds)in terms of service (∆C). Figure 4.8(b), the gain in terms of infrastructure (∆BS), in percentage of the initial density of base-stations (72), and for a cost of 490 s.
24
Simulation Results
100
410
90
410
410
450
80
450 490
450
70
490 530
530
570
ρBS
60
530
570
570
610
450
490
50
40
30
20
10 20
40
60
80
ρ
100
120
140
160
MS
Figure 4.9: Iso-Cost density couples when multihopping is disabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 250 s (for quantization reasons), and the maximal cost is set to 700 s (as a comparison, the system is simulated for 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
100
37 0
90 370
410
370
80
410 70 450
490
50
410
45 0
49 0 53 0
ρBS
60
490
410
45
0
570
40
530
30
490 530 5 610 70
450 490
530 570 610
20
10 20
40
60
80
ρMS
100
120
140
160
Figure 4.10: Iso-Cost density couples when multihopping is enabled. Base-station density is varying from 10 to 100 in steps of 10 and user density is varying from 20 to 160 in steps of 20. The minimal cost is set to 250 s (for quantization reasons), and the maximal cost is set to 700 s (as a comparison, the system is simulated for 30 min i.e. 1800 s). Higher costs are represented by a plain colored zone.
Conclusion and Future Work
In this project, the feasibility of providing three specific radio programs and the impact of a user-to-user communication on the performance of the provision of these programs in user-deployed networks are analyzed. Considering certain quality of service criteria, it has been shown first that the provision of a radio program given an infrastructure density depends on its live behavior, and second multihopping improves the performance in all scenarios whereby the gain is strongly dependent on the base-station and user densities as well as on the considered service. More precisely, the relative improvement in using multihopping increases with declining base-station densities. Furthermore, it has been shown that multihopping allows the use of certain base-station densities that are not possible for the given service quality without enabling the user-to-user communication. Another remarkable issue proved in this project is that the longer the period of validity of a certain file at the base-station is, the greater the impact of multihopping and consequently less base-stations are required. This fact has to be considered when defining services for given base-station and subscriber densities. The performance of services provided in ad-hoc networks strongly depends on the service type. For fixed infrastructure densities, services without any live behavior but with completely pre-defined playlists will perform best. Adding a certain kind of live behavior and consequently reducing the percentage of songs known in advance deteriorates the performance as well as the user satisfaction. To cope with this degradation, higher base-station or user densities respectively have to be provided. The project can be seen as an high level investigation of the applicability of multihopping for the provision of the services defined in Chapter 3. For further research, several additional issues could be taken into consideration to obtain results closer to real-life situations. First of all, the relationship between performance and the total program duration should be analyzed as radio shows often last longer than 30 minutes in practice. Second, the impact of interference should be examined as it is expected to decrease the performance especially for high base-station and user densities. Additionally, power control can be considered in this context. In the performed simulations, all available bandwidth was assigned to the closest user. This access policy could be compared with other strategies, i.e. sharing the bandwidth between all users within a certain range or considering varying rates dependent on the priority of the users. Furthermore, non-cooperative behavior and selfishness of users in the exchange of files is an important issue in reality. A final interesting point is the possibility of having several competing services, which would cause service dependent data rates. In conclusion, it can be said that the results obtained in this project imply that the considered networking strategy shows in general a great potential for future practical implementations as it provides a basis for a low-cost environment for the provision of mobile podcasting services.
Bibliography
[1] J.M. Pereira. Fourth generation: Now, it is personal! In Proc. IEEE PIMRC, pages 1009–1016, 2000. [2] J. Zander. On the cost structure of future wideband wireless access. In Proc. IEEE VTC, pages 1773–1776, 1997. [3] P. Lungaro. Cost/performance trade-offs of ’two-layers’ ad hoc multihop cellular access systems. In Proc. Swedish Workshop on Wireless Ad-hoc Networks, 2004. [4] W.H. Yuen, R.D. Yates, and S.-C. Mau. Exploiting data diversity and multi-user diversity in mobile infostation networks. In Proc. IEEE INFOCOM, pages 2218–2228, 2003. [5] J. Hultell, P. Lungaro, and J. Zander. Service provisioning with ad-hoc deployed high-speed access points in urban environments, 2005. [6] P.I. Bratanov and E. Bonek. Mobility model of vehicle-borne terminals in urban cellular systems. IEEE Transactions on Vehicular Technology, 2003. [7] K.K. Wong and T. O’Farrell. Coverage of 802.11g wlans in the presence of bluetooth interference. In Proc. IEEE PIMRC, 2003. [8] D.J. Goodman, J. Borras, N.B. Mandayam, and R.D. Yates. Infostations: a new system model for data and messaging services. In Proc. IEEE VTC, 1997. [9] P.G. Frankl and D.J. Goodman. Delivering information ”to go” via infostations. WICAT TR 02-008, November 2002.
