| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Jinweon, Joseph and All,
Few
comments:
1.
Typically there is no 1-1 correspondence between data units at different
layers.
For
example, most MAC protocols do both fragmentation and aggregation of data
units
from upper layers. The following terminology is widely used: if we
talk
on
certain layer (e.g. MAC), data units of above layer are called MAC
SDUs
(Service Data Units) while data units of this layer are called MAC
PDUs
(Protocol Data Units)
2.
So a reliability indicator for layer X, it should be provided in the terms
of
errors encountered at the level of SDUs (service data units of this layer). For
example,
Ethernet MAC layer transfers IP datagrams, then the indicator should
be error ratio
of IP
datagrams [M/N where N - number of transferred datagrams, M - number of
erroneous
datagrams]. number . There is some problem as the error
ratio depends on the datagram
size,
but we can normalize to per-1-bit value.
3. It
seems natural to measure reliability of future 802.20 PHY in the terms
of
error
rate for MAC PDUs transported by the PHY. The above comment
on normaliztion is applicable.
Probably "frames" mentioned by Jinweon are MAC
PDUs
Such definition naturally addresses error ratio "before ARQ"
[and other MAC operations,
for
example fragmentation/assembly], but "after FEC" (which is a part of
PHY)
4. I
completely share Jinweon's statement on diversity of services that may
result in
diversity of MAC procedures [enabled/disabled ARQ, restricted delivery
delay etc.].
Then
above MAC [e.g. at TCP/IP level] we may have different error ratio with the
same
PHY reliability.
5.
Bottom line: reliability requirements should be first specified for PHY.
Then - separately -
requirements for MAC's error correction capabilities [for example, "MAC
should be able to ensure
MAC
SDUs error ratio not more than X while having PHY SDUs error
ratio = Y" Typicaly there
is a
tradeoff between MAC correction capabilities and system
latency].
Vladimir
This mail was sent via mail.alvarion.com ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ |