RE: [16NG] IEEE 802.16 QoS parameters
<keshav.chawla@wipro.com> Thu, 21 June 2007 12:49 UTC
Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1I1M6C-0006YQ-Te; Thu, 21 Jun 2007 08:49:20 -0400
Received: from 16ng by megatron.ietf.org with local (Exim 4.43)
id 1I1M6C-0006YL-9x
for 16ng-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 08:49:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1I1M69-0006Y8-4s
for 16ng@ietf.org; Thu, 21 Jun 2007 08:49:17 -0400
Received: from wip-cdc-wd.wipro.com ([203.91.201.26])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1M67-0007zh-Bd
for 16ng@ietf.org; Thu, 21 Jun 2007 08:49:17 -0400
Received: from wip-cdc-wd.wipro.com (localhost.localdomain [127.0.0.1])
by localhost (Postfix) with ESMTP id 5B5F61805F
for <16ng@ietf.org>; Thu, 21 Jun 2007 18:19:15 +0530 (IST)
Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92])
by wip-cdc-wd.wipro.com (Postfix) with ESMTP id 4737B18058
for <16ng@ietf.org>; Thu, 21 Jun 2007 18:19:15 +0530 (IST)
Received: from DEL-GGN-MBX01.wipro.com ([10.105.51.181]) by
blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.3959);
Thu, 21 Jun 2007 18:19:22 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [16NG] IEEE 802.16 QoS parameters
Date: Thu, 21 Jun 2007 18:19:35 +0530
Message-ID: <D607371E06E45641947B21A8E95746B801AA4526@DEL-GGN-MBX01.wipro.com>
In-Reply-To: <dde9f3ed0706051201i21879de2ic8ee3d2ea9a00e98@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [16NG] IEEE 802.16 QoS parameters
Thread-Index: AcenrIMC96ZGUvkHSaCyt6NyWk5KSwMUuBiA
From: <keshav.chawla@wipro.com>
To: <denio@gprt.ufpe.br>
X-OriginalArrivalTime: 21 Jun 2007 12:49:22.0406 (UTC)
FILETIME=[97436860:01C7B402]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>,
<mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org
Hi, Provision for maintaining the Jitter lies with the receiver of the packets and only if some feedback mechanism is there, receiver can inform the sender about the jitter. At the sender's end it may not be possible to calculate jitter(even based on queue stats), as even if packet has gone out of the sender's queue, does not guarantee it reaching the receiver's side. At the receiver, it can be that Packet might not have reached or reached but dropped due to jitter threshold being reached/jitter buffer being full. I think all sender can do is to pump out data at a regular rate over time at which receiver is able to receive and rest lies with the receiver. regards, Keshav -----Original Message----- From: Denio Mariz [mailto:denio@gprt.ufpe.br] Sent: Wednesday, June 06, 2007 12:32 AM To: 16ng@ietf.org Subject: [16NG] IEEE 802.16 QoS parameters Hi, IEEE 802.16-2004 document defines some QoS parameters for admitted connections, which includes maximum latency and maximum jitter. They are defined as: ======= Maximum latency - The value of this parameter specifies the maximum latency between the reception of a packet by the BS or SS on its network interface and the forwarding of the packet to its RF Interface. Maximum Jitter - This parameter defines the maximum delay variation (jitter) for the connection. ====== Assuming D1 and D2 as the delay measured for two consecutive packets, it is common for end-to-end systems to compute the jitter J as J=|D1-D2|. I am studying a scheduling algorithms for the download, which must run inside the BS. This means that D1 and D2 are not available (or must be avoided, since it would depend on measuring them at the mobile terminal). So I am assuming that the algorithm must only consider information from inside the BS (more specifically from queue statistics). So, I am wondering if it is possible to compute correctly the jitter for packets assuming you can not watch the receiving end of the stream and only consider info from the sender side. TIA, Denio Mariz _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] IEEE 802.16 QoS parameters Denio Mariz
- [16NG] IEEE 802.16 QoS parameters Denio Mariz
- RE: [16NG] IEEE 802.16 QoS parameters keshav.chawla