So, what is the idea behind time dependent pricing, STP? The idea is that you're going to be charged not just based on how much you consume, but also when do you consume. And why would this make sense? It will make sense when is available to leverage the following two features: one is a big differential between the peak traffic demand and the valley traffic demand. The second is that some of the applications are delay tolerant. You can wait maybe a few minutes, maybe half an hour, maybe a couple of hours. So, let's see if these two features are indeed here. Now, here's a typical chart of some of our partner ISPs in the U.S. It shows a very typical peak valley differential. If you look at over a period of 24 hours here and you look at the peak traffic versus the bottom traffic, the bottom is actually here, you could easily see a factor of 10 to 20 differential. Even within our factor of half an hour, you can see sometimes a factor of five or so. The average is significantly below the peak traffic. This is a similar story as building a highway. You wonder how many lanes should you build. If you look at the busy highway, you name it, any countries you want, London, Singapore, New York, Sao Paulo - if you really view the traffic based on the peak demand, you're going to need 80 lanes. So, you have to struggle between a severe congestion during the peak hour versus over provision by the peak hour demand. Even if you don't provision 100% of the peak demand, still when the peak demand is many factors bigger than average of the valley, you've got a problem. But you also got opportunity. What if you can dump some of these traffic probably not all of them, into the valley, then that will be very nice. So, the second question is, can the applications on your network tolerate a little delay? Well, it depends on what kind of application. Here, the y axis is volume and the x axis is some measure of time elasticity. Now, some of the applications like streaming, gaming, weather, finance, whether it's high or low volume per session on average, is not that delay tolerant. You want it within a minute, sometimes within a second. But, there are others for example, large e-mail attachment, social network update - Facebook doesn't update instantly - it may take a couple of minutes. So, the time scale is certainly on the order of minutes. And then there are other, for example, a big one is cloud services, they're getting more and more popular these days, or a movie multimedia download, some of the P2P, some of non-critical software downloads and so on. A lot of these can have the elasticity anywhere from say, half an hour to maybe even a few hours. Of course, we have to quantify the notion of different delay tolerance and then leverage that quantitative measure in our pricing optimization, but that's for later. At this point, we just realized that there is indeed an opportunity because you have a big peak value differential, and therefore, you have incentive to chop off some of the peak and dump that into some of the valley hours. At the same time, at least we've got some applications, not all of them, that are delay tolerant to over quite a large dynamic range of delay tolerance. Now, there is also no shortage of challenges. For example, how effective TDP can be in any context such as mobile pricing or broadband price in general, depends on a ratio. The ratio is delay tolerance or delay sensitivity, on the one hand, and price sensitivity or what we call demand elasticity, on the other hand. Depending on which country and what demographic you're talking about, this ratio between delay tolerance and price sensitivity plays a critical role. Another big challenge is that you have to hide the complexity. You cannot bother the consumers to solve math puzzles all the time. There are quite a few ways to do that. For example, on the extreme end, you can even offer a smart fixed price, flat rate. It's almost like going back to the good old days of 2010 and before, except now you would allow the carriers to impart according to your own preferences, schedule some of the traffic away from the peak hours, as long as they are reasonably delay tolerant. So, it is important to decide a right user interface in order for consumers to be able to use it. Now, there is actually no shortage of time dependent pricing adopted already in other industries, in other kinds of networks. Now, this course is online social economic and tech networks. But there are other kinds of network especially transportation and energy networks. Basically, any time you have a cyclic pattern of peaks and valleys, with peak much bigger than the supply can afford to build, you have an opportunity for time dependent pricing in various disguises and implementations. But they all share the common feature that you want to time-shift at least part of the demand that are delay tolerant to gain the benefits of statistical multiplexing, so that different uses don't peak at the same time and you can afford to build a smaller pipe. This is an essential idea behind the ability to scale up services and volume in the Internet. And later, in the next lecture, lecture 13, we will look at more on statistical multiplexing. For example, in the transportation industry, say, urban auto mobile industry, in places such as Singapore or London central business areas, governments have installed some kind of congestion dependent pricing. It could be time dependent, could be location dependent; for example, if you want to enter a certain part of London, then you say what if this is over, say, the time between the morning rush hour to the evening rush hour, they have to pay extra sometimes, substantially more, whereas other time and other areas, you can pay much less. In the energy network, whether it is the current energy grid or is the so-called smart grid, that term is very hot these days and it carries a few different meanings, one of which is so-called demand response. In one of the Homer problems, you will see an exercise to carry through almost mathematically identical analysis into a different physical world of smart grid demand response. The idea again is if you price differently, you can induce different behaviors. Now of course, in energy network, if you're talking about consumer, your home, my home, a, the price sensitivity may not be that high because most of us do not pay a ridiculous or very large electricity bill. Plus the delay tolerance can be quite low because the energy big spenders are usually like a vacuum or driers and is not easily postponable into the middle of the night, unlike mobile data traffic or broadband with a lot of delay tolerant traffic and background traffic. Now, back to our telecom world, for voice calls actually in certain African countries or Middle East or in India, certain carriers have installed already TDP for voice calls. Now, you might think voice calls should be one of the least elastic ones because if I want to call somebody, I probably want to call that somebody. Unlike a background or a download or cloud services that had data. So, our focus now is to go from a voice to data, especially mobile data traffic and look at how these ideas can be generalized and what new challenges do we face over there. Now, one of the challenges is that you need to build a very nice user interface, not just the graphics, "graphics and linkable buttons are important," quoting Steve Jobs, is also about the kind of message you send to the consumers. This is as much about psychology as it is about technology. So, one of the ways to so-called a cruise control autopilot, the consumers can come figure upfront the target monthly expenditure and so on, and which apps can wait a bit longer than the others, and you can also run some learning algorithm to learn their behavior and profile them. Eventually, in real time, the action of wait or not to wait and how long to wait is handled by an agent interfacing with the rest of the network. We can also consider time dependent pricing as a precursor, a special case of the more general congestion dependent pricing. So, it might be 8 pm possibly in a corner in Manhattan, but it so happens that next, say, three minute, very few people using this part of the spectrum. That means you should probably price less because you don't have opportunity cost there and yet, you can use lower price to attract more traffic. These are what we call flashy whitespaces. We don't have time in this course to talk about the notion of whitespace. That means in the electromagnetic spectrum, in different bands, here might be Wi-Fi, here might be GSM, here might be 4G, part of the spectrum is a very sweet premium real estate, if you will on the spectrum. They can penetrate through the walls very well, and they are often used by local TV stations with the content that's increasingly getting obsolete. So, one idea is to reuse some of these either under utilized so-called whitespace spectrum, maybe here is 50MHz, there's another 200MHz or use them for delivering other more popular content more effectively. But these are static y spaces, these underutilized over long time scale and you can see them. There's also much shorter, faster time scale, what we call flashy whitespaces. Even in the heavily congested spectrum, you may see every now and then occasionally in the time frequency grid, this is frequency, this time, in this grid every now and then, certain part is like underutilized, whereas other parts are much more heavily utilized. So, you can think of extensions of time dependent pricing all the way to congestion dependent pricing, all the way to enabling that discovery and utilization of these flashy whitespaces. We talk about spectrum crunch these days a lot. But are we fully utilizing leveraging all the spectrum that we have? Or are we saving a lot of them either because we want to over provision or because we are wasting some of them? So, now before we go any further, let's pull ourselves back down to earth to look at a practical implementation, in particular, a schematic of a basic time dependent pricing. Now, the idea, the economic idea of time dependent pricing is hardly is shocking. You can even say it's quite boring. But to go from economic idea in mathematical equations to a systems implementation on a network such as broadband access over cable modem or 3G or 4G or Wi-Fi even, that is not trivial. We will only have time to take a very quick glimpse. It's also a good way to get us into the next few lectures on technology networks. So, here are the five main modules of a typical TDP schematic. The center of it is the price determination. This is where we have to solve some large scale optimization problem, and say, what price should I set? What rewards should I be announcing and handing away? This depends on the reaction you can expect from the customers. Just like playing chess, you can't just think about your own next move, you have to think about the next move by the opponent in response to your move, and many such steps ahead as a good chess player. So, we have to anticipate the users movement because otherwise we might be simply shifting a peak hour from one hour to another, or even making it even more peaky. And who's going to tell us the potential reaction while profiling engine? It's basically a machine learning engine. And then, these prices will be announced through some kind of a user interface UI, with linkable buttons and nice graphics and so on, it could also involve autopilot. If it's autopilot, users don't have to react to it unless they would like to veto the auto pilot, occasionally. Or it could be going through a specific user-based manual response. Should I wait or should I not wait certain applications in order to save a certain amount of money? Either way, you would then go into a network measurement, part of which stays on the user handset like your phone, part of which goes into the network database owned by the ISPs. And this will in turn complete the loop because user profiling will then learn from such database. And this kind of feedback loop from user reactions to price setting, is very typical of what we have seen a few times already and a couple of times more in this course. So, now we're going to go into a little bit more detail especially the waiting function and the price optimization engine in that schematic.
