Vous êtes sur la page 1sur 5

Internal Use Only

GSM P&O Q&A Collection


2012-12 V1.0

AuditorDjamila DOUACHE

<>
All Rights reserved, No Spreading abroad without Permission of ZTE

Internal Use Only


How to check how many PDTCH channel using right now
Incident Description (Incident Phenomena)
from cell channel managment,we can see the CS channel using status, the PS channel using
status all is idle,no busy status. So from dynamic data management how to check right now
how many PDTCH channel are used ?
from this picture, we can see, the PS channel all is idle

<>
All Rights reserved, No Spreading abroad without Permission of ZTE

Internal Use Only

TCH Congestion Cause OMCR Logic ABIS Bandwidth Limited


Incident Description (Incident Phenomena)
After the iBSC V6.20.200f is upgraded to V6.20.615D on the project, it happened TCH
congestions. According to the TCH measurement, the TCH congestion is caused by Abis
congestion
Problem Cause Analysis
The Abis congestion is due to the insufficiency of Abis bandwidth. After checking the
configuration data of each site, we find that the configured bandwidth of the Abis
bandwidth pool is the same as the actual physical bandwidth.
However, according to the empirical values, the bandwidth configured for the site should be
1.5 times of the actual physical bandwidth, so that the bandwidth can be efficiently used and
Abis congestion can be avoided. After the configuration of Abis bandwidth on site is adjusted,
the indicators are improved .
Solution
1.1 Abis Bandwidth Allocation in iBSCV6.20.200f
In iBSCV6.20.200f, each site is configured with one Abis bandwidth. For TCH allocation
during service access, based on the TCH type (TCH/H, TCH/F, or PDTCH), the
corresponding bandwidth is allocated to the TCH from the Abis bandwidth. If all the Abis
bandwidth is allocated, Abis congestion will appear, which can cause access failures.
According to the TCH type, the allocated bandwidth is a fixed value, which is the sum of
service pay load and packet heade r . The above bandwidth allocation method has the
following flaws:
1 . When being transmitted, the Abis data is packaged per TRX. Therefore, for the eight
channels of a TRX, there is only one packet header. However, when the system allocates
bandwidth, the packet header is calculated into the bandwidth allocated to each
channel, which results in double counting.
2 . During the service process, the actually-consumed bandwidth is smaller than the
bandwidth allocated. For CS service, if DTX is enabled, the physical bandwidth is barely
consumed in the case of DTX ON. For PS service, the system allocates bandwidth
according to the bandwidth demand of MCS9, while MSC9 is not always used for the
services and it is not necessary that all the RLC/MAC blocks are occupied for data
transmission.
Due the above two factors, the actually-used physical bandwidth is smaller than the
bandwidth allocated. In order to make maximum use of the physical bandwidth, it is
required that is configured bandwidth is larger than the actual physical bandwidth.
Besides, in order to allocate bandwidth more accurately, the following strategies for
bandwidth allocation to CS services are added to the system:
l If DTX is enabled in the system, allocate bandwidth of reference bandwidth * DTX
<>
All Rights reserved, No Spreading abroad without Permission of ZTE

Internal Use Only


scale factor for CS services. Value of DTX scale factor: 0.6
Based on the above analysis, the following two points are concluded.
1 . The use of actual physical bandwidth is not considered in the bandwidth allocation
strategy in iBSCV6.20.200f, which results in the inaccurate allocation of bandwidth.
2 . When the above bandwidth allocation algorithm is adopted, it is required that the
configured bandwidth is larger than the actual physical bandwidth. Otherwise, the
efficiency of physical bandwidth is low, which can create congestions.However, if the
configured bandwidth is too large, the physical bandwidth may become inadequate,
which may affect the service quality.
1.2 Abis Bandwidth Allocation in iBSCV6.20.615
To solve problem in the Abis bandwidth allocation algorithm in iBSCV6.20.200f, we
adjust the Abis bandwidth allocation method in iBSCV6.20.615. The major changes
include:
1 . The concept of BWPOOL (bandwidth resource pool) is introduced. Each BWPOOL is
allocated with certain bandwidth. BWPOOL can be shared by multiple sites, or occupied
by a single site. In an IPOE site, the physical transmission resource is only occupied by
this site, thus the BWPOOL is only occupied by one site.
2 . The algorithm of admission control is introduced. Compared with the bandwidth
allocation algorithm used in the previous versions, the major change of the admission
control algorithm is: The bandwidth allocation for services is based on the occupancy
percentage of the existing physical bandwidth. When the occupancy of physical
bandwidth reaches the maximum value of the threshold, the allocation fails; otherwise
the allocation succeeds.
3 . Because the bandwidth can be allocated precisely in the admission control algorithm,
when the bandwidth is allocated for the CS service, the calculation of DTX factors will be
cancelled.
Apparently, the admission control algorithm based on physical bandwidth allocation is
more precise than the algorithm based on configured bandwidth. In addition, the
configured bandwidth can be consistent with the actual physical bandwidth, which does
not need to be expanded manually.
1.3 Analysis of Abis Congestion
After the system is upgraded to iBSCV6.20.615, the admission control function is
disabled by default. The Abis bandwidth allocation algorithm in V6.20.200f is still used in
the system. Meanwhile, the calculation of DTX factors is cancelled, thus more Abis
bandwidth will be allocated. In consequence, the Abis bandwidth will be insufficient, and
the Abis congestion will occur. As shown in the statistics in the following table, both the
Maximum number of Abis TS used and Average number of Abis TS used are increased.
And the increases in Maximum value of Abis TS used to CS and Minimum value of Abis TS
<>
All Rights reserved, No Spreading abroad without Permission of ZTE

Internal Use Only


used to CS are significant
1.4 Follow-up Solution
Phase 1:
Configure all the Abis resource pool bandwidth in the site 1.5 times as large as the
physical bandwidth.
Note: The value of 1.5 times is based on the onsite experience of some projects, which
satisfies the requirement of most scenarios. However, this value can also be adjusted
according to the condition of congestion and physical bandwidth occupancy. The
detailed adjustment method will be provided in another document upon specific
request.
Phase 2:
Learn from the experience for enabling admission control function in other projects,
enable admission control in Portugal project, and modify the Abis resource pool
bandwidth as the actual physical bandwidth.

<>
All Rights reserved, No Spreading abroad without Permission of ZTE