HSDPA Congestion Control

1.
1 FEATURE TEAM WORKSPACE
Requirement ID :
Requirement Version :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.1 1.1 Version history
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
0.0.1: Initial draft. Jussi Laitinen
0.1.0: Document was reviewed 04.04.2007. Review result was Approved With Corrections. Due date for
corrections is 13.04.2007. Minutes are in IRMA database. Jussi Laitinen
0.1.1: Review comments corrected. Jussi Laitinen
1.0.0: Approved. Jari Taavela
1.0.1: "Monitoring the HSDPA Congestion Control" section was updated. Data frame with DRT/FSN reset
was updated.
2.0: Version 2.0, RU10 E1(P3) baseline version.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2 1.2 Introduction
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
This module is workspace for HSDPA congestion Control feature team.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.1 1.2.1 Scope
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
RU10 scope.
This module contains:

working assumptions
main decisions done during the feature team work
all open issues related to the feature
effects on system capacity, performance and licensing issues
technical description of the feature (functionalities and relations to other features)
any other data that is needed for the creation of the formal requirements.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.2 1.2.2 General Description
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Congestion control is implemented at the BTS, and its purpose is to maintain the maximum Iub utilisation
without causing a congestion situation. Existing FP layer flow control mechanism is used to signal how
much RNC is allowed to send the data towards BTS.
Rationale for basing the implementation to the BTS is that the RNC does not see the Iub congestion
after hub points, thus the full view to the congestion situation is not available in the RNC. With this
feature the Iub HSDPA congestion can be detected at the BTS and even proactively prevented, which
makes higher statistical multiplexing ratios feasible.
3GPP R7 introduces mechanisms for Iub HSDPA data congestion detection and control. The HSDPA
congestion detection mechanism is similar to the mechanism introduced for the HSUPA.
Iub congestion detection is done at the BTS FP layer using the build-up delay information (DRT) and
sequence numbering (FSN) in the downlink FP frames which the RNC includes in HS-DSCH Data
Frame.
FSN: The 4-bit long FSN number is added by SRNC to every transmitted HS-DSCH data frame that
belongs to one MAC-d CmCH-PI flow. Every data flow generates its own Frame Sequence Number.
DRT: Delay Reference Time information is 16-bit long field that can be used for dynamic delay
measurement. It is bound to a RNC internal timer with 1 ms resolution. There is a New IE flags in HS-
DSCH DATA FRAME indicates if the 2 octets following the New IE Flags IE contains a valid DRT(1) or
not (0). DRT is used in a way that FP layer in SRCN adds into every frame a new DRT value.
FSN/DRT reset: In SRNC relocation the relocation source and destination RNCs are not synchronized in
terms of HS-DSCH data frame FSN and DRT numbering. For this reason a new information element
(FSN/DRT Reset) is added into the HS-DSCH data frame that indicates the SRNC relocation. This IE is
located at the 2nd spare bit of the 4th byte. The new SRNC enables (value "1") the bit indicating the
relocation in the first data frame of every relocated HS-DSCH channel and BTS resets the FSN/DRT
related congestion detection functions. During normal operation the bit is disabled (value "0") and causes
no actions in BTS.
For compatibility reasons with both south and north BTS it has been decided that RNC includes
FSN/DRT reset = '1' and FSN = '0' to the FP frame where it wants to reset FSN and DRT based
congestion detection. This leads to same result in both type of BTS (and no mobisphere CR is needed
to change south BTS to support FSN/DRT reset.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Figure: HS-DSCH Data Frame
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
BTS functionality
This feature is mostly implemented in the BTS. Latest requirements are available in "BTS requirement"
and "BTS Design" sections in:
"DOORS: WCDMA_BTS / BTS_Requirement / WCDMA User Plane / HSDPA L2 / Flow Control"
and BTS feature module is available in:
"DOORS: WCDMA_BTS / Feature Specification / HSDPA Improvements for WBTS5.0"
Text below subject to change based on ongoing simulations.
BTS monitors the build-up delay using DRT and the lost frames using FSN and CRC (*). The delay
status derived from DRT is indicated to the congestion control algorithm in BTS.
(*) CRC is included because FSN can only be monitored when intact frames are received.
The CC algorithm is based on the Multilevel ECN (Explicit Congestion Notification), which produces the
propability of data rate reduction based on current connection delay (delay gets larger, propability gets
larger). These propabilities are generated for each FP entity experiencing congestion. (this is open in
simulations)Adaptive adjustment of maximum propability as in HSUPA CC is included.
(this is open in simulations) When QoS is in use, the credit reductions are scaled with QoS scheduling
weights so that the magnitude of credit reductions is proportional with the excess capacity given to the
SPI classes. Additionally CC can be turned on or off per SPI class and can be defined if CC is applied to
SPI class completely or just for the part exceeding the NBR/GBR.
If the propability check is succesfull, a congestion indication is given to the flow control functionality in
the BTS, which performs reduction of the data rate by reducing HS-DSCH Credits with HS-DSCH
Capacity Allocation.
Reduction part of flow control algorithm should calculate new credit allocation by multiplying
with a reduction multiplier the number of credits used by RNC (PDUs received from RNC).
If flow control would calculate new credits from previous credit allocation, it might in some
cases have no effect at all, because the RNC might be sending far less than what the allocation is.
For example 100 credits allocation, RNC uses 25 credits and congestion control reduces credits to
75 -> no effect.
BTS informs the congestion status also to the RNC in Capacity Allocation (mandatory field).
It is used by RNC only for debugging purposes. Still, the rate of sending congestion indications from BTS
to RNC should be sensible if some congestion control functionality is added to RNC at later point or CC
information is taken in account in some other feature. Minimum interval for sending the CIs should be
larger than or equal to the RTT (time until rate reduction is seen at BTS from the moment of sending the
CI) and when reporting "No congestion" it should be "larger than or equal to RTT + guard period of no
congestion" before it is sent.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Figure. HS-DSCH Capacity Allocation
7 0
Spare Congestion
bits 7-6 CmCH-PI
Status
Maximum MAC-d PDU Length
Maximum MAC-d PDU HS-DSCH Credits

Length (cont)
HS-DSCH Credits (cont)
HS-DSCH Interval
HS-DSCH Repetition Period
Spare Extension
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.2.1 1.2.2.1 Configuring the HSDPA Congestion Control
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Setting the parameters for MECN CC algorithm is up to the BTS how it is done. These is no way in
standards to send these from RNC to BTS (Annex Z use is avoided).
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.2.2 1.2.2.2 Activating the HSDPA Congestion Control
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Operator can activate the HSDPA CC by setting the BTS-specific management parameter
HSDPACCEnabled to "Enabled" if the licence has been purchased.
Possible values are Enabled and Disabled. Default value is "disabled" because this is ASW feature.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.2.3 1.2.2.3 Monitoring the HSDPA Congestion Control
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Operator can monitor the operation of the HSDPA CC with counters in WBTS Measurement.
Number of HS-DSCH credit reductions due to Iub delay build-up
This counter shall be incremented for credit reductions resulting from succesfull propability P1 check.
Number of HS-DSCH credit reductions due to severe Iub delay build-up
This counter shall be incremented for credit reductions resulting from either a succesfull propability P2
check or from delay exceeding the MECN maximum delay threshold (Thmax).
Number of HS-DSCH credit reductions due to frame loss
This counter shall be incremented for credit reductions resulting of CRC or FSN check.
Number of HS-DSCH credit reductions due MAC-hs buffer filling
This counter shall be incremented for credit reductions to zero due to buffer filling.
Following counters are not related to HSDPA CC but are introduced as byproduct of it. It was
proposed that these would be calculated based on the DRT and receival time in BTS, but they have
been moved back to draft status, because for a receival time n BTS does not know what it corresponds
to at same moment in DRT (no synchronisation).
Average Iub delay
Average delay during a period of time.
Peak Iub delay
Highest delay during a period of time. Calculation is open.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.2.4 1.2.2.4 Deactivating the HSDPA Congestion Control
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Operator can deactivate the HSDPA CC by setting the parameter HSDPACCEnabled to "Disabled".
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.3 1.2.3 Licencing
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
HSDPA Congestion Control has RNC Licence Key.
Dependencies to other features:

HSPA QoS Aware Scheduling is affected.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.4 1.2.4 Terms and abbreviations
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
MECN Multilevel Explicit Congestion Notification

FSN Frame Sequence Number
CC Congestion Control
FP Frame Protocol
DRT Timestamp in each HS-DSCH Data Frame
CI Congestion Indication
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.5 1.2.5 Open Issues
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1. Does congestion control have any effect on existing flow control algorithms in RNC? Does
capability to CC have to be signalled to RNC?
Closed: Capability does not have to be signalled to the RNC. CC does not have effects to the RNC flow
control. BTS indicates the congestion status but no use is seen for it currently in the RNC.
2. Can old BTS without support for CC support new FP Data Frame. Does capability to CC have to
be signalled to RNC?
Closed: Capability does not have to be signalled to the RNC. Old BTS ignores the new fields in data
frame.
3. Is CC behind separate licence and is licensing in RNC or BTS? To be asked from Jukka Nauha
if separate licence is needed.
Closed. Long term capacity licence. RNC LK.
4. Are HSDPA CC parameters (MECN thresholds) in operators control as in HSUPA CC. And can
the same parameters be used?
Closed. Those parameters are configurable with BTS element manager, unless testing finds out that one
set of best values for all environments can be found, in which case they will be R&D parameters without
operator control. Current understanding is that the parameters depend on network topology.
5. Is RTT measurement needed? If congestion notification messages are not used for RNC, RTT
can only be used in BTS CC algorithm.
Closed. Assumption is that measurement is not needed. Would have to be signalled to BTS through
control plane and is changing all the time so accuracy would be problem anyway.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
6. What new counters needed: E.g. FP loss ratio in downlink, duration (or number of) of Iub in
congestion/non-congestion, average Iub delay, peak Iub delay
Closed. New counters are listed in the module.
7. Is CC needed in Iur? If Inter RNC handover feature approved, might be needed.
Closed. At this point, cc will be only thought from Iub point of view.
8. If algorith triggers credit reduction based on delay and packet loss, can same criterias be used
for all HSDPA traffic or should HSDPA QoS be taken in account (for example tighter delay
requirements for the streaming class)
Closed. The QoS is taken in account by excluding the GBR users with QoS Scheduling Weight == "0"
and by weighing the MECN propabilities according to SPI classes so lower SPIs have slightly higher
propability to get targeted by CC.
9. Does the algorithm need to be aware of used transport path? For example if BTS has Hybrid
transport via DSL moded and in addition native ATM connection via E1 link and both can have
HSDPA, does the algorithm need to know in congestion which one is congested or is the traffic
slowed down by some other basis without knowledge of used transport path? Can same
algorithm and chosen parameter values be used also for IP transport? In Dual Iub configuration it
may be possible that HSDPA goes via either IP or ATM transport, at least in fault situations when
IP route is broken. HSDPA traffic can also be on same path but in different ATM VCC and the
congestion (for example in RNC) is only on either one. How does algorithm handle such case?
AP: Toni Tapper
Closed. Algorithm does CC actions only to the FP entities from which the congestion is detected so it
should be independent of the transport path.
10. The "User Buffer Size"-field in the HS-DSCH Data Frame / HS-DSCH Capacity Request is used
to optimise the flow control algorithm. BTS does not know if the RNC has any data to send when
it gives credits. Reduction might have no effect if RNC has less PDUs than credits allow / sends
for other reasons less PDUs than credits allow.
Closed. Not needed.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
11. Handling the Inter-RNC Serving Cell Change. A mechanism is proposed in 3GPP by Siemens
(FSN/DRT reset field in HS-DSCH Data Frame) it is not in standard yet.
Closed. 3GPP mechanism is specified to be the way to do it and only for common iub purposes is
specified a method where FSN 0 is used to indicate the reset of the FSN/DRT congestion detection
measurements.
12. NetAct issues in chapter 1.4.3 (External Interfaces) needs checking. AP: Pasi Sirni
Closed.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.6 1.2.6 Meeting Minutes
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Meeting minutes in team's workspace in PI:

http://esdoc04nok.ntc.nokia.com/urn.htm?auth=T&id=0b006c3780ea93f4&dmw_docbase=espoo11
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.7 1.2.7 Decisions
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
- HSDPA CC shall not have functionality in the Annex Z.
- RNC shall insert FSN=0 and FSN/DRT Reset=1 into same HS-DSCH Data Frame, when it wants to
reset FSN and DRT based congestion detection measurements in the BTS.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.2.8 1.2.8 Feature Team Participants
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Name Role
Multanen Pekka Frame Protocol SFS
Laitinen Jussi BTS EFS author
Petri Ukkola BTS EFS co-author
Guarnieri Mirko RNC EFS author
Tuominen Janne.K RNC EFS author
Keklinen Marko Feasibility Study author
Telkkl Timo Performance Monitoring
Other Contacts
Taavela Jari Telecom category leader
Nauha Jukka Product management
Csaba Vulkan Simulations
Helenius Janne Simulations
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.3 1.3 Input Material
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
3GPP Iub Congestion Control for HSDPA Feasibility Study (link to PI):
http://esdoc04nok.ntc.nokia.com/urn.htm?document_id=13-
347753&version=current&directshow=T&id=09006c37806977b7&dmw_docbase=espoo11
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.3.1 1.3.1 Stakeholder analysis
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
HSDPA Congestion Control features responsible in product management is Jukka Nauha (Nauha
Jukka.P (Nokia-NET/Oulu)).
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.3.2 1.3.2 Input references
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
3GPP TS25.435 UTRAN Iub interface user plane protocols for Common
Transport Channel data streams
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.3.3 1.3.3 Related features
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
HSDPA QoS
These effects are yet to be simulated. Currect assumption is:
- Lower SPIs have higher propability to trigger CC.
- SPIs which are scheduled more are reduced more (scheduling amount can be derived from packet
scheduler QoS Scheduling Weights, which are defined for each SPI).
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.4 1.4 Feature Specification
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.4.1 1.4.1 Model
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.4.2 1.4.2 External interfaces
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Figure below present RAN external actors:

CN OS
RAN
UE
CN (Iu interface) and UE (Uu interface): No effects.
OS-RAN:
These features shall have impacts to adaptations and applications of the NetAct.
Required NetAct version:
- OSS5.1 is the current plan, where RU10 features are supported.
Interface impacts to NetAct will be depicted in more detail on EFS level:
- CM, activation/deactivation parameter for HSDPA Congestion Control feature
- PM, new counters and measurements for HSDPA Congestion Control feature
- FM, impacts are for future study. They are defined in HSDPA improvements for WBTS5.0 EFS.
Impacted OS tools:
- administrator tools
- CM tools
- BTS element manager (to setup MECN algorithm parameters which are listed in the HSDPA
improvements for WBTS5.0 EFS)
- monitoring tools
- service management tools
- reporting tools
- traffica tools
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.4.3 1.4.3 Internal interfaces
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
RNC-BTS (Frame protocol):
- DRT, FSN and FSN/DRT Reset in the HS-DSCH Data Frame.

- Congestion Status in the HS-DSCH Capacity Allocation Frame.
RNC-BTS (O&M interface):

Performance measurements
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
1.4.4 1.4.4 Effects on system capacity and performance
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Check the relevant questions in this questionnaire.
This questionnaire is done to survey those features that have effect on RAN system Capacity and
performance specification.
1. RAN performance
1) Does the feature have effect on RAN performance, as e.g.:

AMR/PS/CS call setup time (RRC / radio bearer setup time)
Radio bearer throughput (peak value, new RBs)
User plane traffic when upgrading / downgrading / changing the RB
User plane traffic in handovers (SHO, Softer HO, Handovers over Iur, IFHO, ISHO)
Call latency / jitter (measured round trip time using ping)
RRC state transition times
Location service accuracy
Voice quality / RB block error rate
RRC/Call Success Rates
--> Simulation show that for HSUPA CC the average data rates of users are increased when CC is used
in crowded Iub compared a simulation where CC is not used. This could also increase the peak rates for
HSDPA a bit. Also the latencies should be reduced according to these simulations.
2) Does the feature have effect on ther RAN key performance indicators?
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
3) What kind of effect on performance? Change to current functionality? Totally new feature? (filled
together with RAN System Performance group / Antti Pietil)
Iub efficiency is increased because in high loads congestion control feature keeps the Iub usage very
near but below the level where Iub delay becomes unacceptable or packets are lost.
4) What is the performance estimate with the feature (min, typical, max)? What was the performance
before the feature? (filled together with RAN System Performance group / Antti Pietil)
If such implementation is considered typical where Iub is dimensioned so that it is not possible to get into
congestion, then with CC it is near maximum usable.
5) Feature team members & expertise areas:

Name Role
Sipola Heikki BTS EFS
Laitinen Jussi BTS EFS
Tapper Toni RNC EFS
Tuominen Janne.K RNC EFS
Other Contacts
4) & 5) are used to fill the RAN performance effect -field in the RAN Focal Point
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2. RAN Capacity
1) Does the feature have effect on Network Connectivity
Number of elements/interfaces/cells
Number of core elements/supported radio technologies/operators
2) Does the the feature have effect on Network User Plane Capacity
Iu/Iub/Iur interface capacities of RAN elements
Cell capacities (Uu interface)
3) Does the the feature have effect on Network Event Capacity

Call setup capacity of elements
Message/Location Update/Registration etc capacity of elements
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
4) Does the the feature have effect on Network UE state handing capacity
Number of users in RRC states
Number of user in Compressed mode
Number of users in Sof/Softer handover
No.
5) Does the the feature have effect on O&M Capacity and connectivity
No.
6) What kind of effect on capacity? Change to current functionality? Totally new feature? (filled together
with RAN System Performance group / Tuomo Kaukonen)
Allows aggressive HSDPA overbooking in ATM networks.

Also enables use of heavily contended packet networks for HSDPA offload (hybrid backhaul).
7) What is the capacity effect with the feature (min, typical, max)? What was the capacity before the
feature? (filled together with RAN System Performance group / Tuomo Kaukonen)
8) Feature team members & expertise areas:

Name Role
Sipola Heikki BTS EFS
Laitinen Jussi BTS EFS
Tapper Toni RNC EFS
Tuominen Janne.K RNC EFS
Other Contacts
4) & 5) are used to fill the RAN performance effect -field in the RAN Focal Point
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2. 2 SFS REQUIREMENTS FOR FEATURE RAN1110
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
HSDPA Congestion Control
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1 2.1 SFS Requirements linked to feature RAN1110
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.1 2.1.1 SFS Requirements from module /WCDMA_RAN/RAN SFS Folder/Performance
Monitoring/PMO_RAN_SFS_MEASURE
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.1.1 2.1.1.1 Report Requirements
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.1.1.1 2.1.1.1.1 Integrity Reports
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.1.1.1.1 2.1.1.1.1.1 RAN Transport connection intergrity
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Reporting HSDPA congestion in Iub
Rationale:
The HSDPA congestion control in BTS side limits the radio layer throughput in the case Iub
HSDPA performance decreases. The HSDPA congestion detection mechanism is similar to
the mechanism introduced for the HSUPA in RNC side (RAN992).
Iub congestion detection is done at the BTS FP layer using the build-up delay information
(DRT) and sequence numbering (FSN) in the downlink FP frames which the RNC
includes.The Iub performance is monitored from FP layer delay and traffic loss detected in
BTS.
It shall be possible to indicate the congested Iub links and also to estimate the effect of
congestion to end user service quality. The proportion of congestion indications to the
number of HSDPA connections gives the needed information.
Reporting Class: RAN transport connection integrity
Reporting topics: HSDPA congestion in Iub
Report usage: Monitoring Iub and BTS capacity usage for HSDPA. This report is useful for
optimization and troubleshooting of Iub specific traffic.
Common reporting parameters:
HSDPA congestion rate in Iub [%] = nmb_of_congestion_indications_sent /
total number of received MAC-d PDUs
The nmb_of_congestion_indications_sent is a sum of all congestion indications
sent, except the no_congestion messages are not included.
Object: WBTS - WCELL
Counter proposals:
- The number of congestion indications sent due to Iub delay
build-up
- The number of congestion indications sent due to severe Iub delay build-up
- Number of congestion indications sent due to frame loss
- The number of congestion indications sent due MAC-hs buffer filling
Time granularity: 60 min
Reporting scope: RAN
Reporting interval: week
Source:
Change history: v. 1.0.1: Counter for Number of congestion indications sent
due to frame loss added.
v. 1.0.2: CR1320 inserted.
v. 2.0.0 requirement frozen.
Implementation alternatives: Measurement type: HSPA in WBTS.
Questions:
Requirement ID : PMO_RAN_SFS_MEASURE.429
Requirement Version : 2.0.0
Feature Info : RAN1110
NE info : RNC
BTS
NetAct
Phase : Fro
Priority : M
Status : New
Requirement Type : REP
Release Latest : RU10
Other Releases :
Reporting FP delay in Iub
Rationale:
With this report is allowed to monitoring the Frame Protocol level delay in Iub for
CCH/DCH/HS-DSCH in BTS.
Reporting Class: Integrity / RAN transport connection integrity

Reporting topics: FP delay at Iub in BTS
Report usage: For monitoring the Iub transport service quality.

Common reporting parameters:
PI: FP delay at Iub in BTS
Object levels to be reported:
PLMN - RAN - RNC - BTS - Local Cell Group (LCG)
Counter proposals:
Average Iub inter-frame delay for received data frame

Peak Iub inter-frame delay for received data frame
Classification:
CCH/DCH/HS-DSCH
Time granularity: 60 min
Reporting scope: RAN
Reporting interval: day
Source:
Change history: CR1320 / req. changed to draft.
Version 1.0.1: inter-frame added to iub delay counters
Implementation alternatives: This report releated counters will be added to the Frame
Protocol in BTS measurement.
Requirement ID : PMO_RAN_SFS_MEASURE.503
NE info : RNC
BTS
NetAct
Phase : Dra
Priority : M
Status : New
Requirement Type : REP
Other Releases :
2.1.2 2.1.2 SFS Requirements from module /WCDMA_RAN/RAN SFS
Folder/Telecom/TF_RAN_SFS_RRConf
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.2.1 2.1.2.1 Functional requirements
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
Activating the HSDPA Congestion Control
Preconditions:
Valid licence exists.

HSDPA CC is not active.
Steps:
Operator sets the management parameter HSDPACCEnabled to "Enabled". Default value is "disabled"
because CC is ASW feature.
Postcondition:
HSDPA CC is activated (RNC begins to fill FSN and DRT fields in HS-DSCH Data Frames as defined in
TF_SFS_RRConf.225). BTS notices this and starts congestion control algorithm.
Requirement ID : TF_SFS_RRConf.206
NE info : RNC
BTS
NetAct Configuring
Phase : Fro
Priority : M
Status : New
Requirement Type : FUN
Other Releases : RAS07
Rationale:
This is needed for HSDPA congestion control. BTS monitors the build-up delay using DRT and the lost
frames using SFN.
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
RAN shall support HS-DSCH Data Frame with DRT and FSN fields.
Rationale:
HS-DSCH Data Frame with DRT/FSN (introduced in 3GPP rel-7) is needed in HSDPA
Congestion Control.
In SRNC relocation the relocation source and destination RNCs are not synchronized in
terms of HS-DSCH data frame FSN and DRT numbering. This causes a need to have a mechanism for
the RNC to indicate the relocation to Node B so that correct decisions can be made about congestion.
FSN: The 4-bit long FSN number is added by SRNC to every transmitted HS-DSCH data frame that
belongs to one MAC-d CmCH-PI flow. Every data flow generates its own Frame Sequence Number.
Value loops from 1 - 15. FSN value "0" is a special value and it's usage is defined in
TF_SFS_RRConf.227.
DRT: Delay Reference Time information is 16-bit long field that can be used for dynamic delay
measurement. It is bound to RNC internal timer with 1 ms resolution. There is a New IE flags in HS-
DSCH DATA FRAME indicates if the 2 octets following the New IE Flags IE contains a valid DRT(1) or
not (0). DRT is used in a way that FP layer in SRCN adds into every frame a new DRT value.
FSN/DRT Reset: A new information element (FSN/DRT Reset) shall be added into the HS-DSCH data
frame that indicates the SRNC relocation. This IE is located at the 2nd spare bit of the 4th byte. Usage is
defined in requirement TF_SFS_RRConf.227.
These fields are included in the transmitted HS-DSCH Data Frames over Iub/Iur interfaces only when
HSDPA Congestion Control is active.
Figure: 3GPP Rel7 HS-DSCH data frame structure including new FSN/DRT Reset field (indicated
by yellow color) and the FSN and DRT fields.
Change history:
1.0.1: Added description of DRT/FSN reset and new frame structure containing it.
1.0.2: Moved congestion control reset to own requirement TF_SFS_RRConf.227 (Light CR).
NE info : RNC
BTS
Phase : Fro
Priority : M
Status : New
RNC shall command the reset the HSDPA Congestion Detection measurements in the BTS.
This method has been agreed to support both South and North BTS implementations so that South BTS
implementation does not need to be changed. South BTS does not look at the FSN/DRT reset but uses
proprietary FSN="0" method. FSN/DRT reset has been defined in TF_SFS_RRConf.225.
RNC shall:
insert the value "0" in the FSN field and value "1" in the FSN/DRT Reset field of the first FP
frame transmitted after a call setup and
insert the value "0" in the FSN field and value "1" in the FSN/DRT Reset field of the first FP
frame transmitted after a Serving RNC relocation and
not use the value FSN field value "0" for normal frames numbering, e.g. at wraparound of
the sequence.
BTS shall:
At reception of [South BTS] value "0" in the FSN field / [North BTS] value "1" in the FSN/DRT Reset field,
BTS shall restart all the ongoing measurements performed within both FSN and DRT based congestion
detection processes for the corresponding MAC-d flow. North BTS shall ignore the FSN value "0".
Rationale: This allows to avoid unwanted congestion triggers due to the change of the DRT reference
counter and the FSN frame numbering process between the old Serving RNC and the new Serving
RNC.
Change history:
1.0.1: Specified the HSDPA congestion control reset functionality (Light CR).
NE info : RNC
BTS
Phase : Fro
Priority : M
Status : New
Deactivating the HSDPA Congestion Control
Trigger and preconditions:
Licence expires and/or

HSDPA CC is active and operator sets the management parameter HSDPACCEnabled to "Disabled".
Postcondition:
HSDPA CC is deactivated (RNC ceases to fill FSN and DRT fields in HS-DSCH Data Frames). BTS
notices this and stops the congestion control algorithm.
NE info : RNC
BTS
NetAct Configuring
Phase : Fro
Priority : M
Status : New
RAN shall support the User Buffer Size field in the HS-DSCH Data Frame and HS-DSCH Capacity
Request.
Rationale: This is used in Flow Control optimisations related to HSDPA Congestion Control.
Figure: HS-DSCH Data Frame

7 0
Header CRC FT
Frame Seq Nr CmCH-PI
MAC-d PDU Length
MAC-d PDU Length (cont) FlushSpare 1-0 Header
Num Of PDUs
User Buffer Size
User Buffer Size (cont)
Spare, bits 7-4 MAC-d PDU 1
MAC-d PDU 1 (cont) Pad
Spare, bits 7-4 MAC-d PDU n
Payload
MAC-d PDU n (cont) Pad
New IE Flags
7(E) 6 5 4 3 2 1 0
DRT
DRT (cont)
Spare Extension
Payload CRC
Payload CRC (cont)
Figure: HS-DSCH Capacity Request

Number of
Octets
7 0
1
Spare bits 7-4 CmCH-PI
1
User Buffer Size
Payload
User Buffer Size (cont) 1
Spare Extension 0-32
NE info : RNC
BTS
Phase : Fro
Priority : M
Status : New
2.1.3 2.1.3 SFS Requirements from module /WCDMA_RAN/RAN SFS
Folder/Telecom/TF_RAN_SFS_UPDT
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
2.1.3.1 2.1.3.1 Functional requirements
Requirement ID :
Feature Info :
NE info :
Phase :
Priority :
Status :
Requirement Type :
Release Latest :
Other Releases :
BTS shall indicate the congestion status to the RNC by including it to the HS-DSCH capacity
allocation
Figure. HS-DSCH Capacity Allocation
7 0
Spare Congestion
bits 7-6 CmCH-PI
Status
Maximum MAC-d PDU Length
Maximum MAC-d PDU HS-DSCH Credits

Length (cont)
HS-DSCH Credits (cont)
HS-DSCH Interval
HS-DSCH Repetition Period
Spare Extension
Valid values for Congestion Status -field:
00 No TNL Congestion
10 TNL Congestion - detected by delay build-up
11 TNL Congestion - detected by frame loss
The rate of repeating congestion indications shall be sensible if the congestion situation persists. That is,
minimum interval of sending CIs to the RNC should be approximately equal to or greater than RTT (time
until rate reduction is seen at BTS from the moment of sending the CI).
BTS shall send to the RNC a congestion indication with reason "No Congestion" after a period (defined
by BTS internal guard timer) of no congestion.
Rationale:
BTS fills this information only because it is mandatory field in Capacity Allocation.
Requirement ID : TF_SFS_UPDT.476
NE info : RNC
BTS
Phase : Fro
Priority : M
Status : New

HSDPA Congestion Control

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HSDPA Congestion Control

Uploaded by

Copyright:

Available Formats

1.

1 FEATURE TEAM WORKSPACE

0.0.1: Initial draft. Jussi Laitinen

0.1.1: Review comments corrected. Jussi Laitinen

1.0.0: Approved. Jari Taavela

2.0: Version 2.0, RU10 E1(P3) baseline version.

This module contains:

Text below subject to change based on ongoing simulations.

Maximum MAC-d PDU Length

Maximum MAC-d PDU HS-DSCH Credits

HS-DSCH Credits (cont)

HS-DSCH Repetition Period