1、 ETSI TR 1Digital cellular telecoUniversal Mobile TelRecommended infrastruMobile Station (MS(3GPP TR 29.9TECHNICAL REPORT 129 994 V13.0.0 (2016communications system (Phaelecommunications System (LTE; tructure measures to overcomS) and User Equipment (UE) .994 version 13.0.0 Release 1316-01) hase 2+)
2、; (UMTS); ome specific ) faults 13) ETSI ETSI TR 129 994 V13.0.0 (2016-01)13GPP TR 29.994 version 13.0.0 Release 13Reference RTR/TSGC-0129994vd00 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 5
3、62 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-search The present document may be made available in electronic versions and/or in print. The content of
4、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 between such versions and/or in print, the only prevailing document is the print of the Portable Document Fo
5、rmat (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 available at http:/portal.etsi.org/tb/sta
6、tus/status.asp 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
7、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 copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Instit
8、ute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Mark
9、s registered and owned by the GSM Association. ETSI ETSI TR 129 994 V13.0.0 (2016-01)23GPP TR 29.994 version 13.0.0 Release 13Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPR
10、s, 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 Secretariat. Latest updates are ava
11、ilable 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 ETSI Web server) which a
12、re, or may be, or may become, essential to the present document. 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 or GSM identiti
13、es. 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 “shall“, “shall not“, “should“, “sho
14、uld not“, “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 T
15、R 129 994 V13.0.0 (2016-01)33GPP TR 29.994 version 13.0.0 Release 13Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 5g31 Scope 6g32 References 6g33 Abbreviations . 6g34 General . 6g35 Specific implementation on the radio interface 7g35.1 Handovers and “Sy
16、nchronisation Indication“ . 7g35.1.1 Justification . 7g35.1.2 Solution . 7g35.2 “Directed Retry“ type Handovers . 7g35.2.1 Justification . 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 Messa
17、ges . 8g35.4.1 Justification . 8g35.4.2 Solution . 8g35.5 Handling of Phase 2 and Phase 2+ SACCH Messages . 9g35.5.1 Justification . 9g35.5.2 Solution . 9g35.6 Handling of assignment message using Mobile Allocation IE including ARFCN=0 9g35.6.1 Justification . 9g35.6.2 Solution . 9g35.7 Hopping sequ
18、ence generation including ARFCN=0 9g35.7.1 Justification . 9g35.7.2 Solution . 9g35.8 QoS IE length between R97 and R99 implementations . 10g35.8.1 Justification . 10g35.8.2 Solution . 10g35.9 MS unable to handle the LOCATION UPDATING ACCEPT, ATTACH ACCEPT and ROUTING AREA UPDATE ACCEPT messages whe
19、n the EPLMN Lists IE is included 10g35.9.1 Justification . 10g35.9.2 Solution . 10g35.10 MS unable to handle messages when the truncation function is used 11g35.10.1 Justification . 11g35.10.2 Solution . 11g35.11 Roaming restrictions issues with reject cause #13 and #15 11g35.11.1 Justification . 11
20、g35.11.2 Solution . 12g36 Use of VAD/DTX in conjunction with frequency hopping for a speech call 12g36.1 Scope 12g36.2 General . 12g36.3 Implementation options to reduce the occurance of undetected bad frames by utilising normal system features . 13g36.3.1 Number of frequency hopping channels . 13g3
21、6.3.2 Frequency hopping type 13g36.3.3 Continuous SID frames on C0 13g3ETSI ETSI TR 129 994 V13.0.0 (2016-01)43GPP TR 29.994 version 13.0.0 Release 136.4 Implementation options to reduce the occurance of undetected bad frames by changing normal system operation . 14g36.4.1 Changing the training sequ
22、ence of the dummy burst to a new (ninth) training sequence . 14g36.4.2 Using an alternative training sequence out of the eight assigned 14g36.4.3 Setting the stealing flag for the bits transmitted which are not intended to be part of the TCH . 14g36.4.4 Sending partial SID frames on C0 14g36.5 Teste
23、d Combinations 14g36.5.1 “Normal“ system. 15g36.5.2 New training sequence 15g36.5.3 Alternative training sequence from the eight assigned . 15g36.5.4 Setting stealing flag for unintentionally transmitted bits 15g36.5.5 Setting stealing flag for unintentionally transmitted bits and modifying training
24、 sequence for Dummy Bursts 16g36.5.6 Sending partial SID information on C0 16g3Annex A: Amendment Request 08.08 - 021 R4: Information 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
25、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 History . 23g3History 24g3ETSI ETSI TR 129 994 V13.0.0 (2016-01)53GPP TR 29.994 version 13.0.0 Release 13Foreword This Technical Specification has been produced by the
26、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 change of relea
27、se 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 substance, i.e. t
28、echnical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI ETSI TR 129 994 V13.0.0 (2016-01)63GPP TR 29.994 version 13.0.0 Release 131 Scope The present document clarifies recommended measures which may
29、be adopted by 3GPP infrastructure utilising GSM or GERAN as access network to enable inter-working to be obtained between network and various User Equipment (UE) implementations of the 3GPP specification. The objective is to obtain compatibility without changing the consolidated set of specification
30、s. The present document describes the recommended changes to the infrastructure to cater for specific faults within some types of UE. 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 Refer
31、ences 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, subsequent revisi
32、ons 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 TR 21.905: “ Voc
33、abulary for 3GPP Specifications“. 2 3GPP TS 04.08 (Phase 1): “Mobile radio interface layer 3 specification Part 1: Generic“. 3 3GPP 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
34、): “Radio Performance Aspects. 6 3GPP TS 05.05 (Phase 2+): “Radio Performance Aspects. 7 3GPP TS 24.007: “Mobile radio interface signalling 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
35、, Concept and Architecture“. 10 3GPP TS 44.018: “Mobile radio interface layer 3 specification, Radio Resource Control (RRC) protocol“. 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 som
36、e aspects of the specifications have been mis-interpreted by some MS manufacturers. These MSs require specific implementations of the Phase 1 standard in the infrastructure, to provide completely compatible interworking. It has been assumed throughout this TR that Phase 2 and later infrastructure wi
37、ll interwork with Phase 1 MSs in the same way as Phase 1 infrastructure. ETSI ETSI TR 129 994 V13.0.0 (2016-01)73GPP TR 29.994 version 13.0.0 Release 13The remainder of this TR describes how to overcome the possible impacts of the above factors. Descriptions given are limited to specific implementat
38、ions which are permissible for the Phase of the infrastructure. 5 Specific implementation on the radio interface This clause deals with 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
39、, 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.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
40、by several optional information elements. The first optional information element is Synchronisation Indication which is a type 1 Information 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: - indica
41、te the frequency hopping sequence to use on the new channel; - indicate the channel mode for the new channel; - indicate a start time. 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 ens
42、ure correct operation the infrastructure should always send the Synchronisation Indication IE to a Phase 1 MS. NOTE: In a few cases 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 optio
43、nal Channel Mode Information Element. When this information element is included in the handover command the MS should go to the new 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
44、 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 channel (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) t
45、o 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 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 on
46、ce 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. The 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
47、will save performance in these cases, and secondly some MS“s will release the call with this additional and unnecessary channel mode change procedure in case of fax or data calls. ETSI ETSI TR 129 994 V13.0.0 (2016-01)83GPP TR 29.994 version 13.0.0 Release 13For internal intra-Base Station System (B
48、SS) 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 commun
49、ication of this information is achieved by using the “current channel“ element in the HANDOVER REQUEST and HANDOVER REQUIRED message as described in the Annex A. In the case of external handover, the following will ensure correct operation with mobiles suffering from fault 5.2.1: i) The change described in Annex A shall be implemented by the MSC and BSS concerned. ii) The new BSS, after receiving a HANDOVER REQUEST containing a current channel IE indicating “signalling only“, and a channel type indicating full rate speech, shall behave
