SIST EN 301 709 V8.0.1:2003

Digital cellular telecommunications system (Phase 2+) (GSM); Link Adaptation (GSM 05.09 version 8.0.1 Release 1999)

Upgrade to R99

Digitalni celični telekomunikacijski sistem (faza 2+) – Prilagoditev povezave (GSM 05.09, različica 8.0.1, izdaja 1999)

General Information

• Status: Published
• Publication Date: 30-Nov-2003
• ICS: 33.070.50 - Global System for Mobile Communication (GSM)
• Technical Committee: SS EIT - Technical Board for the electrotechnical, information technology and telecommunications fields
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Dec-2003
• Due Date: 01-Dec-2003
• Completion Date: 01-Dec-2003
• Ref Project: ETSI EN 301 709 V8.0.1 (2000-10) - Digital cellular telecommunications system (Phase 2+) (GSM); Link Adaptation (GSM 05.09 version 8.0.1 Release 1999)

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Digital cellular telecommunications system (Phase 2+) (GSM); Link Adaptation (GSM 05.09 version 8.0.1 Release 1999)33.070.50Globalni sistem za mobilno telekomunikacijo (GSM)Global System for Mobile Communication (GSM)ICS:Ta slovenski standard je istoveten z:EN 301 709 Version 8.0.1SIST EN 301 709 V8.0.1:2003en01-december-2003SIST EN 301 709 V8.0.1:2003SLOVENSKI
STANDARD



SIST EN 301 709 V8.0.1:2003



ETSIEN301709V8.0.1(2000-10)EuropeanStandard(Telecommunicationsseries)Digitalcellulartelecommunicationssystem(Phase2+);LinkAdaptation(GSM05.09version8.0.1Release1999)GLOBALSYSTEMFORMOBILECOMMUNICATIONSRSIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)2(GSM05.09version8.0.1Release1999)ReferenceREN/SMG-020509Q8KeywordsDigitalcellulartelecommunicationssystem,GlobalSystemforMobilecommunications(GSM)ETSI650RoutedesLuciolesF-06921SophiaAntipolisCedex-FRANCETel.:[phone]Fax:[phone]SiretN°34862356200017-NAF742CAssociationàbutnonlucratifenregistréeàlaSous-PréfecturedeGrasse(06)N°7803/88ImportantnoticeIndividualcopiesofthepresentdocumentcanbedownloadedfrom:http://www.etsi.orgThepresentdocumentmaybemadeavailableinmorethanoneelectronicversionorinprint.Inanycaseofexistingorperceiveddifferenceincontentsbetweensuchversions,thereferenceversionisthePortableDocumentFormat(PDF).Incaseofdispute,thereferenceshallbetheprintingonETSIprintersofthePDFversionkeptonaspecificnetworkdrivewithinETSISecretariat.Usersofthepresentdocumentshouldbeawarethatthedocumentmaybesubjecttorevisionorchangeofstatus.InformationonthecurrentstatusofthisandotherETSIdocumentsisavailableathttp://www.etsi.org/tb/status/Ifyoufinderrorsinthepresentdocument,sendyourcommentto:[e-mail]opartmaybereproducedexceptasauthorizedbywrittenpermission.Thecopyrightandtheforegoingrestrictionextendtoreproductioninallmedia.©EuropeanTelecommunicationsStandardsInstitute2000.Allrightsreserved.SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)3(GSM05.09version8.0.1Release1999)ContentsIntellectualPropertyRights.4Foreword.41Scope.51.1References.51.2Abbreviations.52General.63AdaptiveMulti-Rateinbandcontrolandlinkadaptation.63.1Generaloperation.63.1.1OperationwithoutTandemFreeOperation.63.1.2OperationwithongoingTandemFreeOperation.73.1.3OperationathandoverwithongoingTandemFreeOperation.73.2InbandSignalling.73.2.1FrequentinbandsignallingforAMRcodecmodeadaptation.83.2.1.1Generalaspects.83.2.1.2OperationwithDTXenabled.83.2.1.3Transmitter/ReceiverSynchronisation.83.2.2RobustinbandsignallingforAMRconfigurationmodification.83.2.2.1Generalaspects.83.2.2.2RATSCCHprotocol.93.2.2.3RATSCCHmessages.103.2.2.3.1ACK_OKmessage.103.2.2.3.2ACK_ERRmessage.103.2.2.3.3ACK_UNKNOWNmessage.103.2.2.3.4CMI_PHASE_REQmessage.103.2.2.3.5AMR_CONFIG_REQmessage.113.2.2.3.6THRESH_REQmessage.123.3Codecmodeadaptation.123.3.1Channelqualitymeasure.123.3.2GenerationofCodecModeCommandsandRequests.133.3.3Performancerequirements.133.3.3.1MSresponsetotheCodecModeCommand.133.3.3.2BTSresponsetotheCodecModeRequest.133.3.3.3PerformanceoftheCodecModeRequestGeneration.133.4Setupprocedures.143.4.1DefinitionoftheAMRActiveCodecSet.143.4.2DefinitionofCodecModeCommand/Requestdecisionthresholds.143.4.3InitialCodecModeSelectionatCallSetupandHandover.15AnnexA(informative):ExampleSolutionforLinkqualityestimation.16AnnexB(informative):ExampleDefinitionofModeCommand/Requestdecisionthresholds.17AnnexC(informative):PrinciplesforAMRcodecmodeadaptationwithTFO.18C.1Downgrading.18C.1.1Uplinkdowngrading.18C.1.2Downlinkdowngrading.19C.2Upgrading.20C.2.1Downlinkupgrading.20C.2.2Uplinkupgrading.21AnnexD(informative):Changecontrolhistory.22History.23SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)4(GSM05.09version8.0.1Release1999)IntellectualPropertyRightsIPRsessentialorpotentiallyessentialtothepresentdocumentmayhavebeendeclaredtoETSI.TheinformationpertainingtotheseessentialIPRs,ifany,ispubliclyavailableforETSImembersandnon-members,andcanbefoundinETSISR000314:"IntellectualPropertyRights(IPRs);Essential,orpotentiallyEssential,IPRsnotifiedtoETSIinrespectofETSIstandards",whichisavailablefromtheETSISecretariat.LatestupdatesareavailableontheETSIWebserver(http://www.etsi.org/ipr).PursuanttotheETSIIPRPolicy,noinvestigation,includingIPRsearches,hasbeencarriedoutbyETSI.NoguaranteecanbegivenastotheexistenceofotherIPRsnotreferencedinETSISR000314(ortheupdatesontheETSIWebserver)whichare,ormaybe,ormaybecome,essentialtothepresentdocument.ForewordThisEuropeanStandard(Telecommunicationsseries)hasbeenproducedbyETSITechnicalCommitteeSpecialMobileGroup(SMG).ThepresentdocumentspecifiestherelevantproceduresforlinkadaptationimplementedintheMobileStation(MS)andBaseStationSystem(BSS)ofthedigitalmobilecellularandpersonalcommunicationsystemsoperatinginthe900MHz,1800MHzand1900MHzband(GSM900,DCS1800andPCS1900).ThecontentsofthepresentdocumentaresubjecttocontinuingworkwithinSMGandmaychangefollowingformalSMGapproval.ShouldSMGmodifythecontentsofthepresentdocumentitwillthenberepublishedbyETSIwithanidentifyingchangeofreleasedateandanincreaseinversionnumberasfollows:Version8.x.ywhere:8indicatesrelease1999ofGSMPhase2+.xtheseconddigitisincrementedforallchangesofsubstance,i.e.technicalenhancements,corrections,updates,etc.ythethirddigitisincrementedwheneditorialonlychangeshavebeenincorporatedinthespecification.NationaltranspositiondatesDateofadoptionofthisEN:1September2000DateoflatestannouncementofthisEN(doa):31December2000DateoflatestpublicationofnewNationalStandardorendorsementofthisEN(dop/e):30June2001DateofwithdrawalofanyconflictingNationalStandard(dow):30June2001SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)5(GSM05.09version8.0.1Release1999)1ScopeTherequirementsdescribedinthepresentdocumentaremandatoryforimplementationinallGSMMSsandBSSscapableofsupportingtheAdaptiveMulti-Ratespeechtrafficchannel,unlessotherwisestated.Unlessotherwisespecified,referencestoGSMincludeGSMatanyfrequencyband.1.1ReferencesThefollowingdocumentscontainprovisionswhich,throughreferenceinthistext,constituteprovisionsofthepresentdocument.• Referencesareeitherspecific(identifiedbydateofpublication,editionnumber,versionnumber,etc.)ornon-specific.• Foraspecificreference,subsequentrevisionsdonotapply.• Foranon-specificreference,thelatestversionapplies.• Anon-specificreferencetoanETSshallalsobetakentorefertolaterversionspublishedasanENwiththesamenumber.• ForthisRelease1999document,referencestoGSMdocumentsareforRelease1999versions(version8.x.y).[1]GSM01.04:"Digitalcellulartelecommunicationssystem(Phase2+);Abbreviationsandacronyms".[2]GSM04.08:"Digitalcellulartelecommunicationssystem(Phase2+);Mobileradiointerfacelayer3specification".[3]GSM05.02:"Digitalcellulartelecommunicationssystem(Phase2+);Multiplexingandmultipleaccessontheradiopath".[4]GSM05.03:"Digitalcellulartelecommunicationssystem(Phase2+);ChannelCoding".[5]GSM05.05:"Digitalcellulartelecommunicationssystem(Phase2+);Radiotransmissionandreception".[6]GSM08.08:"Digitalcellulartelecommunicationssystem(Phase2+);Mobile-servicesSwitchingCentre-BaseStationSystem(MSC-BSS)interface,Layer3specification".[7]GSM08.62:"Digitalcellulartelecommunicationssystem;InbandTandemFreeOperation(TFO)ofSpeechCodecs".1.2AbbreviationsForthepurposesofthepresentdocument,thefollowingabbreviationsapply.FurtherGSMrelatedabbreviationsarelistedinGSM01.04.AMRAdaptiveMulti-RateACSActiveCodecSetCMCCodecModeCommandCMICodecModeIndicationCMRCodecModeRequestICMInitialCodecModeRATSCCHRobustAMRTrafficSynchronizedControlChannelSIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)6(GSM05.09version8.0.1Release1999)2GeneralThepresentdocumentgivesthedetailedrequirementsforthecorrectoperationofincallservicespecificlinkadaptationandcontrolforGSMservicesimplementedinGSMMobileStations(MS)sandBaseStationSystems(BSS)s.FortheAdaptiveMulti-Rate(AMR)speechservice,thedetaileddescriptionandrequirementsfortheassociatedinbandsignaling,AMRcodecmodeadaptation,andAMRcodecconfigurationaregiven.AninbandsignalingchannelisdefinedforAMRwhichenablestheMSandtheBTStoexchangemessagesonappliedorrequestedspeechandchannelcodecmodes.CodecmodeadaptationforAMRisbasedonreceivedchannelqualityestimationinbothMSandBTS,followedbyadecisiononthemostappropriatespeechandchannelcodecmodetoapplyatagiventime.TheoveralloperationofAMR,intermsofusedcodecmodesaswellasgeneraladaptationbehaviouriscontrolledbythenetwork.3AdaptiveMulti-Rateinbandcontrolandlinkadaptation3.1Generaloperation3.1.1OperationwithoutTandemFreeOperationAhigh-levelblockdiagramofthecompleteAMRsystemisdepictedinfigure1.ThesystemconsistsofthemajorcomponentsTRAUandBTSonthenetworksideandtheMS.Onthenetworkside,speechencoder(SPE)andchannelencoder(CHE)aswellaschanneldecoder(CHD)andspeechdecoder(SPD)areconnectedviatheserialA-bisinterface.Foreachlink,qualityinformationisderivedbyestimatingthecurrentchannelstate.Basedonthechannelstate,andalsotakingintoconsiderationpossibleconstraintsfromnetworkcontrol,thecodecmodecontrol,whichislocatedonthenetworkside,selectsthecodecmodestobeapplied.Thechannelmodetouse(TCH/AFSorTCH/AHS)iscontrolledbythenetwork.Uplinkanddownlinkalwaysapplythesamechannelmode.Forcodecmodeadaptationthereceivingsideperformslinkqualitymeasurementsoftheincominglink.ThemeasurementsareprocessedyieldingaQualityIndicator.Foruplinkadaptation,theQualityIndicatorisdirectlyfedintotheULmodecontrolunit.ThisunitcomparestheQualityIndicatorwithcertainthresholdsandgenerates,alsoconsideringpossibleconstraintsfromnetworkcontrol,aCodecModeCommandindicatingthecodecmodetobeusedontheuplink.TheCodecModeCommandisthentransmittedinbandtothemobilesidewheretheincomingspeechsignalisencodedinthecorrespondingcodecmode.Fordownlinkadaptation,theDLModeRequestGeneratorwithinthemobilecomparestheDLQualityindicatorwithcertainthresholdsandgeneratesaCodecModeRequestindicatingthepreferredcodecmodeforthedownlink.TheCodecModeRequestistransmittedinbandtothenetworksidewhereitisfedintotheDLModeControlunit.Thisunitgenerallygrantstherequestedmode.However,consideringpossibleconstraintsfromnetworkcontrol,itmayalsooverridetherequest.Theresultingcodecmodeisthenappliedforencodingoftheincomingspeechsignalindownlinkdirection.Bothforuplinkanddownlink,thepresentlyappliedcodecmodeistransmittedinbandasCodecModeIndicationtogetherwiththecodedspeechdata.Atthedecoder,theCodecModeIndicationisdecodedandappliedfordecodingofthereceivedspeechdata.SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)7(GSM05.09version8.0.1Release1999)MSBTSTRAUULcodecmode(received)UL-ModeCtrlUL-Meas.SPESPECHECHDSPDCHDCHESPDDL-Meas.DL-ModeCtrlDLcodecmodeULModeCommandULQualityIndicatorULModeCommand(received)DLModeRequest(received)speechdataspeechdataDLcodecmode(received)networkcontrolDL-Req.GenDLQualityIndicatorDLModeRequestFigure1:HighlevelAMRblockdiagramCodecmodeselectionisdonefromasetofcodecmodes(ACS,ActiveCodecSet),whichmayinclude1to4AMRcodecmodes.Associatedwiththissetisalistof1to3switchingthresholdsandhysteresisesusedbytheDLModeRequestGeneratorandtheULmodecontrolunittogeneratetheCodecModeRequestsandCodecModeCommands.Theseconfigurationparameters(ACS,thresholds,hysteresises)aredefinedatcallsetupandcanbemodifiedathandoverorduringacall.3.1.2OperationwithongoingTandemFreeOperationIftandemfreeoperationisongoing(seeGSM08.62)thenthespeechsignalhastobetransmittedovertworadiolinks,firstuplink(MS1toBTS1)andthendownlink(BTS2toMS2),respectivelysymmetricallyinthereversedirection.TheoptimalCodecModeindirectionMS1toMS2shallbederivedfromtheCodecModeRequestforthefirstuplink(CMC1,withinBTS1)andtheCodecModeRequestderivedfortheseconddownlink(CMR2withinMS2)inthefollowingway:MS2shallsendtheCMR2backtoBTS2intheusualway.BTS2shalleitheracceptthisCMR2(default)ormaymodifyitaccordingtonetworkcontrolneeds:CMR2´.ThenBTS2shallsendtheCMR2´furtheruplinktoitsTRAU2,toTRAU1anddownlinktoBTS1(seeGSM08.62onhowthistransmissionshallbehandledonAbisandAinterfaces).BTS1combinesthereceivedCMR2´withitsownderivedCMC1bytakingtheminimumofbothvalues.Ifneeded,BTS1maymodifythisminimumvalueaccordingtoownnetworkcontrol(-->CMC1´´)andshallsenditfinallydownlinktoMS1asCMC.Theidenticalprocedureshallbeperformedinthereversedirection.AnnexCgivesaninformativedescription.3.1.3OperationathandoverwithongoingTandemFreeOperationBeforeandduringanhandoveratoneorbothsidesoftheMS-to-MSconnection,itmaybeneededtofreezethecodecmodeadaptationforashortwhile,e.g.tooptimisethecommonActiveCodecSet,ortoallowfast(re-)synchronisationbetweenBTSandTRAUortooptimisetheCMIPhaseindownlink.BothBTSsmaythereforeenableordisablethecodecmodeadaptation(seeGSM08.62).Aslongasthecodecmodeadaptationisfrozentoaspecificcodecmode,thenthiscodecmodeshallbeusedinbothdirectionsaslongastandemfreeoperationisongoing,ortandemfreeoperationshallbediscontinued.TheCodecModeRequestsfromtheMSsmaybetakenintoaccounttodecidewhethertocontinueTFOornot,butnotforcodecmodeadaptation.3.2InbandSignallingTheAMRinbandsignallingconsistsoftwoparts:-Frequentsignalling,usedforCodecModeIndicationandCodecModeCommand/Request.-Robust,lessfrequentsignalling,basedonframestealing,usedforchangingtheAMRconfiguration(RATSCCH).SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)8(GSM05.09version8.0.1Release1999)3.2.1FrequentinbandsignallingforAMRcodecmodeadaptation3.2.1.1GeneralaspectsThecodecmodeinformation,whichhastobetransmittedoneachlink,consistsofCodecModeIndicationsandCodecModeCommandsinthedownlink,respectivelyCodecModeIndicationsandCodecModeRequestsintheuplink.CodecModeIndicationsinformthereceiveraboutthecurrentlyappliedcodecmode.CodecModeCommandsinformtheotherendaboutthecodecmodetobeappliedontheotherlink.CodecModeRequestsinformtheotherendaboutthepreferredcodecmodeontheotherlink.Codecmodeinformationistransmittedinbandinthespeechtrafficchannel,usingapartofitstransmissioncapacity.Thecodingofcodecmodesintheinbandsignallingisgiveninsubclause3.4.1.ChannelcodingofcodecmodeinformationisspecifiedinGSM05.03[4]forallframetypes.Codecmodesareconstrainedtochangeonlyeverysecondspeechframe.CodecModeCommands/RequestsandCodecModeIndicationsaresub-sampledsuchthattheyoccuronlyeverysecondframe.CodecModeIndicationsandCodecModeCommands/Requestsshallbetransmittedalternatingwithinconsecutivespeechframes.Both,CodecModeIndicationandCodecModeCommand/Request,shallbetransmittedtogetherwithineveryRATSCCHframe.3.2.1.2OperationwithDTXenabledForSID_FIRSTframes,theCodecModeIndicationorCodecModeCommand/Requestinphasewiththealternatingtransmissionshallbetransmitted(samephaseasinspeechframes).Both,CodecModeIndicationandCodecModeCommand/Request,shallbetransmittedtogetherineverySID_UPDATEframe(asinRATSCCHframes).ForONSETframestheCodecModeIndicationforthesubsequentspeechframeshallbetransmitted,regardlessofthephaseoftheinbandsignalling.Thegeneralphaseoftheinbandsignallingshallnotbechangedbythat.3.2.1.3Transmitter/ReceiverSynchronisationThealternatingtransmissionofthecodecmodeinformationrequiressynchronisationoftransmittingandreceivingends,suchthatCodecModeIndicationsandCodecModeCommands/Requestsaredecodedincorrectorder.Toensurepropersynchronisation,thecodecmodeinformationshallbetransmittedalignedtothe(SACCH)multi-framestructureoftheGSMsystem.ForTCH/AFS,thedefaulttransmissionphaseshallbesuchthatCodecModeIndicationsaresentalignedwithTDMAframe0intheuplinkandwithTDMAframe4inthedownlinkasdefinedinGSM05.02[3].ForTCH/AHS,thedefaulttransmissionphaseshallbesuchthatModeIndicationsaresentalignedwithTDMAframe0or1dependingonthesubchannelintheuplinkandwithTDMAframe4or5dependingonthesubchannel,inthedownlink,asdefinedinGSM05.02[3].ThisdefaultphaseoftheCodecModeIndicationindownlinkdirectioniscalled"odd",thealternativephase,onespeechframeshifted,iscalled"even".Thephaseinuplinkisalwaysthesameandisneverchanged.Atcallsetupandaftereveryhandoverthedefaultphase(odd)shallbeusedindownlinkdirection.Duringacall,thephaseofCodecModeIndicationmaybechangedindownlinkbyusingaRATSCCHmessage.IncaseofhandoverfailureandfallbacktotheBTSbeforethehandoverattempt,thephasebeforethehandoverattemptshallbeusedagain.3.2.2RobustinbandsignallingforAMRconfigurationmodification3.2.2.1GeneralaspectsTheRATSCCHmechanismmaybeusedincaseofTandemFreeOperationtomodifytheAMRConfigurationontheradiointerfacewithoutinterruptionofthespeechtransmission.ItsapplicationforTFOisdescribedinGSM08.62.ThisrecommendationdefinestheRATSCCHprotocolandtheRATSCCHmessages.ThechannelcodingisdefinedinGSM05.03andthereceiverperformanceinGSM05.05.RATSCCHhandlingismandatoryforMSandoptionalforBTS.SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)9(GSM05.09version8.0.1Release1999)RATSCCHisbasedonframestealing.OnTCH/AFS,onespeechframeisstolenforeachRATSCCHmessage,andonTCH/AHStwospeechframesarestolen.InTCH/AHSRATSCCHismappedontotwoconsecutivespeechframes,theRATSCCH_MARKERandtheRATSCCH_DATA.Bothshallbesentalwaysasonepair.FACCHframeshavehigherprioritythanRATSCCHframes.IfFACCHandRATSCCHarescheduledfortransmissionforthesamespeechframe,thentheFACCHshallbesentfirst,followedbytheRATSCCH.IftheRATSCCHisdelayedduetoFACCH,thentheappropriatecounters(see3.2.2.2)shallalsobestartedone(TCH/AFS)respectivelytwo(TCH/AHS)frameslater.IfinthecaseofTCH/AHS,FACCHstealsthesecondframeofoneRATSCCHmessage(RATSCCH_DATA),thecompleteRATSCCHmessage(RATSCCH_MARKERandRATSCCH_DATA)shallbesentfollowingtheFACCHframe.3.2.2.2RATSCCHprotocolTheRATSCCHprotocolelementsconsistofanumberofREQuestMessagesandthreeACKnowledgementMessages.OneinformationexchangeconsiststypicallyofoneREQ-ACKcyclebetweenthe"Initiator"andthe"Addressee".WhiletheInitiatoriswaitingforanACK,itshallnotsendanynewREQmessage,i.e.transmissionandacknowledgementofoneREQ-ACKcycleshallbecompletedbeforethenextcycleisstarted.ACKmessages,asreactiontoreceivedREQmessages,shallalwaysbesentbackassoonaspossible,andlatestwithin3speechframes.BothsidesshallcontinuouslymonitortheradioreceptionfortheRATSCCHpatternanddecodetheRATSCCHmessage.ThetypicalREQ-ACKcycleisdefinedas:1)Ifoneside("Initiator")wantstoinitiatetheinformationexchange,itshallsendthedesiredREQmessage.AtthesametimetheInitiatorshallstarttwocounters:ACK_Timeoutthatshallcounttheelapsedspeechframes(afterREQ)inreceivedirectionandREQ_ActivationthatshallcounttheelapsedspeechframesafterREQinsenddirection.2)IftheREQmessagewasdecodederror-free(byCRCcheck,seeGSM05.03[4])andisdefined(seesubclause3.2.2.3)atreceiverside("Addressee"),thentheAddresseeshallsendanACK_OKmessageback.AtthesametimetheAddresseeshallstart(orrestart)twoowncounters:REQ_ActivationthatshallcounttheelapsedspeechframesafterREQinreceivedirectionandACK_ActivationthatshallcounttheelapsedspeechframesafterACKinsenddirection.3)IftheInitiatorreceivesanACK_OK,thenitshallignoreitsACK_TimeoutcounterandshallstartanACK_ActivationcounterinsteadthatshallcounttheelapsedspeechframesafterACK_OKinreceivedirection.4)ThecontentsoftheREQmessagesshallbecomevalidinthedirectionfromInitiatortoAddresseeexactlyinthatframe,wheretheREQ_Activationcountersreachthevalue12andforallfollowingframes.ThecontentsoftheREQmessageshallbecomevalidinthedirectionfromAddresseetoInitiatorexactlyinthatframe,wheretheACK_Activationcountersreachthevalue12andforthefollowingframes.NOTE:DuetothetransmissiondelayandthereactiontimewithintheAddressee(REQtoACK)theactivationtakesplaceingeneralatfourdifferentpointsintime,butexactlysynchronisedanddefinedinbothdirections.ErrorHandling:1)IftheREQmessagewasdecodederror-free(noCRCerror),butthemessageisnotdefinedattheAddresseeside,thentheAddresseeshallsendanACK_UNKNOWNmessageback.Nocountersareneededinthiscase.TheInitiator,whenreceivingthisACK_UNKNOWNmessageshallterminatetheexchangeforthistypeofREQmessage.2)IftheRATSCCHmessagewasdetected,butcouldnotbedecodedcorrectly(CRCfailure),oritscontentswasnotconsistent,thentheAddresseeshallsendanACK_ERRmessageback.Nocountersareneededinthiscase.3)IftheInitiatordoesnotreceiveanACK_OKorACK_UNKNOWNbeforetheACK_Timeoutcounterreaches10,oritreceivesanACK_ERRinstead,thenitshallinitiatetheexchangeagainbyresendingtheREQandstartingthetimersanew.4)IftheInitiatorhassenttheREQunsuccessfullyforthreetimes,theretransmissionshallbestopped.5)IfateithersideanACK_ERRorACK_UNKNOWNisreceivedalthoughnocorrespondingREQhasbeensentbefore,thisACKmessagesshallbeignored.SIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)10(GSM05.09version8.0.1Release1999)IftheBTSreceivesanACK_OKalthoughithasnotsentacorrespondingREQbefore,thentheBTSshallinitiatethesendingoftheusedAMRConfigurationdowntotheMS.3.2.2.3RATSCCHmessagesEachRATSCCHmessageconsistsofitsRATSCCHmessageidentifierandpotentiallymessageparameters.Intotal35netbitsareavailableforeachmessage.Theyarenumbered34…0inthemessagedescriptionsbelow,andcorrespondtod(34)…d(0)inGSM05.03.ThreedifferentACKnowledgementmessagearedefined.3.2.2.3.1ACK_OKmessageTheACK_OKmessageservesasanacknowledgementthataRATSCCHREQmessagehasbeendetected,correctlydecoded(noCRCerror)andthatitisdefinedfortheAddressee.ItdefinestheexactactivationtimeindirectionfromAddresseetoInitiator.Table3.2.2.3.1showsthedefinitionoftheACK_OK.Table3.2.2.3.1:DefinitionoftheACK_OKmessageBit34…210Value0…0013.2.2.3.2ACK_ERRmessageTheACK_ERRmessageservesasanegativeacknowledgementthataRATSCCHREQmessagehasbeendetected,i.e.theRATSCCHpatternwasdetected,butcouldnotbedecodedcorrectly(CRCerror).Table3.2.2.3.2showsthedefinitionoftheACK_ERR.Table3.2.2.3.2:DefinitionoftheACK_ERRmessageBit34…210Value0…0103.2.2.3.3ACK_UNKNOWNmessageTheACK_UNKNOWNmessageservesasanacknowledgementthataRATSCCHREQmessagehasbeendetectedandcorrectlydecoded,butwasunknowntotheAddressee.Table3.2.2.3.3showsthedefinitionoftheACK_UNKNOWN.Table3.2.2.3.3:DefinitionoftheACK_UNKNOWNmessageBit34…210Value0…011ACKnowledgemessagesshallonlybesentinresponsetoaREQuestmessage.3.2.2.3.4CMI_PHASE_REQmessageTheCMI_PHASE_REQmessagemaybesentbytheBTStochangethephaseoftheCodecModeIndicationindownlink.CMI_PHASE_REQhasonlyparameter,CodecModeIndicationPhase(CMIP).Table3.2.2.3.6ashowstheformat.Table3.2.2.3.4a:FormatoftheCMI_PHASE_REQmessageBit34…210Value0…10CMIPSIST EN 301 709 V8.0.1:2003



ETSIETSIEN301709V8.0.1(2000-10)11(GSM05.09version8.0.1Release1999)AssumingtheCMI_PHASE_REQmessagereplacesDLspeechframeN(framesN-1andNforTCH/AHS),thenthenewphaseshallbeusedstartingwithDLspeechframeN+12.TheCMIPhaseinuplinkshallnotbeaffected.ThenewCMIphaseindownlinkshallbeactiveuntilitismodifiedbyanewCMI_PHASE_REQoruntilahandoverissuccessfullyexecuted.Table3.2.2.3.6bshowshowCodecModeIndicationsandCodecModeCommandsshallbetransmittedinevenandoddspeechframesdependingonthevalueofMIP.Seesubclause3.2.1.4forthedefinitionofevenandoddspeechframes.Table3.2.2.3.4b:PhaseofCodecModeIndication/CommandinDLdependingonCMIPValueofCMIPInformationtransmittedinevenspeechframesInformationtransmittedinoddspeechframes0CodecModeIndicationCodecModeCommand1(default)CodecModeCommandCodecModeIndication3.2.2.3.5AMR_CONFIG_REQmessageTheAMR_CONFIG_REQmessagemaybesentbytheBTSduringacalltochangetheAMRconfigurationontheradiointerfacewithoutinterruptionofthespeechtransmission.AMR_CONFIG_REQcontainsseveralparameters:ActiveCodecSet(ACS),InitialCodecMode(ICM),somepairsofthresholdandhysteresisvalues(THRESHjandHYSTj)andtwoflagsindicatingwhethertheconfigurationparametersshallbevalidfortheuplink(UL),downlink(DL),orboth.Table3.2.2.3.4showstheformat.Table3.2.2.3.5a:MainFormatoftheAMR_CONFIG_REQmessageBit34…32313029…2827…2019…1615…109…65…0Value001DLFULFICMACSHYST2THRESH2HYST1THRESH1TheACSandICMparametersarecodedinthesamewayasdefinedinGSM04.08[2].AllthresholdandhysteresisparametersintheAMR_CONFIG_REQarevalidonlyfordownlinkdirection.Thecodingoftheseparametersisgiveninsubclause3.4.2.IftheACSconsistsofnmodes(n=1,2,3),thenonlyTHRESH1…THRESHn-1andHYST1…HYSTn-1aredefined.Theremainingbitsarereservedforfutureuseandshallbesetto"1".IftheACSconsistsoffourmodes,thenthecompletesetofthresholds/hysteresisescannotbesentwiththismessage.Inthatcase,allTHRESHjandHYSTjfieldsarereservedforfutureuseandshallbesetto"1".Similar,iftheBTShasnothresholdandhysteresisparametersforthegivenconfiguration,thenallTHRESHjandHYSTjfieldbitsshallbesetto"1"toindicatethattheyareundefined.TheTHRESH_REQmessageshallbeusedtotransmittheseparametersatalaterpointintime.AslongastheMShasnodefinedthresholdandhysteresisparametersitshallusetheInitialCodecModefortheCodecModeRequest.Alternatively,incaseoffourcodecmodes,theBTSmaysendthethreethresholdandhysteresisparametersasshownintable3.2.2.3.5.b.ThecodingofHYSTcisgiveninsubclause3.4.2.Allthreehysteresisvalues(HYST1/2/3)areinthatcaserepresentedbyonecommonHYSTcvalue(HYST1=HYST2=HYST3=HYSTc).Table3.2.2.3.5b:AlternativeFormatoftheAMR_CONFIG_REQmessageforfourmodesBit34…32313029…2827…2019…1817…1211…65…0Value001DLFULFICMACSHYSTcTHRESH3THRESH2THRESH1InthiswaytheACSandtheassociatedthresholdsmaybesentinonesinglemessage,allowinganimmediateCodecModeRequestgenerationwithintheMSforthenewconfiguration.IfneededthehysteresisparametersmaybemodifiedinalaterTHRESH_REQmessage.TheDLFand/orULFflagsaresetto"1",ifthec
...