Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc: Continuation of discussion



Dear Changhoi and all,

I'm bit delayed with redrafting the new version of the 
handoff and sleeping mode working document.
Since I don't want to hold the process, lets continue with 
the discussion.

Changehoi, please find my opinion regarding the items you 
have raised:
> 2. MS initiated Sleep to Awake mode change and its 
corresponding messages
> 3. TRF_CFN message(MSS to BS) for BS initiated Sleep to 
Awake 
> mode changes  corresponding messages
> 4. PDU sequence numbering when transiting sleep to awake 
mode 
> 5. SLP_REQ transmission and number of retrying when 
saturating 
> maximum window value of MSS (sleeping interval)
> 6. Sleep and Awake mode changeing approval and rejecting 
> 7. Control and data traffic indication when transiting 
sleep to awake mode

MSS initiating sleep mode is already defined in the standard, 
in my opinion, the only change which should be done is to 
emphasis that the BS may send unsolicited SLP-RSP message to 
initiate sleep mode, without the need of an MSS to response 
(to reduce TX power), the state machine should be exactly as 
in the case of MSS initiating sleep mode, just without the 
SLP-REQ message.
I disagree with the idea of using sleep mode as a traffic 
control function, the MAC has many other mechanisms to 
facilitate such functionality. The main drive of the current 
design of the sleep mode is to enable efficiency in terms of 
power consumption while reducing any potential delay which 
can be cause of being in sleep mode.
The current mechanism has enough flexibility, by using the 
sleep mode parameters, min,max windows and listening time, 
that enables fine tuning of the sleeping mode with respect to 
the specific traffic, services and system requirements of 
each system.

All, I would be glad to hear some more thoughts about this 
issue.

Also, I would like to discuss the last item in our list, e.g. 
contribution C80216e-03_30r1, dealing with reporting of 
scanning results of the MSS to the BS (Periodic reporting and 
event triggering reporting).

Best Regards,
Itzik.

> -----Original Message-----
> From: owner-stds-802-16-mobile@majordomo.ieee.org
> [mailto:owner-stds-802-16-mobile@majordomo.ieee.org]On 
Behalf Of
> Changhoi Koo
> Sent: Tuesday, June 17, 2003 10:52
> To: Itzik Kitroser; stds-802-16-mobile@ieee.org
> Subject: Re: stds-802-16-mobile: Handoff and Sleep Mode Ad-
hoc:
> Continuation of discussion
> 
> 
> Dear Itzik and all
> Thanks for constructive your comments and decision
> I think that there was no strong objection for the basic 
concerns 
> and operation of the sleeping mode. e.g BS initiated Awake 
to 
> Sleep mode changes and its response operation. So I believe 
that 
> this item is almost closed and we can move next stuff.
> Followings are some of individual items to be described and 
> proposed in the contribution 31. I'd like to know how are 
you 
> going to handle following items
> 
> 1. BS initiated Awake to Sleep mode change and its 
corresponding 
> message (being discussed)
> 2. MS initiated Sleep to Awake mode change and its 
corresponding messages
> 3. TRF_CFN message(MSS to BS) for BS initiated Sleep to 
Awake 
> mode changes  corresponding messages
> 4. PDU sequence numbering when transiting sleep to awake 
mode 
> 5. SLP_REQ transmission and number of retrying when 
saturating 
> maximum window value of MSS (sleeping interval)
> 6. Sleep and Awake mode changeing approval and rejecting 
> 7. Control and data traffic indication when transiting 
sleep to awake mode
> 
> Thanks
> Changhoi Koo
> 
> ----- Original Message ----- 
> From: "Itzik Kitroser" <itzikk@runcom.co.il>
> To: "Changhoi Koo" <chkoo@samsung.com>; <stds-802-16-
mobile@ieee.org>
> Sent: Monday, June 16, 2003 8:18 PM
> Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-
hoc: 
> Continuation of discussion
> 
> 
> > Dear Changhoi and all,
> > 
> > First I would like to thank you for the feedback, I'm 
happy 
> that at least there is one participant in this discussion.
> > Regarding the Sleep-mode, since no one have provide a 
feedback, 
> I assume that everybody agrees with the perspective 
provided in 
> my previous mail.
> > I will draft a proposed text, which can be a basis for 
> discussion the details of the proposal. 
> > My perspective is that some of the additions are useful, 
i.e. 
> clearly stating that BS can initiate Sleep-mode and the 
actions 
> of an MSS following disapproval of sleep request, and that 
some 
> of the features are redundant, such as traffic indication 
of the 
> MSS. I don't think that sleep-mode is the right tool for 
traffic 
> management which should be more of implementation dependent 
while 
> using the tools already provided by the current MAC 
protocol.
> > 
> > Regards,
> > Itzik.
> > 
> > 
> > > -----Original Message-----
> > > From: Changhoi Koo [mailto:chkoo@samsung.com]
> > > Sent: Monday, June 16, 2003 02:49
> > > To: Itzik Kitroser; stds-802-16-mobile@ieee.org
> > > Subject: Re: stds-802-16-mobile: Handoff and Sleep Mode 
Ad-hoc:
> > > Continuation of discussion
> > > 
> > > 
> > > Dear Itzik and All
> > > Here are my view on the Sleeping mode operation.
> > > Sleeping mode in mobile environment would be really 
important and 
> > > critical facts for power saving. Furthermore, with this 
feature, 
> > > another befefit that BS can control and manage the all 
MSS for 
> > > cell load capacity through the sleeping mode should be 
considered 
> > > carefully. Therefore, I think it should be allowed that 
the BS 
> > > initiated awake to sleep mode transition based on down 
link 
> > > traffic status and cell load control.
> > > For response statement, always the MAC state machine 
between BS 
> > > and MSS should be adjusted and synchronized to transmit 
the user 
> > > packet data without transmission loss. Therefore the 
response for 
> > > the mode changes should be implemented and considered 
for 
> > > avoiding undesirable retransmission due to packet 
transmission 
> > > loss and undesirable monitoring to detect down link 
packet 
> > > transmission, etc.
> > > 
> > > And, Mr. Chairman, I'd like to ask something on the 
sleeping 
> mode related.
> > > Actually, The contribution 31 includes individual 
several items 
> > > to improve existing sleeping mode operation. The mode 
changes 
> > > mentioned here would be a one of items. Are you going 
to arrage 
> > > and continue the remaining items on this e-mail 
discussion before 
> > > july meeting? 
> > > 
> > > Thanks
> > > Changhoi Koo
> > > 
> > > ----- Original Message ----- 
> > > From: "Itzik Kitroser" <itzikk@runcom.co.il>
> > > To: <stds-802-16-mobile@ieee.org>
> > > Sent: Monday, June 09, 2003 2:59 PM
> > > Subject: stds-802-16-mobile: Handoff and Sleep Mode Ad-
hoc: 
> > > Continuation of discussion
> > > 
> > > 
> > > > Hello all,
> > > > Assuming that the previous item (backoffs) is close, 
I'm 
> > > continuing with the next item to discuss:
> > > > Contribution C802.16e/03-31: Sleep mode enhancement:
> > > > In this contribution the idea of BS initiating sleep 
mode for 
> > > an SS is formally described.
> > > > I expect a discussion at two levels, first, please 
provide your 
> > > perspective about the general idea of BS initiating 
entrance to 
> > > sleep of an SS. Second, if you agree with the general 
concept, 
> > > please provide your feedback about the contents of the 
> > > contribution and the implementation of this concept.
> > > > 
> > > > My perspective on this subject is as follows:
> > > > a. The main motivation of having BS initiating sleep 
mode is 
> > > based on the fact that the BS knows the exact 
downstream traffic 
> > > status of each SS, which can lead into a knowledgeable 
decision 
> > > that no traffic is exists or expected to a specific SS. 
Also this 
> > > provides a good way of reducing some power of the SS by 
not 
> > > requiring it to send SLP-REQ message. So generally I 
think that 
> > > this is a good idea that enhances the performance.
> > > > b. Some aspects of the implementation should be 
revises, with 
> > > the motivation of not requiring the SS to transmit 
response when 
> > > BS initiating sleep mode.
> > > > 
> > > > I expect a feedback on this issue, we have more items 
to 
> > > discuss and the schedule is starting to be tight.
> > > > Regards,
> > > > Itzik
> > > > 
> > > > > -----Original Message-----
> > > > > From: owner-stds-802-16-mobile@majordomo.ieee.org
> > > > > [mailto:owner-stds-802-16-mobile@majordomo.ieee.org]
On 
> Behalf Of Itzik
> > > > > Kitroser
> > > > > Sent: Thursday, June 05, 2003 09:48
> > > > > To: stds-802-16-mobile@ieee.org
> > > > > Subject: RE: stds-802-16-mobile: Handoff and Sleep 
Mode 
> > > Ad-hoc: Start of
> > > > > discussion
> > > > > 
> > > > > 
> > > > > Dear Changhoi, Vladimir and All,
> > > > > 
> > > > > Thank you for your perspectives.
> > > > > I think that an approach which will bridge between 
our views can 
> > > > > be as follows:
> > > > > 1. Have two backoff values (actually min and max 
for each case), 
> > > > > one for initial ranging and one for HO-initial 
ranging.
> > > > > 2. Make those values global, i.e. published in the 
UCD, this 
> > > > > means, add to current UCD encoding another two 
values:
> > > > >    Ho_Ranging_Backoff_Start and 
Ho_Ranging_Backoff_End (with 
> > > > > scope for all PHYs).
> > > > > 3. No change for initial ranging backoff algorithm, 
add 
> > > > > definition that HO MSSs will perform truncated 
binary exponential 
> > > > > backoff with [0..2^HO_BOFF] value, when HO_BOFF in 
> > > > > [Ho_Ranging_Backoff_Start,Ho_Ranging_Backoff_End].
> > > > > 
> > > > > The motivation is as follows:
> > > > > a. I agree with Vladimir that the number of 
expected collisions 
> > > > > will be inherently low, therefore, there is no 
logic for 
> > > > > exclusive windows to eliminate collisions, the 
statistical 
> > > > > spreading should do the work with bounded 
guaranties.
> > > > > b. I also agree with Changhoi, that since we have 
two different 
> > > > > processes, with two different control and 
performance 
> > > > > requirements, having two different window 
parameters makes sense 
> > > > > (even when the windows are overlapping).
> > > > > c. I agree that from BS point of view, changing the 
windows 
> > > > > boundary is totally implementation dependent issue, 
from the MSS 
> > > > > point of view, an deterministic algorithm must be 
defined (i.e. 
> > > > > item 3 above), otherwise, the contention process 
will not work.
> > > > > 
> > > > > Please provide feedback, and agree or disagree 
observations. I 
> > > > > would like for continue for the next topic.
> > > > > 
> > > > > Regards,
> > > > > Itzik.
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Changhoi Koo [mailto:chkoo@samsung.com]
> > > > > > Sent: Thursday, June 05, 2003 04:14
> > > > > > To: Vladimir Yanover; 'Itzik Kitroser'; 
> stds-802-16-mobile@ieee.org
> > > > > > Subject: Re: stds-802-16-mobile: Handoff and 
Sleep Mode 
> > > Ad-hoc: Start of
> > > > > > discussion
> > > > > > 
> > > > > > 
> > > > > > Hello All
> > > > > > 
> > > > > > Thanks fot your comments on Samsung's 
contribution.
> > > > > > Please let me make some answers
> > > > > > For Chairman's view, the boundary of backoff 
region 
> would depend 
> > > > > > on the number of entry call and HO call and it 
can be 
> dynamically 
> > > > > > allocated by the BS through the DL message which 
includes 
> > > > > > information to be used to indicate boundary.
> > > > > > And your suggestion looks good and can be 
alternative 
> in terms of 
> > > > > > allocation and indication of backoff field. 
> Furthermore, it seems 
> > > > > > depend on the operation view.e.g how to handle 
and allocate the 
> > > > > > boundary would be implementational issues.
> > > > > > However, most important thing would be that the 
> different backoff 
> > > > > > region should be defined and allocated for each 
entry 
> call and HO 
> > > > > > call. So I believe if we make a room for 
different 
> backoff field 
> > > > > > allocation on the messgae, everything will be O.K 
and 
> there will 
> > > > > > be no any problem.
> > > > > > 
> > > > > > For Mr Yanover's view
> > > > > > Thanks for your comments. Unfortunately, we did 
not meet in the 
> > > > > > last meeting so I had not chance to hear your 
valuable 
> comments. 
> > > > > > But I'm very happy to see mail from you...
> > > > > > You are right. Everything depends on the number 
of HO call and 
> > > > > > entry call, and statistical charcteristics of the 
MSS. 
> We may or 
> > > > > > may not show some statistical references or 
simulation results. 
> > > > > > Even we have a simple simulation results chich 
can be give the 
> > > > > > evidence to be shown the useful approach of this 
proposal, But 
> > > > > > I'm not sure whether the simulation results can 
be 
> satisfied for 
> > > > > > you. However, it is hard to evaluate and 
analysize the 
> enough and 
> > > > > > reasonable simulation resulta due to so many 
variables such as 
> > > > > > MSS characteristics, call characteristics, number 
of MSS during 
> > > > > > HO and any other parameters which can be obtained 
from 
> > > > > > measurement under real fields..
> > > > > > I believe that the basic purpose of the backoff 
field 
> would give 
> > > > > > avoidance of the collision between the calls and 
the different 
> > > > > > access delay can be happend according to the 
backoff field.And 
> > > > > > the allocation scheme and direction can be 
treatable and 
> > > > > > dynamically handled based on the cell load 
including entry call 
> > > > > > and HOcall. If the BS does not want to allocate 
> different backoff 
> > > > > > field, it can do that..However, we don't need to 
such approache 
> > > > > > and should allow the way for the performance 
enhancement.
> > > > > > Furthermore, Because it does not require the 
major changes and 
> > > > > > H/W changes, and it can be done simply on the 
message 
> level, We'd 
> > > > > > better give minimum directions and way to assist 
the fast HO in 
> > > > > > IEEE802.16e specificatin.
> > > > > > Thanks and Welcome further comments and 
discussions.
> > > > > > Changhoi Koo
> > > > > > 
> > > > > > 
> > > > > > ----- Original Message ----- 
> > > > > > From: "Vladimir Yanover" 
<vladimir.yanover@alvarion.com>
> > > > > > To: "'Itzik Kitroser'" <itzikk@runcom.co.il>; 
> > > > > > <stds-802-16-mobile@ieee.org>
> > > > > > Sent: Thursday, June 05, 2003 12:52 AM
> > > > > > Subject: RE: stds-802-16-mobile: Handoff and 
Sleep Mode Ad-hoc: 
> > > > > > Start of discussion
> > > > > > 
> > > > > > 
> > > > > > > Hello All,
> > > > > > > This is about C802.16e/03-28 document. The tool 
suggested 
> > > > > > > for the solution of the problem seems 
appropriate: 
> allocate for 
> > > > > > mobile users
> > > > > > > 
> > > > > > > a separated initial ranging channel. But it 
would be more 
> > > convincing
> > > > > > > with some statistical data. Is the problem 
really hard? The 
> > > > > > answer depends 
> > > > > > > on traffic/mobility characteristics. 
> > > > > > > 
> > > > > > > For example, we know that for voice cellular 
networks busy 
> > > > > hours arrival
> > > > > > > rate may reach 3-4 users/sec per cell. If we 
assume that data 
> > > > > > terminals are
> > > > > > > not more mobile than cellular
> > > > > > > phones then we may expect same order of maximum 
arrival rate 
> > > > > for 802.16e
> > > > > > > cells.
> > > > > > > If we take MAC frame duration = 5 ms then we 
have 
> 50-60 frames 
> > > > > > per SS for
> > > > > > > initial ranging. So we may allocate MAINT 
region with 
> 1-2 slots 
> > > > > > once per 5
> > > > > > > frames 
> > > > > > > and configure backoff window to 2 or 4 slots 
and 
> still have 4-5 
> > > > > > attempts for
> > > > > > > 
> > > > > > > power adjustment of each incoming SS. 
> > > > > > > 
> > > > > > > Now, what is the role of "fixed" users in this 
picture? 
> > > > > > Probably, busy hours
> > > > > > > are those when people power up their SSs in the 
> evening. If 100 
> > > > > > such events
> > > > > > > are
> > > > > > > distributed over one hour interval, then we 
have 36 sec for 
> > > > > > each user, 10
> > > > > > > times more than for mobile one. Thus, under 
given 
> > > > > assumptions, there is 
> > > > > > > just a small interference from fixed SSs. Do we 
need a 
> > > separated MAINT
> > > > > > > channel
> > > > > > > in this case?
> > > > > > > 
> > > > > > > It would be interesting to hear from other 
> participants of the 
> > > > > > discussion 
> > > > > > > on their view on traffic/mobility 
characteristics of future 
> > > > > > 802.16e users
> > > > > > > 
> > > > > > > Vladimir
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Itzik Kitroser 
[mailto:itzikk@runcom.co.il]
> > > > > > > Sent: Monday, June 02, 2003 6:53 PM
> > > > > > > To: stds-802-16-mobile@ieee.org
> > > > > > > Subject: stds-802-16-mobile: Handoff and Sleep 
Mode 
> > > Ad-hoc: Start of
> > > > > > > discussion
> > > > > > > 
> > > > > > > 
> > > > > > > Hello All,
> > > > > > > 
> > > > > > > Given enough time passed, I would like to start 
the 
> discussion 
> > > > > > in the scope
> > > > > > > of this group.
> > > > > > > As indicated in working document the following 
topics 
> should be 
> > > > > > discussed:
> > > > > > > ---->
> > > > > > > 1. Contributions to discuss:
> > > > > > > a.C802.16e/03-28: Fast handoff service
> > > > > > > b.C802.16e/03-30r1: Reporting of scanning 
results
> > > > > > > c.C802.16e/03-31: Sleep mode enhancement
> > > > > > > 2. Clarification on the types of handoff that 
are supported; 
> > > > > > currently the
> > > > > > > text implies that two kind of handoff are 
supported 
> > > > > > (break-before-make and
> > > > > > > make-before-break) but descriptions are 
provided only for the
> > > > > > > break-before-make type. I would like to request 
proposals on
> > > > > > > make-before-break type (relevant to the current 
Tga/d 
> > > > > > technology of course)
> > > > > > > 3. Provide message flow diagrams for the Sleep 
mode 
> and Handoff 
> > > > > > procedure,
> > > > > > > such diagrams must provide a clear explanation 
of the actions 
> > > > > > performed by
> > > > > > > the BS and by the MSS. The diagrams must be 
considered for 
> > > > > > different kind of
> > > > > > > scenarios (i.e. handoff success, target BS 
rejection etc.)
> > > > > > > <----
> > > > > > > 
> > > > > > > I would like to open the discussion with item 
1.a. 
> > > > > "C802.16e/03-28: Fast
> > > > > > > handoff service " contribution:
> > > > > > > This contribution presents the idea of 
improving the Initial 
> > > > > > Ranging of MSS
> > > > > > > during handoff by using two backoff types of 
backoff 
> parameters:
> > > > > > > 1. "Regular" backoff (min) value for initial 
ranging, called 
> > > > > "MAX_BOFF"
> > > > > > > 2. HO MSS backoff (min) value for MSS during 
handoff time, 
> > > > > > called "HO_BOFF"
> > > > > > > The backoff window of MSS doing HO will be: 
[0,2^HO_BOFF] and 
> > > > > > the backoff
> > > > > > > window for MSS doing regular (i.e. not handoff) 
network 
> > > entry will be:
> > > > > > > [2^HO_BOFF+1,2^MAX_BOFF].
> > > > > > > 
> > > > > > > The advantage of this method, is that, when 
using a 
> > > shared contention
> > > > > > > resource, the MSS performing HO will not 
collide with MSS 
> > > > > > performing initial
> > > > > > > network entry.
> > > > > > > The drawback of this method is the inherited 
delay for the 
> > > > > > initial network
> > > > > > > entry process for regular MSSs.
> > > > > > > 
> > > > > > > My view on this issue is:
> > > > > > > a. One of the main targets of the 802.16 
handoff 
> procedures is 
> > > > > > to make the
> > > > > > > handoff process efficient and fast. Coming for 
this 
> > > > > > orientation, we have the
> > > > > > > ability to make the initial network 
synchronization for 
> > > MSS performing
> > > > > > > handoff, a contentionless process. This is 
achieved 
> by using the
> > > > > > > "Fast_UL_ranging_IE", which is sent 
unsolicited, by 
> the target 
> > > > > > BS to the MSS
> > > > > > > coming in. If the aspire that most of the MSS 
will be able to 
> > > > > > do so, than
> > > > > > > the problem solved by C802.16e/03-28 dose not 
exists.
> > > > > > > b. If there are subscribers, which still 
required to perform 
> > > > > contention
> > > > > > > entry to the target BS, then due to the fact 
that the number 
> > > > > of MSS that
> > > > > > > performing an initial ranging in a stabilized 
system is very 
> > > > > > low, it seems
> > > > > > > more reasonable to make two contention windows, 
which are 
> > > overlapping:
> > > > > > > b1. "Regular" backoff (min) value for initial 
ranging, called 
> > > > > > "MAX_BOFF",
> > > > > > > backoff window [0,2^MAX_BOFF]
> > > > > > > b2. HO MSS backoff (min) value for MSS during 
handoff 
> time, called
> > > > > > > "HO_BOFF", [0,2^HO_BOFF]
> > > > > > > When MAX_BOFF is large enough, then the 
probability of 
> > > > > > collision is still
> > > > > > > low.
> > > > > > > 
> > > > > > > Please provide your views on this issue, 
deadline is 04/06/03.
> > > > > > > 
> > > > > > > Best Regards,
> > > > > > > Itzik.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > >  
> > > > > > >  
> > > > > > > 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.
> > > > > > > 
> > > > > > 
> 
**************************************************************
****
> > > > > > ******************
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
> > 
> > 
>