1、 ETSI TR 126 959 V15.0.0 (2018-07) 5G; Study on enhanced Voice over LTE (VoLTE) performance (3GPP TR 26.959 version 15.0.0 Release 15) TECHNICAL REPORT ETSI ETSI TR 126 959 V15.0.0 (2018-07)13GPP TR 26.959 version 15.0.0 Release 15Reference DTR/TSGS-0426959vf00 Keywords 5G ETSI 650 Route des Luciole
2、s 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 The present document can be downloaded from: http:/www.etsi.org/standards
3、-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents be
4、tween such versions and/or in print, the only prevailing document is the print of the Portable Document Format (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. Infor
5、mation on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright
6、Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyr
7、ight and the foregoing restriction extend to reproduction in all media. ETSI 2018. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETMare trademarks of ETSI registered for the benefit of its Members and
8、of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSMand the GSM logo are trademarks registered and owned by the GSM Association. ETSI ETSI TR 126 959 V15.0.0 (2018-07)23GPP TR 26.959 version 15.0.0 Release 15Intellectual Property Rights Essential patents
9、IPRs essential or potentially essential to normative deliverables 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,
10、or potentially Essential, 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 (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by
11、ETSI. 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. Trademarks The present document may include trademarks and/or tradenames which are asser
12、ted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement b
13、y ETSI of products, services or organizations associated with those trademarks. Foreword This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities
14、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 can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In the present document “should“, “should not
15、“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TR 126 9
16、59 V15.0.0 (2018-07)33GPP TR 26.959 version 15.0.0 Release 15Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 5g3Introduction 5g31 Scope 6g32 References 6g33 Definitions and abbreviations . 7g33.1 Definitions 7g33.2 Abbreviations . 7g34 Overview 7g34.1 Int
17、roduction 7g34.2 UE-based and Network-based Architectures 7g34.2.1 Network-based Architecture . 7g34.2.2 UE-based Architecture 8g35 Parameters for SRVCC Handover Thresholds . 8g35.1 Description . 8g35.2 Potential Solutions 8g35.2.1 Robustness Indication . 8g35.2.1.1 Maximum Packet Loss Rate (PLR) .
18、8g35.2.1.1.1 General 8g35.2.1.1.2 Max PLR recommendation without Application Layer Redundancy 8g35.2.1.1.3 Max PLR recommendation with Application Layer Redundancy . 9g35.3 Conclusion 10g36 Codec Mode Adaptation Procedures 11g36.1 Description . 11g36.2 Potential Solutions 11g36.2.1 Adaptation to Pac
19、ket Loss 11g36.3 Conclusion 11g37 Adaptation Capability Indication . 11g37.1 Description . 11g37.2 Potential Solutions 11g37.2.1 SDP Indication 11g37.2.2 Application Layer Redundancy Adaptation Request 12g37.2.2.1 General 12g37.2.2.2 Signal method 1: RTCP-APP 13g37.2.2.3 Signal method 2: RTP CMR usi
20、ng the Reserved CMR codepoints 13g37.2.2.4 Signal method 3: Padding . 14g37.2.2.5 Signal method 4: RTP header extension . 15g37.2.3 Considerations on the impact of packet loss on adaptation requests 15g37.3 Conclusion 16g38 Impact of JBM and PLC on Handover Thresholds 16g38.1 Description . 16g38.2 P
21、otential Solutions 16g38.2.1 General 16g38.2.2 UE-requested UL and DL PLR . 17g38.2.2.1 General 17g38.2.2.2 Simple Ratio 17g38.2.2.3 SDP-Negotiated 18g38.2.2.4 Dynamic Allocation of UL PLR and DL PLR 19g38.2.3 Network-requested UL and DL PLR 29g3ETSI ETSI TR 126 959 V15.0.0 (2018-07)43GPP TR 26.959
22、version 15.0.0 Release 158.2.3.1 General 29g38.2.3.2 Simple Ratio 29g38.2.3.3 SDP-Negotiated 30g38.2.3.4 PCRF-Negotiated 30g38.2.3.5 PCRF-Negotiated using single SDP parameter . 31g38.2.3.6 Dynamic Allocation of UL PLR and DL PLR 31g38.3 Conclusion 31g39 Conclusions 32g3Annex A: Informal Objective a
23、nd Subjective Experiments for Obtaining Max. PLR Operating Points with and without Application Layer Redundancy . 33g3Annex B: Change history 36g3History 37g3ETSI ETSI TR 126 959 V15.0.0 (2018-07)53GPP TR 26.959 version 15.0.0 Release 15Foreword This Technical Report has been produced by the 3rd Gen
24、eration 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 release dat
25、e 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 substance, i.e. technic
26、al enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. Introduction Voice-over-LTE (VoLTE) may require better LTE Reference Signal Received Power (RSRP) compared to data service, i.e. while the LTE radio signal
27、 may be good enough for pure data session, it may not be reliable enough for VoLTE services. In scenarios where the radio network is dimensioned for data services, eNB may trigger SRVCC handover to CS, e.g. when the UE falls into marginal or weak LTE coverage or when an EPS bearer with QCI-1 reliabi
28、lity is not sufficiently met. In certain network dimensioning, the VoLTE coverage border may be a function of the selected codec and its selected configuration, its rate and mode adaptation, and potentially the applied application layer redundancy, as well as the required QoS of the VoLTE bearer. In
29、 these cases, legacy RAN might unnecessarily hand over fairly good VoLTE calls to 2G/3G CS via SRVCC HO, because it is unaware of the robustness of the selected codec. Radio Resource Management functions could potentially avoid unnecessary SRVCC HOs, if appropriate information is made available. TS
30、26.114 (which is used as basis for the GSMA IR.92 VoLTE profile) includes several tools for increased robustness of speech calls with initial selection of Codecs and their Configuration and in-call dynamic rate and mode adaptation and maybe application layer full redundancy. EVS, especially the EVS
31、Channel Aware mode, demonstrates higher robustness against transmission errors than AMR and AMR-WB codecs by application-layer partial redundancy. The present document investigates possible solutions to maintain voice quality on LTE as high as possible and by that avoiding or at least delaying SRVCC
32、 as much as possible and by that minimize the negative impact on user experience for VoLTE subscribers in areas with weak LTE coverage. ETSI ETSI TR 126 959 V15.0.0 (2018-07)63GPP TR 26.959 version 15.0.0 Release 151 Scope The present document provides a study on the enhanced VoLTE performance (eVoL
33、P). The study focuses on: - Guidelines or requirements to ensure that MTSI clients send requests to adapt to robust modes of codec operation when necessary. This study may require investigating performance results for different conditions and adaptation procedures. - Mechanisms to indicate at setup
34、a terminals ability to send adaptation triggers (e.g. to adapt to the most robust codec mode). - Evaluate the impact of proprietary client implementations of Packet-Loss Concealment and Jitter Buffer Management (JBM) on having different Max PLR and potential mechanisms to indicate this to the networ
35、k. 2 References The following documents contain provisions which, through reference in 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, sub
36、sequent revisions do not apply. - For a non-specific reference, the latest version applies. 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 3GPP
37、TR 21.905: “Vocabulary for 3GPP Specifications“. 2 3GPP TR 21.952: “Codec for Enhanced Voice Services (EVS); Performance characterization“. 3 3GPP TS 26.114: “IP Multimedia Subsystem (IMS); Multimedia telephony; Media handling and interaction“. 4 3GPP TS 26.445: “Codec for Enhanced Voice Services (E
38、VS); Detailed algorithmic description“. 5 3GPP TS 36.331: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification“ 6 IETF RFC 4585 (2006): “Extended RTP Profile for Real-time Transport Control Protocol (RTCP) - Based Feedback (RTP/AVPF)“, J. Ott, S.
39、 Wenger, N. Sato, C. Burmeister and J. Rey. 7 Rep. ITU-R M.2135: “Guidelines for evaluation of radio interface technologies for IMT-Advanced“, 2008. 8 3GPP TS 23.203: “Policy and charging control architecture“. 9 3GPP TS 23.401: “General Packet Radio Service (GPRS) enhancements for Evolved Universal
40、 Terrestrial Radio Access Network (E-UTRAN) access“. 10 3GPP TR 23.759: “Study for enhanced Voice Over LTE (VoLTE) Performance“. 11 GSMA IR.92 (06/2017): “IMS Profile for Voice and SMS v11.0“. 12 IETF RFC 4867: “RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptiv
41、e Multi-Rate Wideband (AMR-WB) Audio Codecs“, J. Sjoberg, M. Westerlund, A. Lakaniemi, Q. Xie. 13 IETF RFC 3550 (2003): “RTP: A Transport Protocol for Real-Time Applications“, H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson. ETSI ETSI TR 126 959 V15.0.0 (2018-07)73GPP TR 26.959 version 15.0.
42、0 Release 153 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 1 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPP TR 21.905 1
43、. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in 3GPP TR 21.905 1 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 3GPP TR 21.905 1. DL Downlink (from eNB to UE)
44、eVoLP Enhanced VoLTE performance JBM Jitter buffer management Max. PLR Maximum end-to-end packet loss rate PLR Packet loss rate UL Up-link (from UE to eNB) 4 Overview 4.1 Introduction 4.2 UE-based and Network-based Architectures 4.2.1 Network-based Architecture The network-based solution relies on t
45、he fact that the information on the negotiated codecs and configurations (or codec modes) for the session is available in the PCRF through its knowledge of the SDP that contains the negotiated session parameters. Based on such information, the PCRF can derive the relevant robustness parameter inform
46、ation (e.g. Maximum Packet Loss Rate) and signal this information to the eNB, using the procedures defined in TS 23.203 8 and TS 23.401 9. The derivation of the robustness parameter information based on the negotiated codec modes can be performed subject to a standardized mapping rule, e.g. with an
47、indication of packet loss rate for each codec mode and calculation of the Maximum Packet Loss Rate based on the negotiated codec modes. The network-based solution is depicted in Figure 4.1. In this solution, the PCRF by default does not know the MTSI client adaptation behavior, and would therefore s
48、et the robustness parameter (e.g. Maximum Packet Loss Rate) based on the least robust codec mode among the negotiated codec configurations. If however the PCRF knows from the SDP that the MTSI client receiver supports adaptation to the most robust codec mode, i.e. that the UE will request the sender
49、 to change its encoder to a more robust mode when it detects packet losses, then the PCRF could set the robustness parameter based on the most robust codec mode, and thereby potentially enabling enhanced optimized SRVCC handover performance. Such indication to the PCRF is enabled via the new SDP parameter adapt, see clause 7.2.1 for further details. Figure 4.1: Network-based solution to signal robustness information to eNB ETSI ETSI TR 126 959 V15.0.0 (2018-07)83GPP TR 26.959 version 15.0.0 Release 154.2.2 UE-based Architecture The UE-b
