ETSI TS 101 709 V7.7.0 (2001-11) Technical Specification Digital cellular telecommunications system (Phase 2+); Link adaptation (3GPP TS 05.09 version 7.7.0 Release 1998) R GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS 3GPP TS 05.09 version 7.7.0 Release 1998 1 ETSI TS 101 709 V7.7.0 (2001-11) Reference RTS/TSGG-010509Q7R6 Keywords GSM 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 742 C Association à but non lucratif enregistrée à la Sous-Préfecture de Grasse (06) N° 7803/88 Important notice Individual copies of the present document can be downloaded from: http://www.etsi.org The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the 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/status/status.asp If you find errors in the present document, send your comment to: [email protected] Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © European Telecommunications Standards Institute 2001. All rights reserved. ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 2 ETSI TS 101 709 V7.7.0 (2001-11) Intellectual Property Rights IPRs essential or potentially essential to the present document 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, 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 (http://webapp.etsi.org/IPR/home.asp). 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 are, or may be, or may become, essential to the present document. Foreword This Technical Specification (TS) 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 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 www.etsi.org/key . ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 3 ETSI TS 101 709 V7.7.0 (2001-11) Contents Intellectual Property Rights................................................................................................................................2 Foreword.............................................................................................................................................................2 Foreword.............................................................................................................................................................4 1 Scope........................................................................................................................................................5 1.1 References..........................................................................................................................................................5 1.2 Abbreviations.....................................................................................................................................................5 2 General.....................................................................................................................................................6 3 Adaptive Multi-Rate inband control and link adaptation.........................................................................6 3.1 General operation...............................................................................................................................................6 3.1.1 Operation without Tandem Free Operation..................................................................................................6 3.1.2 Operation with ongoing Tandem Free Operation.........................................................................................7 3.1.3 Operation at handover with ongoing Tandem Free Operation......................................................................7 3.2 Inband Signalling...............................................................................................................................................7 3.2.1 Frequent inband signalling for AMR codec mode adaptation......................................................................8 3.2.1.1 General aspects.......................................................................................................................................8 3.2.1.2 Operation with DTX enabled..................................................................................................................8 3.2.1.3 Transmitter/Receiver Synchronisation....................................................................................................8 3.2.2 Robust inband signalling for AMR configuration modification...................................................................8 3.2.2.1 General aspects.......................................................................................................................................8 3.2.2.2 RATSCCH protocol................................................................................................................................9 3.2.2.3 RATSCCH messages............................................................................................................................10 3.2.2.3.1 ACK_OK message..........................................................................................................................10 3.2.2.3.2 ACK_ERR message........................................................................................................................10 3.2.2.3.3 ACK_UNKNOWN message...........................................................................................................10 3.2.2.3.4 CMI_PHASE_REQ message..........................................................................................................11 3.2.2.3.5 AMR_CONFIG_REQ message.......................................................................................................11 3.2.2.3.6 THRESH_REQ message.................................................................................................................12 3.3 Codec mode adaptation....................................................................................................................................12 3.3.1 Channel quality measure.............................................................................................................................12 3.3.2 Generation of Codec Mode Commands and Requests................................................................................13 3.3.3 Performance requirements..........................................................................................................................13 3.3.3.1 MS response to the Codec Mode Command.........................................................................................13 3.3.3.2 BTS response to the Codec Mode Request...........................................................................................14 3.3.3.3 Performance of the Codec Mode Request Generation..........................................................................14 3.4 Setup procedures..............................................................................................................................................14 3.4.1 Definition of the AMR Active Codec Set...................................................................................................14 3.4.2 Definition of Codec Mode Command/Request decision thresholds...........................................................14 3.4.3 Initial Codec Mode Selection at Call Setup and Handover.........................................................................16 Annex A (informative): Example Solution for Link quality estimation....................................................17 Annex B (informative): Example Definition of Mode Command/Request decision thresholds..............18 Annex C (informative): Principles for AMR codec mode adaptation with TFO......................................19 C.1 Downgrading..........................................................................................................................................19 C.1.1 Uplink downgrading.........................................................................................................................................19 C.1.2 Downlink downgrading....................................................................................................................................20 C.2 Upgrading...............................................................................................................................................21 C.2.1 Downlink upgrading.........................................................................................................................................21 C.2.2 Uplink upgrading..............................................................................................................................................22 Annex D (informative): Change history.......................................................................................................23 History..............................................................................................................................................................24 ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 4 ETSI TS 101 709 V7.7.0 (2001-11) Foreword This Technical Specification has been produced by the 3rd 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 release date and an increase in version number as follows: Version 7.x.y where: 7 indicates release 1998 of GSM Phase 2+. x the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. y the third digit is incremented when editorial only changes have been incorporated in the specification. ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 5 ETSI TS 101 709 V7.7.0 (2001-11) 1 Scope The requirements described in the present document are mandatory for implementation in all GSM MSs and BSSs capable of supporting the Adaptive Multi-Rate speech traffic channel, unless otherwise stated. Unless otherwise specified, references to GSM include GSM at any frequency band. 1.1 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, 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 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] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms". [2] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification". [3] GSM 05.02: "Digital cellular telecommunications system (Phase 2+); Multiplexing and multiple access on the radio path". [4] GSM 05.03: "Digital cellular telecommunications system (Phase 2+); Channel Coding". [5] GSM 05.05: "Digital cellular telecommunications system (Phase 2+); Radio transmission and reception". [6] GSM 08.08: "Digital cellular telecommunications system (Phase 2+); Mobile-services Switching Centre - Base Station System (MSC - BSS) interface, Layer 3 specification". [7] GSM 08.62: "Digital cellular telecommunications system; Inband Tandem Free Operation (TFO) of Speech Codecs". 1.2 Abbreviations For the purposes of the present document, the following abbreviations apply. Further GSM related abbreviations are listed in GSM 01.04. AMR Adaptive Multi-Rate ACS Active Codec Set CMC Codec Mode Command CMI Codec Mode Indication CMR Codec Mode Request ICM Initial Codec Mode RATSCCH Robust AMR Traffic Synchronized Control Channel ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 6 ETSI TS 101 709 V7.7.0 (2001-11) 2 General The present document gives the detailed requirements for the correct operation of in call service specific link adaptation and control for GSM services implemented in GSM Mobile Stations (MS)s and Base Station Systems (BSS)s. For the Adaptive Multi-Rate (AMR) speech service, the detailed description and requirements for the associated inband signaling, AMR codec mode adaptation, and AMR codec configuration are given. An inband signaling channel is defined for AMR which enables the MS and the BTS to exchange messages on applied or requested speech and channel codec modes. Codec mode adaptation for AMR is based on received channel quality estimation in both MS and BTS, followed by a decision on the most appropriate speech and channel codec mode to apply at a given time. The overall operation of AMR, in terms of used codec modes as well as general adaptation behaviour is controlled by the network. 3 Adaptive Multi-Rate inband control and link adaptation 3.1 General operation 3.1.1 Operation without Tandem Free Operation A high-level block diagram of the complete AMR system is depicted in figure 1. The system consists of the major components TRAU and BTS on the network side and the MS. On the network side, speech encoder (SPE) and channel encoder (CHE) as well as channel decoder (CHD) and speech decoder (SPD) are connected via the serial A-bis interface. For each link, quality information is derived by estimating the current channel state. Based on the channel state, and also taking into consideration possible constraints from network control, the codec mode control, which is located on the network side, selects the codec modes to be applied. The channel mode to use (TCH/AFS or TCH/AHS) is controlled by the network. Uplink and downlink always apply the same channel mode. For codec mode adaptation the receiving side performs link quality measurements of the incoming link. The measurements are processed yielding a Quality Indicator. For uplink adaptation, the Quality Indicator is directly fed into the UL mode control unit. This unit compares the Quality Indicator with certain thresholds and generates, also considering possible constraints from network control, a Codec Mode Command indicating the codec mode to be used on the uplink. The Codec Mode Command is then transmitted inband to the mobile side where the incoming speech signal is encoded in the corresponding codec mode. For downlink adaptation, the DL Mode Request Generator within the mobile compares the DL Quality indicator with certain thresholds and generates a Codec Mode Request indicating the preferred codec mode for the downlink. The Codec Mode Request is transmitted inband to the network side where it is fed into the DL Mode Control unit. This unit generally grants the requested mode. However, considering possible constraints from network control, it may also override the request. The resulting codec mode is then applied for encoding of the incoming speech signal in downlink direction. Both for uplink and downlink, the presently applied codec mode is transmitted inband as Codec Mode Indication together with the coded speech data. At the decoder, the Codec Mode Indication is decoded and applied for decoding of the received speech data. ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 7 ETSI TS 101 709 V7.7.0 (2001-11) TRAU BTS MS SPE speech data CHE CHD SPD DLcodec mode DLcodec mode (received) UL Mode Command DL- UL- DL- UL Mode Command Mode Ctrl Mode Ctrl Meas. (received) network UL Quality Indicator DL Quality Indicator control UL- DL- DL Mode Request Meas. Req.Gen r(eceived) DL Mode Request UL codec mode (received) SPD CHD CHE SPE speech data Figure 1: High level AMR block diagram Codec mode selection is done from a set of codec modes (ACS, Active Codec Set), which may include 1 to 4 AMR codec modes. Associated with this set is a list of 1 to 3 switching thresholds and hysteresis used by the DL Mode Request Generator and the UL mode control unit to generate the Codec Mode Requests and Codec Mode Commands. These configuration parameters (ACS, thresholds, hysteresis) are defined at call set-up and can be modified at handover or during a call. 3.1.2 Operation with ongoing Tandem Free Operation If tandem free operation is ongoing (see GSM 08.62) then the speech signal has to be transmitted over two radio links, first uplink (MS1 to BTS1) and then downlink (BTS2 to MS2), respectively symmetrically in the reverse direction. The optimal Codec Mode in direction MS1 to MS2 shall be derived from the Codec Mode Request for the first uplink (CMC1, within BTS1) and the Codec Mode Request derived for the second downlink (CMR2 within MS2) in the following way: MS2 shall send the CMR2 back to BTS2 in the usual way. BTS2 shall either accept this CMR2 (default) or may modify it according to network control needs: CMR2´. Then BTS2 shall send the CMR2´ further uplink to its TRAU2, to TRAU1 and downlink to BTS1 (see GSM 08.62 on how this transmission shall be handled on Abis and A interfaces). BTS1 combines the received CMR2´ with its own derived CMC1 by taking the minimum of both values. If needed, BTS1 may modify this minimum value according to own network control (--> CMC1´´) and shall send it finally downlink to MS1 as CMC. The identical procedure shall be performed in the reverse direction. Annex C gives an informative description. 3.1.3 Operation at handover with ongoing Tandem Free Operation Before and during an handover at one or both sides of the MS-to-MS connection, it may be needed to freeze the codec mode adaptation for a short while, e.g. to optimise the common Active Codec Set, or to allow fast (re-)synchronisation between BTS and TRAU or to optimise the CMI Phase in downlink. Both BTSs may therefore enable or disable the codec mode adaptation (see GSM 08.62). As long as the codec mode adaptation is frozen to a specific codec mode, then this codec mode shall be used in both directions as long as tandem free operation is ongoing, or tandem free operation shall be discontinued. The Codec Mode Requests from the MSs may be taken into account to decide whether to continue TFO or not, but not for codec mode adaptation. 3.2 Inband Signalling The AMR inband signalling consists of two parts: - Frequent signalling, used for Codec Mode Indication and Codec Mode Command/Request. - Robust, less frequent signalling, based on frame stealing, used for changing the AMR configuration (RATSCCH). ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 8 ETSI TS 101 709 V7.7.0 (2001-11) 3.2.1 Frequent inband signalling for AMR codec mode adaptation 3.2.1.1 General aspects The codec mode information, which has to be transmitted on each link, consists of Codec Mode Indications and Codec Mode Commands in the downlink, respectively Codec Mode Indications and Codec Mode Requests in the uplink. Codec Mode Indications inform the receiver about the currently applied codec mode. Codec Mode Commands inform the other end about the codec mode to be applied on the other link. Codec Mode Requests inform the other end about the preferred codec mode on the other link. Codec mode information is transmitted inband in the speech traffic channel, using a part of its transmission capacity. The coding of codec modes in the inband signalling is given in subclause 3.4.1. Channel coding of codec mode information is specified in GSM 05.03 [4] for all frame types. Codec modes are constrained to change only every second speech frame. Codec Mode Commands/Requests and Codec Mode Indications are sub-sampled such that they occur only every second frame. Codec Mode Indications and Codec Mode Commands/Requests shall be transmitted alternating within consecutive speech frames. Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together within every RATSCCH frame. 3.2.1.2 Operation with DTX enabled For SID_FIRST frames, the Codec Mode Indication or Codec Mode Command/Request in phase with the alternating transmission shall be transmitted (same phase as in speech frames). Both, Codec Mode Indication and Codec Mode Command/Request, shall be transmitted together in every SID_UPDATE frame (as in RATSCCH frames). For ONSET frames the Codec Mode Indication for the subsequent speech frame shall be transmitted, regardless of the phase of the inband signalling. The general phase of the inband signalling shall not be changed by that. 3.2.1.3 Transmitter/Receiver Synchronisation The alternating transmission of the codec mode information requires synchronisation of transmitting and receiving ends, such that Codec Mode Indications and Codec Mode Commands/Requests are decoded in correct order. To ensure proper synchronisation, the codec mode information shall be transmitted aligned to the 26-multiframe structure of the GSM system. For TCH/AFS, the default transmission phase shall be such that Codec Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) in the uplink and TDMA frames 4, 13, 21 (modulo 26) in the downlink as defined in GSM 05.02 [3]. For TCH/AHS, the default transmission phase shall be such that Mode Indications are sent with speech frames having their first burst sent on TDMA frames 0, 8, 17 (modulo 26) or 1, 9, 18 (modulo 26) depending on the subchannel in the uplink and TDMA frames 4, 13, 21 (modulo 26) or 5, 14, 22 (modulo 26) depending on the subchannel, in the downlink, as defined in GSM 05.02 [3]. This default phase of the Codec Mode Indication in downlink direction is called "odd", the alternative phase, one speech frame shifted, is called "even". The phase in uplink is always the same and is never changed. At call set-up, after every successful handover and after a channel mode modify with consistent Multirate IE, the default phase (odd) shall be used in downlink direction. During a call, the phase of Codec Mode Indication may be changed in downlink by using a RATSCCH message. In case of handover failure and fall back to the BTS before the handover attempt, the phase before the handover attempt shall be used again (except if a RATSCCH procedure is pending, see section 3.2.2.2 bullet 6). 3.2.2 Robust inband signalling for AMR configuration modification 3.2.2.1 General aspects The RATSCCH mechanism may be used in case of Tandem Free Operation to modify the AMR Configuration on the radio interface without interruption of the speech transmission. Its application for TFO is described in GSM 08.62. This ETSI 3GPP TS 05.09 version 7.7.0 Release 1998 9 ETSI TS 101 709 V7.7.0 (2001-11) recommendation defines the RATSCCH protocol and the RATSCCH messages. The channel coding is defined in GSM 05.03 and the receiver performance in GSM 05.05. RATSCCH handling is mandatory for MS and optional for BTS. RATSCCH is based on frame stealing. On TCH/AFS, one speech frame is stolen for each RATSCCH message, and on TCH/AHS two speech frames are stolen. In TCH/AHS RATSCCH is mapped onto two consecutive speech frames, the RATSCCH_MARKER and the RATSCCH_DATA. Both shall be sent always as one pair. FACCH frames have higher priority than RATSCCH frames. If FACCH and RATSCCH are scheduled for transmission for the same speech frame, then the FACCH shall be sent first, followed by the RATSCCH. If the RATSCCH is delayed due to FACCH, then the appropriate counters shall also be started as per section 3.2.2.2, based on actual transmission of the RATSCCH on the radio interface. If in the case of TCH/AHS, FACCH steals the second frame of one RATSCCH message (RATSCCH_DATA), the complete RATSCCH message (RATSCCH_MARKER and RATSCCH_DATA) shall be sent following the FACCH frame. 3.2.2.2 RATSCCH protocol The RATSCCH protocol elements consist of a number of REQuest Messages and three ACKnowledgement Messages. One information exchange consists typically of one REQ-ACK cycle between the "Initiator" and the "Addressee". While the Initiator is waiting for an ACK, it shall not send any new REQ message, i.e. transmission and acknowledgement of one REQ-ACK cycle shall be completed before the next cycle is started. ACK messages, as reaction to received REQ messages, shall always be sent back as soon as possible, and latest within 3 speech frames. Both sides shall continuously monitor the radio reception for the RATSCCH pattern and decode the RATSCCH message. The typical REQ-ACK cycle is defined as: 1) If one side ("Initiator") wants to initiate the information exchange, it shall send the desired REQ message. At the same time the Initiator shall start two counters: ACK_Timeout that shall count the elapsed speech frames occurrences (after REQ) in receive direction and REQ_Activation that shall count the elapsed speech frames occurrences (after REQ) in send direction . 2) If the REQ message was decoded error-free (by CRC check, see GSM 05.03 [4]) and is defined (see section 3.2.2.3) at receiver side ("Addressee"), then the Addressee shall send an ACK_OK message back. At the same time the Addressee shall start two own counters: REQ_Activation that shall count the elapsed speech frames occurrences after REQ in receive direction and ACK_Activation that shall count the elapsed speech frames occurrences after ACK in send direction. 3) If the Initiator receives an ACK_OK, then it shall ignore its ACK_Timeout counter and shall start an ACK_Activation counter instead that shall count the elapsed speech frames after ACK_OK in receive direction. 4) The contents of the REQ messages shall become valid in the direction from Initiator to Addressee exactly in that frame, where the REQ_Activation counters reach the value 12 and for all following frames. The contents of the REQ message shall become valid in the direction from Addressee to Initiator exactly in that frame, where the ACK_Activation counters reach the value 12 and for the following frames. Note: Due to the transmission delay and the reaction time within the Addressee (REQ to ACK) the activation takes place in general at four different points in time, but exactly synchronised and defined in both directions. 5) If another REQ message is received by the Adressee before REQ_Activation has elapsed, the Adressee shall ignore the message. 6) If, following a L3 message (e.g. ASSIGNMENT COMMAND or HANDOVER COMMAND) the physical layer is disconnected and reestablished on a new channel, any pending RATSCCH procedure shall be cancelled in the MS: the timers REQ_Activation and ACK_Activation are stopped and the configuration change required by the RATSCCH procedure is not performed. In the case the L3 procedure fails and the MS comes back to the original channel, any pending acknowledged REQ message shall be applied regardless the values of REQ_Activation and ACK_Activation. 7) If a L3 message CHANNEL MODE MODIFY with consistent MultiRate IE is received (see 3GPP TS 04.08), any pending RATSCCH procedure shall be cancelled in the MS: the timers REQ_Activation and ACK_Activation are stopped and the configuration change required by the RATSCCH procedure is not performed. ETSI