1、 ETSI TR 125 902 V7.1.0 (2007-03)Technical Report Universal Mobile Telecommunications System (UMTS);Iub/Iur congestion control (3GPP TR 25.902 version 7.1.0 Release 7)ETSI ETSI TR 125 902 V7.1.0 (2007-03) 1 3GPP TR 25.902 version 7.1.0 Release 7 Reference RTR/TSGR-0325902v710 Keywords UMTS ETSI 650
2、Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Individual copies of the present document can be downloa
3、ded from: http:/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference s
4、hall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is ava
5、ilable at http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following services: http:/portal.etsi.org/chaircor/ETSI_support.asp Copyright Notification No part may be reproduced except as authorized by written permission. The
6、 copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2007. All rights reserved. DECTTM, PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members. TIPHONTMand the TIPHON logo are Trade Marks curre
7、ntly being registered by ETSI for the benefit of its Members. 3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 2 3GPP TR 25.902 version 7.1.0 Release 7 Intellectual Property Rights IPRs essential o
8、r potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Ess
9、ential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http:/webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI
10、. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Pro
11、ject (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities c
12、an be found under http:/webapp.etsi.org/key/queryform.asp. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 3 3GPP TR 25.902 version 7.1.0 Release 7 Contents Intellectual Property Rights2 Foreword.2 Foreword.4 1 Scope 5 2 References 5 3 Definitions, symbols and abbreviations .5 3.1 Definitions5 3.2 Symbols5 3.
13、3 Abbreviations .6 4 Background and introduction .6 5 Requirements6 6 Study areas .7 6.1 Background information.7 6.1.1 Introduction.7 6.1.2 Example 1: TFRC .7 6.1.3 Example 2: “ABR like“ congestion control 7 6.2 Functional description 7 6.2.1 Iub/Iur congestion detection .7 6.2.2 Iub/Iur congestion
14、 reduction.8 6.2.3 A similar solution for HSDPA .9 6.2.4 Handling of the Iur10 6.2.4.1 Iub pipe philosophy.10 6.2.4.2 Iub Cloud philosophy11 6.2.4.3 Co-existence of the two philosophies11 6.3 Impacts on Iub/Iur control plane protocols.12 6.4 Impacts on Iub/Iur user plane protocols .12 6.5 Open issue
15、s.12 6.6 Backwards compatibility12 7 Agreements and associated contributions 12 8 Specification impact and associated Change Requests 13 Annex A: Change history 14 History 15 ETSI ETSI TR 125 902 V7.1.0 (2007-03) 4 3GPP TR 25.902 version 7.1.0 Release 7 Foreword This Technical Report has been produc
16、ed by the 3rdGeneration Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying chang
17、e of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substan
18、ce, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 5 3GPP TR 25.902 version 7.1.0 Release 7 1 Scope The present document is part of the Release 6 work i
19、tem “FDD Enhanced Uplink“. The purpose of the present document is to help the TSG RAN WG3 group to specify the changes to existing Iub/Iur specifications, needed for the introduction of “Iub/Iur Congestion Control“ measures for Release 6. This work task belongs to the TSG RAN Building Block “FDD Enh
20、anced Uplink: UTRAN Iub/Iur Protocol Aspects“, and as such this document is expected to be completed within the Release 6 timeframe. This document also includes 3.84 Mcps TDD Enhanced Uplink which is part of the Release 7 work item “3.84 Mcps Enhanced Uplink”. This document also includes 7.68 Mcps T
21、DD Enhanced Uplink which is part of the Release 7 work item “7.68 Mcps Enhanced Uplink”. This document also includes 1.28 Mcps TDD Enhanced Uplink which is part of the Release 7 work item “1.28 Mcps Enhanced Uplink“. 2 References The following documents contain provisions which, through reference in
22、 this text, constitute provisions of the present document. References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific. For a specific reference, subsequent revisions do not apply. For a non-specific reference, the latest version applies.
23、In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. 1 void. 2 void. 3 void. 4 void. 3 Definitions, symbols and abbreviations 3.1 Definitions For the pu
24、rposes of the present document, the following terms and definitions apply: E-DCH: Enhanced DCH, a new dedicated transport channel type or enhancements to an existing dedicated transport channel type. 3.2 Symbols For the purposes of the present document, the following symbols apply: void ETSI ETSI TR
25、 125 902 V7.1.0 (2007-03) 6 3GPP TR 25.902 version 7.1.0 Release 7 3.3 Abbreviations For the purposes of the present document, the following abbreviations apply: CFN Connection Frame Number DRT Delay Reference Time FSN Frame Sequence Number HSDPA High Speed Downlink Packet Access RFN RNC Frame Numbe
26、r RNL Radio Network Layer SFN System Frame Number TNL Transport Network Layer 4 Background and introduction In RAN Plenary Meeting #27, it was agreed to create a Technical Report on the subject of “Iub/Iur congestion control (Rel-6)“. The technical objective of this TR is to improve the Congestion H
27、andling performance of the UTRAN over the Iub and the Iur interfaces. Any solution should take into account backwards compatibility aspects. This work item is applicable to UTRA FDD only. In a similar manner the work items for enhanced uplink for 3.84 Mcps TDD and 7.68 Mcps TDD also lead to the need
28、 to improve the Congestion Handling over the Iub and Iur interfaces. In a similar manner the work item for enhanced uplink for 1.28 Mcps TDD also leads to the need to improve the Congestion Handling over the Iub and Iur interfaces. 5 Requirements For Iub/Iur Congestion Controlled, the following requ
29、irements were agreed in RAN3: - RNC shall have a means for detecting congestion. - Receiving node shall have a means for notifying the source of congestion i.e. sending node, that congestion has occurred. - Iub/Iur Congestion control for both HSDPA and Enhanced Uplink should if possible employ simil
30、ar solutions. - The development of an Iub/Iur congestion control solution should bear in mind both the existing HSDPA and soon to be completed Enhanced Uplink features. - Any solution should take into account backwards compatibility aspects. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 7 3GPP TR 25.902 ver
31、sion 7.1.0 Release 7 6 Study areas 6.1 Background information 6.1.1 Introduction There are many types of congestion control mechanisms, the main groups are window based, rate based or combination of both. The method often used for congestion detection is the method based on the loss of packets. Othe
32、r methods appropriate for congestion detection are: packet delay, average queue and rate difference. Different congestion control algorithms might be used for IP network and ATM network respectively. It is known, that in IP network as a congestion control protocol mostly TCP is used, so to ensure fa
33、irness and other quality congestion control parameters, TCP like congestion control protocol should be used. TFRC protocol (TCP-Friendly Rate-based congestion Control protocol), as one of the many examples, which intends to compete fairly for bandwidth with TCP flows, could be named. 6.1.2 Example 1
34、: TFRC Congestion Factor depends on the congestion control algorithm, and on the congestion detection method. By detecting the loss of packets and using some method to derive RTT, transmit rate could be prepared according to transmit rate formula X = f(s, RTT, p) where s is the packet size in bytes/
35、second, RTT the round trip time in seconds, p is the loss event rate (based on the packet loss derived from the congestion detection). Congestion Factor depends on the computed data rate X. The Credit, Interval and Repetition Period of FC Allocation message will be influenced by computed Congestion
36、Factor in Congestion Control and the message Capacity Allocation with modified IEs will be sent to RNC. 6.1.3 Example 2: “ABR like“ congestion control “ABR like“ congestion control has “additive increase, exponential decrease“ type of algorithms. Different formulas exist for computing ACR (Allowed C
37、ell Rate) for increase and for decrease. ACR i.e. current transmission rate in cell/s, should be computed in octets or in number of MAC-d PDUs. Then from the computed ACR, by a given HS-DSCH Interval, HS-DSCH Credits can be derived, because ACR is equal to Credits divided by Interval. Capacity Alloc
38、ation message will be sent to RNC. 6.2 Functional description 6.2.1 Iub/Iur congestion detection The Node B scheduler decides on when and with which bit rate each and every UE is allowed to transmit in the cell. Each received MAC-es PDU is placed in a frame protocol data frame and sent to the SRNC (
39、in some cases several PDUs are bundled into the same data frame). For each data frame, the Node B attach the following information: A reference time, that gives an indication on when the frame was sent. A sequence number, that gives an indication on which frame this is in relation to other data fram
40、es. At the reception of the data frames the SRNC can do the following: With the use of the reference time, the SRNC can compare the relative reception time with the relative transmission time (the reference time included in the data frame). With that information the SRNC can detect if there is a del
41、ay build-up in the transmission path. A delay build-up is an indication on that frames are being queued due to overload in the transport network. With the use of the sequence number, the SRNC can detect a frame loss. A frame loss is an indication that packets have been lost in the transport network
42、due to overload reasons. This procedure is illustrated in Figure 1. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 8 3GPP TR 25.902 version 7.1.0 Release 7 RNC Node B Node BUL Data Flow Congestion Detection Figure 1: Iub/Iur Congestion Detection 6.2.2 Iub/Iur congestion reduction When the RNC has detected th
43、at there is a congestion situation in the transport network, it needs to inform the Node B that this is the case. This is done by means of a frame protocol control frame, in which the Node B is informed about the congestion situation. This control frame will be called Congestion Indication. This is
44、illustrated in Figure 2. RNC Node B Node B UL Data Flow Congestion Status Figure 2: Iub/Iur Congestion Indication As the RNC can detect congestion in two different ways, there exist no motivation why such information should not be communicated to the Node B. For that reason the Congestion Indication
45、 Control Frame can take the following values: “Congestion detected by frame loss“, “Congestion detected by delay build-up“, and “No congestion“. At the reception of the Congestion Indication control frame, the Node B should reduce the bit rate on the Iub interface. The exact algorithm the Node B sho
46、uld use is outside the scope of the specifications, but the specifications should address the expected behaviour of the Node B. Such behaviour should include: At the reception of a congestion indication control frame indicating “congestion“ the Node B should reduce the bit rate for at least the MAC-
47、d flow on which the congestion indication control frame was received. At the reception of a congestion indication control frame indicating “no congestion“ the Node B can gradually go back to normal operation. If the Node B has not received a congestion status control frame indicating congestion for
48、the last X seconds, the Node B can gradually go back to normal operation. The value of the parameter X is configured by higher layers. Editors note: Whether the third bullet above should be included in the specifications is an open issue. This level of specification of the Node B behaviour is suffic
49、ient, for the following reasons: 1 The purpose of the congestion control, is not to act as a flow control but rather as an “emergency break“ in order to keep the system at a stable state. ETSI ETSI TR 125 902 V7.1.0 (2007-03) 9 3GPP TR 25.902 version 7.1.0 Release 7 2 The output bit rate from the node B depends on many things, for example radio interference, distance from mobile to Node B, available hardware resources etc. The Node B scheduler will need to take all that into consideration when assigning the bit rate to each mobile. 3 Perf
