IEEE abc-01/22r1

Transcription

1 Project IEEE Broadband Wireless Access Working Group < > Title An ARQ proposal for consideration by TG3/4 MAC group Date Submitted Source(s) Yigal Leiba Itzik Kitroser Runcom Technologies LTD. 2 Ahoma St , Rishon Lezion Israel Voice: Fax: yigall@runcom.co.il itzikk@runcom.co.il Re: Call for comments, document IEEE ab-01/06r1 Abstract This ARQ proposal attempts to incorporate elements from IEEE802.16abc- 01/01 and discussions, comments and contributions that took place within the ARQ Ad-Hoc group. The document attempts to cover the majority of issues related to ARQ incorporation in the MAC. Purp ose For consideration and improvement by the TG3/4 ARQ Ad Hoc Group. Notice Release Patent Policy and Procedures T h i s d o c u m e n t h a s b e e n p r e p a r e d t o a s s i s t I E E E I t i s o f f e r e d a s a b a s i s f o r d i s c u s s i o n a n d i s n o t b i n d i n g o n t h e c o n t r i b u t i n g i n d i v i d u a l ( s ) o r o r g a n i z a t i o n ( s ). T h e m a t e r i a l i n t h i s d o c u m e n t i s s u b j e c t t o c h a n g e i n f o r m a n d c o n t e n t a f t e r f u r t h e r s t u d y. T h e c o n t r i b u t o r ( s ) r e s e r v e ( s ) t h e r i g h t t o a d d, a m e n d o r w i t h d r a w m a t e r i a l c o n t a i n e d h e r e i n. T h e c o n t r i b u t o r g r a n t s a f r e e, i r r e v o c a b l e l i c e n s e t o t h e I E E E t o i n c o r p o r a t e m a t e r i a l c o n t a i n e d i n t h i s c o n t r i b u t i o n, a n d a n y m o d i f i c a t i o n s t h e r e o f, i n t h e c r e a t i o n o f a n I E E E S t a n d a r d s p u b l i c a t i o n ; t o c o p y r i g h t i n t h e I E E E s n a m e a n y I E E E S t a n d a r d s p u b l i c a t i o n e v e n t h o u g h i t m a y i n c l u d e p o r t i o n s o f t h i s c o n t r i b u t i o n ; a n d a t t h e I E E E s s o l e d i s c r e t i o n t o p e r m i t o t h e r s t o r e p r o d u c e i n w h o l e o r i n p a r t t h e r e s u l t i n g I E E E S t a n d a r d s p u b l i c a t i o n. T h e c o n t r i b u t o r a l s o a c k n o w l e d g e s a n d a c c e p t s t h a t t h i s c o n t r i b u t i o n m a y b e m a d e p u b l i c b y I E E E T h e c o n t r i b u t o r i s f a m i l i a r w i t h t h e I E E E P a t e n t P o l i c y a n d P r o c e d u r e s ( V e r s i o n 1. 0 ) < h t t p : / / i e e e o r g / 1 6 / i p r / p a t e n t s / p o l i c y. h t m l >, i n c l u d i n g t h e s t a t e m e n t I E E E s t a n d a r d s m a y i n c l u d e t h e k n o w n u s e o f p a t e n t ( s ), i n c l u d i n g p a t e n t a p p l i c a t i o n s, i f t h e r e i s t e c h n i c a l j u s t i f i c a t i o n i n t h e o p i n i o n o f t h e s t a n d a r d s - d e v e l o p i n g c o m m i t t e e a n d p r o v i d e d t h e I E E E r e c e i v e s a s s u r a n c e f r o m t h e p a t e n t h o l d e r t h a t i t w i l l l i c e n s e a p p l i c a n t s u n d e r r e a s o n a b l e t e r m s a n d c o n d i t i o n s f o r t h e p u r p o s e o f i m p l e m e n t i n g t h e s t a n d a r d. E a r l y d i s c l o s u r e t o t h e W o r k i n g G r o u p o f p a t e n t i n f o r m a t i o n t h a t m i g h t b e r e l e v a n t t o t h e s t a n d a r d i s e s s e n t i a l t o r e d u c e t h e p o s s i b i l i t y f o r d e l a y s i n t h e d e v e l o p m e n t p r o c e s s a n d i n c r e a s e t h e l i k e l i h o o d t h a t t h e d r a f t p u b l i c a t i o n w i l l b e a p p r o v e d f o r p u b l i c a t i o n. P l e a s e n o t i f y t h e C h a i r < m a i l t o : r. b. m a r k i e e e. o r g > a s e a r l y a s p o s s i b l e, i n w r i t t e n o r e l e c t r o n i c f o r m, o f a n y p a t e n t s ( g r a n t e d o r u n d e r a p p l i c a t i o n ) t h a t m a y c o v e r t e c h n o l o g y t h a t i s u n d e r c o n s i d e r a t i o n b y o r h a s b e e n a p p r o v e d b y I E E E T h e C h a i r w i l l d i s c l o s e t h i s n o t i f i c a t i o n v i a t h e I E E E w e b s i t e < h t t p : / / i ee e o r g / 1 6 / i p r / p a t e n t s / n o t i c e s >. 0

2 An ARQ proposal for consideration by TG3/4 ARQ Ad-Hoc group Yigal Leiba Itzik Kitroser Runcom Technologies LTD. 1 General The ARQ mechanism is part of the MAC layer. Its implementation is mandatory, yet it s use is optional, on a per-connection basis. The requirement to use ARQ should be specified upon connection creation, but the decision on which connections ARQ should be used is outside the scope of the air interface specification. When a connection is designated to support ARQ, transmission of non -ARQ traffic on the connection is not allowed. The scope of a specific instance of the ARQ state machines, parameters and messages is limited to one unidirectional unicast MAC connection between the BST and an SS. The feedback information required for the ARQ algorithm is sent as a MAC management message on the appropriate basic management connection between that SS and the BST (i.e. it cannot be fragmented), or as piggybacked information on some existing connection. 2 Block numbering concept An ARQ block is a uniquely identifiable entity on which the ARQ algorithm operates. Each ARQ block is identified by an ARQ block number, which is assigned to it by the MAC. ARQ block numbers are assigned in increasing order, modulo ARQ_MAX_ IDX. When the MAC decides to transmit a certain MSDU for the first time, it assigns it block numbers starting from the current block index, and according to the ARQ_BLOCK_SIZE parameter, that will determine how many ARQ blocks are contained in the MSDU. No te that the ARQ numbering is merely a numbering scheme that identifies both the MSDU transmission order, and the order of the ARQ blocks comprising each MSDU. Note the ARQ block numbering implies nothing on the order and size of MPDU transmission. 3 Packing and fragmentation interoperation with ARQ 3.1 Motivation As the packing and fragmentation mechanism purpose is to allow the MAC to efficiently use arbitrary bandwidth assignments. The BW assignment for any connections while not completely arbitrary is limi ted by the granularity imposed by the PHY, namely relatively large FEC block granularity. The current packing and fragmentation mechanism operates on a byte boundary, i.e. it can fully use any BW assignment to the last byte. The ARQ scheme described here is specifically designed for minimal interference with the existing packing and fragmentation mechanism, and preserves its granularity. The proposed ARQ scheme does pose a restriction that an MSDU fragment should not be smaller than the size of an ARQ block. 3.2 Connection fragmentation state The current MAC creates an MPDU from a single MSDU, a fragment of an MSDU, or packing of several MSDUs or fragments of MSDUs. Currently, the range of states introduced by the fragmentation and packing mechanisms is limited by the fact that the connection on which the MSDU is transported is only allowed to be in one fragmentation state at any given instance. When ARQ, whose operation is based on retransmission of erred data, is introduced into the current MAC, the concept of a connection being in a single fragmentation state no longer holds. Instead, once a MSDU is fragmented, it remains fragmented until all 1

3 its pieces (i.e. ARQ blocks) have arrived at the receiver. The ARQ blocks should carry enough information in them so the receiver can place them correctly without the assumption of a single fragmentation state. 3.3 Block numbering operation To demonstrate how the block numbering works we might look at the allowed formats of MPDUs, and how ARQ block numbering woul d work in each. ARQ block numbering is done in the MSDU level, and ARQ blocks may be split between different MPDUs. As the ARQ algorithm in the receiver has enough information in each ARQ block to place it correctly regardless of the fragmentation, the split will at most cause the yet untransmitted portion of a block to be transmitted in vain. If this situation is to be avoided, the MAC may choose to always fragment on an ARQ block boundary. I order to support this choice of fragmentation, a parameter called SEND_FULL_BLOCKS is defined, that instructs the MAC to always fragment on an ARQ block boundary. Refer to section 7.1 for the format of the ARQ sub -headers. MSDU # MSDU # MSDU # Option I: Single MSDU in the MPDU MPDU # MPDU # MPDU # MSDU#2 MSDU#3 Option II: MSDU and MSDU fragments in the MPDU MPDU # MPDU #2 MPDU #3 MPDU #4 MPDU # MSDU#2 FRG#0 MSDU#2 FRG#1 Option III: MSDU and MSDU fragments packed in the MPDU MSDU#3 FRG#0 MSDU#3 FRG#1 MPDU # FRG#0 FRG#1 MPDU # MSDU#2 MPDU # MSDU#3 FRG#0 MSDU#3 FRG#1 Figure 1: Pa cking Fragmentation and ARQ block numbering 4 ARQ state machine The ARQ scheme is one of type selective repeat, and it uses an independent state machine on each ARQenabled connection. The ARQ scheme utilizes the existing MPDU CRC-32 checksum for detecting erred MPDUs. The proposed ARQ scheme is specifically designed to be simple and include minimal explicit messaging between transmitter and receiver. 4.1 Transmitter state machine At the transmitter the MSDUs are segmented ARQ blocks, and each block is numbered as explained in section 2 above. An ARQ block may be in one of the following four states, not - sent, outstanding, discarded and n o t - acknowledged. Any ARQ block begins as not -sent. When it is sent it becomes outstanding for a period of time termed ACK_WINDOW_DURATION. After that period of time it either is acknowledged and is discarded, or becomes not -acknowledged. An ARQ block can become n o t -acknowledged before the 2

4 ACK_WINDOW_DURATION period expires if it is implicitly negativel y acknowledged (for instance an ACK for a block having a higher sequence number has been received). An ARQ block may also change from not -acknowledged to discarded when an ACK message for it is received or after a timeout ARQ_BLOCK_MAX_DELAY, but setting this timeout is considered outside the scope of the ARQ specification. In order to simplify implementation, a parameter MAX_TX_WINDOW is defined. This parameter specifies the maximum difference between lowest and highest numbered outstanding ARQ blocks at any given time. This parameter can be varied to trade buffering requirements at the transmitter (and the receiver) for ARQ algorithm performance (throughput). The transmitter policy is that if any not -acknowledged ARQ blocks exist, they should be given prec edence over not -sent packets. ARQ blocks that are outstanding or discarded should never be transmitted. The ARQ block state sequence is graphically shown below. Transmit ACk_Window_Size Timer NS OS NA NACK NS - Not Sent OS - Outstanding NA - Not Acknowledged DS - Discarded ACK DS ACK ARQ_Block_Max_Delay Figure 2 : ARQ block states 4.2 Receiver state machine When an MPDU is received, its integrity is determined based on its CRC-32 checksum. If the MPDU is not erred, it is unpacked and de-fragmented. The receiver maintains a sliding- window defined by minimum arq block number state variable and the MAX_TX_WINDOW parameter. When an ARQ block with a number that falls in the range defined by sliding window is received, the receiver will accept it. ARQ block numbers outside the sliding window will be rejected as out of order. The receiver should identify duplicate ARQ blocks (i.e. ARQ blocks that where already received correctly) and discard them. The sliding window is maintained such that the minimum arq block number variable always points to the lowest numbered ARQ block that has not been received or has b een received with errors. When an ARQ block with a number corresponding to the minimum ARQ block number is received, the window is advanced (i.e. minimum arq block number is increased modulo ARQ_MAX_IDX) such that the minimum arq block number variable points to the next lowest numbered ARQ block that has not been received or has been received with errors. If ARQ blocks are being received, yet the minimum arq block number variable has pointed to a specific ARQ block longer than ARQ_SYNC_LOSS_DELAY, the ARQ a lgorithm synchronization will be considered lost. In such a case the window will slide until an ARQ block that has been correctly received is found. The minimum arq block number variable will point to the next lowest numbered ARQ block that has not been 3

5 received or has been received with errors. (Optionally a sync- loss handshake protocol between the transmitter and the receiver can be added if people believe it is important). For each ARQ block accepted fully and without errors (including duplicates), an acknowledgment message is sent to the sender. Acknowledgments may be either for specific ARQ blocks (i.e. contain information on the acknowledged ARQ block numbers), or cumulative (i.e. contain the highest ARQ block number below which all ARQ blocks have been received correctly). Acknowledgments should be sent in order of the ARQ block numbers they acknowledge. An MSDU is handed to the upper layers when all the ARQ blocks between the lowest numbered ARQ block in a fragment marked as starting-fragment and the first highest numbered ARQ block in the a fragment marked as last-fragment have been received without errors. 5 ARQ and scheduling interoperation ARQ and scheduling interact in the sense that ARQ consumes part of the bandwidth for re-transmissions and for control messages (ACK). BW requests from SS supporting connections with ARQ will always include the entire overhead required for the ARQ. To support GPC terminals a new UIUC value is defined, that identifies bandwidth the scheduler has set aside for transmission of uplink ARQ information. Here is the addition to table 108 of document IEEE P802.16/D IE Name U p l i n k Connection ID Description Interval U s a g e C o d e (UIUC) ACK -d a t a 1 2 u n i c a s t Starting offset of burst for ACK data assignment. Table 1 : A C K-data UIUC Note that as this UIUC also describes the modulation parameters to use for sending the data, it might not be an adequate solution. A cleaner solution for GPC terminals would be to define an explicit connection for ACK d ata. 6 ARQ parameters and connection setup Connections are set and defined either statically through the configuration, or dynamically through the DSA/DSC class of messages. All the ARQ parameters for an ARQ supporting connection are set when the connection is set up. The transmitter and receiver windows are reset on connection setup. This section describes the TLV fields for the ARQ algorithm, that are required for both static and dynamic connection creation methods. 6.1 ARQ_BLOCK_SIZE Fixing this number considerably simplifies the definition of related messages and bit field and makes implementation easier. The suggested fixed value is 64 bytes. 6.2 ARQ_MAX_IDX Sets the size of the group of ARQ block numbers, should be expressed as 2^N 1 where N is an integer. The group should be large enough such that no loss of an ARQ block or an ACK will cause any ambiguity. The number would depend on the ACK_WINDOW_DURATION, the ARQ_BLOCK_SIZE, and the transmission rate. Taking as a maximum a PHY data rate of 120Mb/S with frame duration of 1mS, and allowing 16mS for the ACK-WINDOW_DURATION, implies we need N as high as 13 here. 4

6 6.3 MAX_TX_WINDOW From the point of view of performance, it would be ideal if this parameter were set such that the transmitter is never blocked by transmission and processing delays. It is also required for correct ARQ algorithm operation that this number is less than half of the ARQ_MAX_IDX parameter. From the point of view of implementation complexity, this parameter eases implementation by placing a limit on the transmitter (and receiver) buffering requirements. This parameter is negotiated between the transmitter and the receiver at the connection set -up. The DSA/DSC message will contain a suggested value for this parameter The DSA - RSP/DSC-RSP message will contain an acknowledgement of this parameter, or a different suggested value. The lower of the two values will be used. T y p e Length Value S c o p e [ 2 4 / 2 5 ].? D S x -REQ D S x -RSP Table 2 : MAX_TX_WINDOW TLV 6.4 ACK_WINDOW_DURATION The ACK window duration should account for the transmission and processing time for the forward going message and for the scheduling, transmission and processing delays for the ACK message. The combination of all these delays is partly predictable, partly implementation dependent and partly scenario dependant (e.g. the scheduling part). The minimal ACK_WINDOW_DURATION is the sum of the times durations listed below, Tmsg-t x- time: The time it takes to send an ARQ block over the PHY. Depends on the channel and modulation parameters. Known by the BS at connection setup. Tair- delay: The time it takes the RF wave to spread, depends on the cell size. The BS at connection setup knows the maximum value. Treceiver-process: Implementation depen dent receiver processing delay. This is a capability of the receiver. Tack-scheduling: Scenario or policy dependant scheduling delay for the ACK message in the receiver. This value could be set by the BS (for a GPC terminal) or by the SS (for a GPT terminal). The longer value should prevail. Tack-tx-time: The time it takes to send an ACK message over the PHY. Depends on the format of the ACK message as well as on channel and modulation parameters. Known by the BS at connection setup. Tair- delay: The time it takes the RF wave to spread, depends on the cell size. The BS at connection setup knows the maximum value. Ttransmitter-process: Implementation dependent transmitter processing delay of the ACK message. This is a capability of the transmitter. From the above analysis we may conclude that there are three types of parameters here, 1. Parameters set by the BS (namely Tmsg-tx-time, Tair-delay, Tack-tx-time). The DSA/DSC or DSA - RSP/DSC-RSP message will contain the values for these parameters, set by the BS. 2. Parameters negotiated between the BS and the SS (namely Tack- scheduling ). The DSA/DSC message will contain a suggested value for this parameter The DSA -RSP/DSC-RSP message will contain an acknowledgement of this parameter, or a different suggested value. The larger of the two values will be used. 3. Parameters that are capabilities (namely Treceiver-process, Ttransmitter- process). The DSA/DSC or DSA - RSP/DSC - RSP message will contain the values for these parameters where the receiver and transmitter each declare its capability. When the DSA/DSC handshake is over each party should know all the parameters listed above and each can calculate the value for the ACK_WINDOW_DURATION as their sum. 5

7 The table below lists the relevant TLVs. Name T y p e Length Value S c o p e T m s g -t x -t i m e [ 2 4 / 2 5 ].?.? D S x -R E Q (In microseconds) D S x -R S P T a i r-d e l a y [ 2 4 / 2 5 ].?.? (In microseconds) T r e c e i v e r - p r o c e s s [ 2 4 / 2 5 ].?.? (In microseconds) T a c k -s c h e d u l i n g [ 2 4 / 2 5 ].?.? (In microseconds) Tack- t x -t i m e [ 2 4 / 2 5 ].?.? (In microseconds) T t r a n s m i t t e r -p r o c e s s [ 2 4 / 2 5 ].?.? (In microseconds) 6.5 ARQ_BLOCK_MAX_DELAY Table 3: ACK_WINDOW_DURATION releated TLVs D S x -R E Q D S x -R S P D S x -R E Q D S x -R S P C onfiguration D S x -R E Q D S x -R S P D S x -R E Q D S x -R S P D S x -R E Q D S x -R S P This parameter is useful for cases where delay is bounded, yet ARQ can be helpful (e.g. VOIP). It allows limiting the delay that ARQ introduces and guarantees that transmission of ARQ blocks that are no longer useful to the upper layers is avoided. The BS should set this parameter. The DSA/DSC or DSA -RSP/DSC-RSP message will contain the value for this parameter as set by the BS. T y p e Length Value S c o p e [ 2 4 / 2 5 ].? D S x -REQ D S x -RSP 6.6 ARQ_SYNC_LOSS_DELAY Table 4: ARQ_BLOCK_MAX_DELAY TLV This parameter guarantees that the ARQ algorithm does not get stuck indefinitely. The only li mitation on this parameter is that it should be long enough such that a reasonable number of retransmissions are allowed before this timeout occurs and data is lost in the corrective action taken. The BS should set this parameter. The DSA/DSC or DSA -RSP/DSC-RSP message will contain the value for this parameter as set by the BS. T y p e Length Value S c o p e [ 2 4 / 2 5 ].? D S x -REQ D S x -RSP Table 5 : ARQ_SYNC_LOSS_DELAY TLV 6

8 6.7 SEND_FULL_BLOCKS This parameter is negotiated between the transmitter and the receiver at the connection set-u p. The DSA/DSC message will contain a suggested value for this parameter The DSA - RSP/DSC-RSP message will contain an acknowledgement of this parameter, or a different suggested value. The lower of the two values will be used. T y p e Length Value S c o p e [ 2 4 / 2 5 ].? 2 0= Fragment on ARQ block boundary only D S x -REQ 1= No limitation on fragmentation D S x -RSP 7 Formats of ARQ related MAC message 7.1 ARQ sub-header Table 6 : SEND_FULL_BLOCKS TLV The information conveyed by the ARQ sub -header is a BSN, which stands for Block Sequential Number referencing the block number of the first ARQ block in the MPDU. As the size of the ARQ block is known, and it is possible to detect a partial ARQ block (i.e. an ARQ block that was last in the MSDU and therefore its size is smaller than ARQ_BLOCK_SIZE ), this information should suffice to extract all ARQ block numbers in the MPDU. When an ARQ sub -header is present with other sub-headers, it is always inserted between the generic MAC header and the MPDU payload after the grant -management and packing or fragmentation sub -headers. 7.2 ARQ feedback sub-header This sub -header enables piggybacking of ARQ feedback information elements. When A R Q-feedback sub - header is present with other sub-headers, it is always the last to be inserted between the generic MAC header and the MPDU payload. Refer to section for details. 7.3 Generic MAC header update The Generic MAC header TYPE field needs to be updated to indicate the presence of the ARQ feedback subheader. Here are the updated table that should replace table 4 and table 5 of document IEEE P802.16/D

9 T y p e D e s c r i p t i o n 0 x 0 0 N o s u b -h e a d e r s p r e s e n t 0 x 0 1 R e s e rved 0 x 0 2 P a c k i n g s u b -h e a d e r p r e s e n t 0 x 0 3 R e s e r v e d 0 x 0 4 F r a g m e n t a t i o n s u b -h e a d e r p r e s e n t 0 x 0 5 R e s e r v e d 0 x 0 6 R e s e r v e d 0 x 0 7 R e s e r v e d 0 x 0 8 ARQ -f e e d b a c k s u b -h e a d e r p r e s e n t 0 x 0 9 R e s e r v e d 0x0A ARQ -f e e d b a c k a n d p a c k i n g s u b -h e a d e r s p r e s e n t 0 x 0 B R e s e r v e d 0 x 0 C ARQ -f e e d b a c k a n d f r a g m e n t a t i o n s u b -h e a d e r s p r e s e n t 0x0D 0x3F R e s e r v e d Table 7 : Downlink type encoding T y p e D e s c r i p t i o n 0 x 0 0 N o s u b -h e a d e r s p r e s e n t 0 x 0 1 G r a n t m a n a g e m e n t s u b -h e a d e r p r e s e n t 0 x 0 2 P a c k i n g s u b -h e a d e r p r e s e n t 0 x 0 3 G r a n t m a n a g e m e n t a n d p a c k i n g s u b -h e a d e r s p r e s e n t 0 x 0 4 F r a g m e n t a t i o n s u b -h e a d e r p r e s e n t 0 x 0 5 G r a n t m a n a g e m e n t a n d f r a g m e n t a t i o n s u b -h e a d e r s p r e s e n t 0 x 0 6 R e s e r v e d 0 x 0 7 R e s e r v e d 0 x 0 8 ARQ -f e e d b a c k s u b -h e a d e r p r e s e n t 0 x 0 9 ARQ -f e e d b a c k a n d g r a n t m an a g e m e n t s u b -h e a d e r s p r e s e n t 0x0A ARQ -f e e d b a c k a n d p a c k i n g s u b -h e a d e r s p r e s e n t 0 x 0 B ARQ -f e e d b a c k a n d p a c k i n g a n d g r a n t m a n a g e m e n t s u b -h e a d e r s p r e s e n t 0 x 0 C ARQ -f e e d b a c k a n d f r a g m e n t a t i o n s u b -h e a d e r s p r e s e n t 0x0D ARQ -f e e d b a c k a n d f r a g m e n t a t i o n a n d g r a n t m a n a g e m e n t s u b -h e a d e r s p r e s e n t 0x0E 0 x 3 F R e s e r v e d Table 8: Uplink type encoding ARQ with no fragmentation and no packing In this case each MPDU will contain a single MSDU. Knowledge of the BSN, the length of the MSDU (conveyed i n the MAC header) and the ARQ_BLOCK_SIZE parameter enables the calculation of the range of ARQ blocks contained in the message. The ARQ sub- header position and its contents are shown below. Generic MAC Header ARQ sub-header Payload ( = One MSDU) CRC-32 Figure 3 : A RQ sub- header with no fragmentation and no packing 8

10 Syntax Size Notes ARQ_Sub_Header_Format() { Reserved 3 b i t s BSN 1 3 b i t s Block sequential number for the first ARQ block in the MSDU Table 9 : ARQ sub-header forma t with no fragmentation and no packing ARQ with fragmentation only In this case each MPDU will contain a single fragment of a MSDU. Fragmentation is NOT guaranteed to be on an ARQ block boundary, and therefore either the first ARQ block or the last ARQ block (or both) could be partial blocks. Note that part of the information carried in the fragmentation sub -header is no longer very useful. We still require the FC field to tell us if this is the first, last or a middle fragment, but the FSN field is redundant, as we must use the ARQ block numbers for correct fragment placement. We will reuse the FSN bits carry information about the size of the first ARQ block (that may be partial) in the fragment. Note that a partial first ARQ block in a fragment will always carry the last bytes of the ARQ block while a partial last ARQ block in the fragment will always carry the first bytes of the ARQ block (there is an example later). Knowledge of the BSN of the first ARQ block, the size of the first ARQ block, the length o f the MSDU (conveyed in the MAC header) and the ARQ_BLOCK_SIZE parameter enables the calculation of the range of ARQ blocks contained in the message. The ARQ with fragmentation sub- header position and its contents is shown below. Generic MAC Header Fragmentaion and ARQ sub-header Payload ( = One MSDU fragment) CRC-32 Figure 4: ARQ sub -header with fragmentation only Syntax Size Notes Fragmentation_and_ARQ_Sub_Header_Format() { FC 2 b i t s Fragmentation Control Indicates the fragmentation state of the payload: 00 = no fragmentation 01 = last fragment 10 = first fragment 11 = continuing (middle) fragment Reserved 3 b i t s First block length in bytes, minus one 6 b i t s ARQ_BLOCK_SIZE = 64 bytes BSN 1 3 b i t s Block sequential number for the first ARQ block in the MSDU fragment Table 1 0: ARQ with fragmentation sub -header format ARQ with fragmentation and packing In this case each MPDU may contain multiple MSDU or fragments thereof. In this case as well, fragmentation is NOT guaranteed to be on an ARQ block boundary, and therefore either the first ARQ block or the last ARQ block (or both) could be partial blocks. Here as well, part of the information carried in the fragmentation subheader is no longer very useful. We still require the FC field but not the FSN field. We will reuse the FSN bits carry information about the size of the first ARQ block (that may be partial) in the fragment. Note that a partial 9

11 first ARQ block in a fragment will always carry the last bytes of the ARQ block while a partial last ARQ block in the fragment will always carry the first bytes of the ARQ block (see example below). Each of the packed MSDU or MSDU fragments requires its own ARQ sub-header, as some of them may be transmissions while other are re-transmissions. Knowledge of the BSN of the first ARQ block, the size of the first ARQ block, the length of the each MSDU fragment (conveyed in the packing sub- header) and the ARQ_BLOCK_SIZE parameter enables the calculation of the range of ARQ blocks contained in each part of t h e p acked message. The ARQ with packing sub- headers position and the contents of an ARQ with packing and fragmentation sub-header is shown below. Generic MAC Header Packing and ARQ sub-header Payload ( = One MSDU or fragment) Packing and ARQ sub-header Payload ( = One MSDU or fragment) CRC-32 Figure 5 : ARQ sub -header with fragmentation and packing Syntax Size Notes Packing_and_ARQ_Sub_Header_Format() { FC 2 b i t s Fragmentation Control Indicates the fragmentation state of the payload: 00 = no fragmentation 01 = last fragment 10 = first fragment 11 = continuing (middle) fragment L e n g t h 1 1 b i t s T h e length in bytes of the MSDU or MSDU fragment, including the four- byte Packing_and_ARQ sub- header First block length in bytes, minus one 6 b i t s ARQ_BLOCK_SIZE = 64 bytes BSN 1 3 b i t s Block sequential number for the first ARQ block in the MSDU or MSDU fragment Table 11 : ARQ with fragmentation and packing sub-header format As this case is the most complicated, an example is given here to show how information on the ARQ block numbers is extracted from the data in the MPDU in a dynamic situation. 1 0

12 MSDU # MSDU # MSDU # MSDUs to send time axis MPDU #1 MPDU #2 MPDU #3 MPDU # Start FRG Middle FRG Last FRG MSDU#2 Unfragmented MSDU#3 Start FRG MSDU#3 Last FRG Middle FRG First transmission First transmission First transmission First transmission Retransmission FC: Length: First block: BSN: bytes for block 17 (part of MSDU #3) 64 bytes for block 18 (part of MSDU #3) 64 bytes for block 19 (part of MSDU #3) 12 bytes for block 20 (part of MSDU #3) FC: Length: First block: BSN: Figure 6 : ARQ with packing and fragmentation dynamic example bytes for block 9 (part of MSDU #1) 32 bytes for block 10 (part of MSDU #1) 7.4 ACK messages In order to function the ARQ algorithm in the transmitter needs feedback from in the receiver in the form acknowledgment messages for the ARQ blocks that have been received without errors. The feedback information is sent on the appropriate basic management connection between that SS and the BST (there is one such connection in each direction). Note that MAC management messages sent on the basic management connection should not be packed or fragmented Stand-alone ACK message This ACK message may take the format of a stand-alone MAC message. It can signal a cumulative ACK or several selective ACKs, and it can also hint on not acknowledged ARQ block numbers (NACKs). The format is shown below. Syntax Size Notes ACK_Message_Format() { Management Message Type =? 8 b i t s for ( i = 1 ; I <n ; i ++) { Repeat as many times as required ARQ_feed back_ie () 1 6 b i t s The connection ID being referenced Table 1 2 : ACK message 1 1

13 Syntax Size Notes ARQ_feedback_IE () { L a s t _ f l a g 1 bit 0 = More ARQ feedback IE in the list 1 = Last ARQ feedback IE in the lis t C u m _ S e l _ f l a g 1 bit 0 = Selective ACK entry 1 = Cumulative ACK entry B M _ f l a g 1 bit 0 = Bit -map field does not exist 1 = Bit -map field exists If (Cum_Sel_flag == 0) { B S N 1 3 b i t s Block sequential number for the else { B S N If (BM_flag == 1) { ACK MAP 1 3 b i t s 1 6 b i t s acknowledged ARQ block Block sequential number for the ARQ block below which all blocks are acknowledged Each bit set to one means the corresponding ARQ block has been received without errors. The LSB corresponds to the ARQ block whose number is the BSN above, an the MSB relates to the ARQ block whose number is (BSN + 15) modulo 2^13 CID 1 6 b i t s The ID of the connection being referenced Table 13 : ARQ feedback IE definition Piggyback ACK The ARQ feedback can be piggybacked on any connection taking the format of a sub-header. 1 2