1 Introduction

Smartphones are becoming ubiquitous with subscriptions estimated at over 1 billion worldwide and average data traffic generated 365 MB/month by third-generation (3G) users. According to estimations by the International Telecommunication Union [1], in countries where long-term evolution (LTE) networks are available, consumers generate 15 GB/month on average. This important increase in data traffic is expected to be generalized in all networks in the future.

The recent increase in data traffic is mainly due to flat-rate subscriptions offered by operators: users can transfer as much data as they want every month. Right now, some operators define a threshold on the amount of monthly data. Once this threshold is reached, users only get a low data rate. Such a policy is efficient but rather strict.

In dense areas, whatever the operator policy is, the increase in traffic density will be dramatic in the next few years. Hence, deploying femto-cells is the only solution to cope with the demand in hot spots. In rural or semi-urban areas, the traffic increase will be significant but might present some degrees of heterogeneity in both the time and space domains. It is known that the dimensioning of network equipment is done to cope with the traffic conditions for peak hours in the day or even for peak periods in one given day of the week. In a business area, the load in peak hours is very significant compared to the load in off-peak hours. This is due to customers who are routinely concentrated in the same area, and who leave the zone almost simultaneously, thereby transferring data consumption to residential areas.

Therefore, it is interesting to build a solution to regulate traffic as a function of time and location. In some cases, the user can accept the postponement of service delivery and is called a delay-tolerant user (DTU). We propose a solution which benefits from this tolerance. The main concept is that the system is able to monitor the load of each base station, to estimate the achievable data rate, and to decide to trigger the service when the most favorable conditions are fulfilled. With the goal of increasing DTU traffic, the operator can attract users with much lower tariffs for data transferred during times of lower traffic (i.e., when the network triggers the transfer of waiting data). From the user’s point of view, accepting to be a DTU can then be attractive because of the very low-cost monthly subscription and the possibility to keep the same date rate the whole month. From the operator’s point of view, reducing the traffic peak can avoid the necessity to deploy of new base stations, and thus dramatically reducing the cost of the network.

Our goal is to propose a simple solution that can be deployed for every cellular technology with limited software and hardware modifications and that can optimize network performance. Our solution especially targets developing states where increasing the cellular base station density is expensive and difficult because of a lack of transport, electricity distribution.

This contribution is structured as follows. In Section 2, we study the methods and advantages of treating delay-tolerant content. In Section 3, we present our system architecture; then in Section 4, we analyze the system performance and show our test results. Section 5 concludes this contribution.

2 Related work

Increasing the capacity of cellular networks is a major concern for all operators and has been a very important research issue for more than 10 years. Various solutions are possible: densifying the network, deploying micro-cellular base stations, using other technologies like Wi-Fi, or even satellites to offload the cellular network. A huge literature has been produced and cannot be referenced in this article. We focus in the following on solutions that do not add any new access point or base station and really act on the load on the radio interface in a cellular context.

Since the 90s, the objective of mobile telecommunications providers has been to provide wireless services anywhere at any time. However, this is expensive, due to the large number of base stations that have to be deployed to achieve it. A first disruptive approach to this problem was proposed by WinLab [2] and their concept of info-stations. An info-station is an isolated wireless access node that provides a high bit rate but a small coverage area. The transmission power is very low. Hence, the cost per bit is reduced compared to a cellular network, but the latency for the user increases because of the discontinuous coverage. In this case, the data is transferred as soon as the coverage is available. This makes it necessary to prefetch information from remote servers and local caches to reduce latency and to make the discontinuity of the coverage transparent to the user.

In the info-station concept, the network is not always available. This approach was generalized with the concept of delay-tolerant network or disruption-tolerant network (DTN). A typical case of DTN can be found in the satellite domain [3, 4]. Another case is to consider each terminal as a potential forwarder and to develop store-carry-forward protocols as proposed in [5]. This approach is based on device-to-device communications and is thus only interesting with a large density of terminals (e.g., city center).

Prefetching is the silent download of data by a background task before the user orders it. Today, prefetching is the focus of multiple investigations, such as improving energy consumption for sending information [6], or the improvement of service delivery [7]. In [8], a context-based model is presented: a combination of prefetching at the terminals and caching in the network is used to deliver delay-tolerant multimedia content to users of a cellular network. In [9], the same authors present a model to reduce the energy consumption in the terminal by scheduling transfers. The authors conclude that predicting user behavior is the key to effective prefetching.

Prefetching is a controversial feature because some prefetched content may never be really used by the final users. This would cause an increase in traffic, entailing consequences for content servers and the network, as well as cache pollution in the terminal. It can even result in a blocking decision by the network administrator because the terminal shows signs of robot activity. In a prefetching context, having predictions of user behavior can significantly improve the transfer of information as well as the mobile network performance. Thanks to the vast amount of network and performance indicators that are available, prefetching algorithms can be developed in current networks by saving the relevant information on a server [10].

In [11], the authors analyze duplicated transmissions and show that by deploying cache memory in the terminals, the load could be reduced by about 20 %. Sanadhya et al. [12] also proposes a similar approach. If a terminal overhears the radio channel, it can prefetch the content that is transmitted to another terminal if the user is interested in it as proposed in [13]. Duplicated transmissions are thus limited. These proposals are a complementary approach to ours. We consider a mechanism that can delay the service to reduce the peak loads. However, it can be extended to switch off base stations during low load hours as we analyze in [14].

3 Description of the architecture

Our goal is to reduce data consumption at peak hours with a method that can be used in any type of environment without deep modification of the terminal. When a user wants to download something (a video, a file, etc.), a request is transferred through the network, and the network itself decides when it is the right moment to transfer. Like in prefetching solutions, the decision is based on both user behavior and the state of the network. However, in our proposal, we focus on delaying the transfer rather than trying to anticipate it in order to avoid unnecessary transmissions.

Our architecture involves adding a specialized server in the network and an application in the DTU terminals. The server is called a Multimedia Content Delivery Trigger server (MCDT), and it is connected to the supervision system of the cellular network. It therefore knows the load of each node of the network: mainly the base stations but also the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN) in the 3G architecture. When a user wants to download something, the request is intercepted by the MCDT client mobile application in the user equipment (UE) and transmitted to the MCDT server. The MCDT server is then in charge of deciding whether to start the download immediately or to postpone it.

Furthermore, the client mobile application can send reports about the mobile status. The MCDT server can learn user behavior by saving these reports, and can, thus, build profiles of the users. For example, the profile can indicate the most frequent cells in which the user can be found for any time period of the week. Let us imagine that the MCDT server receives a request from a terminal that is in a highly-loaded cell. If it is expected that the user will join either his home network or a low-loaded cell in the next couple of minutes, then the MCDT server decides to delay the download until one of this cells is reached by the terminal. Figure 1 shows the system architecture as well as the main functions of both the mobile application and the MCDT server. The dialog between the MCDT client and the MCDT server is based on hyper text transfer protocol (HTTP). No scheduling algorithm is required in the MCDT server as it only answers to requests sent by the terminal. Each time a report from a terminal is received, the server computes a score (see Section 4.2.1) and either gives a positive or a negative answer to the request.

Fig. 1
figure 1

System architecture

Full size image

Note that our solution can be deployed without any modification of either the protocols (i.e., the radio interface is unchanged) or the nodes (SGSN, GGSN). Hence, this solution can be used for 2G (GPRS), 3G Universal Mobile Telecommunications System, UMTS and 4G (LTE). We checked the feasibility by developing it on a UMTS cellular network. As explained in Section 1, specific billing of DTUs is of high importance. However, the necessary modifications to the billing system are outside the scope of this contribution.

3.1 Mobile application

The mobile application was developed to be embedded in a smartphone. Its two main tasks are (i) to manage items to download and (ii) to periodically generate reports that are sent to the server. These reports are called UE Reports and are structured as shown in Fig. 2. The first time a UE report is sent, it is identified by its international mobile subscriber identity (IMSI), which is sent encrypted for security reasons. A security token is then allocated by the network. This token is then used for subsequent transmissions to identify the subscriber. A UE report includes three types of information:

  • The technical configuration, which includes the type of subscription (personal, business, etc.) and the identity of the terminal

  • The technical status, which includes the battery life

  • A set of radio reports, which includes the collected measurements such as the signal strength

Fig. 2
figure 2

Structure of a UE report

Full size image

The MCDT client application also manages the delay-tolerant content as a list of files that are waiting to be downloaded. This list is filled either manually by the user or automatically by a learning process (e.g., downloading the news every morning or an RSS subscription).

Note that delay-tolerant files in the list are always waiting to be downloaded (postpone), but if a file is added to the list by some entity other than the user (e.g., the MCDT server), it can be considered prefetching. Once a file is downloaded, its related information is sent to the MCDT server.

The reporting process is characterized by two parameters: the measurement period T m and the report period T r (see Fig. 3). A UE report then includes T m /T r radio reports. This makes it possible to minimize the number of messages sent by the UE while maintaining frequent measurements.

Fig. 3
figure 3

Sequence diagram of a download triggered by the MCDT server

Full size image

When a UE report arrives at the MCDT server, an answer is returned regarding the network access as well as timer values (T m and T r ). If the MCDT server answer allows access, the application downloads the elements in the list. The execution of this application is a background task, and it can be stopped either manually by the user or when downloading is accepted.

3.2 MCDT server

The main task of the MCDT server is to deliver a response about network status for a user who is in a specific cell under known radio conditions. The MCDT server can also reduce downloading failures by predicting displacement based on user behavior.

The MCDT server is typically implemented by the operator and located in the mobile core network in order to provide quick responses to users, as well as to maintain a direct connection with the operator’s equipment. The MCDT server must be constantly informed of both user status and network status to save as much information as possible. It is then able to make statistical estimations. Thus, it has a database which is fed by UE reports sent by users, as well as by the network status given by the operator’s equipment. As the MCDT server gets more data over time, a longer time of operation makes more accurate estimations possible. The performance of our algorithm is thus directly related to the amount of information that it can get from users. The MCDT server also has to carry a report with all downloads made, as well as the description of each file, for possible benefit in the billing.

3.2.1 Mobility patterns

Based on reports sent by users, it is possible to design a system capable of providing estimates about the next state of a terminal and to use it both on a temporal and spatial scale. For example, it is possible to avoid overloads in cells having UEs with a high degree of mobility by slightly delaying the traffic of DTU users in order to distribute the load geographically over other cells.

The MCDT server can determine mobility patterns. Patterns makes it possible to see clearly which users have a high probability of handover or which cell is prone to be overloaded, at a certain time of day. Having enough information about user-cell correlation allows an operator to identify residential cells and transit cells, as well as to determine a profile such as commuter user or sedentary user.

3.2.2 Profiles

Users have two profiles: user profile and service profile.

  • The user profile is directly related to the operator subscription, and is unique for each user. Hence, an operator can define fixed files to download depending on the type of user. Additionally, users with higher data can be persuaded by a better offer to become DTUs.

  • Service profiles characterize user behavior. Several service profiles can be defined for the same user: mobility pattern, traffic volume, download frequency, or the most favorite downloaded content. These profiles allow the MCDT server to adjust its decision. For example, for a user who frequently downloads very large files, it is preferable to ensure a good quality connection (i.e., high speed) before transmitting.

The process steps of the client-server structure are illustrated in Fig. 4.

Fig. 4
figure 4

Main steps of the client-server process

Full size image

4 Development, test, and analysis

4.1 The client application

We have divided the terminal functions into two applications: the MCDT list manager and the MCDT service manager (see Fig. 5). They both feed and read a shared database as described below.

Fig. 5
figure 5

Main windows of the client applications

Full size image

Note that the application gives the possibility to the user to force immediate download if he/she wants for his/her own reasons. However, in that case, a specific additional charge should be applied to avoid that all users always use this possibility.

For live content, such as live video streaming, the application will not delay the download but instead will encourage the user to do so by himself when it is relevant from network point of view. This is done thanks to a status icon in the notification bar.

4.1.1 MCDT service manager

The MCDT service manager is responsible for exchanging messages with the server. This application also has a simple graphical interface that allows the user to start, stop, or restart the MCDT service. Client-server exchanges have two main phases. The first one includes the authentication that defines the security rules and the initialization of the timer parameters, such as measurement period (T m ) and report period (T r ). Phase two is the generation of radio reports every T r milliseconds and the transmission of UE reports to MCDT server every T m milliseconds. Every message from the MCDT server can include new values for T m and T r (see Fig. 3). If the server allows the download, then the MCDT service manager stops sending messages and wakes the MCDT list manager application.

4.1.2 MCDT list manager

The MCDT list manager manages the list of all downloads that are currently delayed. Each time it is awakened by the MCDT service manager, it starts to download the entire list. As soon as a download is completed, it is removed from the list and related information is saved in the shared database. This information can then be sent by the MCDT service manager to the MCDT server at an appropriate time. The MCDT list manager also allows users to directly add URLs they want to visit without having to initialize the service (managed by the MCDT service manager). URLs with HTTP-based authentication can be used natively. Other authentication mechanism such as Oauth 2.0 are not yet implemented but will be considered.

4.2 MCDT server development

The server has been developed as a web server with a database. It has a connection to a supervisor server.

4.2.1 Score computation algorithm

When the MCDT server receives a request from a user, it computes a score. The MCDT server then decides to allow the download only if the score is above a given threshold. The threshold is defined for every user profile. The score is calculated per user and includes the following parameters.

  • Stability is related to the number of times that the same cell identifier is present in the last N r requests from the terminal to the MCDT server (e.g., N r =10).

  • The favorite cell is the user’s most visited cell; it makes it possible to foster connections in the coverage area where the user regularly spends time (e.g., at home at night).

  • Signal strength is used to favor low-cost transmissions: if the signal strength is high, an efficient modulation and coding scheme (MCS) can be used by the base station for transmission and hence cost is low. The signal strength is averaged over several successive measurement sample to smooth possible fast variations due to multi-path fading. The bit rate is a function of the signal to interference and noise ratio (SINR) rather than the signal strength (in case of large interference, the rate can be low even with a high signal strength). However, the signal strength was preferred because it is easily available in any terminal.

  • The state of the network is based on the load of several nodes (base stations, SGSN, GGSN...) and is provided by the supervision server.

The score is a weighted average of the different parameters. The weight of each parameter can be specific to the service profile. Furthermore, a global factor can be applied to the score: a small factor is chosen during peak hours and a large factor for off-peak periods.

4.3 Field test

4.3.1 Proof of concept

We implemented the solution in an operational 3G network in order to check the feasibility of the concepts and the validity of the architecture. The client application was developed in Java on the Linux-based Android operating system. The server was coded in PHP, and mySQL was used for the database management system.

We consider a very simple score computation based only on the received signal strength. The download is postponed until the signal strength at the terminal is above a given threshold. The threshold was set to −90 dBm after a test campaign: it was observed that transfers are much faster when the signal received by the UE is above −90 dBm. The test file size is 5 MB. The test scenario is the following: we compare the use of the network by a DTU versus a normal user. We identified two locations, L 1 with good signal strength and L 2 with low signal strength (below −90 dBm). Both users are initially located in the area of poor signal strength and try to request a file download. For a non-DTU, the download starts instantly. If the user is a DTU, the download is postponed until the signal received by the terminal is above the threshold. The test was done ten times in off-peak hours, so we can assume that the same amount of radio resource is allocated to every transmission. Figure 6 shows the average download time for each user (for DTU, it is the pure transmission time without the waiting delay).

Fig. 6
figure 6

Download time for DTU and non DTU-users

Full size image

We note the average transfer time is much higher for non-DTU (\(\overline {T}~=~116.5\text {s}\) versus 25.5) as the transfer is made irrespective of radio conditions. Note that the deviation is also larger (104s versus 4.2). It can be deduced that the use of radio resource by DTUs is divided by 116/25.5 = 4.5 compared to non-DTU. Of course, this is a very rough estimation. A more extensive campaign of tests in different types of cells for various user profiles is necessary to get an idea of the real gain that can be expected.

4.3.2 Battery impact

When MCDT is activated, periodic measurement messages are sent by the MCDT client in the UE, generating additional energy consumption. We then measured the increase in battery consumption as shown in Fig. 7. It can be seen that the additional consumption is less than 10 % when T r = 1800 s.

Fig. 7
figure 7

Impact of the implementation of the MCDT

Full size image

Note that the consumption is lower for T r = 5 s than for T r = 12 s. In 3G systems, there is a timer in the base station: if a UE is silent for a period longer than a threshold, the radio connection is released. Hence, for any subsequent message, the UE has to make a random access to request for that radio connection be set up again. Such a process generates additional messages. For very small T r , the radio connection is maintained between two successive measurement transmissions. For T r ≥ 12, the radio connection is released, and we see the extra consumption due to frequent radio connection initializations and releases.

4.4 Theoretical analysis

4.4.1 Improvement in network performance

In this section, we demonstrate how this solution would improve network performance. To this end, we consider a cell that offers a total bit rate R t o t , and we assume that the most important part of the load is video download. We then consider only this type of traffic: the requests arrived as a Poisson process with parameter λ and the size of files is assumed to be exponentially distributed with mean value F. The total rate is shared among all the downloaders who are assumed to all have the same radio conditions and thus the same data rate. This model is known as processor sharing. It should be noted that the performance of such systems does not depend on the specific distribution of the service but only on the average [16]. As we modify the system by queueing some requests, the insensitivity property is not kept. That is why the exponential distribution of files is assumed. Even if there are a lot of works that propose various laws for the distribution of video files, the exponential study is a first step analysis (same approach as [15].)

When i users are served, the individual service rate is \(\frac {\upmu }{i}\), with μ = R t o t /F. Hence, the global service rate is \(i \frac {\upmu }{i}=\upmu \). In order to guarantee a minimum bit rate R m i n , an admission control is activated by the operator to limit the number of simultaneous downloads to N = R t o t /R m i n .

In this analysis, triggering is not based on radio conditions but on the load of the cell. We define a threshold n on the number of simultaneous downloads. When there are fewer than n downloads, all requests are accepted. When there are more than n−1 downloads, requests by non-DTU users are accepted but requests by DTU users are queued until the load is below the threshold. Note that once a transfer starts, it is never interrupted. Let ρ be the proportion of DTU. Hence, the arrival rate of DTU requests is ρ λ.

The system is modeled as a Continuous Time Markov Chain. The state of the system is fully defined by (i,j) where i is the number of transfers and j is the number of requests in the queue. We define M as the maximum number of requests in the queue. Note that j=0 if i<n as shown in Fig. 8.

Fig. 8
figure 8

Markov chain of a system with delay tolerant user

Full size image

The balance equations of the system are:

$$\begin{array}{@{}rcl@{}} \begin{array}{rll} \lambda\pi{}_{0,0} &= \upmu\pi{}_{1,0} & \\ (\lambda+\upmu)\pi{}_{i,0} &= \lambda\pi{}_{i-1,0}+\upmu\pi{}_{i+1,0}& \text{if } 0<i<n \\ (\lambda+\upmu)\pi{}_{n,0} &= \lambda\pi{}_{n-1,0}+\upmu\pi{}_{n+1,0}\\ &\;\;\,\,\,+\upmu\pi{}_{n,1}\\ (\lambda+\upmu)\pi{}_{i,0} &= (1-\rho)\lambda\pi{}_{i-1,0}\\ &\;\;\,\,\,+\upmu\pi{}_{i+1,0} & \text{if } n<i<N \\ (\rho\lambda+\upmu)\pi{}_{N,j} &= (1-\rho)\lambda\pi{}_{N-1,0}\\ (\lambda+\upmu)\pi{}_{n,j} &= \upmu\pi{}_{n+1,j}+\upmu\pi{}_{n,j+1} & \text{if } 0<j<M\\ & \; \;\,\,\, +\rho\lambda\pi{}_{n,j-1} & \\ (\lambda+\upmu)\pi{}_{i,j} &= \upmu\pi{}_{i,j} +(1\,-\,\rho)\lambda\pi{}_{i-1,j} & \text{if } n<i<N\\ & \; \; \,\,\,+\rho\lambda\pi{}_{i,j-1} & \text{and } 0<j<M \\ (\rho\lambda+\upmu)\pi{}_{N,j} &= (1-\rho)\lambda\pi{}_{N-1,j} & \text{if } 0<j<M \\ & \; \; \,\,\,+\rho\lambda\pi{}_{N,j-1} & \end{array} \end{array} $$
(1)

From Eq. 1, we can then deduce the transition matrix Q. The Markov Chain is irreducible and consists of positive recurrent states. The unique stationary probability vector π is given by:

$$ \pi Q=0 \text{ and } \sum\limits_{j=0}^{M}\sum\limits_{i=0}^{N}\pi_{i,j}=1 $$
(2)

Let P b l o c k be the blocking probability of non-DTU users. We thus have:

$$ P_{block} = \sum\limits_{j=0}^{M}\pi_{N,j} $$
(3)

We compute the performance of a system with the following parameters: F = 10 MB (80 Mbits), R t o t = 3 Mbps (typical rate with UMTS for one user in the cell with average radio conditions), R m i n = 256 kbps. Then, N = 3/0.256 = 12 and μ = 3/80. The service request rate corresponds to the highest possible rate that gives a blocking probability smaller than 1 %. Without DTU, we found that λ = 1/36. We set the proportion of DTU users to 10, 20, and 40 % and chose n = 6. The maximum number of queued requests was fixed to guarantee a blocking probability for DTU users less than 0.05 %.

We searched the highest value of λ that gives the same blocking probability target (1 %) for non-DTU users as in the standard system. Figure 9 shows the relative increase of the load. For 20 % DTU, the cell load may be increased by 7.4 % without any extra resources being allocated by the operator. This capacity increase is moderate but can be much higher with a more fine-tuned management of queued requests. If only the requests of DTU users with bad radio conditions are queued, and if these users are served only when radio conditions improve, then the gain will be higher because DTU users will use a small part of the radio resources.

Fig. 9
figure 9

Performance comparison

Full size image

With the same network structure, the service increases its network performance as a function of ρ. If the proportion of DTU users increases, we can deduce that the queuing delay also increases.

Let P w be the probability that a DTU is queued. It is given by:

$$ P_{w}=\sum\limits_{j=1}^{M}\sum\limits_{i=n}^{N}\pi_{i,j} $$
(4)

The DTU queued average N w is given by:

$$ N_{w}=\sum\limits_{j=1}^{M}j\sum\limits_{i=0}^{N}\pi_{i,j} $$
(5)

In order to estimate the quality of service for DTU users, we compute the average waiting time only for DTU users who wait W D T U . This is given by

$$ W_{DTU}=\frac{N_{w}}{\lambda\rho\,P_{w}} $$
(6)

Figure 10 shows W D T U and P w for each value of ρ. Up to ρ = 20 %, nearly 90 % of the requests are served immediately and the waiting time is less than a minute. At ρ = 40 %, there is a much greater waiting time but it still acceptable. The increase of capacity that is shown in Fig. 9 is obtained at the expense of the delay. It means that the operator has a trade off between maximizing the capacity of the system and guaranteeing an acceptable quality of service to DTU users (by limiting the number of DTUs).

Fig. 10
figure 10

Waiting time (in seconds) for DTU users who wait and probability of waiting

Full size image

When a request from a DTU is queued, measurement reports are sent to the MCDT server. This generates an additional load on the system. We can use the model to get the order of magnitude of this additional load. The average number of reports is W D T U /T r for each request from a DTU that is queued and 1 for each request that is immediately served. Let λ R be the number of measurement report sent per unit time. It is given by

$$ \lambda_{R} = \lambda \left(P_{w} \frac{W_{DTU}}{T_{r}} + (1 - P_{w}) \times 1 \right) $$
(7)

Let L be the size in bits of measurement reports messages. The addition rate is given by

$$ \lambda_{R} = \lambda \left(1 + P_{w} \frac{W_{DTU}}{T_{r}} - P_{w} \right) L $$
(8)

We can compare it with the total rate on the cell (i.e., R t o t = 3 Mbps) as shown in Table 1 for L = 50 bytes. It can be seen that even for the larger proportion of DTU, the additional load is very small compared to the total rate of the cell.

Table 1 Additional load due to measurement reports
Full size table

Variable λ R gives the number of requests per second to the MCDT server. A nationwide network in a country like France typically includes 30,000 cells. With 40 % DTU, the number of requests is 7000 requests per second if there is only one MCDT server for the whole network. If we consider a node like the MME, up to 290,000 messages per second can be processed according to [17]. The MCDT server can then be dimensioned to avoid any bottleneck and a degradation of the QoS due to excessive processing delay.

5 Conclusions and future work

We have proposed an architecture that manages delay-tolerant users and an algorithm that decides when a transfer should be triggered. We have implemented our proposal on an operational network. Furthermore, we have developed an analytical model to compute the gain that can be expected when some transfers are temporarily postponed.

This architecture improves system performance (using underused periods to download), reduces resources spent for network operation, and can also provide a better understanding of customer behaviors. This results in a dynamical adaptation of the network.

This contribution can be integrated as a new service, based on delay-tolerant files to provide content such as television show replays or the press. Using this method, the operator can be sure that the cost of transfer will be minimized and so offer a very inexpensive service.

One interesting extension of the work is to include economical considerations and to study the best pricing strategy between DTU and non DTUs. If the rebate granted to DTUs is large, the proportion of DTUs will be large and the operator can increase the number of subscribers. However, the quality of service of DTU can be bad because of a too large waiting time. On the contrary, if the rebate is too small, the proportion of DTU will be small and the effect is negligible. Finding the best trade-off is thus a key question.