1、 ETSI TR 129 994 V15.0.0 (2018-07) Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Recommended infrastructure measures to overcome specific Mobile Station (MS) and User Equipment (UE) faults (3GPP TR 29.994 version 15.0.0 Release 1
2、5) TECHNICAL REPORT ETSI ETSI TR 129 994 V15.0.0 (2018-07)13GPP TR 29.994 version 15.0.0 Release 15Reference RTR/TSGC-0129994vf00 Keywords GSM,LTE,UMTS ETSI 650 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 7
3、42 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-search The present document may be made available in electronic versions and/or in print. The content of any electronic a
4、nd/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 between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) versi
5、on 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 available at https:/portal.etsi.org/TB/ETSIDeliverableSta
6、tus.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 Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photoc
7、opying 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 copyright and the foregoing restriction extend to reproduction in all media. ETSI 2018. All rights reserved. DECTTM, PLUGTESTST
8、M, 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 of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSMand the GSM logo are trad
9、emarks registered and owned by the GSM Association. ETSI ETSI TR 129 994 V15.0.0 (2018-07)23GPP TR 29.994 version 15.0.0 Release 15Intellectual Property Rights Essential patents IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information pertaini
10、ng 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 Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretaria
11、t. 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 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
12、 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 asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the p
13、roperty 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 by ETSI of products, services or organizations associated with those trademarks. Foreword This Technical Report (TR) has be
14、en produced by ETSI 3rd Generation Partnership Project (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 refer
15、ence 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“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI
16、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 129 994 V15.0.0 (2018-07)33GPP TR 29.994 version 15.0.0 Release 15Contents Intellectual Property Rights 2g3Foreword . 2g3Modal
17、verbs terminology 2g3Foreword . 5g31 Scope 6g32 References 6g33 Abbreviations . 6g34 General . 6g35 Specific implementation on the radio interface 7g35.1 Handovers and “Synchronisation Indication“ . 7g35.1.1 Justification . 7g35.1.2 Solution . 7g35.2 “Directed Retry“ type Handovers . 7g35.2.1 Justif
18、ication . 7g35.2.2 Solution . 7g35.3 Cell broadcast and frequency hopping . 8g35.3.1 Justification . 8g35.3.2 Solution . 8g35.4 Handling of Phase 2 and Phase 2+ BCCH Messages . 8g35.4.1 Justification . 8g35.4.2 Solution . 8g35.5 Handling of Phase 2 and Phase 2+ SACCH Messages . 8g35.5.1 Justificatio
19、n . 8g35.5.2 Solution . 8g35.6 Handling of assignment message using Mobile Allocation IE including ARFCN=0 9g35.6.1 Justification . 9g35.6.2 Solution . 9g35.7 Hopping sequence generation including ARFCN=0 9g35.7.1 Justification . 9g35.7.2 Solution . 9g35.8 QoS IE length between R97 and R99 implement
20、ations . 9g35.8.1 Justification . 9g35.8.2 Solution . 9g35.9 MS unable to handle the LOCATION UPDATING ACCEPT, ATTACH ACCEPT and ROUTING AREA UPDATE ACCEPT messages when the EPLMN Lists IE is included 10g35.9.1 Justification . 10g35.9.2 Solution . 10g35.10 MS unable to handle messages when the trunc
21、ation function is used 10g35.10.1 Justification . 10g35.10.2 Solution . 10g35.11 Roaming restrictions issues with reject cause #13 and #15 11g35.11.1 Justification . 11g35.11.2 Solution . 11g36 Use of VAD/DTX in conjunction with frequency hopping for a speech call 11g36.1 Scope 11g36.2 General . 12g
22、36.3 Implementation options to reduce the occurance of undetected bad frames by utilising normal system features . 12g36.3.1 Number of frequency hopping channels . 12g36.3.2 Frequency hopping type 12g36.3.3 Continuous SID frames on C0 13g36.4 Implementation options to reduce the occurance of undetec
23、ted bad frames by changing normal system operation . 13g3ETSI ETSI TR 129 994 V15.0.0 (2018-07)43GPP TR 29.994 version 15.0.0 Release 156.4.1 Changing the training sequence of the dummy burst to a new (ninth) training sequence . 13g36.4.2 Using an alternative training sequence out of the eight assig
24、ned 13g36.4.3 Setting the stealing flag for the bits transmitted which are not intended to be part of the TCH . 13g36.4.4 Sending partial SID frames on C0 13g36.5 Tested Combinations 14g36.5.1 “Normal“ system. 14g36.5.2 New training sequence 14g36.5.3 Alternative training sequence from the eight ass
25、igned . 14g36.5.4 Setting stealing flag for unintentionally transmitted bits 15g36.5.5 Setting stealing flag for unintentionally transmitted bits and modifying training sequence for Dummy Bursts 15g36.5.6 Sending partial SID information on C0 15g3Annex A: Amendment Request 08.08 - 021 R4: Informatio
26、n on channel in use in HO REQUEST . 17g3A.3.1.5.1.1 Generation of the HANDOVER REQUIRED message 17g3A.3.1.5.2 Handover Resource allocation 18g3A.3.1.5.2.1 Operation of the procedure 18g3A.3.2.1.8 HANDOVER REQUEST . 19g3A.3.2.1.9 HANDOVER REQUIRED . 20g3A.3.2.2.49 CURRENT CHANNEL 21g3Annex B: Change
27、History . 23g3History 24g3ETSI ETSI TR 129 994 V15.0.0 (2018-07)53GPP TR 29.994 version 15.0.0 Release 15Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may
28、 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 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
29、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. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporate
30、d in the document. ETSI ETSI TR 129 994 V15.0.0 (2018-07)63GPP TR 29.994 version 15.0.0 Release 151 Scope The present document clarifies recommended measures which may be adopted by 3GPP infrastructure utilising GSM or GERAN as access network to enable inter-working to be obtained between network an
31、d various User Equipment (UE) implementations of the 3GPP specification. The objective is to obtain compatibility without changing the consolidated set of specifications. The present document describes the recommended changes to the infrastructure to cater for specific faults within some types of UE
32、. The lifetime of the herein described measures together with their potential impact on optimal network performance is out of the scope of the present document. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present documen
33、t. 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 3GPP document (including
34、 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 TR 21.905: “ Vocabulary for 3GPP Specifications“. 2 3GPP TS 04.08 (Phase 1): “Mobile radio interface layer 3 specification Part 1: Generic“. 3 3GPP
35、TS 04.08 (Phase 2): “Mobile radio interface layer 3 specification“. 4 3GPP TS 04.08 (Phase 2+): “Mobile radio interface layer 3 specification“. 5 3GPP TS 05.05 (Phase 2): “Radio Performance Aspects. 6 3GPP TS 05.05 (Phase 2+): “Radio Performance Aspects. 7 3GPP TS 24.007: “Mobile radio interface sig
36、nalling layer 3 General aspects“. 8 3GPP TS 24.008: “Mobile radio interface layer 3 specification Core Network Protocols-Stage 3“. 9 3GPP TS 23.107: “Quality of Service, Concept and Architecture“. 10 3GPP TS 44.018: “Mobile radio interface layer 3 specification, Radio Resource Control (RRC) protocol
37、“. 3 Abbreviations Abbreviations used in the present document are listed in 3GPP TR 21.905 1. 4 General In the implementation of the standard it has been found that some aspects of the specifications have been mis-interpreted by some MS manufacturers. These MSs require specific implementations of th
38、e Phase 1 standard in the infrastructure, to provide completely compatible interworking. It has been assumed throughout this TR that Phase 2 and later infrastructure will interwork with Phase 1 MSs in the same way as Phase 1 infrastructure. The remainder of this TR describes how to overcome the poss
39、ible impacts of the above factors. Descriptions given are limited to specific implementations which are permissible for the Phase of the infrastructure. ETSI ETSI TR 129 994 V15.0.0 (2018-07)73GPP TR 29.994 version 15.0.0 Release 155 Specific implementation on the radio interface This clause deals w
40、ith the choice of specific infrastructure implementation options of the protocols at the radio interface. The protocols concerned are defined in 3GPP TS 04.08 Phase 1 2, Phase 2 3 and Phase 2+ 4. The corresponding protocol definitions for R99 and later releases are in 3GPP TS 24.007 7 and 3GPP TS 24
41、.008 8. 5.1 Handovers and “Synchronisation Indication“ 5.1.1 Justification In the HANDOVER COMMAND message there is a mandatory part consisting of nine octets followed by several optional information elements. The first optional information element is Synchronisation Indication which is a type 1 Inf
42、ormation Element (IE) and as such is coded, with IE Identifier (IEI), on one octet. Other optional IE follow the Synchronisation Indication IE and are used to: - indicate the frequency hopping sequence to use on the new channel; - indicate the channel mode for the new channel; - indicate a start tim
43、e. Some types of MS do not correctly decode these following information elements if the Synchronisation Indication information element is omitted. 5.1.2 Solution To ensure correct operation the infrastructure should always send the Synchronisation Indication IE to a Phase 1 MS. NOTE: In a few cases
44、this will force an extra layer 2 segment to be sent to the MS. 5.2 “Directed Retry“ type Handovers 5.2.1 Justification In the HANDOVER COMMAND message there is an optional Channel Mode Information Element. When this information element is included in the handover command the MS should go to the new
45、channel mode when it hands over to the new channel. This information element may be used for “directed retry“ type handovers where a cell has an MS on a control channel but has no available traffic channel for the MS to use. The network may then choose to handover the MS to a new cell with traffic c
46、hannel (TCH) capacity and change the channel mode at the same time. Some MSs appear to accept the handover command, from Stand-alone Dedicated Control Channel (SDCCH) to TCH with speech mode, and make the required channel and mode change but do not through connect the speech path. 5.2.2 Solution To
47、ensure correct operation, of these MSs, the infrastructure should always initiate a channel mode change procedure according to 3GPP TS 04.08 (Phase 1) 2 clause 3.4.6 once the MS has arrived at the new channel following a handover of a Phase 1 MS involving a channel mode change to full rate speech. T
48、he additional channel mode change procedure shall only be performed for a directed retry handover to a full rate speech channel, and not for a data channel. First this will save performance in these cases, and secondly some MSs will release the call with this additional and unnecessary channel mode
49、change procedure in case of fax or data calls. For internal intra-Base Station System (BSS) handovers, this decision to initiate channel mode modify is taken by the BSS concerned. For external intra-BSS and inter-BSS handovers, the new BSS must know that there has been a change of mode from the previous BSS and that therefore a channel mode change procedure must be executed. The communication of this information is achieved by using the “current channel“ element in the HANDOVER REQUEST and HANDOVER REQUIRED message as described in the A
