Header
Home | Set as homepage | Add to favorites
  Search the Site     » Advanced Search
Sections
Syndication


Blogroll:

||||| ALL Cisco-Network ARTICLES |||||  
CCIE Journey,
The CCIE Journey,


Iub Interface Dimensioning

Feb 20,2011 by alperen

image


The physical interface to a base station will be such that the Iub capacity
from a given base station has some discreet value. For example, a single T1
offers 1.5 Mbps. Typically in North America, we will find that a UMTS base
station has some number of T1, DS-3, or OC-3 interfaces. However, while
determining that a particular base station needs one T1 or two T1s is
important, we need to determine the total Iub load at the RNC.We will not
arrive at that total simply by summing the total Iub capacity available at
each base station. Imagine, for example, that 100 base stations each have
an Iub bandwidth demand of 1.7 Mbps.We could configure each such base
station with, say two T1s, equivalent to about 3 Mbps. However, the total
load at the RNC will still be 170 Mbps, not 300 Mbps.
As described earlier in this chapter, the RF design is performed in accordance
with both the coverage and capacity demand that we expect. Consequently,
information will be available as to the traffic (in Kbps) to be carried
on the Iub interface from each base station. Unlike other parts of the network,
however, the RF design is unlikely to have a very long build-ahead
included. While there should be some build-ahead factored into the design,
a build-ahead of 9 or 12 months is not pragmatic. This is because the RF
network usually represents the greatest component of the total network
cost. A large build-ahead could mean a drastic increase in capital expenditure
far in advance of when the capacity is needed. If, however, there is a
large build-ahead, then we can simply size the Iub interface based upon the
expected throughput (including the build-ahead) and with the addition of
perhaps 40 percent for overhead. While this approach is less than scientific,
the inclusion of a long build-ahead will mean that the interface will have
sufficient capacity for some time in the future. During that time, we have
the opportunity to observe the increase in demand and make more accurate
predictions of future interface capacity needs. If there is only a small buildahead
(such as three to six months), then we need to be more discerning in
our determination of Iub capacity.

To determine the actual Iub capacity required, we need to add a certain
amount of overhead to the user throughput. This overhead needs to allow
for burstiness of traffic, signaling load, and operation and maintenance
(O&M) load. Moreover, we need to add asynchronous transfer mode (ATM)
overhead because all of the user traffic, signaling, and O&M is carried in
ATM cells.
The amount of burstiness will depend on the mix of traffic. If only voice
service is to be offered, then we can assume zero burstiness. On the other
hand, an all-data service could require an overhead of up to 40 percent. An
allowance of 25 percent would be typical. In addition, we can assume that,
for a given throughput, there will be an extra 10 percent required for signaling.
We can also assume that we need an additional 10 percent for O&M
load. To each of these, we must then add ATM overhead, which will vary
according to the service. To begin with, the cell structure of ATM means
that there are five octets of overhead for every 48 octets of payload. This
alone means an overhead of 10.4 percent. In addition, as described in Chapter
6, we have ATM adaptation layers (AALs), which also consume bandwidth.
Each AAL consumes some number of octets in each ATM cell, in
addition to the five octets of the ATM header. For AAL2, 3 of the 48 payload
octets are consumed by AAL2 information. Thus, for AAL2, the total ATM
overhead is approximately 18 percent. For AAL5, 4 of the 48 payload octets
may be consumed, meaning that the total overhead is approximately 20
percent. For signaling the service-specific connection-oriented protocol
(SSCOP) and service-specific coordination function (SSCF), as described in
Chapter 6, reside on top of AAL5 and generate even more overhead. In
order to make calculations straightforward, however, the SSCOP and SSCF
overhead should be included as part of the total signaling overhead.
Based on the foregoing, the total required Iub bandwidth is given by
Iub bandwidth  Expected user traffic  (1  burstiness)
 (1  signaling overhead  O&M overhead)
 (1  ATM overhead) (Equation 12-17)
If we take typical examples as described previously, this equation
becomes
Iub bandwidth  Expected user traffic  (1  0.25)  (1  0.1  0.1)
 (1  0.2)
Iub bandwidth  Expected user traffic  1.8

Thus, because of signaling, O&M, and ATM overhead, the Iub interface
should be sized to a bandwidth that is almost twice that of the actual raw
user traffic. Of course, the user traffic is likely to be asymmetrical, and we
are likely to find that the downlink traffic is greater than the uplink traffic.
The actual Iub transmission facilities, however, will be symmetrical. In
other words, if there is 2 Mbps capacity on one direction, there is also 2
Mbps in the other direction. Therefore, when dimensioning the Iub, we need
only to consider the user traffic in one direction—the direction of greater
demand. This will usually be the downlink direction.

855 times read

Related news

No matching news for this article
Did you enjoy this article?
Rating: 4.00Rating: 4.00Rating: 4.00Rating: 4.00 (total 1 votes)

comment Comments (0 posted) 

More Top News
CCSP-Cisco Certified Security Professional
Most Popular
Most Commented
Featured Author