Top Banner
Nokia Siemens Networks GSM/EDGE BSS, rel. RG10(BSS), operating documentation, issue 05 Plan and dimension BSS (BSC) Traffic Handling Capacity, Network Planning and Overload Protection DN9812388 Issue 10-0 Approval Date 17/02/2009 00:00:00
35
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Bsc Unit Capacity

Nokia Siemens Networks GSM/EDGE BSS, rel. RG10(BSS), operating documentation, issue 05

Plan and dimension

BSS (BSC) Traffic Handling Capacity, Network Planning and Overload Protection

DN9812388

Issue 10-0Approval Date 17/02/2009 00:00:00

Page 2: Bsc Unit Capacity

2 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914e1

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

Page 3: Bsc Unit Capacity

DN9812388Issue 10-0

3

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914e1

Table of ContentsThis document has 35 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Planning the cellular network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 BSC nominal capacity and dimensioning. . . . . . . . . . . . . . . . . . . . . . . . 10

3 Planning of basic GSM radio network parameters. . . . . . . . . . . . . . . . . 143.1 Location Area Definition and CCCH Parameters. . . . . . . . . . . . . . . . . . 143.2 Abis LAPD link and CCS7 link dimensioning . . . . . . . . . . . . . . . . . . . . . 19

4 BSS overload protection and flow control . . . . . . . . . . . . . . . . . . . . . . . 214.1 BSS overload protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 System throughput versus offered load . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Overload protection mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4 How to know when the system is running above the nominal load? . . . 314.5 AS7 overload protection implementation . . . . . . . . . . . . . . . . . . . . . . . . 324.6 The LAPD counters used to check the LAPD load statistics . . . . . . . . . 324.7 Indications on overload protection mechanisms . . . . . . . . . . . . . . . . . . 334.8 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.9 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Page 4: Bsc Unit Capacity

4 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914e1

List of FiguresFigure 1 BSS block diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figure 2 System throughput versus offered load . . . . . . . . . . . . . . . . . . . . . . . . . 25

Page 5: Bsc Unit Capacity

DN9812388Issue 10-0

5

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914e1

List of TablesTable 1 Connectivity of logical PCUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Table 2 Extreme case 1: theoretical maximum (maximum paging capacity in radio

interface, TMSI4 in use, for example 4 TMSIs in each paging) . . . . . . 15Table 3 Extreme case 2: theoretical minimum (minimum paging capacity in radio

interface, IMSI1 in use only, for example 1 IMSI in each paging) . . . . . 15Table 4 Parameter values for the LA size for small cells . . . . . . . . . . . . . . . . . 16Table 5 Parameter values for the LA size for medium size cells . . . . . . . . . . . 16Table 6 Parameter values for the LA size for large cells . . . . . . . . . . . . . . . . . 17Table 7 Parameter values for the LA size for extra large cells . . . . . . . . . . . . . 17Table 8 LA with 2 cells Combined and 8 cells Noncombined . . . . . . . . . . . . . . 18Table 9 LAPD capacity of BSC3i AS7 Variants . . . . . . . . . . . . . . . . . . . . . . . . 20

Page 6: Bsc Unit Capacity

6 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914e1

Page 7: Bsc Unit Capacity

DN9812388Issue 10-0

7

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Summary of changes

Id:0900d805805914d2

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Changes made between issues 10-0 and 9-0The capacity figures for Flexi BSC and PCU2-E added.

A table describing the LAPD capacity of BSC3i AS7 variants added.

Changes made between issues 9-0 and 8-0In chapter Planning of basic GSM radio network parameters, more information on 32 kbit/s LAPD links and CCS7 links has been added to section Abis LAPD link and CCS7 link dimensioning.

Changes made between issues 8-0 and 7-1Modified the name of chapter BSS overload protection to BSS overload protection and flow control and included the information from Flow and Overload Control document into it. Structural changes in chapter BSC nominal capacity and dimensioning.

Updated the Traffic Handling Capacity information with data for the new BSC3i variants.

Updated the PCU Capacity and Overload Protection topic with changes due to the intro-duction of (E)GPRS Inactivity alarm.

Changes made between issues 7-1 and 7-0Editorial changes.

Page 8: Bsc Unit Capacity

8 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914d5

Planning the cellular network

1 Planning the cellular networkThis is an overview of how to plan and configure the GSM/EDGE network implemented by the base station subsystem (BSS) in such a way that the performance experienced by the end-users is not limited by an overload in the BSS.

The general procedure of radio network planning is explained, with a detailed descrip-tion of CCCH parameters. Note that the network planning examples are just generic examples and as such they do not necessarily represent the optimal solution for any par-ticular network.

Commonly cellular network (BSS) planning has the following main targets:

• to achieve the required radio coverage with the maximum time and location proba-bility (more than 90%)

• to maximise the network capacity (Erl/km2) with a limited frequency band (MHz) by reusing frequencies

• to reach a good quality of service (QoS) with a minimum level of interference • to minimise the number of network elements and transmission needed (MSC, BSC,

BTS, ...) and therefore the cost of the network infrastructure

The described network planning process is an optimisation process which needs infor-mation about network elements, system properties (GSM, GPRS, EDGE), planning of the environment, topography of the service area, existing facilities of the operator, dis-tribution of the subscribers, and the estimated future growth of subscribers.

Network dimensioning is done so that the coverage and capacity requirements based on subscriber growth forecast are fulfilled. After the number of network elements and commercial aspects is available, the business plan can be made.

An important activity of network planning is the base station subsystem (BSS) parame-ter planning and radio network verification and optimisation. This is based on experience gained during the trial period of the network.

The general results and documents from network planning are:

• List of sites and network elements • Coverage predictions and measurements • Frequency plan and interference analysis • Capacity calculations • BSS parameter plan • Transmission network plan

During the network's existence, knowledge about its operation and subscriber behaviour will improve. The network will also expand in terms of capacity and coverage because of continuous subscriber growth. Therefore, network planning is also a continuous process which tries to minimise the modifications to the existing network while preparing extension plans. Testing and tuning are also needed at each new stage of the network to ensure good quality of service.

In the planning and optimisation phase we also need to verify that all the network elements and the interfaces between them have enough capacity for the given network configuration providing good quality for all subscribers with their estimated reference call mix.

The following planning aspects should also be checked:

Page 9: Bsc Unit Capacity

DN9812388Issue 10-0

9

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Planning the cellular network

Id:0900d805805914d5

1. BSC erlang capacity load (for example the BSC traffic handling (erlang)) capacity must be large enough for the planned network configuration and traffic load.

2. The optimised location area (LA) and routing area (RA) size and the common control channel (CCCH) structure (for example combined, noncombined CCCH) is defined for the given network in order to keep the paging load in the required physical limits in the BSC Abis LAPD links (16 kbit/s, 32 kbit/s, or 64 kbit/s) and in the radio inter-face.

Both aspects 1 and 2 require, of course, a certain call mix (either the default one or a more precise, case-specific one) to be used as the basis for planning. If the physical limits are exceeded in the given network configuration, the original plan should be reviewed by checking, for example, LA size, CCCH channel structure or BSC configu-ration (amount) in question.

Page 10: Bsc Unit Capacity

10 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914d8

BSC nominal capacity and dimensioning

2 BSC nominal capacity and dimensioningDescribed here are the traffic handling capacities of the GSM/EDGE Base Station Con-trollers, BSC2i, BSC3i and Flexi BSC, with certain average call mixes. Additionally, the whole BSS (BSC) overload protection is described. The overload protection has been implemented to protect the equipment and the system in exceptionally high traffic cases.

In the given network the BSC erlang (traffic handling) capacity must be checked so that the following nominal erlang capacity is not exceeded. This is the simplest case (that is, to check only erlang figures) in which the reference call mix can be used. In many cases the call mix in real networks differs from the nominal one. By a separate agreement Nokia Siemens Networks can provide a separate estimate of the BSC capacity for the call mix in question. The BSC traffic handling capacity in the case of GPRS should be noted separately.

BSC2i and BSC3i traffic handling capacity with the following circuit-switched reference call mix is stated in Product Description of BSC2i and BSCi High Capacity Base Station Controller , Product Description of BSC3i High Capacity Base Station Controller and Flexi BSC Product Description.

The examples below are theoretical and illustrate BSC capacities in relation to nominal call mix as defined in related BSC Product Description documents.

Example: Flexi BSC Traffic Handling CapactiyBSC3i is configured with 3000 full rate TRXs, circuit-switched:

• 18000 erlangs total traffic handling capacity • 25 mErl per subscriber, 720 200 subscribers • 531 000 busy hour call attempts (BHCA) • 120 seconds mean hold time • 70% mobile-originated calls (MO) • 30% mobile-terminated calls (MT) • 1.5 handovers (HO) per call • 2 location updates (LU) per call • 0.1 IMSI detach per call • 63% no paging response • 1 SMS call rate subs/hour • (80% terminated SMS)

In the circuit-switched (CS) case, for example, the nominal BSC paging load for Flexi BSC would be (note that both MT calls and MT SMSS create pages):

531 000 x 0.3 (MT) + 720 000 x 0.8 (SMS MT) = 735 300 + re-paging 0.63 x 735 300 = 1 198 539 pagings per hour in A-interface.

The nominal Flexi BSC RACH load (MO, MT, SMS, LUs) would be, for example:

531 000 (MO, MT) + 2 x 531 000 (LU) + 0.1 x 531 000 (IMSI detach) + 735 300 (SMS) = 2 381 400 RACHs per hour per BSC.

Example: BSC3i 2000 Traffic Handling CapactiyBSC3i is configured with 2000 full rate TRXs, circuit-switched:

• 11880 erlangs total traffic handling capacity • 25 mErl per subscriber, 475 200 subscribers • 354 000 busy hour call attempts (BHCA)

Page 11: Bsc Unit Capacity

DN9812388Issue 10-0

11

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSC nominal capacity and dimensioning

Id:0900d805805914d8

• 120 seconds mean hold time • 70% mobile-originated calls (MO) • 30% mobile-terminated calls (MT) • 1.5 handovers (HO) per call • 2 location updates (LU) per call • 0.1 IMSI detach per call • 63% no paging response • 1 SMS call rate subs/hour • (80% terminated SMS)

In the circuit-switched (CS) case, for example, the nominal BSC paging load for BSC3i 2000 would be (note that both MT calls and MT SMSS create pages):

354 000 x 0.3 (MT) + 475 200 x 0.8 (SMS MT) = 486 360 + re-paging 0.63 x 486 360 = 792 767 pagings per hour in A-interface.

The nominal BSC3i 2000 RACH load (MO, MT, SMS, LUs) would be, for example:

354 000 (MO, MT) + 2 x 354 000 (LU) + 0.1 x 354 000 (IMSI detach) + 486 360 (SMS) = 1 583 760 RACHs per hour per BSC.

Example: BSC3i 660 Traffic Handling CapacityBSC3i is configured with 660 full rate TRXs, circuit-switched:

• 3920 erlangs total traffic handling capacity • 25 mErl per subscriber, 157 000 subscribers • 117 000 busy hour call attempts (BHCA) • 120 seconds mean hold time • 70% mobile-originated calls (MO) • 30% mobile-terminated calls (MT) • 1.5 handovers (HO) per call • 2 location updates (LU) per call • 0.1 IMSI detach per call • 63% no paging response • 1 SMS call rate subs/hour • (80% terminated SMS)

In the circuit-switched (CS) case, for example, the nominal BSC paging load for BSC3i would be (note that both MT calls and MT SMSS create pages):

117 000 x 0.3 (MT) + 157 000 x 0.8 (SMS MT) = 160 700 + re-paging 0.63 x 160 700 = 261 941 pagings per hour in A-interface.

The nominal BSC3i RACH load (MO, MT, SMS, LUs) would be, for example:

117 000 (MO, MT) + 2 x 117 000 (LU) + 0.1 x 117 000 (IMSI detach) + 160 700 (SMS) = 523 400 RACHs per hour per BSC.

Example: BSC2i Traffic Handling CapacityBSC2i configured with 512 full rate TRXs, circuit-switched:

• 3040 erlangs total traffic handling capacity • 25 mErl per subscriber, 120 000 subscribers • 91 000 busy hour call attempts (BHCA) • 120 seconds mean hold time

Page 12: Bsc Unit Capacity

12 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914d8

BSC nominal capacity and dimensioning

• 70% mobile-originated calls (MO) • 30% mobile-terminated calls (MT) • 1.5 handovers (HO) per call • 2 location updates (LU) per call • 0.1 IMSI detach per call • 63% no paging response • 1 SMS call rate subs/hour • (80% terminated SMS)

In the circuit-switched (CS) case, for example, the nominal BSC paging load for BSC2i would be (note that both MT calls and MT SMSS create pages):

91 000 x 0.3 (MT) + 120 000 x 0.8 (SMS MT) = 123 300 + re-paging 0.63 x 123 300 = 200 979 pagings per hour in A-interface.

The nominal BSC2i RACH load (MO, MT, SMS, LUs) would be, for example:

91 000 (MO, MT) + 2 x 91 000 (LU) + 0.1 x 91 000 (IMSI detach) + 123 300 (SMS) = 405 400 RACHs per hour per BSC.

Some call mix is needed in order to get the main performance figures (erlangs, BHCAs) in relation to processor load. With a different call mix, the BHCA value, for example, varies a lot because in a complex system such as GSM there are many other transac-tions, in addition to calls, which load the system.

Roughly it can be said that the erlangs per air channel are the largest contribution to the BSC processor load; the next largest ones are the number of call procedures (call set-up, clearing), SMSS and location updates (LUR, IMSI Attach/Detach are similar) and, lastly, all different types of handovers. By saying that erlangs as such are significant we mean that there is a load in the system even though there is one call with indefinite length on each channel without having any HOs, LURs, and so on.

Packet-switched capacity

• Flexi BSC: max. 30 PCU2-E plug-in units (In Flexi BSC, physical PCU2 = logical PCU2)

• BSC3i 2000: max. 100 PCU2 (50 physical PCU2 units per BSC, 2 logical PCUs in one PCU2 plug-in unit)

• BSC3i 1000: max. 50 PCU2 (25 physical PCU units per BSC, 2 logical PCUs in one PCU2 plug-in unit)

• BSC3i 660: max. 24 PCU1/PCU2 (12 physical PCU units per BSC, 2 logical PCUs in one PCU1/PCU2 plug-in unit)

• BSC2i: max. 16 PCU1/PCU2 (16 physical PCU units per BSC, 1 logical PCU in one PCU1/PCU2 plug-in unit)

16kbit/s Abis TSL TRX Cell/ Segments BTS

Logical PCU2-E in Flexi BSC

1024 1024 256 384

Logical PCU2

(PCU2-D/PCU2-U)

256 256 64 128

Table 1 Connectivity of logical PCUs

Page 13: Bsc Unit Capacity

DN9812388Issue 10-0

13

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSC nominal capacity and dimensioning

Id:0900d805805914d8

Logical PCU1

(PCU-B/PCU-T)

256 128 64 64

Logical PCU1

(PCU/PCU-S)

256

(128 RTSL)

128 64 64

16kbit/s Abis TSL TRX Cell/ Segments BTS

Table 1 Connectivity of logical PCUs (Cont.)

Page 14: Bsc Unit Capacity

14 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914db

Planning of basic GSM radio network parameters

3 Planning of basic GSM radio network param-etersThe following sections provide some recommendations and practical parameter values for network planning which help you to plan and dimension the system to perform in a nominal load area and to ensure the best system performance. To illustrate the idea of calculations, the configurations are simplified to four configurations:

• 2 + 2 + 2 • 4 + 4 + 4 • 6 + 6 + 6 • 12 + 12 + 12

Note that all the theoretical examples presented here are very simplified. They are cal-culated just to give some ideas which parameters the network planners should take into account for example when dealing with the paging process.

3.1 Location Area Definition and CCCH ParametersPaging channel (PCH) signalling will be sent over the whole location area (LA). This means that one paging message over the A interface is 'copied' to all Abis links going to the common control channel (CCCH) TRX of cells in the same location area. An optimal LA size is a balance between PCH load and location updates (LU). If the LA size is too large, paging channels and capacity will be saturated because of limited LAPD Abis or radio interface CCCH paging capacity and BCSU processor may become overloaded. On the other hand, with large location areas there will be a smaller number of location updates (LU) performed and vice versa.

The same applies to paging coming via the Gs and Gb interfaces: the MSC sends the paging message to the SGSN with the LA info and the SGSN defines it to a more accurate area: cell, routing area (RA), LA or BSS. If within the SGSN area there are cells that do not support GPRS services, the SGSN will group these cells under a 'null RA'. The SGSN will perform the paging procedure described above within both the RA(s) derived from the location information and the 'null RA'.

The number of CCCHs depends on the channel structure as follows:

• COMBINED: for a small cell, ≤ 2 TRXs/cell, 3 CCCHs in every signalling multiframe (51 TDMA, 235 ms)

• NONCOMBINED: for a large cell, ≥ 3 TRXs/cell, 9 CCCHs in every signalling mul-tiframe (51 TDMA, 235 ms), used if GPRS is enabled in the cell.

Note that this is a kind of 'rule of thumb' of today, assuming not very heavy SMS traffic.

The parameters that affect the CCCH capacity on a cell basis are the following:

• Number of blocks reserved to AGCH (BS_AG_BLKS_RES); once this parameter is specified, the PCH is calculated; the parameter range is 0 to 7 and value zero is not recommended.

• number of multiframes (BS_PA_MFRMS); this specifies how many multi-frames will go until the given paging group is re-paged; the parameter range is 2 to 9 and the recommended value is 5.

Page 15: Bsc Unit Capacity

DN9812388Issue 10-0

15

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Planning of basic GSM radio network parameters

Id:0900d805805914db

The paging method is also set in MSC TMSI or IMSI. TMSI is more commonly used, because of bigger capacity (4/page group). Here we assume that all the radio interface capacity is used, thus all extra paging will be ignored.

Below there are two extreme cases in terms of how high or low the paging capacity is over the radio interface. These examples are theoretical ones and the intention is to show the range of variation caused by different CCCH parameterisations.

The following examples gives some estimation of parameters and LA sizes with BSC3i 2000 configuration, when 60% of total Erlang capacity is assumed to be used. The paging capacity is presented for four different cell configurations:

• 2 + 2 + 2 • 4 + 4 + 4 • 6 + 6 + 6 • 12 + 12 + 12

Example: LA size for small cells (2 + 2 + 2 configuration)In this example it is assumed that we have a configuration with 2 TRXs per cell. If we use 2% blocking in the radio interface, we can see from the erlang (the unit of measure of carried traffic intensity) B-table that some 9 erlangs will be served on a cell basis. This can be converted to some 360 subscribers per cell (0.025 erlang per subscriber). If one site consists of 2 + 2 + 2 as a configuration, some 264 sites together will serve some 7 128 erlang or 285 120 subscribers.

For small cells (2 + 2 + 2 configuration) LA configuration should be considered. For example, if three LAs are used then LA size would be 528 TRXs.

COMBINED NONCOMBINED

MAX ( ≤ 2TRXs/cell) ( ≥ 3 TRXs/cell)

total CCCH 3 9

PCH 2 8

AGCH 1 1

Pages per hour 122 553 490 212

Table 2 Extreme case 1: theoretical maximum (maximum paging capacity in radio interface, TMSI4 in use, for example 4 TMSIs in each paging)

COMBINED NONCOMBINED

MIN ( ≤ 2 TRXs/cell) ( ≥ 3 TRXs/cell)

total CCCH 3 9

PCH 1 2

AGCH 2 7

Pages per hour 15 319 30 638

Table 3 Extreme case 2: theoretical minimum (minimum paging capacity in radio interface, IMSI1 in use only, for example 1 IMSI in each paging)

Page 16: Bsc Unit Capacity

16 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914db

Planning of basic GSM radio network parameters

Here we assume the BSC nominal call model with only 0.1 SMS call rate per subs/hour.

The parameter number of multiframes value is 5 here. It means that the same paging group will be re-paged after 5 x 235 ms = 1.175 sec. This will ensure longer MS battery lifetime, because the MS has to listen quite seldom to a CCCH channel in a serving cell. You must ensure that the paging load does not exceed the physical limits in radio/Abis interfaces. These could be practical values provided that the SMS paging amount in the BSC call model would be less - for example 0.1 SMS call rate subscribers per hour, which would reduce the paging load.

Example: LA size for medium size cells (4 + 4 + 4 configuration)In this example it is assumed that we have a configuration with 4 TRXs per cell. If we use 2% blocking in the radio interface, we can see from the erlang B-table that some 21.9 erlangs will be served on cell basis. This can be converted to some 876 subscribers per cell (0.025 erlang per subscriber). If one site consists of 4 + 4 + 4 as a configuration, some 108 sites together will serve some 7 117 erlang or 284 700 subscribers.

For medium size cells (4 + 4 + 4 configuration) LA configuration should be considered. For example, if three LAs are used then LA size would be 434 TRXs.

Total number of subscribers 285 120 (in 792 cells, each 360 subs.)

Example TRXs in LA 528

Cell configuration 2 + 2 + 2

CCCH channel structure COMBINED (for example small cell)

Total CCCH 3

Typical PCH 2

Typical AGCH 1

Number of multiframes 5

Max. Pages per hour (in Air) theoretically 110 297 (TMSI4 80%, IMSI2 20%)

Pages per hour with BSC nominal call mix 47 249

Table 4 Parameter values for the LA size for small cells

Total number of subscribers 284 700 (in 325 cells, each 876 subs.)

Example TRXs in LA 434

Cell configuration 4 + 4 + 4

CCCH channel structure NONCOMBINED (for example large cell)

Total CCCH 9

Typical PCH 6

Typical AGCH 3

Number of multiframes 5

Max. Pages per hour (in Air) theoretically 147 062 (TMSI2 60%, IMSI1 40%)

Pages per hour with BSC nominal call mix 47 179

Table 5 Parameter values for the LA size for medium size cells

Page 17: Bsc Unit Capacity

DN9812388Issue 10-0

17

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Planning of basic GSM radio network parameters

Id:0900d805805914db

Here we assume the BSC nominal call model with only 0.1 SMS call rate per subs/hour.

Example: LA size for large cells (6 + 6 + 6 configuration)In this example it is assumed that we have a configuration with 6 TRXs per cell. If we use 2% blocking in the radio interface, we can see from the erlang B-table that some 34.6 erlangs will be served on cell basis. This can be converted to 1384 subscribers per cell (0.025 erlang per subscriber). If one site consists of 6 + 6 + 6 as a configuration, some 68 sites together will serve some 7 127 erlang or 285 104 subscribers.

For large size cells (6 + 6 + 6 configuration) LA configuration should be considered. For example, if three LAs is used then LA size would be 412 TRXs.

Here we assume the BSC nominal call model with only 0.1 SMS call rate per subs/hour.

Example: LA size for extra large cells (12 + 12 + 12 configuration)In this example it is assumed that we have a configuration with 12 TRXs per cell. If we use 2% blocking in the radio interface, we can see from the erlang B-table that some 77.3 erlangs will be served on cell basis. This can be converted to some 3092 subscrib-ers per cell (0.025 erlang per subscriber). If one site consists of 12 + 12 + 12 as a con-figuration, some 30 sites together will serve some 7 111 erlang or 284 464 subscribers.

For extra large size cells (12 + 12 + 12 configuration) LA configuration should be con-sidered. For example, if three LAs is used then LA size would be 369 TRXs.

Total number of subscribers 285 104 (in 206 cells, each 1384 subs.)

Example TRXs in LA 412

Cell configuration 6 + 6 + 6

CCCH channel structure NONCOMBINED (for example large cell)

Total CCCH 9

Typical PCH 8

Typical AGCH 1

Number of multiframes 5

Max. Pages per hour (in Air) theoretically 490 212 (TMSI4)

Pages per hour with BSC nominal call mix ( 0.1 SMS)

47 246

Table 6 Parameter values for the LA size for large cells

Total number of subscribers 284 464 (in 92 cells, each 3092 subs.)

Example TRXs in LA 369

Cell configuration 12 + 12 + 12

CCCH channel structure NONCOMBINED (for example large cell)

Total CCCH 9

Typical PCH 8

Typical AGCH 1

Number of multiframes 5

Table 7 Parameter values for the LA size for extra large cells

Page 18: Bsc Unit Capacity

18 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914db

Planning of basic GSM radio network parameters

Here we assume the BSC nominal call model with only 0.1 SMS call rate per subs/hour.

The parameter number of multiframes value is 5 here. It means that the same paging group will be re-paged after 5 x 235 ms = 1.175 sec. This will ensure longer MS battery lifetime, because the MS has to listen quite seldom to a CCCH channel in a serving cell. In this case you must also ensure from the estimated call mix or from live network statistics and measurement values that you operate in the nominal BSC load area and that the Abis paging load does not exceed the limits of LAPD (16 kbit/s, 32 kbit/s, or 64 kbit/s) link capacity nor the radio interface paging capacity.

The recommendation concerning MSC paging parameters (see The LAPD counters used to check the LAPD load statistics) is to use the 'LA' paging method (LAC or LAI), which prevents the unnecessary cell level CI information from being sent to the BSC via the A interface. If the CI information is included, it is sent for each cell in the LA. Paging via the A interface is always performed on LA level. Inclusion of the CI information does not provide any benefit and loads the MSC, BSC and the A interface unnecessarily.

In the MSC there are also parameters related to CCCH (actually PCH) capacity, which are on a LA basis. To ensure that the paging message reaches the MS, the paging message is sent several times. The repetition procedure is defined in the MSC. These MSC parameters are Repaging_Interval (time between paging attempts) and Number_of_Repaging_Attempts, which can be modified in the (Nokia) MSC.

The recommended values are: Number_of_Repaging_Attempts = 0, Repaging_Interval = 3.5s. This works better if TMSI is in use. This means that the first paging goes with TMSI, and then after 3.5 seconds with IMSI, if the subscriber does not respond to TMSI.

The conclusion is that paging load is highly dependent on parameters. In the same LA, the paging load should be monitored. Note that if there is only one small cell in a given LA, where combined channel structure is in use, this will be the bottleneck if paging blocking criteria are strictly followed. In other words: the smallest cell in the LA will set the PCH limit. Note also that some maximum configurations would not be possible because of other limiting factors such as the 16 kbit/s Abis or radio interface, which would start to limit the message traffic, thus it would be useless to define such parameter settings (for example too large location area size).

If there are only one or two cells with combined channel structure in an LA, you can choose to live with a high paging blocking rate in this cell because the probability of MS location in this cell is very low. Therefore, the Paging blocking rate as seen from the MSC is not modified much by too few PCHs on this cell.

Max. Pages per hour (in Air) theoretically 490 212 (TMSI4)

Pages per hour with BSC nominal call mix (0.1 SMS)

47 140

Blocking rate MS location probabil-ity

Cell 1 30% 2%

Cell 2 30% 2%

Table 8 LA with 2 cells Combined and 8 cells Noncombined

Table 7 Parameter values for the LA size for extra large cells (Cont.)

Page 19: Bsc Unit Capacity

DN9812388Issue 10-0

19

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Planning of basic GSM radio network parameters

Id:0900d805805914db

The final Blocking rate is 30 x 4/100 + (1 x 96/100) = 2.16%.

Moreover, if the MSC repeats the Paging messages, the end user blocking rate can be considerably reduced if the PCH is not overloaded too much: 10% x 10% ≈ 1%.

3.2 Abis LAPD link and CCS7 link dimensioningAbis LAPDYou should also take into account the following factors when estimating the capacity of the Abis LAPD signalling, especially the 16 kbit/s link:

• There can be a maximum of 2 signalling messages unacknowledged at any time, all the subsequent messages must wait for the acknowledgement of at least one of these messages; all the messages are stored in an AS7 buffer until responded to by the opposite end. The LAPD window size 2 is recommended by 3GPP TS 48.056.

• The acknowledgement delay varies from a few milliseconds to tens of milliseconds because of the characteristics of the LAPD protocol, especially if there is a lot of sig-nalling traffic coming in from the opposite direction (measurement reports and so on). All this lowers the maximum capacity much below 16 kbit/s.

• Disturbances on the physical 2 Mbit/s line may cause more delays, which lowers the capacity.

• The average AS7 transmit buffer occupancy should be close to 0 or at most, for optimal use of the link capacity, just a few messages (so that there is always one message waiting for transmission), that is, the buffer is used mainly for temporary storage of the transmitted messages waiting for acknowledgement and for occa-sional bursts of messages. If, instead of this, we assumed a high average buffer occupancy, it would also mean that signalling messages would generally experience long delays while they wait for transmission in the buffer. Generally, the transmit buffer size of the AS7 and its occupancy level need not be considered in dimension-ing, as the capacity of the buffer is sufficient to handle any burst of messages that is still within the capacity of the Abis signalling link and maximum delays considered.

• Based on these previous factors and measurements made on the Abis link, the maximum average signalling traffic load should not exceed 8 kbit/s (1000 bytes/sec). There is a risk of AS7 overflow if the load is more than 1200 bytes/sec.

One of the most common messages sent on the highest loaded Abis link (that is, the BCCH TRX link) is the paging message.

Cell 3 1% 6%

Cell 4 1% 10%

Cell 5 1% 10%

Cell 6 1% 10%

Cell 7 1% 10%

Cell 8 1% 10%

Cell 9 1% 10%

Cell 10 1% 10%

Table 8 LA with 2 cells Combined and 8 cells Noncombined (Cont.)

Page 20: Bsc Unit Capacity

20 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914db

Planning of basic GSM radio network parameters

The length of the paging message (including FCS and flags) is about 21 bytes. Accord-ing to the BSC nominal load and call mix, about 60% of all capacity can be given to the paging messages; the average paging message count/sec/link is thus 0.6 x maximum signalling traffic load / 21. = 29, which roughly equals 100 000 pages per hour (16 kbit/s). This is sufficient, for example, for the nominal BSC call model.

The same general principles apply for 32 kbit/s and 64 kbit/s links. The maximum rec-ommended average signalling traffic is 2000 bytes/sec (32 kbit/s) or 4000 bytes/sec (64 kbit/s), which roughly equals to 200 000 (32 kbit/s) and 400 000 (64 kbit/s) pages per hour.

The number of paging messages is different depending on the call mix and configura-tion. If the reference nominal call mix is not suitable, the limits to be considered are 1000 bytes/s (16 kbit/s LAPD), 2000 bytes/s (32 kbit/s), and 4000 bytes/s (64 kbit/s LAPD) per Abis link, already mentioned above.

Note that these values are for individual links only and they should not be used to estimate the total or even the BCSU capacity without taking other dimensioning rules into account.

CCS7Extended SS7 signalling capacity is needed especially for high SMS usage, short calls, and signalling needs of a high BSC TRX capacity. The BSC3i 2000 offers connectivity and capacity with 2Mbit/s, 512 kbit/s, 256 kbit/s, 128 kbit/s, and 64 kbit/s links as well as SIGTRAN links. SIGTRAN allows flexible capacity allocation which is not tied to a fixed bandwidth such as 64 kbit/s or 2 Mbit/s, for example.

When estimating the need of signalling links, it is recommended that one signalling link load should not overrun 0.2 Erl. Additionally, redundancy should be considered in the case of failure in one of the links. Additional links should be provided so that the overall SS7 signalling traffic maintains normal operations during the failure of a link. In satellite links, the signalling link load should be under 0.06 erlang.

The operator should routinely monitor growing traffic and link conditions to ensure appropriate dimensioning.

BSC Configurations BSC3i 660 BSC3i 1000 BSC3i 2000 Flexi BSC

Type of LapD and Q1 terminal in OMU

AS7-B (S10.5/S10.5ED)

AS7-C (S11/S11.5)

AS7-C AS7-C AS7-D

Number of BCFSIG LapD links per BCSU

84 200 200 500

Number of TRXSIG LapD links per BCSU

110 200 200 500

Table 9 LAPD capacity of BSC3i AS7 Variants

Page 21: Bsc Unit Capacity

DN9812388Issue 10-0

21

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

4 BSS overload protection and flow controlThe main purpose of overload protection and flow control is to avoid the network becoming heavily loaded, which in the worst case scenario could lead to a total collapse of service in a network element. Overload situations can lead to, for instance, call clearing or reset procedures.

In the case of an overload, overload protection and flow control aims to maintain the service level of established calls as normal as possible. This also pertains to handover attempts caused by the radio environment.

The principle of flow control is to set certain restrictions for new call attempts within the network. In the GSM system, flow control can be performed either in the radio interface or inside the network. Flow control in the radio interface is performed by limiting access from mobile stations (MSS) according to specified rules. If required, new call attempts may be abandoned in the network, nevertheless allowing for priorisation, as, for example, in the case of emergency calls.

4.1 BSS overload protectionThe main building blocks of the BSS system, presented below, help in understanding the BSS traffic dimensioning and BSS performing in overload situations. Figure BSS block diagram illustrates the components that are relevant from the BSS capacity point of view.

There are two types of blocks: channels or buses with a certain fixed bandwidth, and processors. There are several different types of processors in the system:

• digital signal processors (DSP) • BTS TRX controllers • BSC main CPUs (BCSU, MCMU) • BSC pre-processors (AS7)

Page 22: Bsc Unit Capacity

22 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

Figure 1 BSS block diagram

• The Radio interface channel has a certain maximum capacity as specified by GSM specifications. From the capacity planning point of view, there are several different channel types with different throughputs to be selected: common control channel (CCCH) and a combined SDCCH/4 & CCCH. Within the CCCH, there is the parameter Number of blocks reserved to Access Grant to adjust CCCH downlink partition. There are also some other CCCH-related parameters, namely paging related: BS_PA_MFRMS and random access-related (RACH) TX_INTEGER and MAX_RETRANS which have an indirect impact on channel capacity.

• BTS DSP is a dedicated block signal processing power allocated permanently for one radio time slot. The actual number of radio time slots per a single DSP chip varies between BTS generations. The principle from the loading analysis point of view is the same: the DSP runs in a loop to execute tasks related to a radio time slot (RTSL) and if it can handle all the frames coming from the radio interface. The pro-cessing power has to be there for the 'worst case' that a single RTSL provides and there is no need to think about call mixes, and so on.

• BTS TRX represents here the processing power reserved to carry TRX-level call control-related tasks such as LAPD termination, BTS call control protocol, DSP interface, and so forth. The actual processor varies in different BTS generations, but in all of them there is a single processor dedicated to a single TRX. At the BTS TRX level, the loading of the processor depends on traffic and configuration.The biggest load is caused by such channel configurations in which the actual number of logical channels is the highest. There is a limitation of a certain number of SDCCHs per TRX. For detailed information, see Dynamic SDCCH in Radio Channel Allocation . TRX processing is dimensioned – according to the worst case

TRXBTS

Airinterfacechannel

BTS

CCCH,TCH,SDCCH

AbisLAPDlink

A interface#7 link

Gb interface

BCSUBSC

Message bus

CPU

MCMU

TRX

DSP

CPU

BCSU

AS7,LAPD

AS7,#7

PCU

Page 23: Bsc Unit Capacity

DN9812388Issue 10-0

23

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

– to handle all the traffic coming from Air/DSP, and no other attention needs to be paid to it when dimensioning the network.The traffic dimensioning can be done just by taking the TRXs as separate and isolated blocks, that is, the high load on one TRX cannot harm the other one within the same BTS. (Frequency hopping is an exception of sharing some common pro-cessing power over sectors/BTSs. Possible limitations coming from frequency hopping are hopping configuration-related, for example the number of hopping groups, and they do not affect call handling capabilities.)

• Abis LAPD link is on a TRX basis and it can be configured to one of the following speeds: • 16 kbit/s • 32 kbit/s • 64 kbit/sThe link can be a bottleneck because both the BSC and BTS processors can offer more messages than it can transfer in some cases. Roughly we can say that a 16 kbit/s link can handle all full-rate configurations of a TRX if the paging load is rea-sonable. A 32 kbit/s link is needed with half rate when the number of logical channels per TRX increases. 64 kbit/s exists for historical reasons as the first, non-optimised LAPD link implementation.

• AS7 LAPD is the BSC's preprocessor for performing the LAPD protocol layer 2 level tasks such as link establishment on the Abis interface, error detection, message segmentation, and retransmissions. AS7 handles LAPD links. The links can be either telecom (TRX) links or O&M (BCF) links. The number of links handled by one processor depends on the plug-in unit variant in use.The basic assumption on dimensioning has been that AS7 can handle all the traffic that both the BSC/BCSU CPU and Abis LAPD links can in practice offer to it. This is true when we talk about calls, HOs and so on (that is, the bottleneck is not the AS7 but the CPU). Because of the AS7 unit, we have to pay some attention to the paging load in LAPD links. Paging comes through the BSC CPU, requiring very small pro-cessing, and it is also very easy to generate a high paging load by radio network planning. That is why it is possible in real networks to run the AS7 to overload pro-tection state. To avoid this high paging load we have to follow certain recommenda-tions as far as the maximum paging load is concerned (see details in Planning of basic GSM radio network parameters).A preprocessing unit AS7 is equipped to the BCSU for both LAPD and SS7 signal-ling. The SS7 interface is for the A interface. It contains a preprocessor, which is capable of handling a maximum of four signalling channels. The regular bit rate in SS7 links is 64 kbit/s. Additionally, wider 128 kbit/s, 256 kbit/s, 512 kbit/s or 2 Mbit/s links can be used. The signalling terminal is semipermanently connected to the time slots used for signalling.The basic assumption on dimensioning has been that the A interface AS7 can handle all the traffic that both the BSC/BCSU CPU and the MSC's A interface #7 links can in practice offer. Additionally, the #7 links are normally redundant. The paging load, however, may also be a bottleneck for the #7 link and its performance.

BCSU, CPUThe BSC Signalling Unit (BCSU) performs those BSC functions that are highly depen-dent on the volume of traffic. It consists of two parts corresponding to the A and Abis interfaces.

Page 24: Bsc Unit Capacity

24 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

In the BSC design phase, the BCSU was thought to be the heaviest loaded functional unit of the BSC even though the MCMU is centralised and the BCSU distributed. A very large number of radio measurements coming from the BTS/MS are processed by the BCSU.

This assumption was confirmed by performance testing and it has also been the case in live networks.

That is why the main focus is to keep the BCSU CPU load in the safe area when loading the BSC. However, normally the BCSU CPU load is not the limiting factor and even in high traffic cases the CPUs have sufficient overload protection.

Packet-switched traffic has only a marginal effect on BCSU load, since the PCU handles it.

MCMU, CPUThe Marker and Cellular Management Unit (MCMU) performs the control functions of a switching matrix and the BSC-specific management functions of the radio resources.

The cellular management functions of the MCMU assume responsibility for cells and radio channels that are controlled by the BSC. This responsibility is centralised in the MCMU. The MCMU reserves and keeps track of the radio resources requested by the MSC or the handover procedures of the BSC. Thus the BSC's MCMU load might rise in high traffic cases, but the CPU has been protected against exceptionally high traffic cases.

Message Bus (MB)A duplicated high-speed Message Bus (MB) is used for data transfer between the OMU and the call control computers of the BSC3i 660.

The length of each message is determined individually by a message length parameter at the beginning of the message. The sender and the receiver of the message are indi-cated in the address field of the message. The receiver can be a single microcomputer, or it can be a group of microcomputers specified by the broadcast address.

The hardware of the Message Bus consists of several parallel twisted pairs, which carry the actual data and also control the information required for the message transfer. In the event of a failure, the hot standby Message Bus takes over the functions of the active bus without interfering with the ongoing calls.

BSC3i 1000/2000 configurations use new Ethernet-based Message Bus (EMB). Today the message bus capacity is not a bottleneck in the BSC even in very high traffic cases, mainly because of the high bus speed and also because the length of the bus is very short – the BSC has only a maximum of two racks, which enables high speed and fast response times.

Packet Control Unit (PCU)The Packet Control Unit (PCU) is used to control the (E)GPRS radio resources. Its pro-cedures include radio resource allocation and management, connection establishment and management, scheduling, data transfer and Gb load sharing and flow control. Reli-ability is achieved by N+1 redundancy.

The PCU is protected against exceptionally high traffic cases by ignoring the overflowing data. The data will not be lost since other network elements will resend it in the acknowl-edged mode. There are also other software-specific overload protection mechanisms.

Page 25: Bsc Unit Capacity

DN9812388Issue 10-0

25

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

With the full PCU configuration, you can share the BSC-controlled BTS domain for multiple PCUs. One BTS is, however, always controlled by one PCU. This means that the packet-switched traffic load can be shared among BCSUs. The equal sharing of the BTSs is also efficient from the O&M point of view. This is because no BTS switchovers from one PCU to another are needed when the network is growing.

4.2 System throughput versus offered load

Figure 2 System throughput versus offered load

Curve 1) in the figure above represents the system design goal; the system will remain stable even though it is loaded above the 100% possible load (here 100% means typi-cally a CPU with full processor usage). In a complex multiprocessor/multitask system, it is quite challenging to keep the system stable at 100% load.

The challenge in maintaining the system on curve 1) is mainly to detect the emerging overload situation and to throw away tasks/messages in a controlled way at the 'border' of a processor. This requires careful consideration of all the possible interfaces from where messages can come in to a processor and to analyse which are the initial/first messages to trigger actions inside the processor.

In BSS, mechanisms have been implemented to keep the system on curve 1) shown in Figure System throughput versus offered load. These mechanisms cover all the major components of the system (Figure BSS block diagram in BSS overload protection). These mechanisms are described in Overload protection mechanisms.

4.3 Overload protection mechanismsOverload cases in BSS can be divided into the following two types:

• External overload: overload in the network as a whole • Internal overload: BSC's own processor overload.

External overloadOverload in the network is indicated by messages sent from one network element to another. The message transfer channels can also be congested.

In the BSC, external overload is manifested in the following cases:

• overload at MSC, indicated by OVERLOAD messages • overload at BTS, indicated by OVERLOAD and LOAD INDICATION messages • MTP congestion • LAPD overload.

SYSTEMTHROUGHPUT

100 % LOAD

NOMINALLOAD

OFFEREDLOAD

1)

2)

Page 26: Bsc Unit Capacity

26 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

Overload at MSCOverload at the MSC is reduced by a stepwise procedure. When the BSC receives an OVERLOAD message from the MSC, traffic is reduced step by step by barring mobile access classes. The number of access classes that are barred during one step is spec-ified with a UTPFIL parameter. Possible values include 1, 2 and 5; as a default two access classes are barred at a time. The access classes are updated by sending a new system information message via the Abis interface to the MSS.

The traffic reduction procedure is supervised by two timers, T17 and T18, which are started when the OVERLOAD message is received. Possible other incoming OVERLOAD messages are ignored until T17 expires. If an OVERLOAD message is received after the expiry of T17 while T18, which is always set further than T17, is still running, traffic is reduced by one more step and both timers are restarted. The reduction procedure is repeated as long as there are incoming OVERLOAD messages, and steps left in the pro-cedure to reduce traffic. The same step-by-step process is also used to increase traffic, if no OVERLOAD messages are received before the expiry of T18.

OVERLOAD messages come from the MSC as connectionless SCCP messages. The SCCP sends them to the BSC and the hand of the BSC sets the timers T17 and T18. For more details on the timers, see PAFILE Timer and Parameter List and 3GPP TS 48.008 Mobile-services Switching Centre – Base Station System (MSC – BSS) inter-face; Layer 3 specification).

The BSC sends an access class updating message to all distributed masters. This message contains the new access class octets for the RACH control parameter infor-mation element. A master distributes the message to its TRX handling hands that update the system information of all the BTSs. If the new RACH control has a user-set value different from the previous one, the master combines both values so that the user-set value remains valid. As a result, there will not be fewer restrictions than with the pre-defined value.

The BSC controls the access class barring procedure by choosing a different class every time: the barring is done in a logical order, taking the previously barred access class(es) into consideration. Similarly, barring is removed in the same order as it was set, so each access class should have equally long barring. This applies to the access classes from AC C00 to C09. The user can bar other classes with the EQF MML command.

The BSC sets the alarm 2478 MOBILE ACCESS CLASS ABNORMAL when mobile access classes are restricted by the system, and, correspondingly, cancels the alarm when the access classes are not restricted by the system.

For more information on handling overload at MSC when Multipoint A interface software is in use, see Multipoint A Interface in BSC.

Overload at BTSThe BSC receives CCCH LOAD INDICATION messages from the BTS on a regular basis, which indicate the load situation on paging (PCH) and random access (RACH) channels. The CCCH LOAD INDICATION message contains either load on an RACH or load on a PCH if BTS level is phase 2 or GPRS PH 1 (General Packet Radio Service Phase 1). The CCCH LOAD INDICATION message is used mainly for statistics: its reception increments the Resource Access Measurement counters.

Every few seconds, the BTS sends information to the BSC about the resources and buffer space available for PAGING messages coming from the BSC. When the PAGING

Page 27: Bsc Unit Capacity

DN9812388Issue 10-0

27

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

message buffer is full, the BSC sends an OVERLOAD message to the MSC in order to reduce paging in a particular cell. Because the BSC does not have the means to reduce paging traffic in a sophisticated way, the BTS discards the PAGING COMMAND messages that it cannot send forward to the MSS. The deletion of a PAGING COMMAND message causes the counter 003038 AVE PCH LOAD ON CCCH to be incremented.

An access grant channel (AGCH) message overflow is indicated by the reception of a DELETE INDICATION message from the BTS. When a DELETE INDICATION message is received, counter 003005 DELETE IND MESSAGES RECEIVED FROM BTS is incremented.

The CCCH LOAD INDICATION and DELETE INDICATION messages are received by the CCCH hand of the BSCU. The CCCH hand also increments the counters.

For more details on counters related to BTS overload, see 3 Resource Access Measure-ment.

MTP congestionThe procedure used in a congested signalling system is similar to the one described in Overload at MSC except that here the indication of the situation comes from the SCCP that sends MTP congestion messages to the BSC.

LAPD overloadLAPD overload may occur in both uplink and downlink direction. In uplink direction, mea-surement reports are transferred from the BTS (and MS) to the BSC. The control of this overload is a matter of network configuration and the BTS.

Overload may occur in downlink direction because of heavy paging and other call sig-nalling procedures. The transmit buffers of the LAPD links handling the Abis signalling may overflow especially with the 16 kbit/s Abis links. BCSU and PCU therefore mark the PAGING and IMMEDIATE ASSIGNMENT REJECT messages to enable them to be dis-carded during very high load on the LAPD signalling link. This ensures that normal call signalling, for example handovers, proceeds. If the congestion level of the transmit buffers still becomes very high, all signalling messages on the channel(s) causing the congestion may be discarded.

Internal overloadIn the BSC, there are centralised and distributed functions:

• centralised functions are situated in the Marker and Cellular Management Unit (MCMU)

• distributed functions are situated in several BSC Signalling Units (BCSU) and in Packet Control Units (PCU).

Radio resource management and administration are an example of centralised func-tions and interface signalling procedures an example of distributed functions.

Internal processor overload control mechanisms have been implemented exclusively in the distributed unit. See Centralised unit overload for details.

Centralised unit overloadOverload control of the centralised unit is handled by the distributed unit.

When the centralised unit handles the circuit switched random accesses slowly, conges-tion of the CCCH hand can also occur. The CCCH channel hand process has a certain number of places for the pending random accesses. If the response from the MCMU

Page 28: Bsc Unit Capacity

28 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

takes a long time and the queue for the pending random accesses is full, the BCSU discards new random accesses coming from MSS. For every pending random access there is also a timer that supervises the MCMU response. In the case of a timer expiry, the random access is removed from the queue and the place is released for a new one.

1. BSC/BCSU/CPU protection against excessive number of paging messages coming from the A interfaceThe PAGING messages sent by the MSC can cause a heavy processor load. The load from the A interface can be increased further because of large amount of paging repetitions.This type of overload situation takes place, for example, when all the A interface links have been down for a while. That has caused the BSC to put all the cells to 'cell barred' status. When the A interface becomes available, the radio network will still remain 'closed' for a while before the BSC has updated all the cell barring away and all the access classes have been opened for traffic.The paging load from the A interface is high and there are a lot of repetitions of paging. To protect the BCSU from this type of overload, the A interface software constantly checks the number of unhandled messages in the BCSU's CPU before distributing the paging message to the other BCSUs, and if the load limit is exceeded, paging messages are omitted (paging represents the biggest unpredict-able message load here, because traffic from the radio network side is starting smoothly because of phased opening of access classes).For every omitted paging message, counter 500627 AIV PAGING REFUSED BIG LOAD is pegged. See 50 BSC Level Clear Code Measurement for details.After the distribution of the paging message, the Abis interface software again makes the same checks with a lower load limit, and if it is exceeded, the paging message is omitted. For every omitted paging message the counter PAGING FROM A INTERFACE REFUSED DUE BCSUX BIG LOAD is pegged. The x stands for the message bus address of the BCSU (30 - 38). The corresponding numbers for the counters are 51177 to 51185.If a predefined threshold of omitted paging messages has been exceeded in the BCSU, the BSC sends an Overload message to the MSC (see 3GPP TS 48.008). At the arrival of this message, the MSC decreases the amount of paging by a certain percentage.The BSC sets the alarm 1302 PAGING OVERLOAD when the total number of omitted paging messages exceeds a certain threshold in the BCSU.

2. BSC/BCSU/CPU general protectionIt is essential to know that about half of the processing power is used to the handling of radio measurement results, the other half to the actual call control signalling. Radio measurements can be sacrificed first when traffic increases. This makes it possible to have a quite large area of the capacity buffer between the nominal load and 100% level.The BCSU is protected against running out of message buffers which normally causes the BCSU restart. Radio measurement shedding starts when a certain limit of unhandled messages in the BCSU's CPU has been exceeded.The BSC's handover and power control algorithm supervises the flow of radio mea-surements based on the running number in them. Radio measurement reports can also be lost because the LAPD link is overloaded and the BTSs have to throw some of them away.This supervision is useful, for example, when introducing half rate into the network in order to know when it is time to upgrade the CPU/LAPD link speed. The BSC sets

Page 29: Bsc Unit Capacity

DN9812388Issue 10-0

29

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

an alarm on when an overload situation occurs. The detection of the overload is based on the threshold ratio of the rejected measurement results to all measurement results. If the threshold is exceeded, the BCSU unit/LAPD link is considered as being overloaded.

3. BSC BCSU CPU overload against high random access channel (RACH) load also provides protection for BSC/MCMU/CPUA typical example of this type of overload is a special event which is causing a large number of subscribers in an area to try to call at the same time. In this case there are many access attempts to the system. Many of the access attempts will face con-gestion in a stand-alone dedicated control channel (SDCCH) and traffic channel (TCH), which in turn leads users to try again and again. Note that this kind of behav-iour is exceptional compared to the average busy hour. The case requires special protection.Each time a new CHANNEL_REQUIRED message comes from the BTS through the Abis interface, a software application in the BCSU checks the number of unhandled messages in the BCSU's CPU. Two limits are defined. When the lower limit is exceeded, the causes moc_data, location_update, other_cases, and re_establishment will be omitted and counter 003039 BCSU OVERLOAD LOWER LIMIT is incremented. For more details on the counters, see 3 Resource Access Measurement.The procedure for handling IMMEDIATE_ASSIGNMENT_REJECT messages can be considered to belong to this category. The message is sent to the MS in two cases: a) no free SDCCHb) the Abis interface process has no internal resources to handle the requestInside the message there is the field 'Wait indication', which defines the wait period for the MS. You can set the value of the timer by the MMI from 2 s to 10 s. The default value is 10 s.

4. AS7 LAPD protectionWhen the send buffer on a plug-in unit is full, the messages are deleted until the sit-uation has been corrected. The situation may be caused by an overload or a failure in the plug-in unit. The alarm is acknowledged when there is a certain number of space in the buffer. See the details of the alarm 2133 in Indications on overload pro-tection mechanisms.

5. BSC/BCSU protection against excessive number of paging messages coming from the Gb interfaceThe BCSU has an overload control to protect itself against the processor overload-ing and the TRXSIG link overloading. The BCSU cuts down the load by rejecting particular messages when the processor load or the link load exceeds the defined load limit. The software rejects messages which are sent in the downlink direction to the TRXSIG, if needed. Each message that is sent to the TRXSIG is given a certain message group value. In case the message buffers of an AS7 are going to fill up, the software starts to discard messages based on the message group value.The software in the BCSU cuts down the load caused by paging messages sent by the SGSN. The load control is based on the number of unhandled messages in the BCSU's message queue. The SGSN sends paging messages to the PCUs via the Gb interface and the PCUs forward them to the host BCSU. The software checks the count of unhandled messages in the BCSU's message queue every time a new

Page 30: Bsc Unit Capacity

30 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

paging message is received after broadcasting the message to the BCSUs. If the load limit is exceeded, the message in the separate BCSUs is deleted.For every omitted paging message, a counter is pegged. For every deleted CS paging message, the counter CS PAGING REFUSED DUE BCSUX BIG LOAD (counters 51168 to 51176) is pegged and for every deleted PS paging message the counter PS PAGING REFUSED DUE BCSUX BIG LOAD (counters 51159 to 51167) is pegged. The x stands for the message bus address of the BCSU (30 - 38). The BSC will set the alarm 1302 PAGING OVERLOAD when the total number of omitted paging messages exceeds a certain threshold in the BCSU unit.

6. BSC/BCSU protection against high PS RACH loadIn the uplink direction BCSU software cuts down the load caused by PCUs. The software rejects P_CHANNEL_REQUIRED messages received from the TRXSIG if the processor load exceeds the defined load limit. The load control of the software is based on the number of unhandled messages in the BCSU's message queue. Software checks the count of unhandled messages in the BCSU's message queue every time a new P_CHANNEL_REQUIRED message is received.

7. Overload due to excessive number of radio measurement reportsMost of the messages received by the BCSU are radio measurement reports coming from the BTS and the MS. These messages come from the LAPD link. Before the distribution, the load state of the BCSU is checked: • If the load exceeds a certain predefined limit, the message is discarded. The

message buffer and processing capacity demand in the unit is thus decreased. The load limit amounts to the number of unhandled messages in the unit.

• If the load does not exceed the limit, messages are distributed and handled nor-mally.

The loss of the radio measurement report does not affect the service quality signifi-cantly; some reports are lost anyway because of the load on the LAPD link. The method of discarding messages is also random, so the loss of messages for one particular connection stays within reasonable limits.The frames incoming from the LAPD link cause an interruption for the BCSU proces-sor. The BCSU reads the frames from the memory of the preprocessor AS7 and dis-tributes them to other units that handle message information. The frames are distributed according to the frame type and the channel or TRX number given in the frame information.Because incoming UI frames only carry measurement report information, these frames acquire special treatment. Every time a UI frame is received, the BCSU reads the number of free message buffers. If this number is below the predefined limit, a message with the frame information is sent forward. On the other hand, if this limit is exceeded, the BCSU discards the UI frame. This method enables an extremely fast response to overload conditions, provided that the parameter limit for discarding UI frames has been set correctly. The signalling in CM/MM/RR layers is thus not affected by an overload situation in the BCSU.

8. PCU overload protectionThe PCU protects itself from a processor overload with its own internal overload pro-tection mechanism. The operator can enable a notice (0125 PCU PROCESSOR LOAD HIGH), which is set by PCU if the processor load is approacing the overload levels. This is only an early warning of PCU processor load being high and no protective actions are taken

Page 31: Bsc Unit Capacity

DN9812388Issue 10-0

31

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

at this stage. This notice does not require cancellation and is suppressed as set in the default options. When the PCU processor load becomes exceptionally high, the PCU raises an alarm (3164 PCU PROCESSOR OVERLOAD**). At this stage the PCU overload protection actions are initiated. The PCU first starts to reduce load by limiting the load caused by functionalities such as Network-Controlled Cell Re-selection, NCCR (if activated). In the first phase, the accuracy of the NCCR algorithm is reduced by ignoring every second measurement report sent by MSS. If the load still rises, the PCU starts to reduce the scheduling rate proportionally as the load rises, which limits the total throughput on PCU level and, if NCCR is activated, new MSS are not accepted to network-controlled cell-reselection, but the MSS are gradually moved to autonomous cell re-selection. If the load still continues to rise, the scheduling rate is further reduced. In extreme load cases, the PCU starts to tear down connections which do not meet the quality targets defined for their traffic class.

4.4 How to know when the system is running above the nominal load?The following may be seen as indicators of the system running above the nominal load, depending on the actual overload case.

Overload protection mechanism(s) is continuously triggeredIn The LAPD counters used to check the LAPD load statistics there are pointers for all the overload mechanisms that are described earlier. If the issues that are mentioned earlier (CPU load, paging load, network performance) are on the safe side, it is improb-able that any overload mechanism triggers. In high traffic BSCs, you should follow the alarm 2720 TELECOM LINK OVERLOAD for BCSU/CPU general protection or statis-tics of BCSU/CPU RACH load protection.

The alarm 2133 SEND BUFFER OVERFLOW IN SIGNALLING TERMINAL also indi-cates that the Abis LAPD interface capacity is overloaded.

See the following for details:

• CPU load counters: 6 Load Measurement • paging, RACH counters and measurements: 3 Resource Access Measurement • TCH/SDCCH counters and measurements: 1 Traffic Measurement

Paging load is above 100 000 pages/h (16 kbit/s LAPD link) or above 410 000 pages/h (64 kbit/s LAPD link)You can verify this from the Resource Access Measurement counter 003000 PAGING MESSAGES SENT TO BTS. This BSC counter tells how many pagings have been sent via one LAPD link (and location area, LA). As paging messages are received on the Abis interface, the counter is increased. Here one message corresponds to one MS to be paged, which means no packing of several IMSI/TMSIs to the same paging message. To find out the paging load over BTSs at the same location area, it is enough to check one BTS per LA.

In The LAPD counters used to check the LAPD load statistics there is a description of layer 2 level counters on Abis LAPD utilisation. The measurement shows all the bytes sent in LAPD paging and other messages.

g This measurement is actually a more accurate source of Abis link or AS7 overload detection. This is because it measures all the data over the link.

Page 32: Bsc Unit Capacity

32 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

However, we recommend the paging counters described above as the main pointer of high load for two reasons:

• The paging load is the component of system load which will increase indirectly (that is, you add load to all cells at the same LA when a new subscriber or a new cell comes to the network).

• BSC resource access measurements are more user-friendly to follow.

Degradation of end-user-experienced network qualityDecreased quality is also shown by key performance indicators:

• congestion rate • paging success rate • call success rate

Handover success rate may also indicate equipment overload. However, in most cases the counters do not indicate problems until the system is overloaded. Also, the paging problems are not as well visible as the main indicators.

The paging success rate can be calculated from MSC counters as follows:

PAGING SUCCESS RATE, only for Nokia MSC, M056: Paging Success % (M7)

The following formula indicates the success rate of paging (call & SMS):

100 x sum(succ_page)/sum(fail_page + succ_page)

4.5 AS7 overload protection implementationAn overload protection mechanism has been implemented to the BSC additionally to protect the equipment from exceptionally high message traffic, for example because of high peak paging load.

The transmit buffers of the AS7 handling the Abis signalling links may overflow during excessive signalling traffic load, especially with the 16 kbit/s Abis links.

To avoid the overflow, a mechanism has been implemented for discarding messages of less significance (requiring no immediate handling or acknowledgment) when AS7 detects congestion on the transmit buffers of the Abis signalling link. IMMEDIATE_ASSIGNMENT_REJECT and PAGING messages are 'labelled' so that they may be discarded during very high load on the LAPD signalling link to ensure that normal call signalling proceeds.

Additionally, if the congestion level of the transmit buffer still becomes very high, all the signalling messages on the channel(s) causing the congestion may be discarded.

The storage space for incoming channel requests is also decreased to avoid an overload situation in the BSC.

4.6 The LAPD counters used to check the LAPD load statisticsAbis LAPD layer 2 counters can be checked in measurement periods of half an hour.

Use the DMF MML command. The following command, for example, shows all counters:

ZDMF:P,,P:A,P:D:;

The observed counter is number 5 TRANSMITTED TOTAL OCTET COUNT. If it exceeds in a half-hour period more than 1 800 000 (in case of 16 kbit/s) or 7 000 000 (in

Page 33: Bsc Unit Capacity

DN9812388Issue 10-0

33

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

case of 64 kbit/s), the LAPD overload problem most probably then already exists and the alarm 2133 is activated.

The safe values could be as follows:

• 1 000 000 for 16 kbit/s • 3 500 000 for 64 kbit/s

An example printout of the counters from the BSC looks as follows:

LOADING PROGRAM VERSION 2.6-0 DX 200 BSC03 1997-11-16 14:55:59 TRANSMITTED AND RECEIVED FRAMES AND OCTETS PRIMARYRATE LINK SET ACTIVE UNIT METERS OF LAST PERIOD: 14:00:00 - 14:30:00 1 2 3 4 5 D-CHA TYPE 6 7 8 9 10 ===== ==== ========== ==================== ========== ========== 0 PRI 0000000059 0000000000 00000018290000000000 0000005425 0000000059 0000000000 0000001829 00000000000000005425 1 PRI 0000000059 0000000000 0000001829 0000000000 0000005421 0000000059 0000000000 0000001829 0000000000 0000005421 2 PRI 0000000000 0000000000 0000000000 0000000000 0000000720 00000000000000000000 0000000000 0000000000 0000000720 3 PRI 0000013170 00000000000000248086 0000000000 0000264586 0000004125 0000010900 00000665020000428455 0000547637 MEASUREMENT NAMES 1 ... TRANSMITTED I FRAMES 2 ... TRANSMITTED UI FRAMES 3 ... TRANSMITTED I FRAME OCTETS 4 ... TRANSMITTEDUI FRAME OCTETS 5 ... TRANSMITTED TOTAL OCTET COUNT 6 ... RECEIVED I FRAMES 7 ... RECEIVED UI FRAMES 8 ... RECEIVED I FRAME OCTETS 9 ... RECEIVEDUI FRAME OCTETS 10 ... RECEIVED TOTAL OCTET COUNT COMMAND EXECUTED

4.7 Indications on overload protection mechanisms1. BSC/BCSU/CPU protection against excessive number of paging messages coming

from the A interface • See counter 500627 in 50 BSC Level Clear Code Measurement on deleted

paging messages. • See counters 51177-51185 in 51 BSC Level Clear Code (PM) Measurement. • Alarm 1302 PAGING OVERLOAD (disturbance)

Meaning: The BSC sends an overload message to the MSC in overload situa-tions inside the BSC. At the arrival of this message, the MSC decreases the amount of paging by a certain percentage. That helps the BSC to cope with the unusually high number of paging messages. The BSC sets the alarm when a predefined threshold of discarded paging messages has been exceeded.For more information, see Disturbance Printouts (1000-1999).

2. BSC/BCSU/CPU general protectionAlarm 2720 TELECOM LINK OVERLOADMeaning: The ratio between the number of rejected measurement results and the number of all measurement results exceeds the acceptable limit set by the user. The alarm is used to supervise the traffic load of LAPD links and BCSU units and to detect the possible overload situations.SUPPLEMENTARY INFORMATION FIELDSa) Unit

• 00: BCSU unit overloaded

Page 34: Bsc Unit Capacity

34 DN9812388Issue 10-0

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

Id:0900d805805914de

BSS overload protection and flow control

• 01: LAPD link overloadedb) BTS identification of the LAPD link...c) etc.For more information, see Failure Printouts (2000-3999).

3. BSC BCSU CPU overload against high RACH loadSee the following counters in 3 Resource Access Measurement: • 003039 BCSU overload lower limit • 003040 BCSU overload upper limit • 003041 BCSU overload deleted rach

4. BSC/MCMU/CPU protectionMCMU CPU load is high, the ratio of channel requests and given channels slightly decreases.

5. AS7 LAPD protectionAlarm 2133 SEND BUFFER OVERFLOW IN SIGNALLING TERMINALMeaning: The send buffer on a plug-in unit is full. Messages are deleted until the sit-uation has been corrected. The situation may be caused by an overload or a failure in the plug-in unit. The alarm is acknowledged when there is a certain amount of space in the buffer.See also Failure Printouts (2000-3999).

6. GSM-specified overload protection implemented by NokiaNo statistics available.

7. Message overflow at BTSACCESS GRANT CHANNEL BLOCKING can be calculated by using BSC mea-surements. The BSC sends 'immediate assignment' or 'immediate assignment rejected' commands to the BTS. If the AG buffer in the BTS is full, it responds with a delete indication. Thus the ratio of delete indications to the sum of imm.assign. and imm.assgn.rej. describes the blocking of AGCH.100 x sum(del_ind_msg_rec)/ sum(imm_assgn_rej+imm_assgn_sent)all counters from p_nbsc_res_acc

8. BSC/BCSU protection against excessive number of paging messages coming from the Gb interfaceSee counters 51159-51176 in 51 BSC Level Clear Code (PM) Measurement.

9. PCU processor load indicators • Alarm 0125 PCU PROCESSOR LOAD HIGH (notice)

Meaning: This notice indicates that the PCU processor load is approaching the overload level, but no overload protection actions are initiated. This notification provides an early warning of a probable need for additional PCU capacity. This notice is suppressed by default, that is, the operator must enable it. The notice identifies the PCU plug-in unit in which the high load has occured. In PCU2, the notice also identifies with a processor index whether the situation has occured on main processor PQII (0xFF) or on one of the DSPs (0x0 .. 0x7).See also Notices (0-999).

• Alarm 3164 PCU PROCESSOR OVERLOAD (**)Meaning: This alarm indicates that the PCU processor load has risen to the level at which the overload protection actions are initiated. If the load still continues to rise, further steps to reduce the load are taken by reducing the scheduling rate gradually according to the PCU processor load. Lowering the scheduling rate lowers the processor load at the expense of data throughput. Other software-specific overload protection actions are also taken. For example, the PCU starts

Page 35: Bsc Unit Capacity

DN9812388Issue 10-0

35

BSS (BSC) Traffic Handling Capacity, Network Plan-ning and Overload Protection

BSS overload protection and flow control

Id:0900d805805914de

to move MSS from network-controlled cell re-selection to autonomous cell re-selection, if NCCR is activated. The alarm identifies the PCU plug-in unit in which the overload situation has occured. In PCU2, the alarm also identifies with a processor index whether the overload situation has occured on the main pro-cessor PQII (0xFF) or on one of the DSPs (0x0 .. 0x7).

4.8 TimersThe following timers are related to Flow and Overload Control. For more details on the timers, see PAFILE Timer and Parameter List.

• T17 Overload procedure • T18 Overload procedure

4.9 ParametersThe following parameter is related to Flow and Overload Control:

• LAPD load threshold (LAPDL)

For more details, see BSS Radio Network Parameter Dictionary.

See also Failure Printouts (2000 - 3999).