Improving the Competitive Ratio of the Online OVSF Code Assignment Problem

: Online OVSF code assignment has an important application to wireless communications. Recently, this problem was formally modeled as an online problem, and performances of online algorithms have been analyzed by the competitive analysis. The previous best upper and lower bounds on the competitive ratio were 10 and 5/3, respectively. In this paper, we improve them to 7 and 2, respectively. We also show that our analysis for the upper bound is tight by giving an input sequence for which the competitive ratio of our algorithm is 7 − ε for an arbitrary constant ε > 0 .


Introduction
Universal Mobile Telecommunication System (UMTS) [1,2] is one of the third generation (3G) technologies, which is a mobile communication standard.UMTS uses a high-speed transmission protocol Wideband Code Division Multiple Access (W-CDMA) as the primary mobile air interface.W-CDMA is implemented based on Direct Sequence CDMA (DS-CDMA), which allows several users to commu-nicate simultaneously over a single communication channel.DS-CDMA utilizes Orthogonal Variable Spreading Factor (OVSF) code to separate communications [3].
OVSF code is based on an OVSF code tree, which is a complete binary tree of height h.The leaves of the OVSF code tree are of level 0 and parents of vertices of level ( = 0, . . ., h − 1) are of level + 1. Therefore the level of the root is h. Figure 1 shows an OVSF code tree of height 4. (Ignore "c 1 , . . ., c 4 " and shaded vertices for a while.We use them later.)Each vertex of level corresponds to a code of level .In DS-CDMA, each communication uses a code of the specific level.To avoid interference, we need to assign codes to vertices of an OVSF code tree so that they are mutually orthogonal, namely, in any path from the root to a leaf of an OVSF code tree, there is at most one assigned vertex.For example, consider the OVSF code tree given in Figure 1.Let (c) denote the level specified by a code c.Suppose that four requests for inserting codes c 1 , c 2 , c 3 , and c 4 such that (c 1 ) = 2, (c 2 ) = (c 3 ) = 1, (c 4 ) = 0 arrive in this order, and that they are assigned as depicted in Figure 1.Then, a request for deleting c 2 arrives and c 2 is removed.Next, a request for inserting c 5 such that (c 5 ) = 3 arrives, but it cannot be assigned unless other codes are reassigned.If c 4 is reassigned to one of the children of the vertex to which c 2 was assigned, we can assign c 5 to the right vertex of level 3.In this case, we need 6 assignments (5 assignments and 1 reassignment).However, if c 2 has been assigned to a vertex in the right subtree of the root, and c 4 has been assigned to a vertex in the left subtree, then we need only 5 assignments.
Erlebach et al. [4] first modeled this problem as an online problem of minimizing the number of assignments, called the online OVSF code assignment problem, and verified the efficiency of online algorithms using competitive analysis.The competitive ratio of an online algorithm ALG is defined as max σ { E ALG (σ) E OP T (σ) }, where E ALG (σ) and E OP T (σ) are the costs of ALG and an optimal offline algorithm, respectively, for a sequence σ of requests, and max is taken over all σ.For the online OVSF code assignment problem, the number of assignments is regarded as a cost.If the competitive ratio of ALG is at most α, we say that ALG is α-competitive.Erlebach et al. [4] developed a Θ(h)-competitive algorithm (recall that h is the height of an OVSF code tree), and proved that the lower bound on the competitive ratio of the problem is 1.5.Forišek et al. [5] developed a Θ(1)-competitive algorithm, but they did not obtain a concrete constant.Chin, Ting, and Zhang [6] proposed algorithm LAZY by modifying the algorithm of Erlebach et al. [4], and proved that the competitive ratio of LAZY is at most 10.Chin, Ting, and Zhang [6] also showed that no online algorithm can be better than 5/3-competitive.
This problem also has an application in assigning subnets to users in computer network managements.An IP address space can be divided into subnets, each of which is a fragment of the whole IP address space consisting of a set of continuous IP addresses of size power of 2. This structure can be represented as a complete binary tree, in exactly the same way as our problem.Usually, the sizes of subnets requested by users depend on the number of computers they want to connect to the subnet, and the task of system managers is to assign subnets to users so that no two assigned subnets overlap.Apparently, we want to minimize the number of reassignments because a reassignment causes a large cost for updating configurations of computers.
Our Contribution.In this paper, we improve both upper and lower bounds on the competitive ratio of this problem, namely, we give a 7-competitive algorithm EXTENDED-LAZY, and show that no online algorithm can be better than 2-competitive.We further show that our upper bound analysis is tight by giving a sequence of requests for which the competitive ratio of EXTENDED-LAZY is 7 − ε for an arbitrary constant ε > 0.
We briefly explain an idea of improving the upper bound.Erlebach et al. [4] defined the "compactness" of assignments, and their algorithm keeps an assignment compact at any time.They proved that serving a request, namely assigning (or removing) a code and modifying the assignment to keep it compact, will cause at most one reassignment at each level, which leads to Θ(h)-competitiveness. Chin, Ting, and Zhang [6] pointed out that always keeping assignments compact is too costly.Their algorithm LAZY does not always keep compactness but makes assignments compact when it is necessary.To achieve this relaxation, they defined a "tank", which is a vertex that virtually contains a code of a lower level.By exploiting the idea of tanks, they proved that the cost of serving each request is at most 5, which results in 10-competitiveness.Our algorithm, called EXTENDED-LAZY, follows this line.We further relax the compactness by defining "semi-compactness".We also use amortized cost analysis, and prove that serving one insertion (deletion, respectively) and keeping the semi-compactness costs at most 4 (3, respectively).This gives a 7-competitiveness of EXTENDED-LAZY.
Related Results.For the online OVSF code assignment problem, there have been some resource augmentation models, namely, online algorithms are allowed to use more bandwidth than an optimal offline algorithm: Erlebach et al. [4] developed a 4-competitive algorithm in which an online algorithm can use a double-sized OVSF code tree.Chin, Zhang, and Zhu [7] developed a 5-competitive algorithm that uses 1/8 extra bandwidth.Recently, Chan et al. [8] gave a 1-competitive online algorithm which uses (h + 1)/2 trees and showed that there is no 1-competitive online algorithm that uses less than (h + 1)/2 trees.They also gave a 2-competitive algorithm with 3h/8 + 2 trees and an amortized (4/3 + α)competitive algorithm with (11/4 + 4/(3α)) trees, for any α where 0 < α ≤ 4/3.
In addition to theoretical analysis, Karakoc and Kavak [9] evaluated the performance of genetic algorithm and simulated annealing by experiments.
Also, there have been several offline results.Minn and Siu [10] developed a greedy algorithm for the problem of finding the minimum number of reassignments to modify the current assignment so that the new code can be assigned, given a current assignment configuration of the tree and a new insertion request.Moreover, Erlebach et al. [4] proved that this problem is NP-hard and developed a Θ(h)approximation algorithm.Erlebach, Jacob, and Tomamichel [11] proved that the problem of finding a sequence of operations that minimizes the number of reassignments, given an OVSF code tree and a whole sequence of requests, is NP-hard and gave an exponential-time algorithm.

Preliminaries
An instance of the online OVSF problem consists of an OVSF code tree of height h and a sequence σ of requests.Each request is either an insertion or a deletion.An insertion i c specifies a code c.Upon receiving an insertion i c , the task of an online algorithm is to assign c to one of the vertices of level (c) (i.e. the level specified by c) of the OVSF code tree, so that the orthogonality condition is not broken.An online algorithm may also reassign other codes (already existing in the tree).A deletion d c specifies a code c which was previously assigned and has still been assigned to the current OVSF code tree.When a deletion d c arrives, the task of an online algorithm is to merely remove c from the tree (and similarly, it may reassign other codes in the tree).Each assignment and reassignment causes a cost of one, but removing a code causes no cost.Without loss of generality, we may assume that σ does not include an insertion that cannot be assigned by any reassignment of the existing codes (in other words, the total bandwidth of codes which should be assigned at any point never exceeds the capacity).
We define terminologies needed to give our algorithm, most of which are taken from [6].Given an assignment configuration, we say that vertex v is assignable if none of descendants, ancestors, or v itself is assigned; in other words, a code can be assigned to v without breaking the orthogonality.We also say that vertex v is dead if v or one of its descendants is assigned.In the example of Figure 2, shaded vertices are assigned, vertices with pluses (+) are assignable, and vertices with stars ( * ) are dead.Note that assignable vertices are all non-dead.If all the assigned vertices are mutually orthogonal and, at any level, all the left vertices (on the same level) to the rightmost dead vertex are dead, then the assignment is called compact.For example, the assignment in Figure 2 is compact.Next, we define statuses of levels.Level is said to be rich if a code of level can be assigned to the leftmost non-dead vertex v at without reassigning other codes; in other words, v is assignable.Otherwise, the level is said to be poor.For example, in the assignment of Figure 2, levels 0, 2, and 3 are rich and levels 1 and 4 are poor.A level is said to be locally rich if the rightmost assigned vertex is the left child of its parent.For example, in Figure 2, only level 0 is locally rich.Note that in a compact assignment, locally rich levels are always rich.We introduce a tank, which is taken from [6]: Suppose that two codes c 1 and c 2 of level 0 arrive when the current configuration is in Figure 2. We can assign c 1 to the leftmost assignable vertex of level 0 with keeping the compactness.However, we cannot assign c 2 with keeping the compactness unless we reassign other codes.If c 2 were a code of level 2, it could be assigned to the leftmost assignable vertex of level 2 without breaking the compactness.The idea of a tank is to do this virtually.See Figure 3 for example.The code c 2 is assigned to x, but we consider as if it were assigned to y, and by doing so, we regard the assignment compact.Formally, we virtually assign a code of level b to a vertex v of higher level t (> b).In this case, v is called a tank and denoted tank[b, t].Levels b and t are called the bottom and the top of tank[b, t], respectively.We say that level (b ≤ ≤ t) belongs to tank[b, t].Note that in the definitions and proofs below, we regard y as "assigned" and x as "unassigned".We also define the semi-compactness.An assignment is said to be semi-compact if the following five conditions are satisfied: (i) All the assigned vertices are mutually orthogonal; (ii) All the left vertices of the rightmost dead vertex are dead at each level; (iii) Each level belongs to at most one tank; (iv) Suppose that there is a tank v(=tank[b, t]) at level t.Then level t contains at least one assigned vertex other than v, and there is no dead vertex to the right of v at t; (v) Levels belonging to tanks are all poor except for the top levels of tanks.Figure 3 shows an example of a semi-compact assignment.

Algorithm EXTENDED-LAZY
To give a complete description of EXTENDED-LAZY, we first define the following four functions [6].Note that a single application of each function keeps the orthogonality, but may break the semi-compactness.However, EXTENDED-LAZY combines functions so that the combination keeps the semi-compactness.
• AppendRich( , c): This function is available if the level of code c is less than or equal to (namely (c) ≤ ), and level is rich.It assigns c to the leftmost non-dead vertex at .Note that if (c) = , this function creates tank[ (c), ].
• AppendPoor( , c): This function is available if (c) ≤ and level is poor.It assigns code c to the leftmost non-dead vertex v at .If there is no such v, abort.Note that if (c) = , tank[ (c), ] is created.Then, it releases a code assigned to a vertex in the path from v to the root and returns it.
(Such a code exists because was poor and v was non-dead.This code is unique because of the orthogonality.) • FreeTail( ): Release the code assigned to the rightmost assigned vertex at level , and return it.
• AppendLeft( , c): This function is available if (c) = .Assign code c to the leftmost assignable vertex at level .
Each of AppendRich, AppendPoor, and AppendLeft yields a cost of 1, and FreeTail does not yield a cost.Now, we are ready to describe EXTENDED-LAZY.Its behaviors on insertions and deletions are given in Sects.3.1.and 3.2., respectively.Executions of EXTENDED-LAZY is divided into several cases.In the description of each case, we explain the behavior of EXTENDED-LAZY, and in addition, for the later analysis, we will calculate the cost incurred and an upper bound on the increase in the number of locally rich levels due to the operations.

Executions of EXTENDED-LAZY for insertions
As summarized in Figure 4, the behavior of EXTENDED-LAZY for an insertion i c is divided into six cases based on the status of the level (c).Case (1): The case that (c) does not belong to a tank and is rich.Execute AppendRich( (c), c).The execution of this case costs 1 and the number of locally rich levels increases by at most one because only (c) changes its status.
Case (2): The case that (c) does not belong to a tank and is poor.Furthermore, if we look at the higher levels than (c) in the order of (c) + 1, (c) + 2, . . ., h until we encounter a level that is rich or a bottom of a tank, we encounter a rich level (say, the level t) before a bottom of a tank.In this case, execute AppendRich(t, c).Note that the new tank[ (c), t] is created.This case costs 1 and the number of locally rich levels increases by at most one since only level t changes its status.

Case (3):
The same as Case (2), but when looking at higher levels, we encounter a bottom b of tank[b, t] before we encounter a rich level.Since this case is a little bit complicated, we give an example in Figure 5, in which (c) = 0, b = 1, and t = 2. First, execute FreeTail(t) and receive the code c of level b (because a level-b code was assigned to level t by exploiting a tank), and then execute AppendPoor(b, c ) (note that b is poor by the condition (v) of semi-compactness)(Figure 5 1 ).Next, receive another code c of level s.Note that there is an assigned vertex at t because of the condition (iv), and hence b < s ≤ t.
Then, using AppendRich(t, c ), assign c to the vertex which was tank[b, t], which creates the new tank[s, t] if s = t (Figure 5 2 ).Now, recall that the level b was poor, and hence c was assigned to a left child.So, the level b is currently locally rich.We execute AppendRich(b, c) (Figure 5 3 ).Note that tank[ (c), b] is newly created.In this case, the cost incurred is 3, and the number of locally rich levels does not change. .Also, note that b currently does not belong to a tank.Hence our current task is to process c of level b where b does not belong to a tank and is poor.So, according to the statuses of levels higher than b, we execute one of Cases (2) or (3).Before going to Cases (2) or (3), the cost incurred is 1 and there is no change in the number of locally rich levels.Hence, the total cost of the whole execution of this case can be obtained by adding one to the cost incurred by the subsequently executed case (Cases (2) or (3)), and the change in the locally rich levels is the same as that of the subsequently executed case.Here we give one remark.Suppose that (c) does not belong to a tank and is poor.Then, we look at higher levels to see which of Cases ( 2) and ( 3) is executed.But, it may happen that we encounter neither a rich level nor a bottom of a tank, namely there is no tank in upper levels and all the upper levels are poor.We define this case as Case (7).However, we can prove the following lemma.Lemma 1.If the semi-compactness is preserved and Case (7) occurs, then there is no configuration that assigns all the current codes.
Proof.We define the bandwidth of a cade c as 2 (c) and the bandwidth of the OVSF code tree of hight h as 2 h .Suppose that the semi-compactness is preserved and Case (7) occurs when an insertion i c arrives.We show that 2 (c) , the bandwidth required by this request, exceeds the bandwidth of the tree not used by the currently assigned codes.
First, we transform the semi-compact assignment to a compact assignment.We remove tanks from the semi-compact assignment.We show that conditions of semi-compactness remain satisfied after the above operation.Conditions (iii), (iv), and (v) remain satisfied for the levels which did not belong to tank[b, t] because no code was released from nor assigned to these levels.Also, conditions (iii), (iv), and (v) remain satisfied for levels which belonged to tank[b, t] because these conditions state on levels that belong to tanks but these levels do not belong to a tank any more since tank[b, t] was removed.(This argument is used several times in the later proofs.)Condition (i) remains satisfied because once two codes overlap, the one, say c, at the higher level is moved immediately.Suppose that c is moved from v 1 to v 2 in this step.Then, v 1 becomes unassigned but is still dead because one of its descendants is assigned.Also, v 2 was the leftmost non-dead vertex at level (c).Hence, Condition (ii) remains satisfied.
If we do the above operation for each tank independently, the initial semi-compact assignment is transformed to a semi-compact assignment with no tanks.By definition, a semi-compact assignment with no tanks is a compact assignment.For example, the semi-compact assignment in Figure 3 is transformed to the compact assignment in Figure 6.Since the levels (c) and higher remain poor, there is no vertex of level (c) which c can be assigned to and the bandwidth which is not used at the levels (c) and higher is 0.Then, we calculate the bandwidth which is not used at the levels lower than (c).We call the vertex v a free-root if v and its all the children are assignable, and its parent is not assignable.Let T denote the set of free-roots.The non-used bandwidth is the total bandwidth of the vertices of T .Each free-root should be the right child of its parent.For, if a free-root is the left child of its parent p, the right child of p is also assignable because of the compactness.Therefore, p is assignable, which contradicts the definition of free-root.Suppose that there are more than one free-roots f and f at the same level , and suppose that f lies to the right of f .As discussed above, both f and f are the right children of their parents.Since both f and f are assignable (and non-dead), all vertices between them are non-dead because of the compactness.In particular, the vertex f immediately left of f is non-dead.Since f is assignable and f is non-dead, the parent p of f and f has no assigned descendants.Moreover, since f is assignable, p has no assigned ancestors.Then p is assignable, which again contradicts the definition.Hence, in a compact assignment, there is at most one free-root at each level.The total bandwidth is then at most As we have mentioned previously, we excluded inputs in which the total bandwidth of all codes which should be assigned exceeds the capacity.Hence, Case (7) does not occur if the semi-compactness is preserved.(Actually, we do not have to exclude this case because our algorithm preserves the semicompactness and detects this situation, and in such a case, our algorithm can simply reject the insertion.) The following lemma proves the correctness of EXTENDED-LAZY on insertions.

Lemma 2. EXTENDED-LAZY preserves the semi-compactness on insertions.
Proof.In order to prove this lemma, we have to show that the five conditions (i) through (v) of semicompactness are preserved after an insertion is served.It is relatively easy to show that (i) is preserved because EXTENDED-LAZY uses only AppendRich, AppendPoor, and FreeTail, each of which preserves the orthogonality even by a single application.So, we show that conditions (ii) through (v) are satisfied after the execution of each of Cases ( 1) through (6), provided that (i) through (v) are satisfied before the execution.
Case (1): It is not hard to see that conditions (iii) through (v) remain satisfied because no tank is created or removed.We check that condition (ii) is satisfied for each group of levels [0, (c)), (c), and ( (c), h].
(c): Since we only append c to the leftmost non-dead vertex at (c), condition (ii) remains satisfied.( (c), h]: Let v be the vertex to which the code c is assigned.Note that by AppendRich( (c), c), some of ancestors of v may turn from non-dead to dead.Suppose that vertex v s of level s (s > (c)) turned from non-dead to dead.Then, by the above observation, v s is an ancestor of v. Next, let v be the vertex which is immediately left of v.Then, since v was dead, v s is not an ancestor of v .As a result, the ancestor of v at level s is the vertex, say v s , immediately left of v s , which implies that v s was dead.Thus, condition (ii) remains satisfied at any level.
will be explained in the following.

Case (I):
The case that (c) does not belong to a tank and is locally rich.Remove c.If c is the rightmost dead vertex at (c), do nothing.Otherwise, use FreeTail( (c)) and receive a code c of level (c).Then, using AppendLeft( (c), c ), assign c to the vertex to which c was assigned.Note that the vertex v which was the rightmost dead vertex of level (c) becomes non-dead after the above operations, which may turn some dead vertices in the path from v to the root non-dead.As a result, an assignment may become non-semi-compact.If the semi-compactness is broken, we use the operation REPAIR, which will be explained later, to retrieve the semi-compactness.The cost of this case is either 1 or 0, and the number of locally rich levels decreases by one without considering the effect of REPAIR.(We later estimate these quantities considering the effect of REPAIR.)Case (II): The case that (c) does not belong to a tank and is not locally rich.EXTENDED-LAZY behaves in exactly the same way as Case (I).Note that vertex v which was the rightmost dead vertex at level (c) becomes non-dead after the above operations, but v is a right child because (c) was not locally rich.Since the semi-compactness was satisfied before the execution, the vertex immediately left of v was (and is) dead, which implies that the parent and hence all ancestors of v are still dead.Thus, we do not need REPAIR in this case.It costs either 1 or 0, and the number of locally rich levels increases by one or remains unchanged because (c) may become locally rich.

Case (III):
The case that (c) belongs to tank[b, t], (c) = t, and t is locally rich.First, remove c.Next, execute FreeTail(t) and receive the code c of level b from tank[b, t].If c was assigned to the vertex immediately left of tank[b, t] at t, do nothing.Otherwise, using FreeTail(t), receive a code c of level t, and using AppendLeft(t, c ), assign c to the vertex to which c was assigned.We then find a level to which we assign the code c .Starting from level t, we see if the level contains at least one code, until we reach level b + 1.Let be the first such level.Then execute AppendRich( , c ), which creates tank[b, ].
If there is no such level between t and b + 1, execute AppendRich(b, c ).In this case, we may need REPAIR.Without considering the effect of REPAIR, it costs either 1 or 2. If it costs 1, the number of locally rich levels stays unchanged or decreases by one, and if it costs 2, the number of locally rich levels decreases by one.

Case (IV):
The case that (c) belongs to tank[b, t], (c) = t, and t is not locally rich.EXTENDED-LAZY behaves in exactly the same way as Case (III).In this case, we do not need REPAIR by a similar observation as Case (II).It costs either 1 or 2, and the number of locally rich levels increases by one.

Case (V):
The case that (c) belongs to tank[b, t], (c) = b, and t is locally rich.First, remove c.If c was the code assigned to tank[b, t], stop here; otherwise, do the following: Execute FreeTail(t) and receive the code c of level b from tank[b, t].Then, using AppendLeft(b, c ), assign c to the vertex to which c was assigned.In this case, we may need REPAIR because tank[b, t] becomes unassigned.The incurred cost is 1 or 0, and the number of locally rich levels decreases by one without considering the effect of REPAIR.
Case (VI): The case that (c) belongs to tank[b, t], (c) = b, and t is not locally rich.EXTENDED-LAZY behaves in exactly the same way as Case (V).In this case, we do not need REPAIR for the same reason as Case (II).The cost is 1 or 0, and the number of locally rich levels increases by one.

Case (VII):
The case that (c) belongs to tank[b, t], b < (c) < t, and t is locally rich.First, remove c.Next, execute FreeTail(t) and receive the code c of level b from tank[b, t].If c was assigned to the rightmost assigned vertex at (c), do nothing.Otherwise, using FreeTail( (c)), receive a code c of level (c), and using AppendLeft( (c), c ), assign c to the vertex to which c was assigned.We then find a level to which we assign the request c in the same way as Case (III).Starting from level (c), we see if the level contains at least one code, until we reach level b + 1.Let be the first such level.Then execute AppendRich( , c ), which creates tank[b, ].If there is no such level between (c) and b + 1, execute AppendRich(b, c ).In this case, we may need REPAIR.Without considering the effect of REPAIR, it costs either 1 or 2. If it costs 1, the number of locally rich levels is unchanged or decreases by one, and if it costs 2, the number of locally rich levels decreases by one.

Case (VIII):
The case that (c) belongs to tank[b, t], b < (c) < t, and t is not locally rich.EXTENDED-LAZY behaves in exactly the same way as Case (VII).In this case, we do not need REPAIR for the same reason as Case (IV).The cost is 1 or 2. The number of locally rich levels increases by one or two when the cost is 1, and by one when the cost is 2.
Recall that after executing Cases (I), (III), (V), or (VII), the OVSF code tree may not satisfy semicompactness.In such a case, however, there is only one level that breaks the conditions of semicompactness, and furthermore, there is only one broken condition, namely, either (ii) or (v).If (ii) is broken at level , level consists of, from left to right, a sequence of unassigned dead vertices up to some point, one non-dead vertex v, a sequence of (at least one) assigned dead vertices, and a sequence of nondead vertices.Note that, if is a bottom of a tank tank[ , t], the last non-dead vertices include a leftmost level-descendant of tank[ , t] (which is non-dead by definition).This non-dead vertex v was called a "hole" in [6].We also use the same terminology here, and call level a hole-level.If (v) is broken at level , is a bottom of tank[ , t] and is rich.Furthermore, level consists of, from the leftmost vertex, a sequence of one or more unassigned dead vertices, a sequence of one or more non-dead vertices, and then the leftmost level-descendant of tank[ , t].We call level a rich-bottom-level.A level is called a critical-level if it is a hole-level or a rich-bottom-level.
The idea of REPAIR is to resolve a critical-level one by one.When we remove a critical-level by REPAIR, it may create another critical-level.However, we can prove that there arises at most one new critical level, and its level is higher than .Hence we can obtain a semi-compact assignment by applying REPAIR at most h times.
We explain the operation REPAIR.If is a hole-level and is not a bottom of a tank, then we execute FreeTail( ) so that we receive a code c and execute AppendLeft( , c), i.e., we release the code c assigned to the rightmost assigned vertex at level , and reassign c to the hole to fill it.(See Figure 8.)In this case, the cost of REPAIR is 1.If is locally rich, the number of locally rich levels decreases by one and at most one critical-level may appear, which means that we may need to apply REPAIR once more.Otherwise, the number of locally rich levels increases by one and a critical-level does not appear.If is a hole-level Figure 8. REPAIR for a hole-level which is not a bottom of a tank.and is a bottom of a tank v(=tank[ , t]), then there is a vertex u that is the leftmost level-descendant of v. Recall that the code virtually assigned to v is actually a code for level and is assigned to u.We release this code c using FreeTail(t) and perform AppendLeft( , c). (See Figure 9.) In this case, the cost of REPAIR is 1.If t is locally rich, the number of locally rich levels decreases by one and at most one critical-level may appear, which means that we may need to apply REPAIR once more.Otherwise, the number of locally rich levels increases by one and a critical-level does not appear.Finally, if is a rich-bottom-level, then we will do the same operation, namely, release the code c from the tank, and execute AppendLeft( , c). (See Figure 10.)In this case, the cost of REPAIR is 1.If t is locally rich, the number of locally rich levels decreases by one and at most one critical-level may appear, which means that we may need to apply REPAIR once more.Otherwise, the number of locally rich levels increases by one and a critical-level does not appear.Proof.Similarly as Lemma 2, we will check that the five conditions (i) through (v) of semi-compactness are preserved for each application of Cases (II), (IV), (VI), and (VIII).For Cases (I), (III), (V), and (VII), since there is no locally rich level at the beginning.The cost of EXTENDED-LAZY for σ is (1) is due to the above analysis, and ( 2) is due to the fact that |D| ≤ |I| since for each deletion, there must be a preceding insertion corresponding to it.Now, the following theorem is immediate from the above inequality.
Theorem 1.The competitive ratio of EXTENDED-LAZY is at most 7.
Next, we give a lower bound on the competitive ratio of EXTENDED-LAZY.
Theorem 2. The competitive ratio of EXTENDED-LAZY is at least 7 − ε for any positive constant ε.
Proof.Consider an OVSF code tree of height h (h ≥ 5).The number of leaves n is 2 h .First, we give following requests in this order (which we call the initialization sequence): n/4 insertions of level-0 codes, an insertion of a level-1 code, an insertion of a level-0 code, an insertion of a level-i code for i = 2, 3, . . ., h − 2 (h − 3 insertions in total), and an insertion of a level-2 code.Note that after the initialization sequence, two tanks (tank[0, 1] and tank[2, h − 2]) are created at the (n/4 + 2)-th and the final request, respectively.EXTENDED-LAZY can serve each insertion with cost 1, thus the cost of EXTENDED-LAZY is n/4 + h.Note that the cost of an optimal offline algorithm OPT is also n/4 + h.Next, we consider the I-sequence, which is defined as the sequence of h − 4 insertions of level-i codes for i = 1, . . ., h−4 (in the increasing order of i).When the I-sequence is given to EXTENDED-LAZY after the initialization sequence, EXTENDED-LAZY executes Case (5) followed by Case (3) for every insertion in the I-sequence.We then define the D-sequence.It consists of the h−4 deletions of level-i codes for i = h − 4, . . ., 1 (in the decreasing order of i).Here, each deletion requires to remove the code which is assigned to the leftmost vertex among all assigned vertices in the corresponding level.If the D-sequence is given to EXTENDED-LAZY subsequently to the I-sequence, then EXTENDED-LAZY executes Case (VIII) for each deletion in the D-sequence.Finally, we define the T-sequence which consists of two requests; the former is a deletion of a level-2 code, which requires to remove the code assigned to the leftmost assigned vertex of level 2, and the latter is an insertion of a level-2 code.For each of the T-sequence, given after the D-sequence, EXTENDED-LAZY executes Cases (I) and (2), respectively.It should be noted that, for EXTENDED-LAZY, the configuration of the OVSF code tree at this moment is the same as the one immediately after processing the initialization sequence.

A Lower Bound
Theorem 3.For any positive constant ε, there is no (2 − ε)-competitive online algorithm for the online OVSF code assignment problem.
Proof.Consider an OVSF code tree of height h (where h is even), namely, the number of leaves are n = 2 h .First, an adversary gives n insertions of level-0 codes so that the vertices of level 0 are fully assigned, by which, an arbitrary online algorithm incurs the cost of n.Then, depending on the assignment of the online algorithm, the adversary requires to remove one code from each subtree rooted at a vertex of level h/2.(Hereafter, we simply say "subtree" to mean a subtree of this size.)Since there are √ n such subtrees, the adversary gives √ n deletions in total.Next, the adversary gives an insertion i c 1 of a level-h/2 code.To assign c 1 , the online algorithm has to make one of subtrees empty by reassignments, for which the cost of at least √ n − 1 is required.
Again, depending on the behavior of the online algorithm, the adversary requires to remove √ n codes of level 0 uniformly from each subtree except for the subtree to which c 1 is assigned.Here, "uniformly" means that the numbers of removed codes for any pair of subtrees differ by at most 1; in the current case, the adversary requires to remove two codes from one subtree, and one code from each of the other √ n − 2 subtrees.Subsequently, the adversary gives an insertion i c 2 of a level-h/2 code.Similarly as above, the online algorithm requires at least √ n − 2 reassignments to assign c 2 .
The adversary repeats the same operation √ n rounds, where one round consists of √ n deletions to remove codes of level 0 uniformly from subtrees, and one insertion of a level-h/2 code.Eventually, all initial codes of level 0 are removed, and the final OVSF code tree contains √ n codes of level h/2.
The total cost of the online algorithm is at least

Figure 4 .
Figure 4. Execution of EXTENDED-LAZY for an insertion i c .

Case ( 6 ):
The case that (c) belongs to tank[b, t] and is not the top of tank[b, t].Execute FreeTail(t) and receive the code c of level b from tank[b, t].Then, execute AppendPoor( (c), c) and receive a code c of level s.By a similar observation as Case (3), we can see that (c) < s ≤ t.Then, assign c to the vertex which was tank[b, t] using AppendRich(t, c ). (Note that tank[s, t] is created if s = t.)Since (c) was poor, c was assigned to a left child.Hence (c) is currently locally rich.Execute AppendRich( (c), c ), which creates tank[b, (c)] if (c) = b.The execution of this case costs 3, and the number of locally rich levels does not change.
Consider tank[b, t].Release the code c of level b from tank[b, t] temporarily.Then, assign c to the vertex v immediately right of the rightmost dead vertex at b.Because of conditions (ii) and (v) of semi-compactness, b is poor and the path from v to the root includes exactly one assigned vertex v at some level ( ≤ t).Release code c assigned to v and assign c to the vertex v immediately right of the rightmost dead vertex at .By repeating the above operations, a code c assigned to a vertex at level t is released.(c exists because of condition (iv) of semi-compactness.)We assign c to the vertex which was tank[b, t].

Figure 6 .
Figure 6.Transformation from a semi-compact assignment to a compact assignment.

Figure 9 .
Figure 9. REPAIR for a hole-level which is a bottom of a tank v.
7. Execution of EXTENDED-LAZY for a deletion d c .