HUAWEI
2G CAPACITY OPTIMIZATION
For internal use
1
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
2
© Nokia Siemens Networks
Presentation / Author / Date
Document Information
 Document Version: 1.0
 Issue Date: June 25, 2010
 Author: Christos Kyriazopoulos
 Document Owner: Ville Salomaa
 SOFTWARE RELEASE: GBSS9.0
 SCOPE:
 BSS Capacity Monitoring
 BSS Capacity Optimisation
 Transmission Network Monitoring
 Transmission Network Capacity Optimisation
 CONVENTION:
 Raw counters are marked in BLUE
 Formulas are marked in GRAY
 Parameters are marked in RED
 MML commands are marked in GREEN
For internal use
3
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
4
© Nokia Siemens Networks
Presentation / Author / Date
Network Elements Capacity Overview
A Interface
•Circuits
configuration
•A over IP
MS/Client
parameters
HLR/AuC/EIR
MSC/VLR
•GSM/GPRS/E
DGE capability
and release
BSC
•Multislot
support
BTS
•Boards
•TRX
•SW features
A
Gs
BSC
Um
Abis
MS
Gb
BTS
Abis Interface
Gb Interface
Air Interface (Um)
•E1 configuration
•CCCH(PCH+AGCH)
•Abis over IP
•Gb link
capacity
•SDCCH
•CS Traffic (TCH)
•PS Traffic (PDCH)
For internal use
5
© Nokia Siemens Networks
Presentation / Author / Date
SGSN
GGSN
PDN
General Methodology
1. Monitor blocking counters:
- If blocking > 0 then take measures to relieve congestion
reactive optimisation
2. Monitor utilization counters:
- If utilization of resources is above specific alarm threshold (e.g. > 80%) take measures to improve capacity
proactive optimisation
Blocking or Utilization issues must occur repeatedly before triggering capacity optimisation; check
corresponding counters on same hours, same day of consecutive weeks:
- Check duration of the problem
- Check availability of current and adjacent network elements
- Check patterns of behaviour (hours of occurrence, weekdays/weekends)
- Check surroundings (theatres, concert halls, stadiums, shopping centres, etc.)
- Check blocking/utilization of adjacent network elements (homogeneously spread or unbalanced)
3. Introduce solution:
- Re-establish full availability
- Increase support from existing NEs (coverage, tilts, azimuths, etc.)
- Increase NEs and/or Interfaces capacity
- Add NEs
This document focuses on increasing NEs and Interfaces capacity
For internal use
6
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
7
© Nokia Siemens Networks
Presentation / Author / Date
CCCH (1)
 AGCH performance monitoring
BLOCKING:
- AGCH Blocking = ([L3188A:CELL_DEL_IND]/[Channel Requests (all reasons)])*{100} %
- L3188A:CELL_DEL_IND: MSG DEL IND Messages Sent on Abis Interface, due to overload DL CCCH (when the IMM ASS
CMD message sent from the BSC is deleted by the BTS because the downlink CCCH in the cell is overloaded, the BTS
reports a DELETE IND message to the BSC)
- Channel Requests (all reasons) = A300A:CELL_CH_REQ_MOC + A300C:CELL_CH_REQ_MTC +
A300D:CELL_CH_REQ_ECALL + A300E:CELL_CH_REQ_CALL_REESTB + A300F:CELL_CH_REQ_LOC_UPDATE +
A300H:CELL_CH_REQ_PACKET_CALL + A300I:CELL_CH_REQ_LMU_AND_RESERVED +
A300K:CELL_CH_REQ_PROTOCOL_INCOMPATIBLE
 PCH performance monitoring
BLOCKING:
- PCH Blocking = [L3188L:CELL_FCTRL_PAGING_MSG_DEL_PCH_QUE]/([Delivered Paging Messages for CS
Service]+[Delivered Paging Messages for PS Service])*{100} %
- Paging Overload Rate CS = ([MSG CCCH LOAD IND (PCH) Messages Sent on Abis Interface]/[Delivered Paging Messages
for CS Service])*{100} %
- Paging Overload Rate PS = ([PACKET CCCH LOAD IND Messages Sent on Abis Interface])/([Delivered Paging Messages
for PS Service])*{100} %
- L3188L:CELL_FCTRL_PAGING_MSG_DEL_PCH_QUE: Paging Messages Discarded from the PCH Queue (Note: when the
cell is configured with the PCCCH, this measurement provides the number of discarded paging messages in only the CS
domain)
- A330:CELL_PAGES_CS: Delivered Paging Messages for CS Service
- A331:CELL_PAGES_PS: Delivered Paging Messages for PS Service
- L3188C:CELL_CCCH_LOAD_PCH_OVERLOADS: MSG CCCH LOAD IND (PCH) Messages Sent on Abis Interface
(overload due to CS service)
- L3188D:CELL_OVERLOAD_PS: PACKET CCCH LOAD IND Messages Sent on Abis Interface (overload due to PS service)
For internal use
8
© Nokia Siemens Networks
Presentation / Author / Date
CCCH (2)
 PCH performance monitoring
UTILISATION:
- A343: CELL_QUE_OCCUPY_PK_VALUE: Peak PCH Paging Queue Usage
(When the new paging messages are successfully added to the PCH queue after scheduling, the number of current PCH
messages in the PCH queue is calculated, and then divided by the valid PCH queue length (calculated based on the current
queuing ratio). Thus, the average paging queue usage is obtained. Then, record the peak paging queue usage within the
granularity period of one minute.)
For internal use
9
© Nokia Siemens Networks
Presentation / Author / Date
CCCH (3)
Capacity optimisation methodology
1. If blocking occurs on CCCH (AGCH or PCH) check the following parameters:
- BSAGBLKSRES: Blocks Reserved for AGCH. Value range: 0-7. Recommended: 2
- BSPAMFRAMS: Multi-Frames in a Cycle on the Paging CH. Value range: 2-9. Value depends on paging load. Increase value
when paging load increases. Value should be kept as small as possible.
- PAGTIMES: Paging Times. Value range: 1-8 (For the BTS, this parameter is used to determine paging retransmissions. This
parameter and the number of paging times configured in the MSC determine the number of paging retransmissions.)
2. Check if Flow Control feature is enabled. Recommendation is that Flow Control is always enabled.
 Control of the Arrival Rate of Paging Messages on the A Interface (MSC-BSC):
The control of the arrival rate of paging messages on the Abis interface (from the A interface) is performed when the
parameter STARTPGARRIVALCTRL=YES. The BSC monitors the number of paging messages over A interface in real time. If
the number of paging messages exceeds PGMAXMSGNUMINPERIOD within a PGSTATPERIOD, the BSC discards the
subsequent paging messages coming from A interface within this period.
- STARTPGARRIVALCTRL: Paging Arrival Control. Recommended value: YES
- PGMAXMSGNUMINPERIOD: Max Paging Message Num in Period. Recommended value: 660
- PGSTATPERIOD: Paging Statistical Period. Recommended value: 1000ms
 Flow Control on LAPD links (BSC-BTS):
• Flow control depending on the length of I frame queue of the LAPD links: If the rate at which the BSC sends
messages on the LAPD links is higher than the rate at which the messages on the Abis interface are sent to the BTS,
DL messages are accumulated in the I frame queue or are even discarded.
- FCSTHD: Flow Control Start Threshold. Recommended value: 90%
- FCETHD: Flow Control End Threshold. Recommended value: 80%
For internal use
10
© Nokia Siemens Networks
Presentation / Author / Date
CCCH (4)
Capacity optimisation methodology
 Flow Control on LAPD links (continued):
• Flow control depending on the flow control level and the service type of the paging messages: This function works
only when the BSC is connected to HUAWEI core network. The BSC controls the flow on the LAPD links based on the
CPU usage. The BSC obtains the CPU usage of the boards once every second and compares it with the specified
threshold to determine the flow control level.
Related parameters:
- P11: CPU Usage for Critical Paging FC. Recommended value: 90%
- P12: CPU Usage for Major Paging FC. Recommended value: 85%
- P13: CPU Usage for Minor Paging FC. Recommended value: 80%
- P14: CPU Usage for Slight Paging FC. Recommended value: 75%
For internal use
11
© Nokia Siemens Networks
Presentation / Author / Date
CCCH (5)
Capacity optimisation methodology
3. Check volume of PS pagings (A331:CELL_PAGES_PS: Delivered Paging Messages for PS Service). If too high then
check if PCCCH is configured. If PCCCH is configured then packet pages can be transmitted through PPCH, thus reducing
PCH load.
CS pages can also be transmitted through packet control channels (PACCH or PPCH). For this to work, Gs interface needs
to be configured between SGSN-MSC. Also Network Mode of Operation should be set to 1.
- NMO: Network Operation Mode
4. Check Location Area: re-size might be required (make smaller).
5. Consider splitting cells in the paging overload area. This will grow CCCH capacity.
6. Add CCCH capacity (Extended BCCH).
For internal use
12
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
13
© Nokia Siemens Networks
Presentation / Author / Date
SDCCH (1)
 SDCCH Performance Monitoring
BLOCKING:
- SDCCH Congestion Rate (Overflow) = ([Failed SDCCH Seizures due to Busy SDCCH]/[SDCCH Seizure Requests])*{100} %
UTILISATION:
- SDCCH Utilisation = ([R3550M:CELL_SIG_CH_TRAF_SD]/[CR3020:CELL_CH_AVAIL_NUM_SD_AVR])*{100} %
- R3550M:CELL_SIG_CH_TRAF_SD: Traffic Volume on Signalling Channels (SDCCH) (Erlangs)
- CR3020:CELL_CH_AVAIL_NUM_SD_AVR: Mean Number of Available Channels (SDCCH)
AVAILABILITY:
- SDCCH Availability = ([Mean Number of Available Channels (SDCCH)]/[Mean Number of Dynamically Configured Channels
(SDCCH)])*{100} %
OTHER:
- Immediate Assignment Success Rate = ([Call Setup Indications (Circuit Service)]/[Channel Requests (Circuit Service)])*{100}
%
For internal use
14
© Nokia Siemens Networks
Presentation / Author / Date
SDCCH (2)
Capacity optimisation methodology
1. Check cell signalling statistics:
- if SDCCH Congestion Rate (Overflow) > 0.5 % then cell is an object for capacity optimisation
2. Check SDCCH usage. If SDCCH is congested try to identify the reason of high usage. Check SMSs, LAUs, Call Setups. SDCCH
cause distribution will influence the possible solution.
• Check Call Setups:
- CELL_ESTB_IND_MOC_NONSMS_SD: Number of Call Setup Indications for MOC on SDCCH
- CELL_ESTB_IND_MTC_SD: Number of Call Setup Indications for MTC on SDCCH
• Check amount of SMS. Check and verify with Core engineers SMS Center parameterization.
- A3030B: CELL_ESTB_IND_MOC_SMS_SD: Number of Call Setup Indications for SMS on SDCCH
- CA3340: CELL_Pt_to_Pt_SMS_SD: Number of Point-to-Point Short Messages on SDCCH (includes UL + DL)
• Check LAU/RAU requests:
- A300F: CELL_CH_REQ_LOC_UPDATE: Number of Channel Requests for Location Update
- A3030F: CELL_ESTB_IND_LOC_UPDATE_SD: Number of Call Setup Indications on SDCCH for Location Update
3. If high SCDDH usage is due to LAU then:
• Check if the problem is caused by roamers that do not have access to the network, thus causing big amount of failed
LAUs/RAUs.
• Check if cell is in LA border: if yes, then we can increase CRH parameter value
- CRH: Cell Reselect Hysteresis Parameters (Cell reselection hysteresis. This is one of the parameters used for deciding whether
to reselect cells in different location areas.)
• Check LA border planning. Verify LA borders by checking HO statistics between cells in LA border:
- H380:CELLCELL_INCELL_HO_REQ: Incoming Inter-Cell Handover Requests between 2 cells
• Check the value of T3212; if too low, increase
- T3212: T3212 (This parameter specifies the length of the timer for periodic location update). Recommended value: as high as
possible, usually 4h.
• Check whether moving LA borders (if possible to move) could help relieving the congestion.
• Check the pattern of LAU requests. Check hours and duration of high number of such requests. Check whether the problem is
constant throughout the day or it occurs only during 1 hour for example. If the problem occurs only on specific hour of day check if
it is worth acting to solve it (costs vs. benefits).
For internal use
15
© Nokia Siemens Networks
Presentation / Author / Date
SDCCH (3)
Capacity optimisation methodology
4. Check if TCH Immediate Assignment is allowed:
- IMMASSEN: TCH Immediate Assignment (Whether to allow immediate TCH assignment. If this parameter is set to YES,
the BSC can assign a TCH immediately when there is no available SDCCH for a channel request.) Note: It is not
recommended to activate this in congested LA borders.
5. Activate SDCCH dynamic conversion feature: Dynamic SDCCH conversion can be triggered if the SDCCH resource is
insufficient or the SDCCH allocation fails during the channel assignment
- SDDYN: SDCCH Dynamic Allocation Allowed (Whether to allow SDCCH dynamic allocation, that is, whether to allow
dynamic conversion between TCHs and SDCCHs.)
- IDLESDTHRES: Idle SDCCH Threshold N1 (When the number of idle SDCCH channels in a cell is smaller than this
parameter, the system searches for available TCHs and transforms them into SDCCH channels)
- CELLMAXSD: Cell SDCCH Channel Maximum (Maximum number of SDCCHs in the cell. Before converting a TCH into
an SDCCH, the BSC compares the number of SDCCHs after the conversion in the cell with "Cell SDCCH Channel
Maximum". If the number of SDCCHs after the conversion in the cell exceeds this parameter, the BSC does not convert the
TCH into an SDCCH.)
6. Add SDCCH/8 channel
7. Add TRX
Note: Huawei recommended SDCCH configuration in a cell is:
- 1 SDCCH/8 per 2 TRXs for FR
- 1 SDCCH/8 per 1 TRX for HR
For internal use
16
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
17
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (1)
 TCH Performance Monitoring
BLOCKING:
- TCH Congestion Rate (Overflow) = (([Failed TCH Seizures due to Busy TCH (Signaling Channel)]+[Failed TCH Seizures due
to Busy TCH (Traffic Channel)]+[Failed TCH Seizures in TCH Handovers due to Busy TCH (Traffic Channel)])/([TCH Seizure
Requests (Signaling Channel)]+[TCH Seizure Requests (Traffic Channel)]+[TCH Seizure Requests in TCH Handovers (Traffic
Channel)]))*{100} %
UTILISATION:
- TCH Utilisation = (([Mean Number of Busy TCHs (TCHF) (900/850 Cell)]+[Mean Number of Busy TCHs (TCHF) (1800/1900
Cell)]+[Mean Number of Busy TCHs (TCHH) (900/850 Cell)]+[Mean Number of Busy TCHs (TCHH) (1800/1900 Cell)])/([Mean
Number of Dynamically Configured Channels (TCHF) (900/850 Cell)]+[Mean Number of Dynamically Configured Channels
(TCHF) (1800/1900 Cell)]+[Mean Number of Dynamically Configured Channels (TCHH) (900/850 Cell)]+[Mean Number of
Dynamically Configured Channels (TCHH) (1800/1900 Cell)]))*{100} %
- TCH FR Utilisation = (([Mean Number of Busy TCHs (TCHF) (900/850 Cell)]+[Mean Number of Busy TCHs (TCHF)
(1800/1900 Cell)])/([Mean Number of Dynamically Configured Channels (TCHF) (900/850 Cell)]+[Mean Number of
Dynamically Configured Channels (TCHF) (1800/1900 Cell)]))*{100} %
- TCH HR Utilisation = (([Mean Number of Busy TCHs (TCHH) (900/850 Cell)]+[Mean Number of Busy TCHs (TCHH)
(1800/1900 Cell)])/([Mean Number of Dynamically Configured Channels (TCHH) (900/850 Cell)]+[Mean Number of
Dynamically Configured Channels (TCHH) (1800/1900 Cell)]))*{100} %
AVAILABILITY:
- TCH Availability = ([Mean Number of Available Channels (TCH)]/[Mean Number of Dynamically Configured Channels
(TCH)])*{100} %
For internal use
18
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (2)
Capacity optimisation methodology
1. Check cell congestion statistics:
- if TCH Congestion Rate (Overflow) > 1.5 % then cell is an object for capacity optimisation
2. Check cell traffic channel availability in order to verify that congestion is not due to availability issue.
- if TCH Availability < 100%, cell congestion is due to availability issue: check cell alarms
3. Check availability of neighboring sites. If neighboring cells are unavailable this will cause big amount of HOs directed to our
current cell thus leading to congestion.
4. Check cell traffic channel configuration. Check if all HR resources are in use before TCH congestion occurs.
- verify that HR is enabled; following parameters can be used to cause earlier HR channel selection according to cell load:
- TCHRATEMODIFY: TCH Rate Modify (When this parameter is set to YES and the BSC policy is used, the BSC
preferentially selects full-rate or half-rate channels based on the internal load)
- TCHBUSYTHRES: TCH Traffic Busy Threshold (If the current channel seizure ratio reaches or exceeds this
value, the half-rate TCH is assigned preferentially; otherwise, the full-rate TCH is assigned preferentially)
- TCHAJFLAG: TCH Rate Adjust Allow (Whether to allow the cell to dynamically change a channel from full rate to half rate
or from half rate to full rate)
- ALLOWHALFRATEUSERPERC: Ratio of TCHH (Maximum allowed ratio of the number of half rate channels to the total
number of channels in a cell); verify that value = 100
- In case AMR is supported by the operator, verify that is enabled. Following parameters can be used to cause earlier AMR HR
channel selection according to cell load (note: it would make sense first to check whether there is a considerable amount of AMR HR
capable phones in the network):
- AMRTCHHPRIORALLOW: AMR TCH/H Prior Allowed (Whether to enable the BSC to assign AMR half rate
channels preferentially according to the channel types allowed by the MSC and the current TCH seizure ratio of the cell)
- AMRTCHHPRIORLOAD: AMR TCH/H Prior Cell Load Threshold (Load threshold for assigning half rate
channels preferentially. If the current TCH seizure ratio of the cell is greater than this threshold, AMR half rate
channels are assigned preferentially.)
- ALLOWAMRHALFRATEUSERPERC: Ratio of AMR-HR (Maximum allowed ratio of the number of AMR half rate
channels to the total number of channels in a cell); verify that value = 100
For internal use
19
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (3)
Capacity optimisation methodology
4.
Load balancing between cells: certain features can be activated to manage the traffic sharing between cells
- Load HO: enable load HO algorithm
- LoadHoEn: Load Handover Support (This parameter specifies whether a traffic load-sharing handover is
enabled. The load handover helps to reduce cell congestion, improve success rate of channel assignment, and
balance the traffic load among cells, thus improving the network performance.)
- TRIGTHRES: Load HO Threshold (The load handover is triggered when the traffic load in a cell is greater than
the value of this parameter)
- LoadAccThres: Load handover Load Accept Threshold: (If the load of a cell is lower than the value of this
parameter, the cell can admit the users handed over from other cells with higher load.)
- Directed Retry: enable directed retry due to load
- DIRECTRYEN: Directed Retry (Whether to enable a directed retry. The directed retry is to hand over an MS to
a neighbouring cell in the same procedure as the handover.)
- ASSLOADJUDGEEN: Assignment Cell Load Judge Enable (Activate directed retry due to heavy load in the
cell)
- CDRTTRYFBDTHRES: Cell Directed Retry Forbidden Threshold (if the current cell load is greater than or
equal to the value of this parameter, the BSC allocates a channel to an MS through the process of
directed retry)
- DTLOADTHRED: Directed Retry Load Access Threshold (Only a cell whose load is lower than or equal to this
threshold can be selected as a candidate target cell for directed retry)
For internal use
20
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (4)
Capacity optimisation methodology
5.
Load balancing between cells:
- Concentric Cells: check relative parameters so as to implement optimal traffic sharing between underlaid-overlaid cells.
Main parameters to be checked are shown below:
- HRIUOLDRATESELALLOW: Load of UL-OL Cells Rate Select Allowed (Whether to enable the BSC to assign
half or full rate channels to MSs according to the channel seizure ratio in the overlaid and underlaid subcells)
- TCHTRICBUSYOVERLAYTHR: TCH Traffic Busy Overlay Threshold (If the channel seizure ratio of overlaid
subcell is greater than the value of this parameter, half-rate channels are assigned. Otherwise, full-rate channels
are assigned)
- TCHTRIBUSYUNDERLAYTHR: TCH Traffic Busy Underlay Threshold: (If the channel seizure ratio in the
underlaid subcell exceeds the value of this parameter, half-rate channels are assigned. Otherwise full rate
channels are assigned.)
- ATCBHOEN: Concentric Circles ATCB HO Allowed (Whether to enable the ATCB handover algorithm for the
concentric cell. According to the neighbour cell signal, the ATCB handover algorithm determines the coverage of
the overlaid subcell and balances the load between the overlaid subcell, underlaid subcell, and neighbour cell.
Therefore, the algorithm helps to decrease the interference, to improve the conversation quality, and to achieve
aggressive frequency reuse in the overlaid subcell.)
- Enhanced Dual Band Network: check relative parameters so as to implement optimal traffic sharing between underlaidoverlaid cells. Main parameters to be checked are shown below:
- OUTGENOVERLDTHRED: UL Subcell General Overload Threshold (When the load of the underlay subcell is
higher than this parameter, some of the calls in the underlay subcell will be switched to the overlay subcell, and
channels in the overlay subcell will be preferentially assigned to calls initiated in the underlay subcell as well.)
- OUTLOWLOADTHRED: UL Subcell Lower Load Threshold (When the load of the underlay subcell is lower
than this parameter, some of the calls in the overlay subcell will be switched to the underlay subcell, and
channels in the underlay subcell will be preferentially assigned to channel requests initiated in the overlay subcell
as well.)
For internal use
21
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (5)
Capacity optimisation methodology
6.
Check if additional capacity related features can be activated in the network:
- BCCH Dense Frequency Multiplexing: enables the BCCHs to reuse frequencies more tightly to free more frequencies for nonBCCH TRXs, thus increasing the system capacity.
- TIGHTBCCHSWITCH: TIGHT BCCH Switch (Whether to enable the BCCH aggressive frequency reuse
algorithm)
- Interference Based Channel Allocation (IBCA): On a network where the frequency resources are insufficient, the same frequency
is repeatedly used in neighboring cells. In this case, severe co-channel interference and adjacent-channel interference exist on the
network, and such interference cannot be eliminated even if the frequency hopping (FH) technology is applied. When the number of
calls on such a network exceeds a certain limit, the mutual interference between calls will decrease the speech quality to such a
level that the C/I ratio required by a call is not guaranteed. In this case, even if there is an idle channel on this network, the idle
channel cannot be assigned to a call because of the severe interference. As a result, the utilization of the frequency resources is
restricted, and the network capacity is thus decreased.
To alleviate the interference on the network, the Interference Based Channel Allocation (IBCA) algorithm is introduced. The IBCA
algorithm requires the BSC to estimate the C/I ratio of the new call in every channel assignment procedure; it also requires the BSC
to estimate the interference caused to the established calls on the network when an idle channel is assigned to a new call. In this
way, the optimal channel, that is, the one that meets the C/I ratio requirement of the new call and causes the least interference to
the established calls after being occupied, is assigned to the new call to alleviate the interference and ensure the full use of the
frequency resources.
- IBCAALLOWED: IBCA Allowed (Whether to enable the IBCA algorithm)
- Flex MAIO: BSC dynamically adjusts the MAIO according to the current interference level of a channel when assigning an MAIO to
the channel (note that the BSC assigns an MAIO to only a channel under activation). In this way, the BSC assigns the MAIO with the
minimum interference to the channel, and the channel experiences the minimum interference in the BTS.
- FLEXMAIO: Start Flex MAIO Switch (Whether to enable the function of Flex Mobile Allocation Index Offset)
- Precondition for Flex MAIO use is to have RF hopping enabled (BB FH does not support Flex MAIO). Also, only CS
service supports Flex MAIO (PS service does not).
For internal use
22
© Nokia Siemens Networks
Presentation / Author / Date
Traffic (6)
Capacity optimisation methodology
7.
If congestion is still present although the previous described fine tuning and features activation, then:
- Check Interference in the network (C/I); check frequency plan
- Check coverage: maybe network layout should be changed in traffic hot spots
- We can use TA distribution in order to identify traffic distribution among cells. In some cases overshooting can be
detected, so we can check the possibility to reduce service area of the overshooting cell. Before doing so, we need, of
course, to make sure that there is clear dominance in the area that we are going to shrink serving cell’s coverage.
- Implement physical network changes where necessary and feasible: tilt, azimuth, antenna type, etc.
- Add TRX
- Long term monitoring (e.g. one month) can be used to identify whether we have constant growth in traffic in a site and
area close by. If traffic increases in area level and we have already high HR/AMR HR utilization then there are not too
many other options than implement a new site.
- Add Site
For internal use
23
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
24
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (1)
 Abis Transmission Modes
The following transmission modes can be used for Abis interface:
• Abis over TDM
In TDM-based networking mode, the BSC and the base station communicate with each other through the
SDH/PDH network, and TDM transmission is applied to the Abis interface.
- Fix Abis: the timeslot resources on the Abis interface correspond to the TCH resources on the Um
interfaces based on configurations, and the mapping is 1:1.
- Flex Abis: Flex Abis indicates that different services in the same BTS share Abis interface timeslots. An
Abis TS is assigned only when an Um channel is occupied. In cases different BTSs share Abis interface
timeslots, Abis interface timeslots are assigned as required. It is advisable to enable Flex Abis in the
following cases:
- Transmission resources are limited, and the rent for them is very high, for example, in satellite
transmission mode.
- The traffic volume in actual situation is far lower than that in the channel resource planning.
- The cells that share Abis interface transmission resources have different traffic peak hours.
- The proportion of PS service users in the cell is high.
• Abis over IP
In IP-based networking mode, the BSC and the base station communicate with each other through the
IP/SDH/PDH network, and layer 3 of the protocol stack of Abis interface uses the IP protocol.
For internal use
25
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (2)
 Abis over TDM – Performance Monitoring
 Fix Abis: There is 1:1 mapping between Um interface channels and Abis timeslots. So blocking on Abis is not possible.
UTILISATION:
- L1151A: BS_ABIS_USED_TS_AVG: Average Number of Busy Timeslots per Abis Port
- L1151B: BS_ABIS_USED_TS_MAX: Maximum Number of Busy Timeslots per Abis Port
- LST ABISTS: An OM command that queries the number of service timeslots configured on the Abis interface per Abis
port.
Utilisation can be found by dividing the “Average Number of Busy Timeslots per Abis Port” by the number of
“Configured TS per Abis port”.
 Flex Abis: In dynamic allocation mode, the Abis interface transmission resources form a pool. These resources are allocated
to the Um interface channels only when the channels are occupied. This way it is possible to map more Um channels than
configured timeslots on Abis. Which might create congestion during busy hours.
BLOCKING:
- A312F: CELL_ASS_FAIL_NO_IDLE_ABIS: Number of TCH Assignment Failures due to no available Abis resources
- H322M: CELL_INTRABSC_INCELL_HO_FAIL_NO_IDLE_ABIS: Number of incoming internal inter-cell handover
failures because no Abis CS resource is available in the target cell when the Abis dynamic allocation is enabled
- H342L: CELL_INTERBSC_INCELL_HO_FAIL_NO_IDLE_ABIS: Number of failed incoming external inter-cell
handovers because no Abis circuit resource is available in the target cell when the Abis dynamic allocation is enabled
- RR2751: SITE_8K_ASS_FAIL_RATE: Congestion Ratio of Dynamic Assign Abis Resource (8K)
- RR2752: SITE_16K_ASS_FAIL_RATE: Congestion Ratio of Dynamic Assign Abis Resource (16K); this counter
includes CS and PS service.
For internal use
26
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (3)
 Abis over TDM – Performance Monitoring
 Flex Abis: In dynamic allocation mode, the Abis interface transmission resources form a pool. These resources are allocated
to the Um interface channels only when the channels are occupied. This way it is possible to map more Um channels than
configured timeslots on Abis. Which might create congestion during busy hours.
UTILISATION:
- R2720:SITE_ASS_CS_8K: Dynamic Assign Abis Resource (8K_CS) (This counter is measured when the 8 kbit/s Abis
resources are assigned to the voice channel for the CS service)
- R2721: SITE_ASS_CS_16K: Dynamic Assign Abis Resource (16K_CS) (This counter is measured when the 16 kbit/s
Abis resources are assigned to the voice channel for the CS service)
- R2741: SITE_FLEX_TS_NUM: FlexAbis TSs (This counter is used to measure the number of available FlexAbis
timeslots of the site.)
- R2742: SITE_FAULT_FLEX_TS_NUM: Fault Flex TSs (This counter is used to measure the number of fault FlexAbis
timeslots of the site.)
For internal use
27
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (4)
 Abis over IP – Performance Monitoring
 BSC6000
BLOCKING:
- Congestion Rate =
([L01057:BSC_LGCPORT_TXDROPPACKETS]/([L01057:BSC_LGCPORT_TXDROPPACKETS]+[L01055:BSC_LGCP
ORT_TXPACKETS]))*{100}
- L01057:BSC_LGCPORT_TXDROPPACKETS: Number of Packets Discarded on a Logical Port due to congestion
- L01055:BSC_LGCPORT_TXPACKETS: Number of Packets Sent on a Logical Port
UTILISATION:
- L01061:BSC_LGCPORT_MEAN_TXRATE: Average Throughput of Packets Sent on a Logical Port
- BANDWIDTH: Bandwidth of the Logical Port [32kbps] (ADD LOGICALPORT)
 BSC6900
BLOCKING:
- VS.ANI.IP.FailResAllocForBwLimit: Number of Failed Resource Allocations Due to Insufficient Bandwidth on the IP
Transport Adjacent Node
- VS.IPPATH.Fwd.Cong: Number of Forward Congestions on the IP Path
- VS.IPPATH.Fwd.Cong.Dur: Duration of Forward Congestion on the IP Path
- VS.IPPATH.Bwd.Cong: Number of Backward Congestions on the IP Path
- VS.IPPATH.Bwd.Cong.Dur: Duration of Backward Congestion on the IP PATH
UTILISATION:
- OS.ANI.IP.AllocedFwd: IP Path Forward Bandwidth Allocated to IP Transport Adjacent Node
- OS.ANI.IP.AllocedBwd: IP Path Backward Bandwidth Allocated to IP Transport Adjacent Node
- TXBW: Forward Bandwidth: Transmit bandwidth of IP path (ADD IPPATH)
- RXBW: Backward Bandwidth: Receive bandwidth of IP path (ADD IPPATH)
For internal use
28
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (5)
 Abis over IP – IPPM (IP link Performance Monitoring)
The quality of an Abis IP link can be monitored through the IPPM function. Enable this through MML command: ADD IPPM
(BSC6000), ACT IPPM (BSC6900). The IPPM is a method to check the IP transmission quality. In this method, the forward
monitoring (FM) and backward reporting (BR) messages are used to check the transmission quality of IP paths.
- The monitor periodically sends FM messages to indicate number of outgoing packets, number of bytes, and sending time.
- The peer responds with BR messages after receiving the FM message to report number of received packets, number of
received bytes, the receiving time of PM message and the sending time of BR response.
- The sender calculates packet loss rate, transmission delay and jitter according to the BR response from the receiver.
BSC6000:
- L01033:IPPM_FORWARD_DROPMEANS: Average IPPM Forward Packet Loss Rate
- L01034:IPPM_FORWARD_PEAK_DROPRATES: Maximum IPPM Forward Packet Loss Rate
- L01035:IPPM_RTT_MEANS: Average RTT Delay of an IPPM Link
- L01032:IPPM_MAXRTTDELAY: Maximum RTT Delay of an IPPM Link
BSC6900:
- VS.IPPM.Forword.DropMeans: Average Forward Packet Loss Rate of IPPM
- VS.IPPM.Forword.Peak.DropRates: Peak Forward Packet Loss Rate of IPPM
- VS.IPPM.Rtt.Means: Average RTT Delay of IPPM
- VS.IPPM.MaxRttDelay: Maximum RTT Delay of IPPM
- DSP IPPMLNK: An OM command that queries the information on the received and transmitted packets of the IP PM link
For internal use
29
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (6)
Capacity optimisation methodology
 Abis over TDM
1. In case of Fix Abis, if Utilisation meets the set thresholds (e.g. 80%) then check Fix Abis configuration:
- MPMODE: Multiplexing Mode: Specifies the multiplexing mode of signalling timeslots over Abis. Values: 1:1, 2:1, 3:1, 4:1,
5:1, 6:1, 16K. (Certain rules apply for each multiplexing mode, check parameter description first.)
Increase of MPMODE, e.g. from 1:1 to 4:1 can free additional Abis TS for TCHs. Modes 5:1 and 6:1 can only be used in
Flex Abis.
- FIXAPALT and FIXABISPRILDTHRED (BSC6000): these two parameters decide the load threshold on Fix Abis above
which HR channels are assigned; consider reduction of the parameters in order to assign HR channels earlier.
- FLEXABISMODE: Flex Abis Mode: Specifies the working mode of Abis. Values: FIX_ABIS, FLEX_ABIS, SEMI_ABIS
(SemiSolid indicates that the Fix Abis is used in the BTS. All its upper-level BTSs use Flex Abis.)
- If the highest Multiplexing Mode is used and still Utilisation is high, check the transmission plan: re-arrange chains and
sites if possible.
- If Utilisation is constantly very high (close to 100%), a change in Abis transmission mode from Fix to Flex will not brink
significant benefits; it will probably result in congestion in Flex Abis mode.
- Add E1.
2. In case Flex Abis is in use, if blocking counters are not null or utilisation counters are high, check Flex Abis configuration:
- MPMODE: check if there is room to increase the value to 6:1, thus freeing some additional TSs for TCHs.
- FLEXAPALT and FLEXABISPRILDTHRED (BSC6000): these two parameters decide the load threshold on Flex Abis
above which HR channels are assigned; consider reduction of the parameters in order to assign HR channels earlier.
- TDMCONGTH (BSC6900): Congestion remain ratio. If the ratio of available TDM bandwidth is less than or equal to this
value, congestion control (LDR - see next slide for brief description) is triggered. Usual value 15%.
- Check the transmission plan: re-arrange chains and sites if possible.
- In case that only a portion of the E1 timeslots are flex TSs, investigate the possibility to increase the percentage of flex
TSs in use before adding a new E1.
- Add E1.
For internal use
30
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - Abis Interface (7)
Capacity optimisation methodology
 Abis over IP
1. In case of Abis over IP, if blocking counters are not null:
check congestion trigger and clear thresholds in the logical port (BSC6000):
- LPNCONGBW: Congestion Bandwidth Threshold [%], usual value 85%. Above this value LDR actions are triggered.
- LPNCONGCLRBW: Congestion Clear Bandwidth Threshold [%], usual value 75%. Below this value LDR stops.
check congestion trigger and clear thresholds in the IP Path (BSC6900):
- FWDCONGBW / BWDCONGBW: Forward / Backward congestion threshold, usual value 85%.
- FWDCONGCLRBW / BWDCONGCLRBW: Forward / Backward congestion clear threshold, usual value 75%.
LDR (Load Reshuffling algorithm) performs some actions in order to relieve congestion. These actions are:
1. PS service rate decrease
2. Allocate half-rate channels to newly-accessed MSs requesting CS services
3. Limit AMR rate for MSs in CS services
4. Handover of MSs in CS services from the full-rate channel to the half-rate channel
The order of actions to be performed is controlled through the MML command: SET LDR
2. Check if ABIS_MUX feature is enabled. ABIS_MUX improves IP transmission efficiency:
- ABISMUXFLAG (BSC6000): Abis MUX Global Enable Switch; value=ENABLE
- MUXTYPE (BSC6900): IP MUX Type; value=ABISMUX
3. Increase Abis bandwidth if nothing of the above improves the situation.
For internal use
31
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - A Interface (1)
 A Transmission Modes
The following transmission modes can be used for A interface:
• A over TDM
A over TDM indicates that the TDM transmission is used on the A interface. In TDM-based networking mode,
the BSC6900 and the MSC/MGW communicate with each other through the SDH/PDH network.
• A over IP
A over IP indicates that layer 3 of the A interface protocol stack uses the IP protocol. In IP-based networking
mode, the BSC6900 and the MSC/MGW communicate with each other through the IP network.
For internal use
32
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - A Interface (2)
 A over TDM – Performance Monitoring
BLOCKING:
- A3050: CELL_CM_SERV_REJ_CONG: Number of rejections of Service Requests due to congestion
- A3129E: CELL_ASS_FAIL_NO_CIC: Number of ASS FAIL messages sent by the BSC to the MSC when the BSC receives
an ASS REQ message that carries an unavailable A interface CIC
- H342E:CELL_INTERBSC_INCELL_HO_FAIL_NO_CIC: Number of failed incoming external inter-cell handovers because the
specified CIC on the A interface is unavailable, after the BSC receives the HO REQ from the MSC
- H362E:CELL_INTERRAN_INCELL_HO_FAIL_NO_CIC: Number of failed incoming inter-RAT inter-cell handovers because
the specified CIC on the A interface is unavailable, after the BSC receives the HO REQ from the MSC
UTILISATION:
- A Utilisation =
([AL0055:BS_A_INTF_BUSY_CIC_AVG]/([AL0050:BS_A_INTF_UNINST_CIC_AVG]+[AL0051:BS_A_INTF_FAIL_CIC_AVG]+
[AL0052:BS_A_INTF_MTN_CIC_AVG]+[AL0053:BS_A_INTF_CONG_CIC_AVG]+[AL0054:BS_A_INTF_IDLE_CIC_AVG]+[AL
0055:BS_A_INTF_BUSY_CIC_AVG]+[AL0089:BS_A_INTF_PEER_UNINST_CIC_AVG]))*{100}
Mean number of circuits in busy state over mean number of circuits in all states in A interface in a granularity period. The
possible states of an A interface circuit are:
- Uninstalled
- Faulty
- Maintenance
- Blocked
- Idle
- Busy
- Uninstalled peer circuit
- AL00n:BS_A_INTFACE_BUSY_TSn_SUMAVR: Average busy time of timeslot n during granularity period, 01 <= n <= 31 (TS
0 for synchronisation is not measured)
- The MML command LST AE1T1 can be used to display all circuits in A interface.
For internal use
33
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - A Interface (3)
 A over IP – Performance Monitoring
 BSC6000
BLOCKING:
- Congestion Rate =
([L01057:BSC_LGCPORT_TXDROPPACKETS]/([L01057:BSC_LGCPORT_TXDROPPACKETS]+[L01055:BSC_LGCP
ORT_TXPACKETS]))*{100}
- L01057:BSC_LGCPORT_TXDROPPACKETS: Number of Packets Discarded on a Logical Port due to congestion
- L01055:BSC_LGCPORT_TXPACKETS: Number of Packets Sent on a Logical Port
UTILISATION:
- L01061:BSC_LGCPORT_MEAN_TXRATE: Average Throughput of Packets Sent on a Logical Port (Kbps)
- BANDWIDTH: Bandwidth of the Logical Port [32kbps] (ADD LOGICALPORT)
 BSC6900
BLOCKING:
- VS.ANI.IP.FailResAllocForBwLimit: Number of Failed Resource Allocations Due to Insufficient Bandwidth on the IP
Transport Adjacent Node
- VS.IPPATH.Fwd.Cong: Number of Forward Congestions on the IP Path
- VS.IPPATH.Fwd.Cong.Dur: Duration of Forward Congestion on the IP Path
- VS.IPPATH.Bwd.Cong: Number of Backward Congestions on the IP Path
- VS.IPPATH.Bwd.Cong.Dur: Duration of Backward Congestion on the IP PATH
UTILISATION:
- OS.ANI.IP.AllocedFwd: IP Path Forward Bandwidth Allocated to IP Transport Adjacent Node
- OS.ANI.IP.AllocedBwd: IP Path Backward Bandwidth Allocated to IP Transport Adjacent Node
- TXBW: Forward Bandwidth: Transmit bandwidth of IP path (ADD IPPATH)
- RXBW: Backward Bandwidth: Receive bandwidth of IP path (ADD IPPATH)
For internal use
34
© Nokia Siemens Networks
Presentation / Author / Date
Transmission - A Interface (4)
Capacity optimisation methodology
 A over TDM
In case of A over TDM, if blocking counters are not null, or utilisation is high (e.g. above 80%):
- Check state of circuits: DSP ACIC. Note number of circuits that are not idle or busy (e.g. faulty, uninstalled, etc.) and take
proper actions to repair them (e.g. reset a circuit), thus freeing more A resources.
- Add E1.
 A over IP
1. In case of A over IP, if congestion appears or utilisation is high, check congestion trigger and clear thresholds in the logical
port (BSC6000):
- LPNCONGBW: Congestion Bandwidth Threshold [%], usual value 85%.
- LPNCONGCLRBW: Congestion Clear Bandwidth Threshold [%], usual value 75%.
check congestion trigger and clear thresholds in the IP Path (BSC6900):
- FWDCONGBW / BWDCONGBW: Forward / Backward congestion threshold, usual value 85%.
- FWDCONGCLRBW / BWDCONGCLRBW: Forward / Backward congestion clear threshold, usual value 75%.
2. Check if it is possible to activate the following features to increase bandwidth efficiency (BSC6900):
- UDP multiplexing: enables multiple RTP packets to be multiplexed in one UDP packet, thus reducing the overhead of the
UDP/IP/L2/L1 header and increasing the transmission efficiency. Caution: UDP_MUX improves the transmission efficiency
but increases the transmission delay. Relative parameter: MUXTYPE (value=UDPMUX)
- Header compression: used to reduce the frame header overhead on PPP links, thus improving bandwidth efficiency.
Relative parameters: ACFC (value=Enable), PFC (value=Enable), IPHC (value=UDP/IP_HC or RTP/UDP/IP_HC).
3. Increase A interface bandwidth
For internal use
35
© Nokia Siemens Networks
Presentation / Author / Date
Contents
1. Capacity Optimisation Overview
2. CCCH Capacity Optimisation
3. SDCCH Capacity Optimisation
4. Traffic Capacity Optimisation
5. Transmission Capacity Optimisation
6. BSC Hardware
For internal use
36
© Nokia Siemens Networks
Presentation / Author / Date
BSC6000 - Boards

CPU Usage Measurements are used to measure the CPU usage of BSC boards and the GBAM.
BLOCKING:
- R9703:CPU_USG_MAX: Maximum CPU Usage
UTILIZATION:
- AR9702:CPU_USG_AVG: Mean CPU Usage
For internal use
37
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - DPU Board
BLOCKING:
- VS.DPU.CPULOAD.MAX: Maximum CPU Usage of the DPU.
- VS.DPU.CPULOAD.OVER: Rate of the period in which the CPU Usage of the DPU exceeds the Alarm Threshold.
UTILIZATION:
- VS.DPU.CPULOAD.MEAN: Average CPU Usage of the DPU.
- VS.DPU.CPULOAD.LESS: Rate of the period in which the CPU Usage of the DPU is lower than the Alarm Threshold.
FUNCTIONS:
- DPUc: The DPUc board processes GSM voice services and data services.
•
Provides the speech format conversion and data forwarding functions
•
Encodes and decodes voice services
•
Provides the Tandem Free Operation (TFO) function
•
Provides the voice enhancement function
•
Detects voice faults automatically
- DPUd: The DPUd board processes GSM PS services.
•
Processes the PS services on up to 1,024 simultaneously active PDCHs where signals are coded in MCS9
•
Processes packet links
•
Detects packet faults automatically
For internal use
38
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - GCU Board
BLOCKING:
- VS.GCU.CPULOAD.MAX: Maximum CPU Usage of the GCU.
- VS.GCU.CPULOAD.OVER: Rate of the period in which the CPU Usage of the GCU exceeds the Alarm Threshold.
UTILIZATION:
- VS.GCU.CPULOAD.MEAN: Average CPU Usage of the GCU.
- VS.GCU.CPULOAD.LESS: Rate of the period in which the CPU Usage of the GCU is lower than the Alarm Threshold.
FUNCTIONS:
The GCUa board provides the synchronization clock signals for the system.
•
Traces, generates, and maintains the synchronization clock
•
The standby GCUa board traces the clock phase of the active GCUa board. This ensures the smooth output of the clock
phase in the case of active/standby switchover.
For internal use
39
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - INT Boards
BLOCKING:
- VS.INT.CPULOAD.MAX: Maximum CPU Usage of the INT.
- VS.INT.CPULOAD.OVER: Rate of the period in which the CPU Usage of the INT exceeds the Alarm Threshold.
UTILIZATION:
- VS.INT.CPULOAD.MEAN: Average CPU Usage of the INT.
- VS.INT.CPULOAD.LESS: Rate of the period in which the CPU Usage of the INT is lower than the Alarm Threshold.
FUNCTIONS:
The INT (Interface) boards provide connectivity to BSC over Abis, Ater, A, Pb, Gb interfaces. INT board can be:
•
EIUa board: provides E1/T1 transmission over A, Abis, Ater, and Pb interfaces. Provides 32 E1 ports.
•
FG2a board: provides IP over Ethernet transmission for Abis, A and Gb interfaces. Provides 8 FE and 2 GE ports.
•
FG2c board: provides IP over Ethernet transmission for Abis, A and Gb interfaces. Provides 12 FE and 4 GE ports.
•
GOUa board: provides optical channels of IP over Ethernet for Abis and A interfaces. Provides 2 optical GE ports.
•
GOUc board: provides optical channels of IP over Ethernet for Abis, A and Gb interfaces. Provides 4 optical GE ports.
•
OIUa board: provides STM-1 transmission over Abis, Ater, A and Pb interfaces. Provides 1 STM-1 port for TDM
transmission.
•
PEUa board: provides E1/T1 transmission for Abis and Gb interfaces. Provides 32 channels of IP over PPP/MLPPP over
E1/T1.
•
POUa board: provides IP over channelized STM-1/OC-3 transmission for Abis, Ater, A, Pb, Gb interfaces. Provides 4
optical channelized STM-1/OC-3 ports for IP transmission.
For internal use
40
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - SCU Board
BLOCKING:
- VS.SCU.CPULOAD.MAX: Maximum CPU Usage of the SCU.
- VS.SCU.CPULOAD.OVER: Rate of the period in which the CPU Usage of the SCU exceeds the Alarm Threshold.
UTILIZATION:
- VS.SCU.CPULOAD.MEAN: Average CPU Usage of the SCU.
- VS.SCU.CPULOAD.LESS: Rate of the period in which the CPU Usage of the SCU is lower than the Alarm Threshold.
FUNCTIONS:
The SCUa board provides the maintenance management and GE switching platform for the subrack in which it is located. It
performs the following functions:
•
Provides the maintenance management function
•
Provides configuration and maintenance of a subrack or of the entire BSC6900
•
Monitors the power supply, fans, and environment of the cabinet
•
Supports the port trunking function
•
Supports the active/standby switchover
•
Enables inter-subrack connections
•
Provides a total switching capacity of 60 Gbit/s
•
Distributes clock signals and RFN signals for the BSC6900
For internal use
41
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - TNU Board
BLOCKING:
- VS.TNU.CPULOAD.MAX: Maximum CPU Usage of the SCU.
- VS. TNU.CPULOAD.OVER: Rate of the period in which the CPU Usage of the SCU exceeds the Alarm Threshold.
UTILIZATION:
- VS. TNU.CPULOAD.MEAN: Average CPU Usage of the SCU.
- VS. TNU.CPULOAD.LESS: Rate of the period in which the CPU Usage of the SCU is lower than the Alarm Threshold.
FUNCTIONS:
The TNUa board provides the TDM switching and serves as the switching center for the CS services of the entire system. It
performs the following functions:
•
Provides 128 kbit/s x 128 kbit/s TDM switching
•
Allocates the TDM network resources
For internal use
42
© Nokia Siemens Networks
Presentation / Author / Date
BSC6900 (R11 boards) - XPU Board
BLOCKING:
- VS.XPU.CPULOAD.MAX: Maximum CPU Usage of the XPU.
- VS.XPU.CPULOAD.OVER: Rate of the period in which the CPU Usage of the XPU exceeds the Alarm Threshold.
UTILIZATION:
- VS.XPU.CPULOAD.MEAN: Average CPU Usage of the XPU.
- VS.XPU.CPULOAD.LESS: Rate of the period in which the CPU Usage of the XPU is lower than the Alarm Threshold.
FUNCTIONS:
Loaded with different software, the XPU board is functionally divided into main control XPU board and non-main control XPU
board. The main control XPU board is used to manage the GSM user plane resources, control plane resources, and
transmission resources in the system and process the GSM services on the control plane. The non-main control XPU board is
used to process the GSM services on the control plane.
•
Managing the user plane resources; managing the load sharing of the user plane resources between subracks
•
Maintaining the load of the control plane within the subrack; exchanging the load information on the control planes between
subracks
•
Providing functions such as the logical main control function of the BSC6900, the IMSI-RNTI maintenance and query, and
the IMSI-CNid maintenance and query
•
Forwarding the RRC connection request message to implement the sharing of user plane resources and sharing of control
plane resources in the BSC6900
•
Processing upper-layer signalling over the A, Um, Abis and Ater interfaces
•
Processing transport layer signalling
•
Allocating and managing the various resources that are necessary for service setup, and establishing signalling and service
•
connections
•
Processing RFN signalling
- XPUa: Main control XPUa has 4 logical subsystems. Non-main control XPUa has 4 logical subsystems.
- XPUb: Main control XPUa has 8 logical subsystems. Non-main control XPUa has 8 logical subsystems.
For internal use
43
© Nokia Siemens Networks
Presentation / Author / Date
Transcoder
There are 2 configuration modes of Transcoders in Huawei BSS:
1. BM/TC Separated: Transcoder is a separate subrack (GTCS) which can be located either on the BSC side or on the MSC
side. Ater interface should be configured.
2. BM/TC Combined: Transcoder functions are performed by specific boards installed in BM subracks (GMPS/GEPS). Ater
interface does not need to be configured.
UTILIZATION:
- AR0755:BS_RES_BUSY_TC_AVG: Mean Number of Busy TC Resources
- AR0754:BS_RES_IDLE_TC_AVG: Mean Number of Idle TC Resources
- AR0751:BS_RES_FAIL_TC_AVG: Mean Number of Faulty TC Resources
For internal use
44
© Nokia Siemens Networks
Presentation / Author / Date
THANK YOU
For internal use
45
© Nokia Siemens Networks
Presentation / Author / Date