1、ETSI TR 125 946 V4.0.0 (2001-03) Technical Report Universal Mobile Telecommunications System (UMTS); RAB Quality of Service Negotiation over lu (3GPP TR 25.946 version 4.0.0 Release 4) 3GPP TR 25.946 version 4.0.0 Release 4 1 Reference DTWTSGR-0325946Uv4 Keywords UMTS ETSl 650 Route des Lucioles F-O
2、6921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 O0 Fax: +33 4 93 65 47 16 Siret N“ 348 623 562 O0017 - NAF 742 C Association but non lucratif enregistre la Sous-prfecture de Grasse (06) N“ 7803/88 Important notice ETSl TR 125 946 V4.0.0 (2001-03) Individual copies of the present document c
3、an be downloaded from: hiltx/www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing c perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the
4、 reference shall be the printing on ETSl printers of the PDF version kept on a specific network drive within ETSl 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 ETSl docu
5、ments is available at hi%:i/wc%lw.esi.orBb/slatls/ If you find errors in the present document, send your comment to: editoretsi.fr Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all me
6、dia. O European Telecommunications Standards Institute 2001. All rights reserved. ETSl 3GPP TR 25.946 version 4.0.0 Release 4 2 ETSI TR 125 946 V4.0.0 (2001-03) Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The informatio
7、n pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR O00 3 14: “Intellectual Property Rights (IPRs); Essential, orpotentially Essential, IPRs notjed to ETSI in respect ofETSI standards I, which is available from the ETSI Se
8、cretariat. Latest updates are available on the ETSI Web server (-). Pursuant to the ETSI IPR Policy, no investigation, includmg IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR O00 3 14 (or the updates on the ETSI Web s
9、erver) which are, or may be, or may become, essential to the present document. Foreword This Technical Report (TR) has been produced by the ETSI 3d Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identitie
10、s or GSM identities. These should be interpreted as being references to the correspondmg ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.ordkey . ETSI 3GPP TR 25.946 version 4.0.0 Release 4 3 ETSl TR 125 946 V4.0.0 (2001-03) Contents For
11、eword 4 1 2 3 3.1 3.2 3.3 4 5 5.1 5.2 5.3 5.4 5.5 5.6 6 6.1 6.2 6.2.1 6.2.2 6.2.3 6.3 6.4 6.4.1 Scope . 5 References . 5 Definitions. symbols and abbreviations . 5 Definltlons 5 Symbols 6 Abbrevlatlons 6 . Background . 6 Requirements . 6 General requirements . 6 Scope 7 Negotiable parameters 7 Contr
12、ol of allowed negotlatlon 7 Control of needed negotlatlon 7 Backwards Compatlblllty . 7 . . Study Areas . 7 Negotiable parameters 7 Control of allowed negotlatlon . 8 General . 8 Scenario 1 . 8 Scenario 2 . 9 Mechanisms for negotlatlon . 10 Specification Impact and associated Change Requests 11 RANA
13、P specification 11 11 6.4.1.1 Impacts . 11 6.4.1.1.1 RAB ASSIGNMENT REQUEST . 11 6.4.1.1.2 RAB ASSIGNMENT RESPONSE . 11 7 Study Areas regarding possible extensions to the W1 . 11 7.1 RAB QoS Negotlatlon at relocation 11 7.1.1 Message sequence chart related to RAB QoS negotiation during Relocation 11
14、 7.1.2 What should be considered? . 13 7.1.3 The timing of switching the user plane in the CN nodes 14 7.1.4 Evaluate if it can be included in RAB QoS Negotiation Working Item . 14 7.1.5 Open issues . 14 7.1.6 Specification Impact and associated Change Requests 14 . 8 Agreements and associated agree
15、d contributions 16 8.1 Negotiable parameters 16 8.2 Not negotiable parameters 16 9 Relation and communication with other groups 16 Annex A: Change history 18 ETSl 3GPP TR 25.946 version 4.0.0 Release 4 4 ETSl TR 125 946 V4.0.0 (2001-03) Foreword This Technical Specification has been produced by the
16、3d Generation 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 change of relea
17、se date and an increase in version number as follows: Version x.y.z where : x the fiist digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indxates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. t
18、echnical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSl 3GPP TR 25.946 version 4.0.0 Release 4 5 ETSl TR 125 946 V4.0.0 (2001-03) 1 Scope The present document gives a presentation of the current statu
19、s of the Work Item “RAB Quality of Service Negotiation over Iu“ within TSG RAN WG3. It describes requirements, additional studies needed, and agreements reached so far for the Work Item. It identifies the affected specifications. It also describes the schedule of the Work Task. If information needs
20、to be communicated to groups outside of TSG RAN WG3, this is also indicated. The document is a living document, i.e. it is continuously updated and presented to all TSG-RAN meetings. 2 References The following documents contain provisions which, through reference in this text, constitute provisions
21、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. In the case of a reference to a 3G
22、PP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as theyresent document. Il 3G TS 25.413: “3dGeneration Partnership Project (3GPP) Technical Specification Group Radio L21 RAB Quality of Service Negotiation o
23、ver Iu, Work Item Description, TSG-RAN#7 RP-000137 Access Network; ; UTRAN Iu Interface RANAP Signalling (Release 1999)“. 31 3G TS 24.008: “3rd Generation Partnership Project (3GPP) Technical Specification Group Core Network; Mobile Radio Interface Layer 3 Specification; Core Network Protocols Stage
24、 3 (Release 1999)“. 3G TS 25.33 1: “3rd Generation Partnership Project (3GPP) Technical Specification Group Radio Access Network; RRC Protocol Specification (Release 1999)“. 3G TS 25.423: “3rd Generation Partnership Project (3GPP) Technical Specification Group Radio Access Network; UTRAN Iur Interfa
25、ce RNSAP Signalling (Release 1999)“. 3G TS 25.433: “3rd Generation Partnership Project (3GPP) Technical Specification Group Radio Access Network; UTRAN Iub Interface NBAP Signalling (Release 1999)“. 3G TS 29.060: i3rd Generation Partnership Project (3GPP) Technical Specification Group Core Network ;
26、 General Packet Radio Service (GPRS); GPRS Tunneling Protocol (GTP) across the Gn and Gp Interface (Release 1999)“. 3 Definitions, symbols and abbreviations 3.1 Definitions None. ETSl 3GPP TR 25.946 version 4.0.0 Release 4 6 ETSl TR 125 946 V4.0.0 (2001-03) 3.2 None 3.3 Symbols Abbreviations For the
27、 purposes of the present document, the following abbreviations apply: cc CN CS DRNC PDP PS QOS RAB RANAP RB RNC SDU SM SRNC UE UTRAN Call Control Core Network Circuit Switched Drift RNC Packet Data Protocol Packet Switched Quality of Service Radio Access Bearer Radio Access Network Application Part
28、Radio Bearer Radio Network Controller Service Data Unit Session Management Serving RNC User Equipment Universal Terrestrial Radio Access Network 4 Background The general idea behind the RAB QoS negotiation is to have a solution for the following situation: A user is asking for a service with syeciji
29、ed QoSyarameters, but for some reason (e.g. resources not available) the system can not fuljil the requestyrecisely, even though an almost matching bearer would be available. The inability to provide the requested RAB most likely causes the service to fail, leaving the user without service, and the
30、operator without the revenue from the service. Clearly, if the user had accepted the bearer with the available resources rather than having no service at all, it would have been a common benefit to do so. Many of the applications expected to be used in 3G would be able to use alternative QoS paramet
31、ers, e.g. most data, voice and video applications can be operated at different data rates. It also seems that in many situations the user would rather have taken the connection with compromised QoS rather than no connection, simply to save another try. Also in many cases the time consumed by making
32、another try would overrun the time it takes to complete some simple tasks with the compromised QoS parameters. The concern of the operator is that the user might be annoyed if the connection doesnt go through with one try, and will not try again at all, and might ultimately change service provider.
33、5 Requirements 5.1 General requirements The chosen solution for RAB QoS Negotiation shall: - be a simple solution - not cause any significant delay in the RAB Assignment procedure - be a generic solution common for both the PS and the CS domain ETSl 3GPP TR 25.946 version 4.0.0 Release 4 7 ETSl TR 1
34、25 946 V4.0.0 (2001-03) 5.2 Scope RAB QoS Negotiation shall, according to 2 be possible to do: - at RAB establishment Any changes to this scope need to be approved by TSG-RAN. (See 7.) 5.3 Negotiable parameters The parameters agreed to be negotiable shall be based on the Re14 set of RAB parameters.
35、The number of negotiable parameters shall be kept to as few as possible, since the negotiation will become complicated if several parameters are involved and since also combinations of these parameters then need to be considered. 5.4 Control of allowed negotiation From Iu point of view, it is the CN
36、 that decides that RAB QoS Negotiation is allowed for one or more parameters. 5.5 Control of needed negotiation The RNC shall, based on the current resource situation and on the information received from the CN, decide if RAB QoS Negotiation shall be done. If a RAB with parameter values within the l
37、imits given by the CN can be provided by the RNC, the RAB Assignment procedure shall be reported as successfl to the CN. Otherwise it shall be reported as failed. 5.6 Backwards Compatibility 6 Study Areas 6.1 Negotiable parameters If any more parameters than the one(s) already agreed to be negotiabl
38、e (see 8.1) shall be included needs to be studied. The following figure gives an indication of what parameters out of the R99 set that could be considered: invariable service parameters (possible) variable service parameters traffic class SDU format information SDU size asymmetry indicator guarantee
39、d bitrate delivery order maximum bitrate SDU error ratio residual bit error ratio Delivery of erroneous SDUs I transfer delay traffic handling priority allocation/retention priority source statistics descriptor ETSl 3GPP TR 25.946 version 4.0.0 Release 4 8 ETSl TR 125 946 V4.0.0 (2001-03) 6.2 Contro
40、l of allowed negotiation 6.2.1 General Two different solutions for control of negotiation has been defined, one with negotiation information from the CN and one without. These are presented below as scenario 1 and scenario 2. Common for both scenarios is that the CN indicates to the RNC which parame
41、ters that are negotiable. 6.2.2 Scenario 1 In the CN side, the requested RAB parameters are mapped in a fairly straight forward manner from the QoS parameters used at CC/SM level, and CN does not have any other essential information than what the RNC has. Only the applicationher has this information
42、. To assure that there is no need for trial-and-error method based on educated guesses at any protocol layednetwork element, the necessary information should be made available by the applicationhhe user, and it should be conveyed by both CC/SM and RANAP 11 protocols. The possibility of this needs to
43、 be studied. Any changes to the CC/SM protocols are, however, outside the scope of TSG-RAN3, why input from other relevant groups will be needed. It must also be noted that solutions requiring changes to the CC/SM protocols may prohibit the use of RAB QoS Negotiation together with R99 mobiles. ETSl
44、3GPP TR 25.946 version 4.0.0 Release 4 9 ETSl TR 125 946 V4.0.0 (2001-03) f kctivate PDP Conte resource not Activate PDP Con - Location UDdate I I Insert Subscriber D:.ta f3ubscribed QoS wi;h Guaranteed bit rate, max bitrate) Insert Subscriber D:.ta Ack b Update Location Ack L J I Request RAB Assign
45、ment ?Requested RAI3 Qol3) Rec.uest P b RAB Assignment Qklooserz) (Negotiated RAB Recuest Response Create PDP Context Ibesponse Create PDP Context Request :xt Accept Figure 1 RAB QoS Negotiation during RAB Establishment for PS domain 6.2.3 Scenario 2 The following dagram shows an example of how QoS
46、negotiation can be achieved on the Iu interface with the following principles: - no change of the current SM signalling from R99 - HLR information is used by the SGSN as done in R99 - Guaranteed bit rate used over the Iu is negotiable by the RNC. This is indicated by the CN in the RAB assignment req
47、uest. This indication from the CN is not in the R99 specifications. - If the RNC can not offer the requested guaranteed bit rate, the RNC indicates this to the CN in the RAB assignment response. This is a change from the R99 specifications since the response has to include the available guaranteed b
48、it rate. ETSl 3GPP TR 25.946 version 4.0.0 Release 4 10 ETSl TR 125 946 V4.0.0 (2001-03) - The SGSN indicates the negotiated bandwith range to the UE by using the “Activate PDP context accept” messages. Update location I Insert Subscriber Data Subscribed QoS with Guaranteed bit rate, Max bit rate 4
49、Update location ack D Activate PDP context request Guaranteed bit rate, Max bit rate RAB Assignment request Guaranteed bit rate marked as negotiable a RAB Assignment response Available Guaranteed bit rate Activate PDP context accept Negotiated Guaranteed bit rate, Max b.t rate b I Figure 2: RAB QoS Negotiation during RAB Establishment Note that using the same call flow, the SGSN could also query a Network management entity before deciding on which value to use to set the Guaranteed bit rate that it requests from the RNC. Also note that the HLR and the mobile
