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 : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2 1.2 Introduction Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.1 1.2.1 Scope Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.2 1.2.2 General Description Requirement ID : Requirement Version : 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 HSDSCH 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : Figure: HS-DSCH Data Frame

Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : Figure. HS-DSCH Capacity Allocation
7 Spare bits 7-6 Congestion Status CmCH-PI 0

Maximum MAC PDU Length -d Maximum MAC PDU -d Length (cont) HS-DSCH Credits

HS-DSCH Credits (cont) HS-DSCH Interval HS-DSCH Repetition Period Spare Extension

Requirement ID : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.3 1.2.3 Licencing Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.4 1.2.4 Terms and abbreviations Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : MECN FSN CC FP DRT CI Multilevel Explicit Congestion Notification Frame Sequence Number Congestion Control Frame Protocol Timestamp in each HS-DSCH Data Frame Congestion Indication

Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.5 1.2.5 Open Issues Requirement ID : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.6 1.2.6 Meeting Minutes Requirement ID : Requirement Version :

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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.7 1.2.7 Decisions Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.2.8 1.2.8 Feature Team Participants Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases :

Name Multanen Pekka Laitinen Jussi Petri Ukkola Guarnieri Mirko Tuominen Janne.K Keklinen Marko Telkkl Timo Other Contacts Taavela Jari Nauha Jukka Csaba Vulkan Helenius Janne

Role Frame Protocol SFS BTS EFS author BTS EFS co-author RNC EFS author RNC EFS author Feasibility Study author Performance Monitoring Telecom category leader Product management Simulations Simulations

Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.3 1.3 Input Material Requirement ID : Requirement Version : 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=13347753&version=current&directshow=T&id=09006c37806977b7&dmw_docbase=espoo11 Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.3.1 1.3.1 Stakeholder analysis Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.3.2 1.3.2 Input references Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 3GPP TS25.435 Transport Channel Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.3.3 1.3.3 Related features

UTRAN Iub interface user plane protocols for Common data streams

Requirement ID : Requirement Version : 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 : Requirement Version : Feature Info :

NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.4 1.4 Feature Specification Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.4.1 1.4.1 Model Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.4.2 1.4.2 External interfaces Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : Figure below present RAN external actors:
C N O S

RN A

U E

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 : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 1.4.3 1.4.3 Internal interfaces Requirement ID : Requirement Version : 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 : Requirement Version : 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 : Requirement Version :

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 : Requirement Version : 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 Multanen Pekka Frame Protocol SFS

Sipola Heikki Laitinen Jussi Tapper Toni Tuominen Janne.K Keklinen Marko Telkkl Timo Other Contacts Taavela Jari Nauha Jukka Csaba Vulkan Helenius Janne

BTS EFS BTS EFS RNC EFS RNC EFS Feasibility Study author Performance Monitoring Telecom category leader Product management Simulations Simulations

4) & 5) are used to fill the RAN performance effect -field in the RAN Focal Point Requirement ID : Requirement Version : 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 : Requirement Version : 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 Multanen Pekka Frame Protocol SFS Sipola Heikki BTS EFS Laitinen Jussi BTS EFS Tapper Toni RNC EFS Tuominen Janne.K RNC EFS Keklinen Marko Feasibility Study author Telkkl Timo Performance Monitoring Other Contacts Taavela Jari Nauha Jukka Csaba Vulkan Helenius Janne Telecom category leader Product management Simulations Simulations

4) & 5) are used to fill the RAN performance effect -field in the RAN Focal Point Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : 2. 2 SFS REQUIREMENTS FOR FEATURE RAN1110 Requirement ID : Requirement Version : Feature Info : NE info : Phase : Priority : Status : Requirement Type : Release Latest : Other Releases : HSDPA Congestion Control Requirement ID : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 : Requirement Version : 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 HSDPA Congestion Control 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 Requirement Version : 1.0.1 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS NetAct Phase : Dra Priority : M Status : New Requirement Type : REP Release Latest : RU10 Other Releases : 2.1.2 2.1.2 SFS Requirements from module /WCDMA_RAN/RAN SFS Folder/Telecom/TF_RAN_SFS_RRConf Requirement ID : Requirement Version : 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 : Requirement Version : 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 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS NetAct Configuring Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 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 : Requirement Version : 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 HSDSCH 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). Requirement ID : TF_SFS_RRConf.225 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 Other Releases : RAS07 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). Requirement ID : TF_SFS_RRConf.227 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 Other Releases : RAS07 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. Requirement ID : TF_SFS_RRConf.209 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS NetAct Configuring Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 Other Releases : RAS07 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 Header CRC Frame Seq Nr CmCH-PI 0 FT

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 MAC-d PDU n (cont)

7(E) 6 New IE Flags 5 4 3 2 1 Pad 0

Payload

DRT DRT (cont) Spare Extension Payload CRC Payload CRC (cont)

Figure: HS-DSCH Capacity Request

Number of Octets 7 0

Spare bits 7-4

CmCH-PI

1 1 Payload 1 0-32

User Buffer Size User Buffer Size (cont) Spare Extension

Requirement ID : TF_SFS_RRConf.226 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 Other Releases : RAS07 2.1.3 2.1.3 SFS Requirements from module /WCDMA_RAN/RAN SFS Folder/Telecom/TF_RAN_SFS_UPDT Requirement ID : Requirement Version : 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 : Requirement Version : 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 Spare bits 7-6 Congestion Status CmCH-PI 0

Maximum MAC PDU Length -d Maximum MAC PDU -d Length (cont) HS-DSCH Credits

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 Requirement Version : 2.0.0 Feature Info : RAN1110 HSDPA Congestion Control NE info : RNC BTS Phase : Fro Priority : M Status : New Requirement Type : FUN Release Latest : RU10 Other Releases : RAS07