Re: stds-80220-requirements: Frame Error Rate Requirement, 4.1.10
Hi all,
I agree that the word "packets" should be replaced by "frame".
In addition, I concur with Jinweon Chang and the submission from
John Fan et al that the last sentence of section
4.1.10 be removed since "802.20 will support diverse services of which
characteristics can be very different from viewpoint of delay and
error rate".
Mike
On Tue, Jul 29, 2003 at 09:10:04AM +0300, Vladimir Yanover wrote:
> Jin and All,
>
> As for names of layers, MAC+RLC in WCDMA are together functionally similar
> to so-called "Common MAC"
> in 802.16, MAC in 802.11, MAC in 802.3; see also 802 Reference Model where
> "Medium Access" layer is mentioned.
> Working in IEEE802, we probably have to use name "MAC" for the layer
> covering this functionality.
> But whatever are the names, there should be probably separated layers "PHY"
> and "above PHY".
> I accepted your suggestion as to replace "packets" with "frames" which are
> SDUs of PHY
> (meaning that PHY receives them from higher layer and transports to receiver
> side). If such understanding
> is correct, I would appreciate replacing "packets" (misleading term) with
> "frames". But probably
> we need further clarification of how we understand the term "frame" (my
> suggestion was: frame = SDU of PHY).
> Also it is important what we do with the fact that SDUs of different size
> typically have different failure probabilities.
>
> Vladimir
>
> -----Original Message-----
> From: Jinweon Chang [mailto:jwchang1@samsung.com]
> Sent: Tuesday, July 29, 2003 8:34 AM
> To: Vladimir Yanover; Joseph Cleveland; stds-80220-requirements@ieee.org
> Subject: Re: stds-80220-requirements: Frame Error Rate Requirement, 4.1.10
>
>
> Dear Vladimir, Joseph, and colleagues,
>
> Thanks for the comments.
> I agree with Vladimir's opinion generally.
>
> In the last mail, I tried to explain that the requirement of frame error
> rate
> should be given at the physical layer first.
> Although a function of packet segmentation/concatenation could be performed
> either at MAC (Medium Access Control ^^;;) layer (in case of 802.16 system)
> or at RLP(cdma2000 system case)/RLC(WCDMA system case),
> data unit at physical layer is different from that in the higher layers
> (as Vladimir mentioned in his comment bullet #3).
>
> I believe that the requirements for MBWA systems should be minumum
> within large-scale charateristics of MBWA.
> So I think the current requirement statements of 4.1.10 Frame Error Rate are
> appropriate
> if the last sentence is excluded and if frame replace packet.
>
> Best regards, Jin
>
>
> ----- Original Message -----
> From: Vladimir Yanover <mailto:vladimir.yanover@alvarion.com>
> To: 'Jinweon Chang' <mailto:jwchang1@samsung.com> ; Joseph
> <mailto:JClevela@sta.samsung.com> Cleveland ;
> stds-80220-requirements@ieee.org <mailto:stds-80220-requirements@ieee.org>
> Sent: Monday, July 28, 2003 8:52 PM
> Subject: RE: stds-80220-requirements: Frame Error Rate Requirement, 4.1.10
>
> 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
>
> -----Original Message-----
> From: Jinweon Chang [mailto:jwchang1@samsung.com]
> Sent: Monday, July 28, 2003 1:47 PM
> To: Joseph Cleveland; stds-80220-requirements@ieee.org
> Subject: Re: stds-80220-requirements: Frame Error Rate Requirement, 4.1.10
>
>
> Dear Joseph and colleagues,
>
> Thank you for taking your time to work for the requirements.
> But I still have two concerns on the current requirement statement of
> 4.1.10 packet error rate.
>
> One:
> If I understand the desciption of 4.1.10 subsection correctly,
> the mentioned packet errors mean errors over the air.
> In this case, packets from the higher layer are segmented usually at MAC
> (Multiple Access Control) layer into frames in a certain size
> for the efficient transmisson over the radio channel.
> The terminology of Frame Error Rate(FER) would be better than
> Packet Error Rate(PER).
>
> Two:
> To my understanding, MBWA system will support diverse services
> of which characteristics can be very different from viewpoint of
> delay and error rate.
> We can consider, for instance, two services of VoIP and data services.
> In case of VoIP service,
> FER needs to be tightly controlled below a certain threshold
> and retransmission of frames may not be allowed.
> In case of data service,
> FER can be less strict in order to maximize throughput over the air.
>
> Thus, I would like to propose that the terminology of "Packet Error Rate" in
>
> subsection 4.1.10 be replaced to "Frame Error Rate" and
> that the last sentence in 4.1.10 ("The packet error rate for...") be
> deleted,
> which is also proposed by John Fan and other colleagues in the previous
> mail.
>
> Best regards, Jin
>
> ----------------------------------------------------------------------------
> -----------
> Jin Weon Chang, Ph. D.
> Senior Engineer
>
> Global Standards and Strategy Team
> Samsung Electronics Co., Ltd.
> Tel: +82-31-279-5117
> Pcs: +82-16-384-7017
> Fax: +82-31-279-5130
> jwchang1@samsung.com <mailto:jwchang1@samsung.com>
> ----------------------------------------------------------------------------
> ---------------------
>
>
>
> ----- Original Message -----
> From: Joseph Cleveland <mailto:JClevela@sta.samsung.com>
> To: stds-80220-requirements@ieee.org
> <mailto:stds-80220-requirements@ieee.org>
> Sent: Friday, July 25, 2003 2:44 AM
> Subject: stds-80220-requirements: Frame Error Rate Requirement, 4.1.10
>
>
> Hi All,
>
> Here is a revision to the wording on section 4.1.10 based on feedback from
> many of you. Thanks for the comments.
> <<frame_error_v0.2.1.rtf>>
> Joseph Cleveland
> Director, Systems & Standards
> Wireless Systems Lab
> Samsung Telecommunications America
> Richardson, TX 75081
> (O) 972-761-7981 (M) 214-336-8446 (F) 972-761-7909
>
>
>
> This mail passed through 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.
> ****************************************************************************
> ********
>
>
> 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.
> ****************************************************************************
> ********
>
>
>
>
> This mail passed through 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.
> ****************************************************************************
> ********
>
>
>
> 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.
> ************************************************************************************