EGPRS Inactivity Alarm and PCU Performance

1 © NOKIA Feature Training – (E)GPRS Inactivity Alarm.PPT/ 08.02.2005 / ArK

BSS20062: (E)GPRS Inactivity Alarm

BSS20071: PCU Performance Optimization

BSC S12 Feature Training

Trainer: Ari Kosonen

11.02.2005


BSS20062: (E)GPRS Inactivity Alarm / BSS20071: PCU

Performance Optimization Contents

• (E)GPRS Inactivity Alarm (BSS20062)• Introduction, Terminology & Definitions• S12 solution• Example• Architecture• Operability and MML modifications• Effects on Interfaces• Parameters and Statistics

• PCU Performance Optimization (BSS20071)

• Additional information and contacts



IntroductionProblem:

Sleeping BTSs occur occationally in some live (E)GPRS networks. These are currently detected afterwards from statistics. In order to initiate the needed recovery actions in timely manner, a quicker way to detect sleeping BTSs is needed.

Current (pre-S12) solution:

A GPRS Inactivity Alarm was introduced as a correction to S11 and S11.5, using the existing alarm for CS inactivity (0x7738 BTS WITH NO TRANSACTIONS). This alarm has certain limitations:

- configurable only on BSC level- not possible to separately activate on CS and/or PS domain- Not ”really” on BTS level, not able to detect inactivity on non-

BCCH BTSs



Terminology & DefinitionsSleeping BTS

A BTS where no successful user traffic has occurred within the defined supervision period, although there has been attempted traffic. Sleeping BTS is indicated with a specific alarm, in order to initiate recovery actions to be taken. Separate causes may occur for CS and PS traffic; therefore these shall be handled separately.

Active periodA period of time, when the alarm may be raised if the criteria has been met. All the supervision for raising the alarm is carried out during the Active period that is specified for each BTS and is operator configurable. Outside the active period the alarm is not raised.

Active period is defined by weekdays and within day by one continuous period of time, typically few hours. The period of active hours is same for each day set active by the weekday parameter, i.e. different periods for different weekdays are not possible.

Supervision periodA period of time (e.g. 15 minutes) during which the (E)GPRS traffic is supervised. If no traffic occurs during the supervision period, an alarm is raised in the end of the supervision period if the alarm is within active period.



S12 SolutionThe new S12 alarm: NO GPRS OR EGPRS TRANSACTIONS IN BTS** • Sleeping BTSs are detected by lack of normal TBF releases within the supervision period. To

ensure sufficient amount of attempted traffic, number of TBF allocation and reallocation attempts is required in addition to lack of normal TBF releases before raising the alarm

• The active periods for the alarm are configurable on BTS level, i.e. the operator can define for each BTS separately the following:

• Weekdays when the monitoring for the alarm is active• Within the given weekdays, hours when the alarm is active

• e.g. MON thru FRI, 08:00 – 18:00• The active periods should be chosen so that reasonable amount of (E)GPRS traffic is

expected in the given cells. • Operator can choose the triggering criteria on BSC level (i.e. same criteria for all BTSs):

• As a default alarm is disabled (no criteria defined)• No normal UL TBF releases• No normal DL TBF releases• No normal UL TBF releases and no normal DL TBF releases (recommended criteria)• Additional criteria may be introduced in the future

• The alarm is set, if the chosen criteria is met in the end of the supervision period and there has been sufficient amount of attempted traffic.

• The alarm is cancelled if either UL or DL TBFs are successfully released in subsequent supervision periods in a BTS where the alarm has previously been set.



Example (one BTS view)Alarm active period: every day 12:00 – 13:00

Supervision period: 15 minutes

Criteria: No normal UL and DL TBF releases

Traffic threshold: 4 TBF allocation attempts per hour required 1 TBF alloc per 15 minutes

All alarm settings and cancellations are done in the end of a supervision period.

= TBF allocation attempt

= normal TBF release

12:00 13:001 supervision period

No traffic, butthe traffic thresholdnot met OK, no alarm(no alarms set on previousperiods either)

TBF allocations attempts and at least one normal TBF release OK, no alarm

Few TBF allocation attempts, but no normal TBF releases SET ALARM

TBF allocation attempts andat least one normal TBFrelease CANCEL ALARM



Alarm cancellationNormally, the alarm is cancelled if normal TBF releases

occur in a BTS where the alarm has been raised. This is not dependent on the raising criteria, i.e. occurance of any TBF (UL or DL) is interpreted as an activity in BTS. PCU detects the traffic and requests RRM to set or cancel the alarm accordingly.

Other reasons to cancel the alarm (RRM cancels the alarm):• GPRS is disabled in BTS

• BTS or BCF reset

• BTS or BCH blocked

• All GPRS capable TRXs in BTS are blocked

• BCSU Swithchover (controlled or forced)

• BCSU Reset or PCU restart

The currently set alarms are also cancelled (by PCU), if the (E)GPRS Inactivity Alarm is disabled either on BTS or BSC level.

In these cases RRM informs PCU aboutthe cancellation (cancel_inact_al_s message)



ArchitectureBTS & BSC level

parameter handling

RNW Parameter delivery to PCU

Setting / cancelling the alarm by PCU

Informing PCU about alarm cancellation by

RRM



Operability• (E)GPRS Inactivity Alarm does not require feature activation

• Anyhow, as a default the alarm is not enabled.

• To enable the alarm in certain BTS, following steps are needed:

• Choose the triggering criteria for the alarm. This enables the alarm on BSC level, i.e. the criteria is same for whole BSC

• Select the alarm weekdays for each BTS. This enables the alarm on the given weekdays on BTS level

• The remaining parameters have default values, but operator can adjust these as needed:

• Alarm start and stop times; i.e. defining the hours when the alarm is enabled. As a default the alarm is active between 08:00 and 18:00

• Supervision period length. Default 60 minutes• Triggering threshold; i.e. number of TBF allocation attempts required

per hour (to ensure sufficient level of traffic, when alarm is raised)



Operability

PCU

BSC

PCU

BSC

BTSBTSBTSBTS

BTSBTS

1. Enable and Configure on BSC level

• Define the triggering criteria• Define supervision period

length• Define traffic threshold2. Enable and Configure for

each BTS• Enable the alarm by defining

the supervision weekdays• Define the start / end times

when the alarm is active

No succ UL/DL TBFs and at least one TBF allocation attempt within 15 minutes

period

Supervision for (E)GPRS Inactivty

Alarm is active from Monday to Friday,

08:00 to 18:00 each day

Alarm not

enabled

Alarm not

enabled



MML ModificationsPBTHAN• BTS-level parameters related to (E)GPRS Inactivity alarm added to MML

command ZEQV (MODIFY GPRS PARAMETERS):• EAW= <(E)GPRS inactivity alarm weekdays>• EAS = <(E)GPRS inactivity alarm start time>• EAE = <(E)GPRS inactivity alarm end time>

PBCHAN• BSC-level parameters related to (E)GPRS Inactivity alarm added to MML

command ZEEJ (MODIFY GPRS PARAMETERS):• EGIC= <EGPRS inactivity alarm criteria>• IEPH = <Number of TBF allocation attempts required per hour>• SPL = <Supervision period length>

• See the IS for examples

• These parameters are added to the respective messages and fastreads:• bts_modification_s, bsc_modification_s (PBTHAN/PBCHAN PUBDAT)• get_bts_pcu_params_r, get_bsc_pcu_params_r (PUBDAT BSDATA)



Effects on Interfaces• PCUSIG:

• Changed messages:• pcu_bts_params_rnwdb_s (PUBDAT CHM):

– Delivering the BTS level RNW parameters to PCU– S12: BTS-level parameters for alarm scheduling (weekday, start time end

time) added to the data type s12_bts_params_t

• pcu_bsc_params_rnwdb_s (PUBDAT CHM):

– Delivering the BSC level RNW parameters to PCU– S12: BSC-level parameters for alarm supervision period, criteria and traffic

threshold added to the data type s12_bsc_params_t

• bts_gprs_inact_al_status_s (CHM RRM):

– PCU requests RRM to set or cancel the alarm for given BTS– S12: alarm criteria added as a new field

• New message:• cancel_inact_al_s (RRM CHM):

– Cancelling the alarm without request from PCU


BSS20062: (E)GPRS Inactivity Alarm Parameters

Name Level Description(E)GPRS Inactivity Criteria

BSC Criteria used to detect the (E)GPRS Inactivity.

Criteria are defined as a bit map. Each bit enables one criterion. Note that all the values may not be valid, i.e. some combinations of criteria may be contradictory.

0x00 = Alarm disabled0x01 = No normal UL TBF releases0x02 = No normal DL TBF releases0x03 = No normal UL TBF releases and no normal DL TBF releases.(0x04 = (future criterion)

Default: 0x0 (Alarm disabled in whole BSC)

Number of TBF allocation attempts required per hour for (E)GPRS Inactivity Alarm

BSC Required number of TBF allocation and reallocation attempts per BTS per one hour to ensure there has been traffic.

Default: 10

(E)GPRS Inactivity Alarm weekdays

BTS Day of week when the (E)GPRS inactivity alarm is enabled

Range: defined as a bit mask, i.e.

All weekdays : 01111111bMonday : 01000000bTuesday : 00100000b….Sunday : 00000001bMon thru Fri : 01111100bDisabled : 00000000b

Default: 0 (Alarm disabled in this BTS)

(E)GPRS inactivity alarm start time

BTS Time of day when the (E)GPRS inactivity alarm is enabled. The time can be defined in 15 minutes resolution.

Example: period is started at 8 a.m. each day: 08-00

Range: 00-00 .. 23-45Default: 08-00

(E)GPRS inactivity alarm end time

BTS Time of day when the (E)GPRS inactivity alarm is disabled. The time can be defined in 15 minutes resolution.

Example: period ends at 6 p.m. each day: 18-00

Range: 00-00 .. 23-45Default: 18-00

Supervision period length for (E)GPRS inactivity alarm

BSC Length of the supervision period for (E)GPRS inactivity alarm in minutes.

Range: 0 .. 1440Default: 60



Statistics• No statistics related to (E)GPRS Inactivity Alarm



Tips & Advice on TestingThings to be tested:

- setting the alarm with different criteria (lack of normal UL/DL TBF releases within the supervision period)

- not setting the alarm if there is not even attempted traffic (i.e. not enough TBF allocation/realloaction attempts)

- cancelling the alarm with occurring GPRS traffic (normal TBF releases)

- Cancelling the alarm with other reasons (resets, blocks, switchovers…)

- Scheduling of the alarm, I.e. supervision is started in correct weekdays, within the given periods.



Performance Requirements for PCU-1 in S12• Memory: At least 10 MB free RAM available in all PCU-1 variants

• RNW Connectivity: 64 (E)GPRS capable cells/segments, 64 BTSs, 128 TRXs per one logical PCU-1

• Channel Connectivity: • PCU and PCU-S: 256 GPRS/EGPRS 16 kbit/s Abis channels , with max. 128 RTSLs. Exceeding the

supported number of RTSLs is possible, but this will raise an alarm (notice)• PCU-T and PCU-B: 256 GPRS/EGPRS 16 kbit/s Abis channels carrying PDCHs

• Nominal throughput: 2Mbit/s on Gb per logical PCU

• Supported PCU-1 variants in S12: PCU, PCU-S, PCU-T, PCU-B

Performance Requirements for PCU-2 (Rel 2.) in S12 • Memory: usage upto 50% of PQII memory, upto 75% of DSP external memory and upto 100% of DSP internal

memory (preliminary, to be frozen in E1)

• Processing capacity: usage upto 70% of PQII processing capacity and upto 75% of DSP processing capacity (preliminary, to be frozen in E1)

• RNW Connectivity: 64 (E)GPRS capable cells/segments, 128 BTSs, 256 TRXs per one logical PCU2

• Channel Connectivity: 256 GPRS/EGPRS 16kbit/s Abis channels carrying PDCHs.

• Nominal throughput: 2Mbit/s on Gb per logical PCU (including all overheads)

• Supported PCU-2 variants in S12: PCU2-D, PCU2-U



After S11.5 about 15 MB of free memory is available in the most memory limited PCU-variants (PCU and PCU-S). As the estimated increase of memory usage in S12 with PCU-1 is quite small, no need for memory optimizations.

Anyhow several memory optimization items have been identified (e.g. reorganization of Abis pools and RLC data structures, common database for TBF information). These may be applied in the future, if needed.

The following optimization items will have impact on S12:

• Adjusting MAC timers according to MS timers (PCU-2 only)The supervision timers in MAC are adjusted to reduce unnecessary delays in TBF

assignments

• Introduction of new version of gcc-compiler (PCU-1 only).

A new version of gcc compiler produces slight performance gain compared to current version. The new compiler will come as a part of the new version of Chorus OS (4.2), if this is decided to take in use with B12 platform. Some minor code modifications may be needed (this will be verified with S11.5)



Adjusting MAC timers according to MS timers (PCU-2 only)

• The default values for the supervision timers (T_ULA and T_TR) are too long (2 seconds) compared to default value of MS timer T3168 (1 second) causing PCU try to resend the assignment to MS for unnecessarily long time in the cases when MS does not reply to the original assignment. Resending is continued until the supervision timer expires or the MS replies. When the timer has expired an abnormal TBF release is made.

• Solution: PCU shall get the value of T3168 (which is provided to MS in the sysinfo messages PSI1 and SI13) and use this value instead of the current default value in the following cases:

• In two-phase access, MS sends a request for UL TBF in Packet Resource Request, PCU replies with the Packet Uplink Assignment and starts the supervision timer (T_ULA).

• MS sends a request for UL TBF by adding Channel Request Description to the Packet Downlink Ack/Nack. PCU replies with Packet Uplink Assignment, when DL not reallocated. PCU starts the supervision timer (T_ULA).

• MS sends a request for UL TBF by adding Channel Request Description to the Packet Downlink Ack/Nack. PCU replies with Packet Timeslot Reconfigure, when DL is reallocated. PCU starts the supervision timer (T_TR)

• In the network initiated reassignments the current default value shall still be used.

• A similar situation occurs when PCU tries to start a new DL TBF immediately after the previous one. This will succeed only when the timer T3192 has not elapsed in the MS. By default the value for T3192 is 500 milliseconds, but PCU tries to start the DL TBF for 2 seconds according to supervision timer (T_DLA). Anyhow, the DL TBF is not established if the T3192 has elapsed.

• Solution: PCU shall use as the value of the supervision timer (T_DLA) the value of T3192 added with a constant value (~500ms), instead of the current default value

the constant is introduced as a new PRFILE parameter (NEW_DL_TBF_RETRY_DELAY), which is forwarded to PCU (MAC) in pcu_parameter_s message from ABIPRB.


BSS20062: (E)GPRS Inactivity Alarm / BSS20071: PCU Performance Optimization

Contacts & Additional information • RS Author: Ari Kosonen

• IS Author (DX): Tero Niemensivu (Comprog)

• IS Author (PCU-1): Ville Marjusaari / Mika Rantanen (Plenware)

Documents (available in PI):PCU Performance Optimization and (E)GPRS Inactivity Alarm,

Requirement Specification, v.1.0.2

PCU Performance Optimization and (E)GPRS Inactivity Alarm, Implementation Specification, v.1.1.0

Chorus-PCU Adaptation in S12, Implementation Specification, v.1.0.0

PCU Performance Optimization and (E)GPRS Inactivity Alarm, Feature Design Document for IMS GW Rel.2 (PCU-2), v.2.1

EGPRS Inactivity Alarm and PCU Performance

Documents

Transcript of EGPRS Inactivity Alarm and PCU Performance