SIST ETS 300 946 E4:2003
(Main)Digital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP) for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface (GSM 04.22 version 5.3.1)
Digital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP) for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface (GSM 04.22 version 5.3.1)
SUBJECT HSCSD Corrections for 14.4 kbit/s
Digitalni celični telekomunikacijski sistem (faza 2+) – Protokol za radijsko povezovanje (RLP) podatkov in telematskih storitev o vmesniku sistema mobilna postaja-bazna postaja (MS-BSS) in vmesniku komutacijskega centra sistema bazne postaje-mobilne storitve (BSS-MSC) (GSM 04.22, različica 5.3.1)
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.VLVWHPDDigital cellular telecommunications system (Phase 2+) (GSM); Radio Link Protocol (RLP) for data and telematic services on the Mobile Station - Base Station System (MS - BSS) interface and the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface (GSM 04.22 version 5.3.1)33.070.50Globalni sistem za mobilno telekomunikacijo (GSM)Global System for Mobile Communication (GSM)ICS:Ta slovenski standard je istoveten z:ETS 300 946 Edition 4SIST ETS 300 946 E4:2003en01-december-2003SIST ETS 300 946 E4:2003SLOVENSKI
STANDARD
EUROPEANETS 300 946TELECOMMUNICATIONMarch 1998STANDARDFourth EditionSource: SMGReference: RE/SMG-040422QR3ICS:33.020Key words:Digital cellular telecommunications system, Global System for Mobile communications (GSM)GLOBAL SYSTEM
FOR MOBILE COMMUNICATIONSRDigital cellular telecommunications system (Phase 2+);Radio Link Protocol (RLP) for data and telematic services on theMobile Station - Base Station System (MS - BSS) interfaceand the Base Station System - Mobile-services Switching Centre(BSS - MSC) interface(GSM 04.22 version 5.3.1)ETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEInternet: secretariat@etsi.fr - http://www.etsi.fr - http://www.etsi.orgTel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1998. All rights reserved.SIST ETS 300 946 E4:2003
Page 2ETS 300 946 (GSM 04.22 version 5.3.1): March 1998Whilst every care has been taken in the preparation and publication of this document, errors in content,typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to"ETSI Editing and Committee Support Dept." at the address shown on the title page.SIST ETS 300 946 E4:2003
Page 3ETS 300 946 (GSM 04.22 version 5.3.1): March 1998ContentsForeword.51Scope.72Normative references.72.1Definitions and abbreviations.83Introduction.94Frame structure.104.1Basic frame structure.104.2RLP header.104.3Order of transmission.114.4Frame check sequence.115Elements and procedure.115.1Modes.115.1.1Asynchronous Balanced Mode (ABM).125.1.2Asynchronous Disconnected Mode (ADM).125.2Header and parameters.125.2.1Generally used bits.125.2.1.1Command/response bit, C/R.135.2.1.2Poll/Final bit, P/F.135.2.2Unnumbered frames, U.135.2.2.1Set asynchronous balanced mode SABM (11100).135.2.2.2Unnumbered Acknowledge. UA (00110).135.2.2.3Disconnect, DISC (00010).145.2.2.4Disconnected Mode, DM (11000).145.2.2.5Unnumbered Information, UI (00000).145.2.2.6Exchange Identification, XID (11101).145.2.2.7Test, TEST (00111).155.2.2.8Null information, NULL (11110).155.2.2.9REMAP (10001).155.2.3Supervisory frames, S, and numbered information transfer andsupervisory frames combined, I+S.165.2.3.1Numbering.165.2.3.2Send Sequence number, N(S).165.2.3.3Receive sequence number, N(R).165.2.3.4L2R Status bit.175.2.3.5Receive ready, RR (00).175.2.3.6Reject, REJ (01).175.2.3.7Receive not ready, RNR (10).175.2.3.8Selective reject, SREJ (11).175.3Error Recovery.185.3.1Improper frames.185.3.2N(S) sequence error.185.3.3N(R) error.185.3.4Time-out and checkpointing.185.3.4.1Treatment of errors during link establishment, link resetand link disconnect.185.3.4.2Treatment of errors during numbered information transfer.185.3.5Contentious situations.195.4Transitions between TCH/F9.6 and TCH/F14.4 channel codings.195.5List of system parameters.205.5.1RLP Version N°.20SIST ETS 300 946 E4:2003
Page 4ETS 300 946 (GSM 04.22 version 5.3.1): March 19985.5.2Maximum number of outstanding I frames k (Window size).205.5.3Timer T1.215.5.4Maximum number of retransmissions N2.215.5.5Data Compression Parameters.215.5.6Re-sequencing period (Timer T4).215.6Support for discontinuous transmission (DTX).216Service definitions.226.1Introduction.226.2Conventions.226.3Queue model.226.4List of Primitives.236.5Possible RLP time sequence diagrams.25Annex A (informative):RLP SDL Diagrams.28A.1List of RLP entity states.28A.1.1(main) states.28A.1.2state variables.28A.2List of RLP entity events.32History.64SIST ETS 300 946 E4:2003
Page 5ETS 300 946 (GSM 04.22 version 5.3.1): March 1998ForewordThis fourth edition European Telecommunication Standard (ETS) has been produced by the SpecialMobile Group (SMG) of the European Telecommunications Standards Institute (ETSI).This ETS specifies the Radio Link Protocol (RLP) for data transmission over within the digital cellulartelecommunications system.The specification from which this ETS has been derived was originally based on CEPT documentation,hence the presentation of this ETS may not be entirely in accordance with the ETSI rules.Transposition datesDate of adoption of this ETS:3 April 1998Date of latest announcement of this ETS (doa):30 June 1998Date of latest publication of new National Standardor endorsement of this ETS (dop/e):31 December 1998Date of withdrawal of any conflicting National Standard (dow):31 December 1998SIST ETS 300 946 E4:2003
Page 6ETS 300 946 (GSM 04.22 version 5.3.1): March 1998Blank pageSIST ETS 300 946 E4:2003
Page 7ETS 300 946 (GSM 04.22 version 5.3.1): March 19981ScopeThis European Telecommunication Standard (ETS) specifies the Radio Link Protocol (RLP) for datatransmission over the GSM PLMN. RLP covers the Layer 2 functionality of the ISO OSI Reference Model(IS 7498). It is based on ideas contained in IS 3309, IS 4335 and IS 7809 (HDLC of ISO) as well as CCITTX.25 and Q.92x (LAP-B and LAP-D of CCITT, respectively.) RLP has been tailored to the special needs ofdigital radio transmission. RLP provides to its users the OSI Data Link Service (IS 8886).RLP is intended for use with non-transparent data-transfer. Protocol conversion may be provided for avariety of protocol configurations. Those foreseen immediately are:-Character-mode protocols using start-stop transmission (IA5);-X.25 LAP-B.For reasons of better presentation, material about protocol conversion has been placed within thoseSpecifications concerned with the relevant Terminal Adaptors, i.e. GSM 07.02 for the asynchronous caseand GSM 07.03 for the synchronous case. Care must be taken that that material also applies toInterworking Functions; see GSM 09.04 - 09.07.2Normative referencesThis ETS incorporates by dated and undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to or revisions of any of these publicationsapply to this ETS only when incorporated in it by amendment or revision. For undated references, thelatest edition of the publication referred to applies.[1]GSM 01.04 (ETR 350): "Digital cellular telecommunication system (Phase 2+);Abbreviations and acronyms".[2]GSM 04.21 (ETS 300 945): "Digital cellular telecommunication system; Rateadaption on the Mobile Station - Base Station System (MS - BSS) interface".[3]GSM 07.02 (ETS 300 914): "Digital cellular telecommunication system(Phase 2+); Terminal Adaptation Functions (TAF) for services usingasynchronous bearer capabilities".[4]GSM 07.03 (ETS 300 584): "Digital cellular telecommunication system(Phase 2); Terminal Adaptation Functions (TAF) for services using synchronousbearer capabilities".[5]GSM 09.04: "Digital cellular telecommunication system; Interworking betweenthe Public Land Mobile Network (PLMN) and the Circuit Switched Public DataNetwork (CSPDN)".[6]GSM 09.05: "Digital cellular telecommunication system; Interworking betweenthe Public Land Mobile Network (PLMN) and the Packet Switched Public DataNetwork (PSPDN) for Packet Assembly/Disassembly facility (PAD) access".[7]GSM 09.06 (ETS 300 975): "Digital cellular telecommunication system(Phase 2+); Interworking between a Public Land Mobile Network (PLMN) and aPacket Switched Public Data Network/Integrated Services Digital Network(PSPDN/ISDN) for the support of packet switched data transmission services".[8]GSM 09.07 (ETS 300 976): "Digital cellular telecommunications system(Phase 2+); General requirements on interworking between the Public LandMobile Network (PLMN) and the Integrated Services Digital Network (ISDN) orPublic Switched Telephone Network (PSTN)".SIST ETS 300 946 E4:2003
Page 8ETS 300 946 (GSM 04.22 version 5.3.1): March 1998[9]CCITT Recommendation I.440 (Redbook): "ISDN user-network interface datalink layer - General aspects".[10]CCITT Recommendation I.441 (Redbook): "ISDN user-network interface, datalink".[11]CCITT Recommendation Q.920 (Redbook): "ISDN user-network interface datalink layer - General aspects".[12]CCITT Recommendation Q.921 (Redbook): "ISDN user-network interface - datalink".[13]CCITT Recommendation Q.921bis: "Abstract test suites for LAPD conformancetests".[14]CCITT Recommendation Q.922: "ISDN data link layer specification for framemode bearer services".[15]CCITT Recommendation V.42bis: "Data Compression for Data CircuitTerminating Equipment (DCE) using Error Correction Procedures".[16]CCITT Recommendation X.25 (Redbook): "Interface between Data TerminalEquipment (DTE) and Data Circuit Terminating Equipment (DCE) for terminalsoperating in Packet Mode and connected to Public Data Networks by dedicatedCircuit".[17]ISO/IEC Recommendation 4335: "Information technology - Telecommunicationsand information exchange between systems - High level data link control(HDLC) procedures - Elements of procedures".[18]ISO Recommendation 3309: "Information technology - Telecommunications andinformation exchange between systems - High level data link control (HDLC)procedures - Frame structure".[19]ISO Recommendation 7498: "Information processing systems - Open SystemsInterconnection - Basic Reference Model".[20]ISO Recommendation 8885: "Information technology - Telecommunication andinformation exchange between systems - High-level data link control (HDLC)procedures - General purpose XID frame information field content and format".[21]ISO Recommendation 8886: "Information technology - Telecommunication andinformation exchange between systems - Data link service definitions for OpenSystems interconnection".[22]ISO Recommendation 8509: "Information processing systems - Open SystemsInterconnection - Service conventions".[23]ISO/IEC Recommendation 7809: "Information technology - Telecommunicationand information exchange between systems - High-level data link control(HDLC) procedures - Classes of procedures".[24]ISO Recommendation 7776: "Information processing systems - High-level datalink control procedures - Description of the X.25 LAPB-compatible DTE data linkprocedures".2.1Definitions and abbreviationsAbbreviations used in this ETS are listed in GSM 01.04 [1].For the purposes of this ETS, the following definitions apply:SIST ETS 300 946 E4:2003
Page 9ETS 300 946 (GSM 04.22 version 5.3.1): March 1998backwards compatibility: RLP defines several backwards-compatible versions. That means that anewer version can interwork with an older one without changing the older one. This is realized by a fallback mechanism during XID exchange.command: An instruction represented in the RLP header, causing the receiving RLP entity to execute aspecific function.frame check sequence: A field of redundant information based on a cyclic code, used for error detection.I + S frame: An RLP frame that is used for user information transfer, carrying supervisory informationpiggyback.improper frame: An RLP frame having an FCS error or having a header the contents of which isinconsistent with this Specification.non-transparent: In PLMN data transmission, a configuration where at layer 2, protocol information of thefixed network is mapped on RLP elements, and vice versa.piggybacking: Means by which one and the same frame can carry both user information and RLP relatedsupervisory information.response: A reply represented in the RLP-header, by which the sending RLP entity reports back about itsstatus.RLP frame: A sequence of contiguous bits, representing an RLP procedural element.RLP header: That part of an RLP frame that encodes either a command or a response, located at thebeginning of the RLP frame.S frame: An RLP frame that contains supervisory information in the absence of user information.transparent: In PLMN data transmission, a configuration where at layer 2 (and also at the layers above)no protocol conversion takes place.U frame: An RLP frame that contains unnumbered protocol control information.3IntroductionThree versions of RLP are defined:-RLP version 0: single-link basic version;-RLP version 1: single-link extended version (e.g. extended by data compression);-RLP version 2: multi-link version.RLP uses one (single-link) or from 1 up to 4 (multi-link) physical links. However, the RLP multi-link versionis designed to be able to support up to 8 physical links. If, in the call setup signalling, either end indicatesthat it cannot support multilink operation, neither end shall require usage of RLP-versions higher than 1. Ifthe BC negotiation during call setup results in a possibility for multi-link operation during the call, both endsshall require and accept RLP version 2 only.If the BC negotiation during call setup results in maximum number of traffic channels = 1 TCH and UIMI =not required/not allowed or up to 1 TCH/F allowed/may be requested, this is interpreted as if at least oneend does not support multilink operation, and neither end shall require RLP version higher than 1.RLP makes use of an underlying FEC (Forward Error Correction) mechanism. For RLP to performadequately it is assumed that the basic radio channel together with FEC provides for a block error rate ofless than 10 %, where a block consists of 240 or 576 bits (Further study on the BLER for 576-bit blocks isneeded). Furthermore, it is assumed that in case of multi-link RLP the difference of the delay between allphysical links is less than timer T4.SIST ETS 300 946 E4:2003
Page 10ETS 300 946 (GSM 04.22 version 5.3.1): March 1998RLP frames are sent in strict alignment with the radio transmission. (For details, see GSM 04.21). RLPframes are of a
fixed size of 240 (TCH/F9.6 channel coding) or 576 bits (TCH/F14.4 channel coding).Whenever a frame is to be sent, the RLP entity has to provide the necessary protocol information to becontained in it. Provision is made for discontinuous transmission (DTX).RLP spans from the Mobile Station (MS) to the interworking function (IWF), located at the nearest MobileSwitching Centre (MSC), or beyond. Depending on the exact location of the IWF, handover of the MS mayresult in link-reset or even total loss of the connection.In the terminology of HDLC, RLP is used in a balanced configuration, employing asynchronous operation,i.e. either station has the right to set-up, reset, or disconnect a link at any time. Procedural means areprovided for to deal with contentious situations, should they ever occur.RLP is full-duplex in the sense that it allows for information to be transferred in both directionssimultaneously.4Frame structure4.1Basic frame structureAn RLP-frame has a fixed length of either 240 or 576 bits consisting of a header, an information field, andan FCS (frame check sequence) field. The size of the components depends on the the radio channel type,RLP version and on the RLP frame. As a benefit of using strict alignment with underlying radiotransmission there is no need for frame delimiters (like flags etc.) in RLP. In consequence, there is no "bit-stuffing" necessary in order to achieve code transparency. Frames cannot be aborted while beingtransmitted.a) 240 bit frame sizeHeaderInformationFCSversion 0 and 1, version 2 (U framesonly)16 bit200 bit24 bitversion 2 (S and I+S frames only)24 bit192 bit24 bitb) 576 bit frame sizeHeaderInformationFCSversion 0, 1, and version 2 (U framesonly)16 bit536 bit24 bitversion 2 (S and I+S frames only)24 bit528 bit24 bitFigure 1: Frame structure4.2RLP headerAn RLP-header carries one of three types of control information, the first being unnumbered protocolcontrol information (U frames), the second being supervisory information (S frames), the third being userinformation carrying supervisory information piggybacked (I + S frames).SIST ETS 300 946 E4:2003
Page 11ETS 300 946 (GSM 04.22 version 5.3.1): March 19984.3Order of transmissionThe header, as defined in clause 5.2, shall be transmitted from left to right. The FCS shall be transmittedcommencing with the highest order term. The order of bit transmission for the information field is from leftto right.4.4Frame check sequenceThe FCS shall be the ones complement of the modulo 2 sum of:a)the remainder of:For 9.6/4.8 kbit/s channel coding:x216 (x23 + x22 + x21 + x20 + x19 + x18 + x17 + x16 + x15 + x14 + x13 + x12 + x11 + x10 + x9 + x8 + x7 + x6 + x5 + x4 +x3 + x2 + x + 1)For 14.4kbit/s channel coding:x552 (x23 + x22 + x21 + x20 + x19 + x18 + x17 + x16 + x15 + x14 + x13 + x12 + x11 + x10 + x9 + x8 + x7+ x6 + x5 + x4 + x3 + x2 + x + 1divided modulo 2 by the generator polynomial:x24 + x23 + x21 + x20 + x19 + x17 + x16 + x15 + x13 + x8 + x7 + x5 + x4 + x2 + 1andb)the remainder of the division modulo 2 by the generator polynomial:x24 + x23 + x21 + x20 + x19 + x17 + x16 + x15 + x13 + x8 + x7 + x5 + x4 + x2 + 1of the product of x24 by the content of the frame, excluding the FCS field. (The first bit transmittedcorresponds to the highest order term.)Implementation note: As a typical implementation, at the transmitter, the initial content of the register ofthe device computing the remainder of the division is pre-set to all ones and is then modified by division bythe generator polynomial (as described above) of the header and information field; the ones complementof the resulting remainder is transmitted as the 24 bit FCS sequence.At the receiver, the initial content of the register of the device computing the remainder is pre-set to allones. The final remainder after multiplication by x24 and then division (modulo 2) by the generatorpolynomial:x24 + x23 + x21 + x20 + x19 + x17 + x16 + x15 + x13 + x8 + x7 + x5 + x4 + x2 + 1of the serial incoming protected bits and the FCS will be:0 1 1 0 1 1 0 1 1 0 0 0 1 0 0 1 0 0 1 1 0 0 0 0 (x23 to x0, resp.)in the absence of transmission errors.5Elements and procedure5.1ModesAn RLP entity can be in one of two modes:-Asynchronous Balanced Mode (ABM)-Asynchronous Disconnected Mode (ADM)SIST ETS 300 946 E4:2003
Page 12ETS 300 946 (GSM 04.22 version 5.3.1): March 19985.1.1Asynchronous Balanced Mode (ABM)In ABM, which is the data link operational mode, either RLP entity may send commands at any time andmay initiate response frame transmission without receiving explicit permission to do so from the otherRLP-station. In ABM, frames shall be used for information field transfer and/or to indicate status changesin the RLP-station.5.1.2Asynchronous Disconnected Mode (ADM)In ADM, which is the data-link non-operational mode, the RLP entity shall be logically disconnected fromthe data link and shall, therefore, neither transmit nor accept numbered information frames.The RLP entity shall, however, be permitted to transmit and accept NULL, DM, UI, TEST and XID frames.Either RLP entity can issue an SABM command at any time, in order to terminate the ADM state. In thatcase, entrance of the ABM state will be indicated by a UA response from the opposite station. If theopposite station is not able to enter ABM, it will indicate this by a DM response. All commands other thanthose mentioned above and any unsolicited response will be ignored in ADM under all circumstances.5.2Header and parametersThe formats defined for the header are listed in figure 2.5.2.1Generally used bitsNOTES:C/R = COMMAND/RESPONSE BITP/F = POLL/FINAL BITX
= DON'T CARESM1M2M3M4M51 1 1 0 0S A B M0 0 1 1 0U A0 0 0 1 0D I S CS1S21 1 0 0 0D M00R R1 1 1 1 0NULL01R E J0 0 0 0 0U I10R N R1 1 1 0 1X I D11S R E J0 0 1 1 1T E S T1 0 0 0 1REMAPVersions 0 and 1:NOTES:N(S) : Bit 4 low order bitN(R) : Bit 11 low order bitUC/RXX111111P/FM1M2M3M4M5XSC/RS1S2011111P/F______________
N (R)
______________I+SC/RS1S2______________
N (S)
______________P/F______________
N (R)
______________bit12345678910111213141516SIST ETS 300 946 E4:2003
Page 13ETS 300 946 (GSM 04.22 version 5.3.1): March 1998Version 2:NOTES:S=L2R Status BitN(S) : Bit 1 low order bitN(R) : Bit 14 low order bitUC/RXX111111P/FM1M2M3M4M5XSXXX011111P/FC/RS1S2______________
N(R)
______________XXI+S______________
N(S)
______________P/FC/RS1S2______________
N(R)
______________SXbit123456789101112131415161718192021222324Figure 2: Header formats5.2.1.1Command/response bit, C/RThe C/R-bit is used to indicate whether the frame is a command or response frame and whether theP/F-bit is to be interpreted as a poll or final bit, resp. For commands, the C/R bit shall be set to "1", forresponses it shall be set to "0".5.2.1.2Poll/Final bit, P/FThe P/F-bit is used to mark a special instance of command/response exchange. With a command, it iscalled the P-bit, with a response, it is called the F-bit. In any one direction, only one P/F-bit exchange maybe outstanding at any time. A response with the F-bit set to "1" shall always reflect the latest receive statusof the RLP entity.A P/F-bit exchange always starts with a command frame with the P-bit set to "1", which shall be answeredby a response frame with the F-bit set to "1" at the earliest response opportunity.No unsolicited F-bit = "1" is allowed. Such a frame shall be considered "improper" (see subclause 5.3.1).In ABM, the use of the P/F-bit with numbered information exchange is only allowed for checkpoint-recovery (see subclause 5.3.3).5.2.2Unnumbered frames, U5.2.2.1Set asynchronous balanced mode SABM (11100)The SABM encoding is used as a command only. It is always used with the P-bit set to "1".The SABM command is used either to initiate a link for numbered information transfer, i.e. to go fromADM to ABM, or to reset a link already established for numbered information transfer. With an SABMcommand, no information transfer is allowed.When issuing an SABM, the RLP entity has set to zero its internal variables for sending and receivingnumbered information. The other RLP entity, on receiving an SABM command, will either confirm it bysetting to zero its internal variables for sending and receiving numbered information and then issuing anUA (unnumbered acknowledgement) response or reject it by sending a DM (disconnected mode)response. In the former case, both entities have entered ABM and numbered information transfer maycommence. In the latter case, both entities are in ADM.When an SABM command is issued, a loss of information may occur. Appropriate action is in theresponsibility of the layers above.5.2.2.2Unnumbered Acknowledge. UA (00110)The UA encoding is used as a response only. It is used to positively acknowledge an SABM or DISCcommand. With the UA response, no information transfer is allowed.SIST ETS 300 946 E4:2003
Page 14ETS 300 946 (GSM 04.22 version 5.3.1): March 19985.2.2.3Disconnect, DISC (00010)The DISC encoding is used as a command only. It is used to disestablish a link, previously established fornumbered information transfer, i.e. to terminate ABM and go into ADM. With the DISC command, noinformation transfer is allowed.The other RLP-entity shall answer with a UA response before actioning the DISC command. When aDISC command is actioned, loss of information may occur. It is the responsibility of the layers above, toprovide for a "graceful" disconnect.5.2.2.4Disconnected Mode, DM (11000)The DM encoding is used as a response only. It is used by RLP entity to report that it is in ADM and, as ananswer to SABM, that it is (possibly temporary) unable to action a mode setting command. With the DMresponse, no information transfer is allowed.5.2.2.5Unnumbered Information, UI (00000)The information field is to be interpreted as unnumbered information. Unnumbered Information (UI)frames can be sent in both ADM and ABM. There is no acknowledgement of receipt of UI-frameswithin RLP.5.2.2.6Exchange Identification, XID (11101)The information field is to be interpreted as exchange identification. This frame is used to negotiate andrenegotiate parameters of RLP and layer 2 Relay function. XID frames can be sent in both ADM and ABM.The negotiation procedure is one step i.e. one side will start the process by sending an XID command,offering a certain set of parameters from the applicable parameter repertoire (see table 1) the sendingentity wants to negotiate proposing values within the allowed range. In return, the other side will send anXID response, either confirming these parameter values by returning the requested values, or offeringhigher or lower ones in their place (see table 1 for sense of negotiation), except when the indicated RLPversion is a lower one where a limited set of those parameters presented in the XID command may beanswered according to the negotiated version. In RLP versions higher than "0", any unrecognisableparameters will be ignored. Default values will apply to those parameters which are not commented uponby the responding side (see section 5.4 for default values). This normally will end the negotiation process.XID frames are always used with the P/F-bit set to "1".Without any prior XID exchange, default values will apply (see section 5.4). A negotiation of datacompression parameters (see table 1) is only allowed in ADM. In addition, in RLP version 2, negotiation ofRLP version N°(see table1) is only allowed in ADM.In the case of a collision of XID commands, all XID commands shall be ignored. The MS shall restart theparameter negotiation on expiry of T1, while the Interworking Function shall do so on expiry of twice thevalue of T1. An unsuccessful XID exchange shall be repeated on expiry of T1. After N2 times ofunsuccessful repetition, the link shall be disconnected.In table 1 a list of parameters is given which constitute the parameter repertoire. In addition, the format ofthe XID information field is given.Table 1: XID parametersParameter NameTypeLengthFormat(87654321)UnitsSense ofNegotiationValid inVersionsRLP version N°11bbbbbbbb*./.down³ 0IWF to MS window size2100bbbbbb./.down0.1IWF to MS window size2100bbbbbb8down³ 2MS to IWF window size3100bbbbbb./.down0.1MS to IWF window size3100bbbbbb8down³ 2SIST ETS 300 946 E4:2003
Page 15ETS 300 946 (GSM 04.22 version 5.3.1): March 1998Acknowledgement Timer(T1)41bbbbbbbb10msup³ 0Retransmission attempts (N2)51bbbbbbbb./.up³ 0Reply delay (T2) **61bbbbbbbb10msup³ 0CompressionPTP0P1 lowP1 highP274aaaa
00bbccccccccccccccccdddddddd././././.nonesee [15]downdown³ 1Re-sequencing timer (T4) **81bbbbbbbb10 msup³ 2* NOTE 1:Characters "a", "b", "c" and "d" indicate a bit which is part of the parameter value inquestion. Parameters indicated by "a" are not negotiable.** NOTE 2:In case of negotiation of this parameter it may be necessary to negotiate also the othertimer values (e.g. "Acknowledgement timer" (T1)).The type and length are encoded within one octet, the type field occupying bits 8 to 5 and the length fieldoccupying bits 4 to 1; 1 resp. 5 being the least significant bit. The least significant bit shall always betransmitted first.A parameter item consists of the type/length-octet followed by the value of that parameter, where thelength-indicator gives the number of octets the value actually occupies. Such parameter items may bearranged in arbitrary order, with the exception of the RLP version number, which shall be sent first in RLPversions higher than "0". The parameter items must begin in the first octet of the XID-information field andfollow on contiguously. The parameter list is delimited by parameter type zero.5.2.2.7Test, TEST (00111)The information field of that frame is to be interpreted as test information. Test frames can be sent in bothADM and ABM. A test sequence is always initiated by sending a TEST command in one direction andcompleted by sending a TEST response in the other direction.5.2.2.8Null information, NULL (11110)In ADM, null-frames shall be sent each time there is a send opportunity but no UI, TEST or XID frame isawaiting transmission.In ABM, null-frames shall be sent in reset state if there is a send opportunity and no unnumbered framesare to be sent.The information field is to be interpreted as null information i.e. the information field is not used and itscontents may be arbitrary.5.2.2.9REMAP (10001)A REMAP-exchange can only take place in ABM when the RLP-entities are in synchronisation modefollowing a change of channel coding. The exchange is started by the mobile-end which sends a REMAPcommand U-frame in the information field of which the RLP-entity indicates the N(R) of the frame -according to the ‘old’ frame format - from which the network-end should resend the information mappedinto a frame format corresponding to the new channel coding. The mobile-end sends a REMAP-frame onevery sending opportunity until a responding REMAP-frame is received from the network-end. Thenetwork-end answers by sending a REMAP U-frame with the C/R-bit set to ‘Response’. In the information-field the network-end indicates the N(R)-number of the frame from which the mobile-end should remapthe information into the new frame format. The network-end responds to all REMAP-commands itreceives. Any REMAP-acknowledgement that may arrive at the mobile-end after one of them has beenreceived is discarded by the mobile-end. The RLP shall supervise the synchronisation state by a timer withthe value of N2*T1. If the network-end does not receive an appropriate U-frame within N2*T1, it entersADM. If the mobile-end does not receive a response within N2´T1 measured from the transmission of thefirst command, it enters ADM.SIST ETS 300 946 E4:2003
Page 16ETS 300 946 (GSM 04.22 version 5.3.1): March 1998In addition to the N(R)-information the REMAP-frame information field can include any XID-parametersthat should be renegotiated because of the change of channel coding. The procedures concerning theseXID-parameters are as defined in section 5.2.2.6 (Exchange Identification) except that the mobile-endalways starts the negotiation. Also the mapping of the parameters is as defined in section 5.2.2.6(Exchange Identification) except that the first two octets in the REMAP information field are occupied bythe N(R)-number (The LSB is transmitted first). If no XID-parameters are included in the REMAP-information field, the values used before the change of channel coding remain valid. The information fieldmust, however, always include parameter type zero, which delimits the XID-parameter list.Header 16 bitsN(R) 6 bitsxxxxxxxxxxXID parameters00000000xxxxxxFCS 24 bits
Information field either 200 or 536 bitsx= don’t carea.) version 0 and 1Header 16 bitsN(R) 9 bitsxxxxxxxXID parameters00000000xxxxxxFCS 24 bits
Information field either 200 or 536 bitsx= don’t careb.) version 2Figure 3: REMAP U-frame format5.2.3Supervisory frames, S, and numbered information transfer and supervisory framescombined, I+SIn ABM, there are cases where there is no user information pending transmission. In consequence,supervisory (S) frames alone must be conveyed. In such cases, the information field is to be interpretedas null information, i.e. the information field is not used and may be of arbitrary contents.For reasons of optimization in the special situation of digital radio transmission, numbered informationtransfer frames carry also supervisory type information ("piggy-backing"). Numbered information can beexchanged only in ABM.NOTE:The extent to which piggy-backing is used by the sending RLP entity is optional. AnRLP entity receiving any of allowed piggy-backed formats, however, shall take theappropriate actions. Implementors should be aware that not using the full capability ofpiggy-backing could, in certain circumstances, result in a less than optimalperformance.5.2.3.1NumberingEach I frame is sequencially numbered and may have the value 0 through M-1, where M is the modulus.The modulus M is 62 (single-link) or 496 (multi-link).5.2.3.2Send Sequence number, N(S)The send sequence number contains the number of the I frame. With the exception of SREJ conditions,information frames are transmitted in numerical order of their N(S). If multiple physical links are used, theframes may arrive the receiver in another order. Normal information transfer is halted, when the number ofoutstanding, unacknowledged frames is equal to the currently established window size (see section 5.4).5.2.3.3Receive sequence number, N(R)The N(R) field is used in ABM to designate the next information frame to be sent by the other RLP entityand to confirm that all frames up to and including N(R) - 1 have been received properly. As an exceptionto this, in the case of SREJ (selective reject), N(R) designates the information frame that is selectivelyrejected and thus requested for retransmission. In this case, no previously received frames are confirmed.SIST ETS 300 946 E4:2003
Page 17ETS 300 946 (GSM 04.22 version 5.3.1): March 19985.2.3.4L2R Status bitThe L2R status bit set to „1“ indicates that the L2R PDU transported in the information field of the RLPPDU contains at least a status octet. Otherwise, the L2R PDU contains only user data. The bit is only usedfor RLP-version 2.5.2.3.5Receive ready, RR (00)The RR encoding can be used either as command or response. In ABM, it is used by an RLP entity toconfirm all information frames up to and including N(R)-1. In doing so, the RLP-station allows the otherstation to transmit up to k additional information frames, counting from N(R) onwards. The issue of an RRcommand/response clears any previous busy condition in that direction.5.2.3.6Reject, REJ (01)The REJ encoding can be used either as command or response. It is used by an RLP entity to indicatethat in numbered information transfer one or more out-of sequence frames have been received. Framesup to and including N(R)-1 have been received correctly, frames N(R) and following are requested to beretransmitted. Following retransmission of those frames, further frames awaiting initial transmission maybe sent. With respect to each direction of transmission, only one REJ condition may exist at any giventime.A REJ condition is cleared:-on receipt of the frame numbered N(R);-on time-out;-or on reset (SABM).An REJ shall be sent at the earliest opportunity. On time-out, REJ frames shall not be repeated. AnRLP-entity receiving an REJ frame with the same N(R), which has already been the starting frame of aretransmission sequence due to P/F-bit checkpointing, shall inhibit the retransmission due to thatparticular REJ frame.5.2.3.7Receive not ready, RNR (10)The RNR encoding can be used either as command or response. It is used by an RLP entity to indicatethat it is temporarily not ready to receive numbered information frames. In that case, the RLP entity is saidto be in the busy condition. All frames up to and including N(R)-1 shall be considered acknowledged.Subsequent frames, if any, shall not be considered confirmed. The acceptance status of those is a matterof further status exchange.5.2.3.8Selective reject, SREJ (11)The SREJ encoding can be used either as command or response. The SREJ command/response is usedto request retransmission of a single frame, thus, under certain circumstances, providing for more efficienterror recovery than by REJ. No acknowledgement of received I frames is indicated by an SREJ frame,thus allowing an RLP entity to transmit one or more SREJ frames with a different N(R) before earlierSREJ conditions have been cleared.An SREJ condition shall be cleared:-on receipt of an information frme with N(S) equal N(R) of the SREJ;-on time out;-on reset (SABM).No SREJ shall be issued during a pending REJ condition. For each frame, only one SREJ condition mayexist at any time.SREJ frames shall be sent at the earliest possibility. On time-out, SREJ frames may be repeated.NOTE:Sending SREJ commands/responses is not mandatory.SIST ETS 300 946 E4:2003
Page 18ETS 300 946 (GSM 04.22 version 5.3.1): March 19985.3Error Recovery5.3.1Improper framesFrames containing an FCS error or having a control field the contents of which is not implemented orinconsistent with those defined in this Specification are called improper frames. Improper frames shall beignored, i.e. the receiving RLP station shall not make any use of their contents.5.3.2N(S) sequence errorIn numbered information transfer, any information frame with an N(S) out of the normal sequence shalllead to an N(S) sequence error condition, unless that frame is requested for retransmission by an SREJ,sent at an earlier time. In case multiple channels make up a connection when the multi-link version
isused the received frames must be re-sequenced. For that a timer T4 defines a re-sequencing period (seesection 5.4) during which frames may be out-of-order. An N(S) sequence error condition only occurs if theN(S) arrives after the expiry of T4. There are three mechanisms to deal with N(S) sequence errors:-REJ recovery;-SREJ recovery;-P/F-bit recovery (checkpointing);the first two being the responsibility of the receiving station, the last being the responsibility of the sendingstation. There are no strict rules as to whether REJ or SREJ recovery shall be applied, however, if astation decides to initiate REJ or SREJ recovery, it shall do so at the earliest opportunity. The informationpart of out-of sequence frames shall be discarded, unless the receiving station intends to initiate SREJrecovery.5.3.3N(R) errorAny confirming N(R) that is not in the range of the window size shall be ignored.5.3.4Time-out and checkpointingAll frames requiring a response or acknowledgement shall be guarded by time-out (timer T1). In detail,those frames are:-SABM;-DISC;-REJ;-SREJ;-numbered information frames (see note);-any frame with the P-bit set to "1" in ABM, i.e. checkpointing.NOTE:T1 started, or restarted if already running, on the transmission of every numberedinformation frame.5.3.4.1Treatment of errors during link establishment, link reset and link disconnectAn SABM, which is not answered by either UA or DM within the timer period, shall be repeated up to N2times (Action on finally unsuccessful SABM is for further study, pending decisions on stationmanagement.)A DISC, which is not answered by UA within the timer period, shall be repeated up to N2 times. If theDISC is finally unanswered, the RLP station will go into ADM in any case. For this reason, it is theresponsibility of the management of any RLP entity to put the RLP entity into ADM, should there be anindication of a permanent outage, i.e. a loss of connectivity longer than N2 times the timer value.5.3.4.2Treatment of errors during numbered information transferThe last frame of a sequence of numbered information frames shall also be guarded by time-out. If neithera positive acknowledgement nor a REJ is received, the RLP entity will start checkpoint recovery, i.e. theSIST ETS 300 946 E4:2003
Page 19ETS 300 946 (GSM 04.22 version 5.3.1): March 1998station will send a frame with the P-bit set to "1", requesting the latest status information from the otherentity, indicated by the F-bit set to "1". In that case, status information is carried either by RR or RNRrespons
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...