n Sec. 35.4. The next step is to chart demand for these services on the clock so that we can de- termine the hourly requirement for these services. This may involve evaluating the time-of-day usage of a mix of services, perhaps services used in different base stations. It does not matter which base stations are involved because we are planning transport from MSC-to-PPDN transport, one big packet pipe to the outside world. We then find the busy hour of this mix of services and do the traffic engineering to ensure low delay for the maximum packet load. This is the amount of transport re- quired for these services. The packet pipe from the MSC to the PPDN will have to have at least this much capacity. Now we can go to the next level of delay requirement. The next level may be a lower level of the same service, perhaps a Web browsing service that allows 3 seconds of de- lay when there is a premium service with a half-second maximum wait. Whatever the second tier of services may be, these are the services we add to the list. Again, we eval- uate the demand for these services by time of day to get a full usage picture. Now we take the total packet data demand of the first two tiers of service and the de- lay requirement of the second tier and do another traffic engineering exercise. If this calculation gives a bigger capacity requirement than the first tier alone, then we ex- pand the transport requirement to this amount. We repeat this process for each delay requirement until all the data and other ser- vices are represented. In each cycle of the traffic engineering process, we use all the data requirements for this level and all previous levels, and we use the delay require- ments for this level. There will be enough capacity to carry all the top-level data with top-level delay, all the top-two-level data with second-level delay, all the top-three-level data with third-level delay, and so on. Any one of these levels could produce the maxi- mum capacity requirement for the MSC-to-PPDN packet pipe, so we need to check 