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.
> > > > >
> > > > ******************************************************************
> > > > ******************
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>