Presentation title

Congestion control in Packet Abis# Nokia Siemens Networks RN20107EN14GLN0

# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Congestion control mechanismImplementation Congestion control in Packet Abis: reaction procedures two sets of procedures (R1 and R2) are started up based on congestion severitymechanism behaviour shown below for BU case (PL behaviour is analogous):

R1 reaction procedure involves:decrease of AMR codec rate: AMR codec is downgraded directly to the lowest codec supported by the affected BTS sitedecrease PS scheduler rate by 25%: PCU omits frame insertion in every 4th scheduling cycle towards the affected sites, this will effect in reduction of backhaul throughput rate R2 reaction procedure involves:rejection of newly incoming calls and PS territories upgrades: BSC does not start any new calls towards the affected BTS sites and rejects PS upgrades requested thereindecrease PS scheduler rate by 75%: PCU omits frame insertion in 3 out of 4 scheduling cycles towards the affected BTS sitesR2R1BU11_HyBU22_HyTONTONTOFFTOFF# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Congestion control mechanismImplementation Congestion control in Packet Abis: architecture Packet Abis provides set of mechanisms which control the system in the event of congestion

Packet Abis congestion control mechanism can be enabled or disabled per BCF basis by means of packetAbisCongestionControl parameter when congestion control is enabled then monitoring of the following indicators is started to detect congestion state:backhaul utilization (BU) monitoring for link congestionpacket loss (PL) detection for transport network congestion

congestiondetection and reactionBTS Tx queueshandlingdiscardingobsolete packetswhen enabledBUmonitoringPLdetectionwhen enabledstart/stop relatedcongestion reaction procedureswhen thresholds exceededPacket Abis congestion control# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Congestion control mechanismImplementation Congestion control in Packet Abis: congestion detection algorithms (BU) The backhaul utilization monitoring (BU) allows to observe Packet Abis bandwidth consumption: BU is defined as percentage of bandwidth reserved per BTS site

In PSN transport: Abis bandwidth available for BTS site in the PSN is defined explicitly by setting committed information rate (CIR)

Eth

EthBSC

Packet SwitchedNetworkETH (100M/1G)CIR kbit/s# Nokia Siemens Networks RN20107EN14GLN0Congestion control mechanismImplementation Congestion control in Packet Abis: configuration and handling Congestion control mechanism is supervised by the following parameters:configurable thresholds defining congestion severity for backhaul utilization (BU1 / BU2) and packet loss (PL1 / PL2): depending on congestion severity appropriate reaction procedure (R1 or R2) is invokedfiltering timers managing switch on/off of the reaction procedures (TON / TOFF) Mechanism behaviour shown below for BU case (PL behaviour is analogous):

hysteresis thresholds are hardcodedBU: 5% below, PL: 5 units below (cf. Slide99 for the range of the relevant parameters)congestion state can be modified only after expiry of TON/TOFF exceeding threshold starts filtering timer and not reaction procedurereturning threshold while filtering timer runs, resets the timer without update the congestion stateBU1_Hy BU2_Hy BU[%]defaults:BU2 = 90% => BU2_Hy = 85%BU1 = 75% => BU1_Hy = 70%BTON = 4 secBTOFF = 10 sec PL2 = 28 (10%) => PL2_Hy = 24 (6%)PL1 = 14 (0.5%) => PL1_Hy = 10 (0.1%)PLTON = 10 secPLTOFF = 100 secBU1BU2TONTONt [sec]TOFFTOFFcongestion detected (R1)severe congestion detected (R2)R2 stoppedR1 re-startedcongestionremoved# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Congestion control reactionsbu1AbisThroughputThresholdOR pl1ThresholdPacketLoss is exceededbu2AbisThroughputThresholdOR pl2ThresholdPacketLoss is exceeded1-The BSC reduces the TBF scheduling rate by 25%2- AMR codec is downgraded to the lowest codec 1-The BSC reduces the TBF scheduling rate by 75%2- any new calls towards the affected BTS sites are allocated# Nokia Siemens Networks RN20107EN14GLN0Congestion control mechanismImplementation Congestion control in Packet Abis: Tx queues handling Behavior of BTS transmission queues is configurable in addition to congestion control mechanisms:BTS removes from transmission queues of its scheduler all packets which are kept there longer than configurable period of time called drop perioddrop period is defined for each traffic type (plane) separatelyit is also possible to prevent given traffic type from dropping regardless on load these additional procedures are helpful:when link is overloaded in spite of running congestion control mechanismswhen link is overloaded, congestion control is enabled but filtering timer has not yet expiredwhen link is overloaded and congestion control is not enabled (but then it can help with short-lasting peak periods) BSC transmission queues behavior is managed by means of QoS definitionpackets are served according to QoS mappingdropping principles within QoS class: FIFO # Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies# Packet Abis Congestion Control (Recap)BTS detects interface congestion by link utilization monitoring (UL/DL)network congestionby packet loss monitoringBTS and BSC react to congestion:Two threshold can be configuredReduction of GPRS/EDGE throughput (BSC)AMR HR & AMR FR codec rate reductions (BTS)PS and CS call limitation (BSC) (depend on congestion situation)# Nokia Siemens Networks RN20107EN14GLN0Packet AbisConfiguration managementGo to Table of content# Nokia Siemens Networks RN20107EN14GLN0

# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (1/9)ParameterDescriptionobject: BCF range: 03: 0 = Legacy Abis 1 = Packet Abis over TDM 2 = Packet Abis over Ethernetdefault: 0 unit: -MML command: EFC, EFM, EFOMML abbreviated name: AICT

Abis interface connection type (abisInterfaceConnectionType), with this parameter it is possible to define realization of Abis interface: it is possible to choose between legacy (Dynamic Abis) and Packet Abis. For Packet Abis also physical realization can be indicated. Please note that the setting of this parameter determines next mutually exclusive configuration steps:- for Packet Abis over TDM (AICT=1): HDLC link(s) must be created reflecting the existing PCM configuration and available backhaul bandwidth (see HDLC parameters section),- for Packet Abis over Ethernet (AICT=2): available backhaul bandwidth is expressed in terms of Committed Information Rate (CIR) therefore traffic shaping and Ethernet links capabilities must be configured (see Packet Abis over PSN section).Besides, for Abis connection types different than legacy Abis, ETP object must exist in the BSC. object: BCF range: 0, 1: 0 = satellite Abis is not used 1 = satellite Abis is useddefault: 0 unit: -MML command: EFOMML abbreviated name: PASUPacket Abis over satellite in use (paSatelliteUse), the parameter indicates whether satellite connection is used by Packet Abis or not. Usage of satellite connection is reflected in settings of retransmission timeouts which control SCTP procedures related to TRXSIG and OMUSIG traffic. This is read-only parameter: system sets the parameter depending on setting of SCTP association for RTO.init for M-plane (OMUSIG). object: BCF range: 04default: 0 unit: -MML command: EFM, EFOMML abbreviated name: TRS5

Packet transport E1/T1 usage (packetTrsE1T1Usage), the parameter indicates whether transport features aiming at protecting installed base (UltraSite and BTSplus) are enabled. In particular, the parameter is related to one of the available options which foresees cross connection of co-sited legacy BTS products through FlexiEDGE BTS using Dynamic Abis (between legacy BTS and FlexiBTS, and CESoPSN between FlexiBTS and BSC) and additionally allows to indicate how many PCM lines are used to connect UltraSite/BTSplus with FlexiEDGE BTS site. Connection type and topology# Nokia Siemens Networks RN20107EN14GLN0TRS1: Flexi EDGE Abis over IP Ethernet usageTRS2: Flexi EDGE Additional 2 E1T1 usageTRS3: Flexi EDGE TRS Abis grooming usageTRS4: Flexi EDGE TRS looop prortection usageRN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (2/9)ParameterDescriptionobject: ETP range: 05 step: 1default: - unit: -MML command: -MML abbreviated name: -ETP object ID (etpId), this parameter allows to define identity of particular ETP units plugged in to the BSC (regardless on physical realization of Packet Abis) and represents the relevant HW.

object: ETP range: 015 step: 1default: - unit: -MML command: ESK, ESH, ESL, EFC, EFM, EFOMML abbreviated name: ETPGID

ETP group ID (etpGroupId), this parameter allows to identify ETP group.ETP group is needed for redundancy purposes when N+N scheme is in use and therefore the concept in only applicable for ETPT and ETPE (i.e. ETP modules responsible for AoIP have different redundancy scheme). To define ETP group which indicates the pair of active and spare modules (terminating the same Packet Abis type, i.e. either Packet Abis over TDM or Packet Abis over Ethernet) ETP type is needed in addition to ETP group ID (see below, ETPT parameter).object: ETP range: 1, 2: 1 = ETP-T (ETP for TDM transport)2 = ETP-E (ETP for Ethernet transport)step: - default: - unit: -MML command: ESK, ESHMML abbreviated name: ETPTETP type (etpType), this parameter allows to define ETP type of ETP unit to be used for Packet Abis. ETP type and ETP group ID (see above, ETPGID parameter) are needed to define ETP group.

object: BCF range: 0255 step: 1default: - unit: -MML command: EFOMML abbreviated name: EBIDETP BCF ID (etpBcfId), this parameter identifies BCF in ETP and PCU and is used internally for PCU-ETP communication only. It is created by the system automatically whenever Packet Abis is enabled in a new BCF. This is read-only parameter.

BSC HW (Exchange Terminal for Packet transport, ETP)# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (3/9)Packet Abis over TDM: HDLC parameters (1/2)ParameterDescriptionobject: BCF range: 0255 step: 1default: - unit: -MML command: EFOMML abbreviated name: MLPPP

ML-PPP bundle ID (mlPppBundleId), this parameter allows to identify ML-PPP bundle related to the BCF. The parameter is read-only and its value is set by the system.Multilink point-to-point protocol (MLPPP) aggregates several physical links (i.e. PCM TSL available for the BCF) into a single logical pipe". To be more precise, MLPPP bundles multiple link-layer channels into a single network-layer channel (pipe). The parameter is mandatory for Packet Abis over TDM (AICT=1) where it allows to bundle HDLC links representing all TDM lines connecting given BCF to the BSC. Thus the bandwidth available in the BCF on Packet Abis depends on the number of TSLs assigned to the HDLC links (listed by BHIDL, see below) which the MLPPP bundle is composed of.The parameter is not relevant for Packet Abis over Ethernet (AICT=2) where traffic shaping mechanisms are required to define bandwidth available for the BCF and to ensure traffic management in Packet Switched network.object: BCF range: 13000 step: 1default: - unit: -MML command: EFC, EFM, EFOMML abbreviated name: BHIDL

BCF HDLC ID list (bcfHdlcIdList), this parameter allows to define the list of HDLC links related to the BCF. Bandwidth contributions of each HDLC link listed by the parameter are summed up so they constitute logical pipe (represented by ML-PPP bundle parameter) which determines transmission capacity available on Packet Abis for given BTS site (BCF). Up to 8 entries (HDLC links representing the entire PCM line or smaller bandwidth) may be defined for BCF and listed by the parameter.

BSCTDM

TDM1st E1 (e.g. PCMID=101), TSL1-202nd E1 (e.g. PCMID=102), TSL1-31

HNBR=20, HPCM=101HTSL=1, HBAND=20

TSL1TSL20TSL1TSL31BCF: MLPPP=1,BHIDL=20, 21

MLPPP bundle == (20+31)*64 kbit/sHNBR=21, HPCM=102HTSL=1, HBAND=31# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (4/9)Packet Abis over TDM: HDLC parameters (2/2)ParameterDescriptionobject: HDLC range: 13000 step: 1default: - unit: -MML command: ESX, ESF, ESS, ESYMML abbreviated name: HNBRHDLC link ID (hdlcLinkId), this parameter allows to identify HDLC link in the related ML-PPP bundle. HDLC link represents the TDM line connecting the BCF with the BSC (or with another BCF, in case of chained BTSs) and its ID is unique per BSC. A BCF can have up to 8 HDLC links included in BCF HDLC ID list (cf. BHIDL, previous slide) as each TDM line configured in the BCF for Abis transport purposes must be reflected in HDLC configuration.object: HDLC range: string of 015 charactersdefault: - unit: -MML command: ESX, ESF, ESS, ESYMML abbreviated name: HNAMEHDLC link name (hdlcLinkName), this is optional parameter which allows to define a name of the HDLC link in addition to, but not instead of, its ID to e.g. easily distinguish between several HDLC links related to the same BCF (ML-PPP bundle).

object: HDLC range: 03559 step: 1 default: - unit: -MML command: ESX, ESLMML abbreviated name: HPCMHDLC PCM ID (hdlcPcmId), this parameter allows to indicate the identity of the TDM line represented by the HDLC link.

object: HDLC range: 130 (ETSI) or 124 (ANSI)step: 1 default: - unit: -MML command: ESX, ESLMML abbreviated name: HTSLHDLC start TSL (hdlcStartTsl), this parameter allows to define the number of PCM TSL where given HDLC link begins.

object: HDLC range: 231 (ETSI) or 224 (ANSI)step: 1 default: - unit: PCM TSLMML command: ESX, ESF, ESLMML abbreviated name: HBAND

HDLC bandwidth (hdlcBandwidth), this parameter allows to define the bandwidth which is available for Packet Abis traffic in the given HDLC link. The bandwidth is expressed in terms of PCM TSLs assigned to given HDLC link. A single HDLC link consists of continuous block of 64kbit/s PCM TSLs, more than one HDLC link can be configured on the same TDM line (fractional PCM configurations are supported). The minimum configurable HDLC bandwidth is of 128 kbit/s (i.e. 2 subsequent PCM TSLs) and the maximum one is limited by TDM line capacity in ETSI/ANSI environment. Please note that BCF bandwidth can be split to several HDLC links (e.g. when BCF has more than one E1/T1 available for Abis interface).# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (5/9)Packet Abis over TDM: Header compressionParameterDescriptionobject: BCF range: 0 (OFF), 1 (ON) default: 0 unit: -MML command: EFM, EFOMML abbreviated name: HECOP

Header compression for ML-PPP (headerCompression), this parameter is used to enable (HECOP=1) or disable (HECOP=0) header compression for ML-PPP header. Even though header compression is optional procedure it is recommended to enable it as it contributes to bandwidth savings what is very important for Packet Abis over TDM. For details about header compression please refer to Slide33. Header compression is not possible with Packet Abis over Ethernet therefore the parameter is only relevant for Packet Abis over TDM (AICT=1).object: BCF range: 0 (OFF), 1 (ON) default: 0 unit: -MML command: EFM, EFOMML abbreviated name: HECOU

Header compression for UDP/IP (headerCompressionForUdpIp), this parameter is used to enable (HECOU=1) or disable (HECOU=0) header compression for UDP and IP headers.Even though header compression is optional procedure it is recommended to enable it as it contributes to bandwidth savings what is very important for Packet Abis over TDM. For details about header compression please refer to Slide33. Header compression is not possible with Packet Abis over Ethernet therefore the parameter is only relevant for Packet Abis over TDM (AICT=1).# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (6/9)Packet Abis over PSNParameterDescriptionobject: BCF range: 0, 1: 0 = NO SHAPING 1 = SHAPING COMMITTEDdefault: 0 unit: -MML command: EFM, EFOMML abbreviated name: ULTS=> cf. Slide228 for Element Manager

Uplink traffic shaping (uplinkTrafficShaping), this parameter is used to enable (ULTS=1) or disable (ULTS=0) uplink traffic shaping for the BCF operating with Packet Abis over Ethernet. The parameter is not relevant for Packet Abis over TDM.Traffic shaping provides means necessary to control traffic transmitted by Packet Switched networks (PSN) including traffic classification concepts, queue disciplines, congestion management and quality of service. Enabling and cooperation of these mechanisms allow to maximize performance within available bandwidth: packets related to particular traffic types can be distinguished and are treated accordingly to the priorities they got. Without traffic shaping each and every packet is treated in an identical manner regardless on the traffic type and network load: they all are buffered in the same queue and there are no means to indicate their importance, e.g. in the presence of congestion discarding of the packets would be done randomly-like (i.e. based on queuing discipline used in the transmission buffer). For Packet Abis it means that enabling of traffic shaping is a prerequisite to configure set of mechanisms which aim at managing traffic in a PSN (i.e. separate parameters to control QoS mappings and scheduling as well as congestion management). The interactions between QoS mechanisms and congestion management are fully configurable to gain the best out of traffic shaping activities. The parameter is mandatory for Packet Abis over Ethernet (AICT=2). When traffic shaping is enabled in a BCF then Abis bandwidth available in the BCF is defined explicitly by committed information rate (CIR) value which is reflected in ULCIR parameter. Note: ULCIR (see next slide) is mandatory for the BCF where traffic shaping enabled (ULTS=1) as traffic shaping is done at CIR level. # Nokia Siemens Networks RN20107EN14GLN0Despite (or maybe because of) the open and cooperative nature of IP networks, competition for available resources tend to be unfair or selfish. This is why traffic shaping is needed.RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (7/9)Packet Abis over PSNParameterDescriptionobject: BCF range: 100250000 step: 100default: - unit: kbpsMML command: EFM, EFOMML abbreviated name: ULCIR=> cf. Slide228 for Element Manager

Uplink committed information rate (ulCommittedInformationRate), this parameter is used to define committed information rate (CIR) value for traffic shaping in the BCF. Committed Information Rate (CIR) is the average bandwidth guaranteed by a PSN owner (e.g. ISP) to work under normal conditions, i.e. the available bandwidth should be never below the committed value. Normally, CIR is a part of SLA where apart from bandwidth availability also acceptable level of transport impairments (delay, delay variations, packet loss rate) are subjects to agreement.Furthermore, bursty nature of the traffic leads to short-lasting periods when required bandwidth is above CIR. This is also normally subject to agreement via SLA and such bandwidth demands are reflected in definition of Excess Information Rate (EIR). Usually EIR handling is done in one of the following ways (but in principle also other policies are possible):- either EIR is only provided in low network load conditions (i.e. when required bandwidth is available),- or EIR is always provided but transport impairments are not guaranteed (i.e. delay, delay variation and packet loss rate can exceed the levels agreed for CIR traffic).CIR value depends on traffic profile and load in the BCF and must be evaluated for each BCF separately by means of dimensioning. Please refer to section Impact on dimensioning for explanations how to estimate the bandwidth required per BCF. EIR value is not needed in database as it is optional parameter mainly related to SLA rather than to BSC database. Do not mix up CIR and EIR while defining bandwidth required by the BCF.Note that for Packet Abis over TDM the concept of CIR is not applicable. Cf. ML-PPP bundle ID parameter which is relevant then.Note that in RG20 traffic shaping is only supported in UL. In consequence, only UL CIR is to be set for traffic shaping purposes. However, DL CIR value is also required in RG20 DB because it is used by congestion control mechanism for DL bandwidth definition in case of Packet Abis over PSN. Please refer to section congestion control for further details. # Nokia Siemens Networks RN20107EN14GLN0SLA: Service Level AgreementRN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (8/9)Packet Abis over PSNParameterDescriptionobject: BCF range: 065535 step: -default: 1522 unit: octetMML command: EFM, EFOMML abbreviated name: ULCBS=> cf. Slide228 for Element Manager

Uplink committed burst size (ulCommittedBurstSize), this parameter is used to define committed burst size value for traffic shaping in the BCF. Burst size is understood as the amount of octets being scheduled for transmission in given scheduling cycle (all scheduled packets, including payload and header bits, contribute to individual packet burst).For shaping of bursty traffic which is present in Packet Abis, the average limit (allowing for bursts of data to be sent) rather than a hard and unbreakable (i.e. constant) one on data rate must be met. For that purpose a token bucket algorithms with configurable CBS are in use since they allow a certain amount of burstiness while imposing a limit on the average data transmission rate (defined by CIR). Committed burst size (CBS) denotes the maximum size available for a burst of packets sent at the given link to keep its information rate in conformity with the relevant CIR. For the token bucket overall principles refer to backup slides.For planning of CBS similar parameters should be involved like those for CIR (i.e. CS/PS load, signalling profile as well as codec distribution and feature configuration e.g. CS multiplexing). The easiest way to estimate CBS is to express the chosen CIR in terms of octets per frame that is: CIR[kbit/s] x 1024 x 8 / 50. This simple approach may however lead to understimation of CBS (as averaging of burst size is done over 50 cycles scheduled in 1 sec period) what should be avoided (e.g. by chosing 10-15% greater CBS than that related directly to CIR).# Nokia Siemens Networks RN20107EN14GLN0Note: The CIR is subject to averaging because all packets/frames are always sent at the interface (UNI) speed (e.g. 10 Mbps, 100 Mbps)RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementPacket Abis connection type (9/9)Packet Abis over PSNParameterDescriptionclass: ETHPRT range: 2001500 step: 1 default: 1500 unit: octets(BTS parameter) cf. Slide227 for Element Manager[Ethernet maximum transfer unit size (ethernetMtuSize), this parameter is used to define the maximum payload size that can be carried by Ethernet frame.The higher MTU the better transport efficiency because each packet carries more user data while protocol overheads remain fixed. However, large packets can occupy a slow or heavy loaded link for some time, causing greater delays to the following packets.class: ETHPRT range: 0 (OFF), 1 (ON)default: 1 unit: -(BTS parameter) cf. Slide226 for Element Manager

Ethernet auto-negotiation (ethernetAutoNegEnabled, this parameter is used to define whether Ethernet auto-negotiation functionality is enabled or not.Ethernet auto-negotiation is a procedure by which two connected devices choose common transmission parameters such as speed (also other parameters like duplex mode, port type, master-slave relation, etc can be agreed). In this process, the connected devices first share their capabilities for these negotiated parameters and then choose the fastest transmission mode they both support. Note: In Packet Abis auto-negotiation is always enabled in BSC. At BTS side auto-negotiation is optional and shall be enabled/disabled by configuration. Auto-negotiation is managed only from BTS Element Manager.# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (1/8)Congestion control activationParameterDescriptionobject: BCF range: 0, 1:0 = DISABLE1 = ENABLEdefault: 0 unit: -MML command: EFM, EFOMML abbreviated name: PACC=> cf. Slide229 for Element Manager

Packet Abis congestion control (packetAbisCongestionControl), this parameter allows to enable (PACC=1) or disable (PACC=0) congestion control mechanism including both Abis backhaul monitoring as well as Abis packet loss detection. When Packet Abis congestion control is enabled (PACC=1) then severity thresholds and filtering timers must be additionally configured (please refer to the related parameters on Slide97 Slide101). Besides, in case of Packet Abis over Ethernet, definition of ULCIR and DLCIR is mandatory (cf. Slide96 for further details).When Packet Abis congestion control is disabled (PACC=0) then severity thresholds and filtering timers are meaningless. In such case discarding of obsolete packets is the only countermeasure in the presence of congestion. Therefore drop periods (cf. next slide) must be cautiously defined to ensure BTS Tx queues handling according to expectations.Note that drop periods are meaningful regardless on whether congestion control is enabled or not. Even if congestion control is enabled prioritization of packets to be discarded can be helpful to smoothly overcome congestion situation.Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms as it can help to better understand the meaning of and interdependencies between all relevant parameters.# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (3/8)Backhaul Utilization (1/3): DL bandwidth definition for PSNParameterDescriptionobject: BCF range: 100250000 step: 100 default: - unit: kbpsMML command: EFM, EFOMML abbreviated name: DLCIR=> Slide229 for Element Manager

Downlink Committed Information Rate (dlCommittedInformationRate), this parameter is used to define DL committed information rate (CIR) value for congestion control purposes.Congestion control mechanism requires bandwidth definition for both TDM-based and PSN-based transport in both directions: - for Packet Abis over TDM, the number of capacity of HDLC links assigned to an ML-PPP bundle determine the bandwidth available for given BTS site,- for Packet Abis over PSN, the bandwidth per BTS site is defined explicitly by means of CIR values: in UL congestion control mechanism re-uses the value related to traffic shaping (cf. ULCIR parameter on Slide84), in DL where traffic shaping is not supported in RG20 a dedicated value is needed and therefore DLCIR is additionally introduced.Note that in RG20 DLCIR has nothing to do with traffic shaping (e.g. does not need to be a part of SLA) and is only used by the system in the context of congestion control mechanism.Also DLCIR value depends on traffic profile and load in the BCF and must be evaluated for each BCF separately by means of dimensioning. Please refer to section Impact on dimensioning for explanations how to estimate the bandwidth required per BCF. # Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (5/8)Backhaul Utilization (3/3): filtering timersParameterDescriptionobject: BSCrange: 1300 step: 1default: 4 unit: secMML command: EEY, EEOMML abbreviated name: BTON=> cf. Slide229 for Element Manager

Backhaul Timer Duration Start Reaction (bhTimerDurStartReact), this timer defines how much time backhaul congestion must persist to declare detection of the related congestion level (lower or upper) and to start the appropriate reaction procedures.The timer starts when a congestion severity threshold (BU1 or BU2) is exceeded. If backhaul utilization remains greater than the related threshold BUx for the whole duration time of BTON then the related (R1 or R2) reaction procedures are invoked. Otherwise (i.e. when backhaul utilization moves back even for a while below BUx before BTON expiry), BTON is stopped and the related reaction procedure is not invoked. The value of the timer is valid both for UL and for DL direction.Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms.object: BSC range: 1600 step: 1default: 10 unit: secMML command: EEY, EEOMML abbreviated name: BTOFF=> cf. Slide229 for Element Manager

Backhaul Timer Duration Stop Reaction (bhTimerDurStopReact), this timer defines how much time backhaul congestion must not be active to declare cancellation of the related congestion level and to stop the appropriate reaction procedures.The timer starts when backhaul utilization falls below hysteresis threshold associated with congestion severity threshold (BU1 or BU2), i.e. 5% below given severity threshold. If backhaul utilization remains lower than the related hysteresis threshold BUx_Hy for the whole duration time of BTOFF then the related (R1 or R2) reaction procedures are stopped. However, any rise of backhaul utilization above BUx_Hy before BTOFF expiry, causes reset of BTOFF and lack of relaxation of ongoing reaction procedures.Note that clearance of congestion level does not necessarily mean that reaction procedures are completely stopped: clearance of congestion level 2 means that R2 procedure is just replaced with R1 and only clearance of congestion level 1 actually means that reaction procedures are cancelled. The value of the timer is valid both for UL and for DL direction.Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (6/8)Packet Loss (1/3): severity thresholdsParameterDescriptionobject: BCF range: 132 step: 1default: 14 unit: -MML command: EFM, EFOMML abbreviated name: PL1=> cf. Slide229 for Element Manager

Packet loss on DL Abis PL1 threshold (pl1ThresholdPacketLoss), this parameter is used to define a first (lower) threshold triggering congestion reaction procedure based on packet loss (PL) detection.The threshold is compared with the difference between PS and CS loss rates which are measured separately in advance. Loss rate is defined as a ratio between the lost frames and the expected (i.e. lost + received) ones and expressed as percentage. Therefore parameter values are also eventually mapped to the percentage (see table on the right).When difference between PS and CS loss rates exceeds the percentage defined by PL1 then timer PLTON starts (cf. see next but one slide). If difference between PS and CS loss rates remains greater than the threshold for the whole duration of PLTON then R1 reaction procedures are invoked, otherwise the timer is reset and no congestion reaction is invoked.R1 reaction procedures are removed when difference between PS and CS loss rates become represented by the value mapped 5 levels below PL1 and is kept within that range for a time longer than PLTOFF (cf. see next but one slide). Hardcoding of PL hysteresis offset leads to the following rules:- if PL1 > 5: PL1_Hy = PL1 5 (e.g. PL1_Hy = 9 for PL1 = 14)- if PL1 5: PL1_Hy are predefined as follows - PL1 = 1 => PL1_Hy = 5x10exp(-5) = 0.00005 = 0.005% - PL1 = 2 => PL1_Hy = 6x10exp(-5) = 0.00006 = 0.006% - PL1 = 3 => PL1_Hy = 7x10exp(-5) = 0.00007 = 0.007% - PL1 = 4 => PL1_Hy = 8x10exp(-5) = 0.00008 = 0.008% - PL1 = 5 => PL1_Hy = 9x10exp(-5) = 0.00009 = 0.009%Note that monitoring of lost frames is only implemented for DL direction in RG20. Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms. valuesymbolic value11x10exp(-4) = 0.0001 = 0.01%22x10exp(-4) = 0.0002 = 0.02%33x10exp(-4) = 0.0003 = 0.03%44x10exp(-4) = 0.0004 = 0.04%55x10exp(-4) = 0.0005 = 0.05%66x10exp(-4) = 0.0006 = 0.06%77x10exp(-4) = 0.0007 = 0.07%88x10exp(-4) = 0.0008 = 0.08%99x10exp(-4) = 0.0009 = 0.09%101x10exp(-3) = 0.001 = 0.1%112x10exp(-3) = 0.002 = 0.2%123x10exp(-3) = 0.003 = 0.3%134x10exp(-3) = 0.004 = 0.4%145x10exp(-3) = 0.005 = 0.5%156x10exp(-3) = 0.006 = 0.6%167x10exp(-3) = 0.007 = 0.7%178x10exp(-3) = 0.008 = 0.8%189x10exp(-3) = 0.009 = 0.9%191x10exp(-2) = 0.01 = 1%202x10exp(-2) = 0.02 = 2%213x10exp(-2) = 0.03 = 3%224x10exp(-2) = 0.04 = 4%235x10exp(-2) = 0.05 = 5%246x10exp(-2) = 0.06 = 6%257x10exp(-2) = 0.07 = 7%268x10exp(-2) = 0.08 = 8%279x10exp(-2) = 0.09 = 9%281x10exp(-1) = 0.1 = 10%292x10exp(-1) = 0.2 = 20%303x10exp(-1) = 0.3 = 30%314x10exp(-1) = 0.4 = 40%325x10exp(-1) = 0.5 = 50%# Nokia Siemens Networks RN20107EN14GLN0expected frames are evaluated based on the Sequence Number that is included in RTP header of the CS and PS U-plane frames. RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (7/8)Packet Loss (2/3): severity thresholdsParameterDescriptionobject: BCF range: 132 step: 1default: 28 unit: -MML command: EFM, EFOMML abbreviated name: PL2=> cf. Slide229 for Element Manager

Packet loss on DL Abis PL2 threshold (pl2ThresholdPacketLoss), this parameter is used to define a second (upper) threshold triggering congestion reaction procedure based on packet loss (PL) detection.Please refer to the previous slide for additional explanations about what is the threshold compared with and what values is the parameters range mapped to.When difference between PS and CS loss rates exceeds the percentage defined by PL2 then timer PLTON starts (cf. see next slide). If difference between PS and CS loss rates remains greater than the threshold for the whole duration of PLTON then R2 reaction procedures are invoked, otherwise the timer is reset and no adjustment of congestion reaction procedure occurs.R2 reaction procedures are removed (changed to R1) when difference between PS and CS loss rates become represented by the value mapped 5 levels below PL2 and is kept within that range for a time longer than PLTOFF (cf. see next slide). Hardcoding of PL hysteresis offset leads to the following rules:- if PL2 > 5: PL2_Hy = PL2 5 (e.g. PL2_Hy = 23 for PL2 = 28)- if PL2 5: PL2_Hy are predefined as follows - PL2 = 1 => PL2_Hy = 5x10exp(-5) = 0.00005 = 0.005% - PL2 = 2 => PL2_Hy = 6x10exp(-5) = 0.00006 = 0.006% - PL2 = 3 => PL2_Hy = 7x10exp(-5) = 0.00007 = 0.007% - PL2 = 4 => PL2_Hy = 8x10exp(-5) = 0.00008 = 0.008% - PL2 = 5 => PL2_Hy = 9x10exp(-5) = 0.00009 = 0.009%Note that monitoring of lost frames is only implemented for DL direction in RG20.Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms. # Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#Configuration managementCongestion control (8/8)Packet Loss (3/3): filtering timersParameterDescriptionobject: BSC range: 1300 step: 1default: 10 unit: secMML command: EEY, EEOMML abbreviated name: PLTON=> cf. Slide229 for Element Manager

Packet Loss Timer Duration Start Reaction (packetLossTimerDurStartReact), this timer defines how much time backhaul congestion must persist to declare detection of the related congestion level (lower or upper) and to start the appropriate reaction procedures.The timer starts when a congestion severity threshold (PL1 or PL2) is exceeded. If difference between PS and CS loss rates remains greater than the related threshold PLx for the whole duration time of PLTON then the related (R1 or R2) reaction procedures are invoked. Otherwise (i.e. when difference between PS and CS loss rates moves back even for a while below PLx before PLTON expiry), PLTON is stopped and the related reaction procedure is not invoked. The value of the timer is valid only for DL direction (monitoring of lost frames in UL is not implemented in RG20). Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanisms.object: BSC range: 11000 step: 1default: 100 unit: secMML command: EEY, EEOMML abbreviated name: PLTOFF=> cf. Slide229 for Element Manager

Packet Loss Timer Duration Stop Reaction (packetLossTimerDurStopReact), this timer defines how much time backhaul congestion must not be active to declare cancellation of the related congestion level and to stop the appropriate reaction procedures.The timer starts when difference between PS and CS loss rates falls below hysteresis threshold associated with congestion severity threshold (PL1 or PL2), i.e. 5 levels below given threshold. If difference between PS and CS loss rates remains lower than the related hysteresis threshold PLx_Hy for the whole duration time of PLTOFF then the related (R1 or R2) reaction procedures are stopped. However, any rise of difference between PS and CS loss rates above PLx_Hy before PLTOFF expiry, causes reset of PLTOFF and lack of relaxation of ongoing reaction procedures.Note that clearance of congestion level does not necessarily mean that reaction procedures are completely stopped: clearance of congestion level 2 means that R2 procedure is just replaced with R1 and only clearance of congestion level 1 actually means that reaction procedures are cancelled. The value of the timer is valid only for DL direction. Refer to Slide64 Slide70 for overview about Packet Abis congestion control mechanism.# Nokia Siemens Networks RN20107EN14GLN0RN20107EN14GLN0Handover Control and Adjacencies#