3.2 The TLS Framework
3.2.6 Computational Overhead
In this section, we provide an analysis of the per TTI computational overhead of the TLS framework. TLS TTI level complexity has three components: (i) effect of the scheduling overhead at the boundary of each super-frame at a TTI, (ii) effect of the frame level scheduling overhead on a TTI and (iii) RB allocation overhead at each TTI. The effect of the first component has been determined by first calculating the overall complexity at the super-frame level and then dividing it by the length of the super-frame to obtain amortized complexity. Amortized complexity for the second component is obtained in a similar fashion as the first component. No amortization is actually involved for the third component, this being the actual overhead of the TTI level RB allocator.
Assuming that a super-frame and frame is composed ofp and q TTIs respec- tively, a measure of the per TTI computational complexity of TLS (T(TLS))
may be obtained as shown in equation 3.11.
T(T LS) = T1 p + T2
q +T3 (3.11)
where,T1, T2, T3 are overheads corresponding to the super-frame, frame andTTI level schedulers, respectively.
Super-frame level scheduling overhead (T1):
T1 =Nrt ×O(Overhead of traffic prediction model) +O(Overhead of Cell capacity prediction) +Nrt ×O(Overhead of graceful degradation)
where, Nrt is total number of active RT VBR flows. As traffic prediction, cell capacity estimation and graceful degradation can all be performed in constant time, the overall complexity of T1 reduces to O(Nrt).
Frame level scheduling overhead (T2):
At this level, the overhead is dominated by the complexity of the FLRA. The FLRA scheme (refer Algorithm 1) calls function Schedule Flows (S) thrice - first for RT flows, followed by bursty RT flows and then for NRT flows. Before dis- cussing the overall computational complexity ofFLRA, we first describe here the computational overhead for Schedule Flows(S).
The functionSchedule Flows()inFLRAbucket sorts the flows in non-increasing order of their metric values, for each sub-channel (refer Algorithm 2, lines 1-2).
The bucket sorting procedure takesO(S) time (where, S denotes the set of flows) to order the input queues for each sub-channel. Assuming that there are |Qsch| sub-channels, the complexity for bucket sorting all sub-channel queues becomes O(S× |Qsch|). At each round (refer Algorithm 2, while loop at line 4) and for each sub-channel (refer Algorithm 2, lines 5-16), one unscheduled flow is selected for RB allocation. All the steps between lines 6-16 of Algorithm 2 may be ex- ecuted in O(1) time. Even the removal of a flow from all sub-channel queues (line 11) may be accomplished in constant time by employing a global queue that
3.2 The TLS Framework
maintains the currently remaining data to be allocated for each flow and allowing each sub-channel queue node to point to its corresponding index on the global queue. If we assume that all flows require at-most one RB to transmit their data (in the worst-case), and there are enough flows to consume all RBs in a frame (S ≥ |F| × |Qsch|), then the while loop (lines 4-16) will execute |F| × |Qsch| times. As the complexity for bucket sorting all sub-channel queues (lines 1-2) is O(S× |Qsch|) and the overhead for thewhile loop (lines 4-16) is O(|F| × |Qsch|), the complexity incurred by the function Schedule Flows(S) will beO(S× |Qsch|).
Let us now discuss the overall overhead for the FLRA procedure. As |Qsch| is the total number of available sub-channels, the complexity of the loop in lines 2-3 of theFLRA scheme (refer Algorithm 1) is O(|Qsch|). Further, the overheads in Algorithm 1 due to the function callsSchedule Flows(S) in lines 6, 8 and 12 is O(SRT× |Qsch|),O(SBRT× |Qsch|) andO(SN RT × |Qsch|) respectively. Therefore, the overall complexity of the FLRA procedure will be O(N × |Qsch|), where N =SRT +SBRT +SN RT.
TTI level scheduling overhead (T3):
The TTI level scheduler uses a O(1) overhead look-up on the RB Allocation Matrix (obtained from the FLRA module) to physically allocate RBs at each TTI. Hence, the Overhead T3 is O(1).
Therefore, the amortized per TTI complexity of TLS becomes:
T(T LS) = O(Nrt)
p +O(N × |Qsch||)
q +O(1) (3.12)
In our framework, as super-frame durations are generally of the order of hun- dreds of milliseconds, the super-frame level scheduling overhead may typically be contained within amortizedO(1) time. However, frames within a super-frame oc- cur at much higher frequencies and as discussed above, their overheads at frame boundaries is also high. Therefore, lower frame rates/higher frame durations of- ten allow significant reduction in computational overheads. On the other hand, it has been shown through the experiments conducted in section 3.3.1.2, higher
ALGORITHM 3: Dynamic Frame Size Adjustment Scheme
Input: Running average PLR (P LRavg), Threshold PLR (P LRth), Guard PLR(P LRgd), Minimum frame duration (|F|min), Maximum frame duration (|F|max)
Output: Adjusted frame duration
1 Update the running average PLR (P LRavgi ) for the ensuing super-frame (SFs);
2 if (P LRavgs −P LRth)> P LRgd && |F|>|F|min then
3 |F|=|F| −1 ;
4 else if (P LRsavg−P LRth)< P LRgd && |F|<|F|max then
5 |F|=|F|+ 1 ;
frame durations degrade TLS’ performance in terms of packet loss rates (and also other related parameters). Therefore, maintaining just as much frame rate as is essential to keepPLRbounded within a stipulated threshold (P LRth) often helps contain computational overheads. The slack computational capacity thus scav- enged (if any) through such dynamic frame duration adjustment process may be utilized in efficiently accomplishing various other important activities at eNodeB.
We now describe the dynamic frame size adjustment procedure used in this work.