| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
All,
I have some comments and questions on 802.16 MAC and its derivatives, to which your response will be appreciated.
1. The ARQ as defined in IEEE 802.16ab-01/01, June 2001 introduces a fundamental MAC level acknowledgment mechanism into 802.16, but its complex alternatives (short/long SN, ACK/CACK, and especially block/MPDU sequencing) may technically inhibit 802.16 from being as successful as DOCSIS.
On the other hand, in addition to the ARQ schemes defined on pages 189-208, a few lines need be added to make their operation normative. (a) The expiration of "retransmission retries" of a given packet used in defining the ARQ Timeout parameter on page 192 need be referenced to a specific time point. This reference may be chosen to be the point when the next out-of-sequence packet is received at the MAC, so that a received packet is passed up to the higher layer within an ARQ Timeout of its reception at the receiving MAC, regardless of the reception status of packets of lower sequence number. (b) There need be a Retransmission Timeout parameter at the transmitting MAC entity, so that the transmitting MAC will not retransmit a frame for which the retries are considered to have expired by the receiving MAC. Such a Retransmission Timeout may be equal to the ARQ Timeout, and is referenced to the time when the packet is first transmitted from the transmitting MAC. Thus, if a lost packet has not been successfully retransmitted within an ARQ Timeout of its initial transmission, it is discarded by the transmitting MAC, but is considered to have been positively acknowledged for the ARQ Window Size rule. (c) Whether a packet received after another packet of a higher sequence number has been passed up to the higher layer will be discarded by the receiving MAC or continued to be passed up need be explicitly stated. (d) The definition of the ARQ Window Size should not be expressed in terms of receipt of a NACK, as a NACK may be returned by the recipient for a lost packet, by itself lost on the way to the sender and hence not received by the sending MAC. It should be stated in terms of the sliding window concept. Thus, the ARQ Window Size is defined to be the number of packets the transmitting MAC may send ahead of, but including, the lowest-numbered packet for which a positive ACK has not been received. (e) There need be a rule specifying whether a packet received before another packet with a sequence number at least the ARQ Window Size smaller is pending retransmission will be discarded by the receiving MAC, or whether any lost packet with a sequence number at least the ARQ Window Size smaller than a recently received packet will be considered by the receiving MAC to have been discarded by the transmitting MAC due to the Retransmission Timeout limit and hence to have exceeded the ARQ Timeout limit at the receiving MAC. In the case where a received packet of a higher sequence number is discarded due to receive buffer overflow, further specification is required of whether the corresponding acknowledgment will be a positive, a negative, or no ACK at all. (f) In a case where a station (BS or SS) has the right to access the channel but has reached its ARQ Window Size limit--a case likely to occur when bitmap-type acknowledgments covering ranges of transmitted packets are lost--it need be specific whether that station will be using the access right to retransmit those packets not yet positively acknowledged from the sender's standpoint. (g) The range of sequence numbers required for ARQ purposes need be larger than estimated by the bandwidth-delay product, since the recipient usually cannot acknowledge a packet immediately upon its reception. If fact, the sender may be allowed to have a long transmit opportunity before any other station has its turn for transmission.
2. I would like to understand the objective of introducing an "optional mesh topology" into TG4 and the potential circumstances in which that option applies.
Would the objective be achieved if direct SS to SS transmission were enabled? Such direct transmission would not be relayed by the BS, but would be still coordinated by the BS in terms of channel access. The current definition of CID--a unidirectional mapping between a given SS and the BS--is not adequate for the MAC address filtering of an SS to SS transmission, yet it appears in the generic MAC header (and ARQ Feedback IE) which is also used for the mesh topology.
By the way, how is the receiver address derived in a BS-initiated DSA-REQ message? In other words, how is a CID first associated with a MAC address?
3. A single CID-type MAC address identification is adequate in DOCSIS as the application is carried on a closed environment, but a CID alone may not be sufficient for uniquely identifying a received packet in an open wireless environment.
If two or more adjacent cells happen to be operating in the same frequency band, how does a receiving station unambiguously determine the sending station of a received packet to be from the same cell, but not from another cell?
4. The backoff procedure as implied in the 802.16 draft may need to be refined or redefined.
If an SS sends a bandwidth request message based on the Request Backoff Start value contained in the most recently received Uplink MAP message, and if the SS determines from the next Uplink MAP message that transmission to have failed, will the SS retransmit the same request by doubling the backoff window and hence ignoring the Request Backoff Start and Request Backoff End values contained in the latest Uplink MAP message, or by using the Request Backoff Start value appearing in the latest Uplink MAP message?
If retransmission is based on the Request Backoff Start and Request Backoff End values that were broadcast at the time the initial transmission was made, the BS basically loses its control over contending stations once they have started to send (contend). However, the following paragraph written for "Contention Resolution" on page 124 of the 802.16/D2-2001 draft seems to indicate otherwise?
"The BS has much flexibility in controlling the contention resolution. At one extreme, the BS may choose to set up the Data Backoff Start and End to emulate an Ethernet-style back-off with its associated simplicity and distributed nature, but also its fairness and efficiency issues. This would be done by setting Data Backoff
Start = 0 and End = 10 in the UL-MAP. At the other end, the BS may make the Data Backoff Start and End identical and frequently update these values in the UL-MAP so all SS are using the same, and hopefully optimal, back-off window."
Again, insightful feedback on this note--which is by not means intended to be a criticism of the related work already put together by various individuals and groups--will be greatly appreciated.
Best regards,
Jin-Meng Ho
Texas Instruments
(214) 480-1994