ETSI EP BRAN
`
`WG3 Temporary document wg3td76
`13. October 1997
`
`page 1
`
`Source:
`
`Dietmar Petrasz, Ulrich Vornefeld1, Markus Scheibenbogen1
`
`1ComNets, RWTH Aachen, Germany
`
`2Bosch Telecom GmbH, Backnang, Germany
`
`Title:
`
`Candidate protocol stack (MAC + LLC) for a Wireless ATM air in-
`terface
`
`Agenda item:
`
`Document for: —-
`—III
`—III
`
`
`
`1
`
`Decision/action requested
`
`References
`(most of the papers are available at http://www.comnets.rvvth—aachen.de/~petras/Publications
`
`[1] M88 Project. Mobile Broadband System: System Description Document. Technical report, RACE
`il, 1995.
`
`[2]
`
`http:/lhosteriacet.ptlsamba/GenerailGeneralMain.htm
`
`[3]
`
`http://wwwcomnets.nNth—aachendelprojectlATMmobillhome.html
`
`[4] ETSI BRAN, WG 3 temp. doc. 28, D. Petras, Rea/isation of an ATM Cell Scheduler at an
`Air lnterface and comparison of appropriate Service Strategies for VBR Services
`
`ATM
`
`[5] H. Kist, D. Petras, Service Strategy for VBR Services at an ATM Air interface, EPMCC ‘97, Bonn,
`Germany, Sep. 1997
`
`[6]
`
`B. Walke, D. Petras, D. PIaBmann, Wireless ATM: Air Interface and Network Protocols of the
`mobile Broadband System,
`iEEE Personal Communications Magazine, vol. 3, pp. 50—56, Aug.
`1996.
`
`[7] D. Petras, A. Hettich, Pen‘ormance Evaluation of a Logical Link Control Protocol for an ATM Air
`lnterface, Int. J. of Wireless Information Networks, 1997.
`
`wgStd76.doc
`
`Broadcom v. Ericsson
`
`|PR2013-00636
`
`ERicsson Ex. 2025
`
`

`

`Temporary document WG3TD76
`page 2 of 26
`
`[8] D. Petras, A. Kramling, Wireless ATM: Performance Evaluation of DSA++ MAC Protocol with fast
`Collision Resolution by a Probing Algorithm, Int. J. of Wireless Information Networks, 1997.
`
`[9] D. Petras, A. Kramllng, Fast Collision Resolution in Wireless ATM Networks.
`Vienna, Austria, Feb. 1997.
`
`In 2nd MATHMOD,
`
`[10] D. Petras, M. Radimirsch, A. Kramling, U. Vornefeld, Support ofATM Service Classes in Wireless
`ATM Networks.
`In ACTS Mobile Communication Summit 1997, Aalborg, Denmark, Oct. 1997
`
`[11] D. Petras, A. Kramling, A. Hettich, MAC Protocol for Wireless ATM; contention free versus con-
`tention based Transmission of Reservation Requests. In PIMRC‘96, Taipei, Taiwan, Oct. 1996
`
`[12] D. Petras, A. Hettich, A. Kramling, Performance Evaluation ofa Logical Link Control Protocol for
`an ATM Air Interface. In PIMRC’96, Taipei, Taiwan, Oct. 1996
`
`[13] D. Petras. Medium Access Control Protocol for Wireless, transparent ATM access. In IEEE Wire—
`less Communication Systems Symposium, Long Island, NY, Nov. 1995.
`
`[14] D. Bertsekas, R. Gallager. Data Networks. Prentice—Hall, Englewood Cliffs, NJ, 1987.
`
`[15] Ed. Weldon. An Improved Selective-Repeat ARQ Strategy. IEEE Transactions on Communica-
`tions, Vol. COM-30,3, pp. 480-486, March 1982.
`
`[16] ETSI BRAN, WG 3 temp. doc. 42 A. Hettich, U. Vornefeld, J. Rapp, ARQ Protocols for Wireless
`ATM systems: requirements and solutions
`
`[17]
`
`lTU—T Recommendation |.356: B-lSDN ATM Layer Cell Transfer Performance, Geneva 1993.
`
`2 Introduction
`
`The department of Communication Networks (ComNets) of the Aachen University of Technology has
`been involved in wireless ATM projects since 1992.
`It has been responsible for the system studies in
`the Mobile Broadband System (MBS) project of RACE II.
`It is currently involved in the ACTS SAMBA
`(System for Advanced Mobile Broadband Application) project [2]. Furthermore,
`it leads the German
`national project ATMmobil [3], that Is supported by the German Federal Minister of Education, Sci—
`ence, Research and Technology (BMBF). The ATMmobil project is studying system concepts and
`technologies as well as building demonstrators for different configurations of wireless ATM systems:
`cellular ATM system, wireless ATM LAN and ATM Wireless Local Loop and IBMS (Integrated Broad—
`band Mobile System).
`
`ComNets has accompanied its system studies on wireless ATM with extensive simulation works. The
`implemented wireless ATM simulator is based on realistic models for radio channel and load genera—
`tors. A complete protocol stack for an ATM air interface has been developed,
`implemented in the
`simulator and evaluated in deep detail. The concepts of the simulation model, the obtained results and
`experiences provide the basis for the implementation of the protocol stack for the demonstrators of the
`SAMBA and ATMmobil projects, which is currently carried out at ComNets.
`
`The SAMBA and ATMmobil projects are focusing on the support of the full functionality of an ATM
`system. There is a special attention to the support of CBR/VBR services, since the ability to transport
`real—time services is the main advantage of ATM compared to IP and thus should also be the motiva—
`tion for an wireless ATM system compared to conventional wireless LANs like HIPERLAN/1. Thus,
`one of the main features of the SAMBA and ATMmobil demonstrators is the realisation of a scheduling
`function as described in [4],[5].
`
`

`

`Temporary document WG3TD76
`page 3 of 26
`
`The protocol stack described in this document will first be implemented in the demonstrator of the
`SAMBA project. But due to the ambitious time schedule of the SAMBA project and because of the
`structure of the physical layer some simplifications for the protocols ofthe air interface had to be intro—
`duced.
`
`The demonstrator of the ATMmobil subproject C—ATM will show as much as possible of the protocols
`and algorithms, in order to provide quality of service on demand at the air interface and fully support of
`all ATM service categories.
`
`This document gives a detailed description of the protocol stack, see also [6],[7],[8],[9],[10],[11],[12].
`considers protocols and algorithms for:
`
`it
`
`0 medium access control
`
`. ATM cell scheduler for CBR/VBR/ABR/UBR service categories
`
`.
`
`.
`
`transmission of capacity request messages over uplink with fast collision resolution
`
`service specific ARQ protocol with selective discarding
`
`Although there is a wide agreement, that the BRAN standard should not specify algorithms, we have
`included a description of our most favoured algorithms for collision resolution and acknowledging
`strategy. The algorithms may be useful to verify the specification of BRAN protocols. This document
`does not contain any performance evaluation. We are currently preparing another document, that will
`give a detailed evaluation ofthe system performance for realistic traffic loads.
`
`3 Design of MAC and LLC protocols for an ATM air interface
`
`The data link layer of the ATM air interface contains the ATM cell scheduler of a virtual distributed
`ATM cell multiplexer within one radio cell [6,7]. The following constraints have to be considered:
`
`1. The scheduler distinguishes between ATM service categories and virtual connections. The MAC
`protocol controls the access of the wireless terminals and the base station to the common used ra—
`dio channel.
`
`2. The scheduler within the base station has no direct access to the occupancy of the send buffers of
`the wireless terminals. A special signalling channel is necessary in order to transmit the capacity
`requests of the wireless terminals to the base station.
`
`3. The unreliable behaviour of the radio channel requires additional methods for error recovery. ARQ
`protocols have to be used [16].
`
`4. Conventional ARQ protocols are able to transmit information (i) frames (i.e. the information field
`contains an ATM cell) together with piggybacked acknowledgements or short supervisory frames
`which contain only acknowledgements.
`In case of asymmetric traffic it is often impossible to trans-
`mit acknowledgements piggybacked to l—frames (ATM cells). Hence,
`it
`is necessary that the
`scheduler considers the transmission of ATM cells flq acknowledgements.
`
`The scheduler is divided into two parts, of. Figure 1. The lower part belongs to the MAC layer and
`decides which wireless terminal is permitted to transmit or has to receive an ATM cell. The upper part
`belongs to the LLC layer.
`it selects the virtual connection after the MAC scheduler has chosen the
`terminal that is allowed to transmit or receive.
`
`

`

`Temporary document WG3TD76
`page 4 of 26
`
`4 Services and protocols of the MAC layer
`
`The MAC layer establishes a MAC connection for each registered terminal. This connection is avail—
`able at the MAC service access point (SAP). For each terminal a connection endpoint (CEP) is estab—
`lished within the MAC—SAP of the base station. The address of this CEP (CEP—ld) is called MAC—Id (6
`bit) and is used as a short address for the terminal within a radio cell. This allows to register up to 64
`terminals simultaneously within the same radio cell. Inside the wireless terminal the MAC connection
`ends up at the only CEP of the WT—MAC—SAP (MAC—ld=’l).
`
`
`ATM—
`Layer
`
`Terminal
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`LLC—
`Layer
`
`MAC-
`Layer
`
`LLC-Scheduler
`
`
`BS—MAC—SAP
`
`MAC—Connection
`
`
`
`Radio Channel
`
`Figure 1: Division of the ATM cell scheduler into a MAC and an LLC scheduler
`
`The MAC connection provides two data transmission services for long and short service data units
`(SDU). Based on these transmission capabilities the two logic channels Data—Channel (DCH) and
`Request-Channel (RQCH) are defined. The services of the DCH are used to transmit ATM cells on
`up— and downlink. A DCH—SDU contains one (optional multiple) ATM cells and additional protocol con—
`trol information (PCl). The size of a DCH—SDU depends on the size ofthe LLC—PDUs to be transmitted
`(55 bytes for Down—DCH—SDU and 57 bytes for Up—DCH—SDU, cf. paragraph 5 and Figure 10). The
`scheduler reserves the required transmission capacity for a DCH. The RQCH data service is used to
`transmit RQCH—SDUs on the uplink. These SDUs are 4 byte long and contain capacity request mes—
`sages or LLC acknowledgements.
`
`A dedicated permanent signalling channel, the Global Control Channel (GCCH) is available at the
`specific CEP with CEP—ld=0 [1]. This channel is used for the transmission of connectionless signalling
`messages for radio— and mobility specific functions such as paging,
`location update, registration of
`terminals and handover. On the downlink the GCCH is implemented as a broadcast channel. On the
`uplink random access is used.
`In the following,
`it is assumed that the registration procedures of the
`terminals have been executed successfully and the MAC connections have been established. The
`required signalling protocols are beyond the scope ofthis document.
`
`

`

`Temporary document WG3TD76
`page 5 of 26
`
`
`
`MSC "Scheduler
`
` :l
`l:
`
`BS knows capacity requests (dynamic parameters) of the terminal
`
`
`
`Transmission phase follows
`
`
`
`
`
`Estimation of current
`capacity demand
`of the terminal based on
`capacity requests trans-
`mitted previously
`
`Start of
`reservation
`
`BS—CapJnd
`
`%
`
`BS-Cap.Res
`
`W'|'—Cap.lnd
`
`
`Prediction
`
`
`
`Signalling
`of Reservations
`
`Reservation phase finished
`
`
`
`Figure 2: Message sequence chart (MSC) of the reservation phase ofthe MAC scheduler
`
`The work of the ATM cell scheduler is performed in two phases, the reservation phase and the trans-
`mission phase. During the reservation phase the scheduler determines slot reservations for a certain
`future time interval. During the transmission phase the actual transmission of ATM cells is carried out.
`The reservation phase of the scheduler is performed by the MAC entity of the base station. In order to
`increase processing and channel efficiency, the determination of the transmission sequence of sev—
`eral DCH—SDUs is executed at the same time. The message sequence chart (M30) in Figure 2 shows
`the reservation procedure. The MAC entity of the base station asks the LLC entity for the current ca—
`pacity demands for the transmission of DCH—SDUs of each MAC connection (service primitives (SP)
`
`

`

`Temporary document WG3TD76
`page 6 of 26
`
`BS—Capacity. Indication fOl' downlink and SP WT—Capacity. Indication for Upllnk). The LLC
`entity responds with the SPs BS—Capacity.Response for its own capacity demands and WT—
`Capacity.Response for the uplink capacity demands of the terminals. The demands of the base
`station are determined by a scheduling run of the LLC scheduler. The capacity demands of the termi—
`nals have to be transmitted to the base station in time using the RQCH data service.
`
`The radio channel is organised in a sequence of time slots. The access to the slots is co—ordinated by
`the Dynamic Slot Assignment (DSA++) protocol.
`It makes use of the four PDU types defined in Table
`1.
`
`Period—Ctrl—PDU
`
`Downlink
`
`Details in Table 2
`
`Signalling of time
`slot reservations
`
`Down—DCH—PDU
`
`Downlink
`
`Type (2 bit)
`MAC—Id (6 bit)
`Down—DCH—SDU (55 byte)
`
`Transmission of
`downlink DCH—SDU
`
`Up—DCH-PDU
`
`Type (2 bit)
`MAC-id (6bit)
`Up—DCH-SDU (57 byte)
`
`
`Transmission of
`uplink DCH-SDU
`
`RQCH—SDU (4 byte)
`
`RQCH—PDU
`
`Type (2bit)
`MAC—Id (6 bit)
`
`Transmission of
`RQCH—SDU
`
`Table 1: PDUs of the DSA++ protocol
`
`
`
`Tail (4 symbols)
`
`188§188 I j Data
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`4.4 its
`4rrrrrrrrrrrrrrrrrrrrrrrrrrrrr’i
`l
`
`19%19).
`
`short slot
`
`Training Sequence (16 symbols)
`
`I Guard Time (26 symbols)
`
`Figure 3: Structure and length of the physical bursts of the Mobile Broadband System (MBS)
`
`Physical bursts in slots are used to transmit the MAC-PDUs over the radio channel. The length of
`bursts and with it the length of slots highly depends on the employed modern technology as well as
`protocols and algorithms of the physical layer. The development and investigations of the protocols
`started based on the physical layer proposed by the Mobile Broadband System (M88) [1], since mo-
`dems especially developed for wireless ATM were not available at this early stage. Figure 3 shows the
`structure and length of the physical bursts (using 4 QAM modulation) of M88. For each slot type the
`
`

`

`Temporary document WG3TD76
`page 7 of 26
`
`required amount of symbols for synchronisation (tail symbols), channel estimation (training sequence)
`and guard times is nearly constant. Thus, the ratio between the length of long DCH slots and short
`RQCH slots rsk), = TDCHW / rRQCHW highly depends on the implementation of the modem. Realistic
`values for rsm are in the range of 3 to 8. The functionality (but not performance) of the DSA++ protocol
`is independent to a great extend of the realisation ofthe modem.
`
`Since the power level of the transmit signal can be up to 100dB higher as of the receive signal, an
`additional transceiver turn—around interval 1er between downlink and uplink slots is required in order
`to wear off the energy ofthe transmit signal. A value of 7er = 1—2;:5 seems to be realistic.
`
`
`
`
`
`
`
`
`
`
`Time
`Signalling Period —>
`Signalling Period
`Signalling Period
`
`
`/,
`Transceiver
`Turn Around Interval
`
`
`
`
`
`
`
`
`
`
`
`
`Figure 4: Slot timing structure of the signalling period of the DSA++ protocol
`
`In order to co—ordinate the channel access, the DSA++ protocol groups slots in so called signalling
`periods, of. Figure 4. A signalling period starts with a Period—Ctrl—PDU followed by three phases of
`slots for Down—DCH—PDUs, Up—DCH-PDUs and RQCH—PDUs. Between Down—DCH and Up—DCH
`phases as well as at the end ofthe signalling period a transceiver turn—around interval is inserted.
`
`Each slot of Down—DCH phase and Up—DCH phase is reserved for a specific MAC channel. The ac—
`cess to the RQCH slots is controlled by a RQCH access protocol which is described in paragraph 8.
`The protocol uses random access in order to enable terminals a spontaneous access to the RQCH.
`
`The Period-Ctrl-PDU signals the length of each phase of a signalling period as well as the reserva-
`tions of slots. Table 2 describes the structure of the PDU.
`it contains a field of reservation messages
`for each phase. The reservations fields for Down—DCH phase and Up—DCH phase contain the MAC—
`lds of the served MAC connections. The signalling of the number of RQCH slots and the correspond—
`ing access rights makes use of the generic RQCH signalling field with a length of LRQCH bit.
`lts struc-
`ture is determined by the applied RQCH protocol. Finally, the Period—Ctrl—PDU contains a field of 144
`bit
`length, which can be used to broadcast signalling messages of
`the LLC layer (eg. LLC—
`acknowledgements together with the corresponding MAC—ids).
`
`The loss of a Period—Ctrl—PDU due to transmission errors causes the loss of the PDUs transmitted in
`
`the reserved slots. Therefore, a better protection of the contents of the Period—Control—PDU against
`transmission errors than for DCH—PDUs is strongly recommended (ie. by an FEC with a smaller code
`rate). Assuming the same slot length for a DCH—PDU and the Period—Ctrl—PDU (440 bit), a stronger
`FEC (approx. 30% more redundancy) leads to a length of 338 bit for the Period—Ctrl—PDU. The length
`of the reservations fields of the Period—Ctrl—PDU and the resulting lengths of each phase is variable
`but limited by the overall length of the Period—Ctrl—PDU.
`
`

`

`Temporary document WG3TD76
`page 8 of 26
`
`
`
`
`
`Length
`2 bit
`
`LmCH
`6 bit
`
`NDDX 6 bit
`6 bit
`NUDX 6 bit
`144 bit
`
`Purpose
`identifies Period—Ctrl—PDU
`
`deoends on RQCH orotocol
`Number of Down—DCH-PDUs
`
`Field of NOD MAC—Ids
`Number of Up-DCH-PDUs
`Field of NUD MAC-Ids
`LLC-PDUs + MAC-Id
`
`Field
`
`RQCH sioonallin
`
`Down—DCH reservations
`NW
`Up DCH reservations
`broadcast field
`
`Table 2: Structure of Period-CtrI-PDU
`
`The number of slots of each phase is determined during the reservation phase of the scheduler. The
`DCH-SDUs of up— and downlink compete with each other i.e. the values NED and NUD result from the
`corresponding capacity requirements and are limited by the length of the Period-Ctrl-PDU, of. Table 2.
`Ifthere are less DCH-SDUs to transmit than signalling capacity is available, parts of the DCH reserva-
`tion fields remain unused and the signalling period is shortened. The reservation algorithm consists of
`the following steps:
`
`1. Generation of the RQCH signalling field by the RQCH protocol.
`
`2. Calculation ofthe maximum amount of reservation messages of the Down—DCH or Up—DCH field:
`
`)
`
`338—2—L is —2-6—144btt
`
`mg:it
`
`NDD iNLD —(
`
`3. Calculation of up to NDD + NUD reservations for DCH—SDUs.
`the DCH—SDUs belong to uplink or downlink.
`
`In this step it is not relevant whether
`
`4. Mapping ofthe calculated reservations into Down—DCH and Up—DCH reservation field.
`
`The maximum amount of reservations which can theoretically be achieved, sums up to NDCHmaX = NDD
`+ NUD = 30 under the condition of an empty RQCH field (LRQCH = 0). With respect to the performance
`of the whole system considering especially the RQCH protocol and the ARQ protocols of the LLC
`layer the restriction of NDCHmax to a lower value, eg. NDCHmax = 20 is reasonable. This enables the
`scheduler to consideration retransmissions after collision or transmission errors and new arrivals ear-
`lier.
`
`The duplexing scheme is of minor importance. Although the DSA++ protocol has been described for time division
`duplexing (TDD), the investigations have shown that the DSA++ protocol is suitable for frequency division duplex—
`ing (FDD) as well.
`
`5 Structure of the LLC layer
`
`Figure 5 shows the structure of the LLC layer for the terminal and Figure 6 for the base station. The
`LLC layer contains the ARQ instances, which perform the ATM service category specific ARQ proto—
`cols. Also the upper part of the scheduler (LLC scheduler) is located inside the LLC layer. Inside the
`base station one instance of the LLC scheduler for each registered terminal is created and connected
`to the appropriate CEP within the MAC-SAP that provides the MAC connection to the terminal, of.
`Figure 1. The LLC scheduler consists of one entity per ATM service category. Between the service
`categories static priorities are employed.
`In this document the UBR service category represents the
`service categories without real-time constraints, ABR and UBR. The structure of these entities is simi-
`lar.
`In the following, the VBR entity is described. The lower part of the VBR entity contains the LLC-
`VBR scheduler and the functions required for the signalling and processing of the capacity requests of
`the terminals. The upper part contains one ARQ instance for each virtual connection (virtual channel,
`VC), which is connected to a CEP inside the VBR—VC—SAP.
`
`

`

`Temporary document WG3TD76
`page 9 of 26
`
`
`CBR—
`.
`U BR-
`VC-SAP
`LLC-VBR—Entity
`VC-SAP
`
`LLC-CBR-
`Entity
`
`
`
`
`
`LLC-UBR—
`Entity
`
`
`
`
`
`
`
`States of Occupancy
`
`
`
`
`
`
`
`Capacity
`requests
`
`ynamic
`Parameters
`(dynP)
`
`
`
`
`
`
`
`Figure 5: LLC entities of the terminal
`
`In case of parallel virtual connections, possibly belonging to different service categories, a correspond—
`ing amount of ARQ instances is created and operated in parallel. ARQ identifiers (ARQ—ld, 8 bit long)
`are used to address the ARQ instances. These ARQ—lds are unique within the LLC instance of the
`terminal.
`It is mandatory to create one ARQ instance per virtual connection with real—time constraints
`in order to enable the due—date based scheduling of ATM cells with respect to their connection specific
`quality of service requirements.
`
`In case of parallel ARQ instances, the instance with the most urgent ATM cell does not necessarily
`have to transmit the most urgent acknowledgement. This is the reason why the content of the informa—
`tion field and acknowledgement field of one ARQ frame can be occupied by different ARQ instances.
`The information (i) frames of the ARQ instances do not contain piggybacked acknowledgements, but
`only the content of an ATM cell. An ARQ—PDUs is an information frame (l—PDU) or an acknowledge—
`ment (Ack—PDU), generated independently from each other. They are concatenated to an LLC-PDU
`below the LLC scheduler.
`
`

`

`Temporary document WG3TD76
`page 10 of 26
`
`
`
`
`CBR—
`UBR-
`VC-SAP
`VC-SAP
`
`.
`LLC-VBR—Entity
`
`VBR-VC-SAP
`
`
`
`
`
`*
`*
`
`
`
`
`
`
`
`
`LLC-CBR-
`Entity
`
`‘
`
`I O I
`
`Expected
`
`State of Occupancy Acknowledgements
`
`
`LLC-UBR-
`Entity
`
`I I O
`
`a
`
`E
`.9 *‘
`
`Acknowledgements (A)
`
`8 % 3
`2 o n:
`
`£5} %
`1’ V
`
`l
`
`%
`.9 ._
`
`ggk
`o a: “5
`
`l
`l
`
`
`
`LLC-PDU
`
`MAC-SAP
`
`Figure 6: LLC entities of the base station
`
`Information—Frame
`(l-PDU)
`
`{figggvgg‘ggements
`
`D namlc Parameters
`(
`nPara-PDU)
`
`ARQ-ld N(S) P-Bit User data, 51 byte
`
`a bit
`6 bit
`1 bit
`(ATM—Cell without HEG and VPI)
`
`
`
`
`
`
`ARQ-ld
`Typ N(R)l P/F—B'rt
`
`a bit
`3 bit 6 bit
`1 bit
`
`
`lSer.Class. Requests
`
`2 bit
`2 byte
`
`399'“ 53 bYte
`
`appmx' 2 ”“9
`
`approx. 2 byte
`
`Figure 7: Protocol data units of ARQ instances and LLC scheduler
`
`Figure 7 shows the structure of both ARQ—PDUs and of the DynPara—PDU. Since an FEC scheme is
`employed by the physical layer which is able to detect and correct transmission errors, the Header
`Error Control (HEC) field of the ATM cell needs not to be transmitted. Also the virtual path identifier
`(VPl) can be omitted, since it can be reconstructed out ofthe ARQ—ld.1
`
`1
`
`If a virtual path is used, the visited network elements are not informed about the setup of a virtual connection inside the path.
`Thus, the VCI cannot be reconstructed using the ARQ-ld and has to be transmitted.
`
`

`

`Temporary document WG3TD76
`page 11 of 26
`
`
`
`MSC TransSched
`‘,,,,,,,,
`
`l
`i
`
`‘t
`l
`W. J
`
`
`lVV'iifiiélecVVVVVi
`[WT/BSMAC
`
`
`
`
`
`Reservation phase completed
`
`lTransmit times known
`
`Transmission. lnd
`
`
`
`.
`Determination i
`oftransmitting E Planning
`ARQ-lnstance
`
`
`
`
`
`
`Figure 8: MSC to determine the transmitting ARQ instance after transmit time, MAC—Id and
`transmission direction are determined by the reservation phase of the scheduler
`
`During the reservation phase the LLC scheduler selects the ARQ instance with the most urgent ATM
`cell and/or the most urgent acknowledgement. Furthermore, it provides information about the amount
`and urgency ofthe ATM cells and acknowledgements waiting for transmission. They are characterised
`by appropriate parameters that are used
`
`. during the reservation phase to inform the MAC scheduler of the base station about the current
`capacity requests of an LLC instance. cf. Figure 2,
`
`. during the transmission phase inside base station and terminals to determine the MAC-id and di—
`rection (uplink or downlink) ofthe ARQ instance permitted to send , of. Figure 8,
`
`o
`
`to signal the capacity requirements of a terminal to the base station, of. Figure 9.
`
`The main difference between the VBR entities of base station and terminals is the functionality for
`handling the capacity requirements. A terminal uses a coding function (f(x) in Figure 5) to map its ca—
`pacity requirements into a 2 byte data structure called dynamic parameters. The dynamic parameters
`have to be transmitted in time as DynPara-PDU piggybacked to an l-frame and an acknowledgement
`in an Up-DCH-PDU or together with an acknowledgement over the RQCH. The base station stores
`the most recent dynamic parameters received from each terminal. The MAC scheduler of the base
`station estimates the current capacity demand of a terminal using a prediction algorithm that extrapo-
`lates the dynamic parameter to the corresponding transmission time.
`
`

`

`Temporary document WG3TD76
`page 12 of 26
`
`
`
`
`
`
`
`
`
`
`
`DynPara—PDU
`
`
`
`
`
`
`
`
`
`< BS knowscapacity requests
`
`
`
`of terminals
`
`Figure 9: Message sequence chart for the transmission of capacity request messages form
`terminal to base station
`
`The ARQ-PDUs and DynPara-PDUs are concatenated to LLC-PDUs below the LLC service-category
`entities in the LLC-PDU generator. The selection of appropriate PDUs is executed according to the
`static priorities between different ATM service categories. The length of the LLC-PDUs differs depend-
`ing on the used transmission service of the MAC connection (Uplink— / Downlink-DCH, RQCH), cf.
`Figure 10. The LLC-PDUs of the uplink always contains a DynPara-PDU. The type field of the LLC-
`PDUs ofthe DCH (length 1 bit) determines whether up to 24 additional acknowledgements (Down/Up-
`DCH—Ack—PDU, called bundle acknowledgement) are transmitted instead of an l—PDU. Thus, it is pos—
`sible to transmit several acknowledgements of one or different ARQ instances simultaneously. Finally,
`it is possible to pass acknowledgements (ACK—PDUs) directly to the MAC layer,
`in order to transmit
`them within the broadcast field of the Period-Ctrl—PDU.
`
`

`

`Temporary document WG3TD76
`page 13 of 26
`
`Down—DCH—PDU
`
`_
`.
`Up DCH PDU
`
`Up—DCH—Ack—PDU
`
`RQCH-PDU
`
`Down—DCH—Ack—PDU E.
`
`di7
`
`93:]
`
`J
`
`9|?)th
`
`l
`
`up to 24
`
`
`
`i
`_
`l
`D-
`DynPara l
`Aok
`"iii”
`
`| PDU
`PDU 1
`PDU .
`.E
`0: 7
`E 93:]
`
`-- up to 24 iDyguPara
`
`SIS:
`
`£35 BESS“
`
`T7777777777777777777777777777777777777777777777777777777777777777Kck
`
`
`I-PDU
`
`l
`
`PDU
`
`E
`
`
`
`
`
`
`approx. 55 byte
`
`approx. 55 byte
`
`approx. 57 byte
`
`approx. 57 byte
`
`approx. 4 byte
`
`Figure 10: Protocol data units ofthe LLC protocol
`
`6 SRlD-ARQ protocol for the real-time oriented CBR and VBR services
`
`The reduction of the cell loss ratio (CLR) by the deployment of ARQ protocols for wireless transmis-
`sion channels always leads to an increased delay of information frames due to retransmissions. If the
`transmission delay is not limited to an upper value, an infinite number of retransmission is possible
`and cell losses can completely be avoided. The limitation of delays to a maximum value can cause the
`loss of the ATM cell, since after several retransmissions a cell is exceeding its due-date. Two types of
`ARQ protocols are deployed at the ATM air interface:
`
`0 Standard ARQ protocol: For ABR/UBR services no maximum delay is specified. A conventional
`ARQ protocol such as HDLC can be applied.
`
`. Real-time ARQ protocol: Real—time oriented CBR and VBR services have high demands in meet—
`ing the maximum cell delay Tdmax- A newly developed ARQ protocol is used that automatically dis—
`cards old cells after having exceeded their due—date.
`
`As a real—time ARQ protocol for CBR and VBR services the newly developed Selective Repeat with
`Discard/rig (SR/D) ARQ protocol is used. The functionality of the SR/D protocol is based on a conven—
`tional selective repeat ARQ protocol. The SR/D protocol is able to adapt the effort for error recovery to
`the quality of service requirements (given by the maximum delay Tdmax at the air interface and maxi—
`mum cell loss ratio, CLR) for each virtual connection. This adaptability is achieved by the following
`means:
`
`. The number of retransmissions of an ATM cell is controlled by the current waiting time of the cell
`inside the transmit buffer or its due—date respectively. The quality of service requirements and the
`current channel load are taken into account.
`
`.
`
`It is permitted to discard ATM cells which have exceeded their due—date.
`
`The number of retransmission is controlled by the scheduler located below the ARQ instances. lt tries
`to transmit an ATM cell as long as its due-date (time of arrival + Tamax) has not been exceeded. which
`will result in the discarding of the cell. The real number of retransmission depends on the priorities
`inside the scheduler as well as on the current channel load. The scheduler prefers retransmissions by
`applying the Earliest—Due-date—First (EDD) scheduling or the Relative Urgency (RU) strategy [41,[5].
`
`

`

`Temporary document WG3TD76
`page 14 of 26
`
`Discarding of obsolete ATM cells is advantageous in short term congestion situations. The waiting
`time of the following cells and the probability that further cells are exceeding their due—dates are re—
`duced.
`
`6.1 The discarding mechanism of the SR/D protocol
`
`Discarding is performed in three different situations:
`
`1. The discarding of ATM cells stored inside the transmit buffer does not affect the ARQ protocols,
`since no sequence number has been assigned yet.
`
`2.
`
`In case of the first transmission the ATM cell is moved from the transmit buffer to the transmit win—
`
`dow of the sender and a sequence number is assigned. The discarding of a cell already stored in—
`side the transmit window is not possible in conventional ARQ protocols and causes problems.
`When discarded, the cell is missing inside the transmit window and cannot be retransmitted if the
`receiver requests the retransmission of this cell. The operation of the ARQ protocol fails. Additional
`actions are necessary to avoid this situation.
`
`3.
`
`It is possible to forward ATM cells waiting inside the receive buffer to the upper protocol layer be—
`fore their due—dates expire. These cells are waiting, because one or several previous cells are
`missing. ln the case that the missing cells are received afterwards they have to be discarded in or—
`der not to change the sequence of the cells. To use this procedure it is necessary to transmit the
`due-dates ofthe cells. This leads to an increased signalling overhead.
`
`The strict adherence of the maximum delay is only possible by employing all three procedures. This
`leads to a higher complexity of the protocols but only procedure 3 leads to an increased signalling
`load due to necessary transmissions of the due—dates of cells. By using procedure 2, the situation can
`occur that the receiver requests the retransmission of a cell that has already been discarded inside the
`sender in the meantime.
`If the receiver is not informed about the discarding of the cell,
`it will request
`the retransmission of this cell by sending selective reject acknowledgements infinitely and the opera—
`tion of the protocol fails.
`ln order to avoid this situation a short discard message that only contains the
`sequence number instead of the discarded cell is send by the sender. The transmission is performed
`like the transmission of an acknowledgement and requires less channel capacity than the transmis—
`sion of the discarded cell. The receiver has to acknowledge this discard message like a normal
`I—
`frame and a poll timer has to be used to control the acknowledgement in order to avoid an instability of
`the protocol if acknowledgements get lost.
`
`
`ARQ—Sender
`ATM-Cell of l(2) is discarded
`v
`\/ \x
`\/
`x
`\% \/
`/
`\a \f‘»
`\a.
`a.
`(5‘3
`\‘9
`”
`a a
`w/
`$
`\rb \% \‘éé
`Ra} u-
`u.
`,o
`176.?)
`\f\ \x‘.
`‘f/
`\ \x
`\
`
`‘4
`a
`mg
`.
`/
`§
`
`\@
`\‘9
`\
`“(:17
`\fi‘é
`
`\/l
`f/
`?’/
`3/
`
`I
`
`ARQ—Receiver
`
`—>
`
`Figure 11: Protocol sequence of the SR/D-ARQ protocol describing the discarding of ATM-cells
`and the signalling of the discarding to the receiver using discard-messages.
`
`Figure 11 gives an example for the usage of the discard message. The frames l(O) and l(2) are lost
`during transmission. Also the SREJ(2) acknowledgement which request the retransmission is lost.
`In
`the mean time the cell of the l(2) frame is discarded due to the delay caused by the necessary repeti-
`
`

`

`Temporary document WG3TD76
`page 15 of 26
`
`tion of the SREJ(2). The discarding is signalled to the receiver with the DISCARD(2) message that is
`transmitted piggybacked to the |(5)—frame.
`
`The discarding of some consecutive cells is determined by the increasing sequence numbers since
`the same delay bound Tamax is valid for all cells of this virtual connection.
`If the receiver requests the
`retransmission of several cells which have been discarded in the meantime.
`it is sufficient to signal
`only the d