** I resend thie email because ad-hoc reflector has not sent it for 5 hours.
Dear Prakash, Lalit, and all;
I am sorry not to participate in Jun 10th Teleconference because of the business trip from Jun 10th to Jun 11th.
Thoung I am still on business trip, I had better reply to Lalit's comments in brief to escape confusion in our group.
First of all, thanks for Lalit's comment.
The material "Service requirement" is just supplementary one as a reference.
It is focused on service side; of course, it is out of this adhoc's main scope.
BTW, the quick reply to Lalit's comment is as follows;
1. The delay is end-to-end delay. The radio acess network delay should be far less than this value.
2. Right, it is a total delay.
3. For Realtime service, ARQ is useless; therefore, BER is a value just supported by FEC in PHY.
For other servicec: BER is the value achieved after ARQ.
More comments are always welcomed.
See you in next teleconference & Hawaii,
Min-sung, Kim
KT (Korea Telecom)
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On Behalf Of Lalit Kotecha
Sent: Thursday, June 10, 2004 2:31 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: Re: [STDS-802-16-MOBILE] [Handoff] Servie Requirement related with HO
Dear Min-sung,
Thanks for taking efforts to put together service level requirements. I have couple of basic questions listed below.
1. Is delay specified for different categories of service is end-to-end delay requirements for service or specific to radio access network only. I think, we need to specify radio access network delay in 802.16e domain.
CHKOO) Actually, radio access delay may be determined as a deterministic number with some vairiation such as backoff delay something...In my personal view, in this HO AdHoc, it may not be used that how much end-to-end delay takes, we should just make focusing on HO breaking time between serving BS and Target BS to provide seamless connection...Any way, it seems that the value from Min-sung would be reference, it does not require hot discussion or concern...
2. In my opinion, radio access delay of 150msec for voice application is little high. If this is total delay, I agree with this number.
CHKOO) in case of the existing voice communication like 3G service, it is not strictly required the access delay, however, in case VoIP like service, the access delay shall be critical points, if we have enough time to discuss this items later, it would be good approach to make firm the specification
3. I would like to clarify that BER specified in this document is BER achieved after use of H-ARQ and ARQ, if used for specific type of service.
CHKOO) After H-ARQ, it would be residual BER. However, it does not need to discuss on UGS or Rt-polling because it may not allow the retransmission. BTW, BER in data service will be definetly critical point too, but it would not be out of scope in this AdHoc...
Thanks
Lalit
-----Original Message-----
From: owner-stds-802-16-mobile@listserv.ieee.org [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On Behalf Of cyberk@KT.CO.KR
Sent: Wednesday, June 09, 2004 2:43 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: [STDS-802-16-MOBILE] [Handoff] Servie Requirement related with HO
Dear Prakash and all HO ad hoc members:
* Request to operators who are participating in the adhoc - the group can benefit from an understanding of requirements for HO support in .16e. Please submit any text to this effect to this group (suggest uploading to the Handoff temporary space and sending out an email notification)
I uploaded ¡°C802.16e-04_Service Requirement.ppt¡± in HO adhoc temporary space related with above action item.
In the file, I briefly wrote some HO-related requirements about several services which may be provided.
The file is a just supplementary material for this ad hoc group.
I hope it will be helpful for discussing HO scenarios and optimization.
Best regards,
Min-sung, Kim / Korea Telecom