RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc: Continuation on of discussion
Gordon,
Your question is interesting, but I was wandering whether such considerations are in the scope of the standard:
The general approach which we based the sleeping mode definition was to try to define Air Interface protocol + mechanism for efficient sleep mode functionality.
The basic goals was that: (a) we should address power reduction issue, (b) the algorithms to employ potential power reduction should be efficient, and (c) we should not force any implementation based requirement as normative requirements.
Taking the current mechanism plus the addition of Vladimir, which I totally agree with, I think that we managed to reach the goals defined above, and from my point of view, any more details about specific power reduction mechanisms at the MSS will be over specification.
Regarding specifically your question, dealing with sleep mode and real time services is very implementation dependent issues. It depends on the expected wakening delay of the MSS including synchronization delay and actual time of going from sleep mode to full operative mode and vise versa, and the periodic nature of the real time service itself.
The current sleep mode terminology has flexibility of defining the maximum and minimum window sizes and wakening delay. It seems to be enough of deciding whether a service or specific traffic scenario was engage sleep mode while the traffic service is active.
I will be happy to hear any other thoughts on this issue.
Itzik.
> -----Original Message-----
> From: Gordon Antonello [mailto:GAntonello@wi-lan.com]
> Sent: Tuesday, June 24, 2003 17:19
> To: 'Itzik Kitroser'
> Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc:
> Continuati on of discussion
>
>
> Yes. Did you consider sleep mode for Real Time Protocol services?
>
> -----Original Message-----
> From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
> Sent: Tuesday, June 24, 2003 10:14 AM
> To: Gordon Antonello; stds-802-16-mobile@ieee.org
> Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc:
> Continuati on of discussion
>
>
> Gordon,
>
> I did not understand your question. Do you mean Real Time
> Protocols by RTP?
>
> Itzik.
>
> > -----Original Message-----
> > From: Gordon Antonello [mailto:GAntonello@wi-lan.com]
> > Sent: Tuesday, June 24, 2003 16:51
> > To: 'Vladimir Yanover'; 'Itzik Kitroser'; Changhoi Koo;
> > stds-802-16-mobile@ieee.org
> > Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc:
> > Continuati on of discussion
> >
> >
> > Did anyone consider sleep mode and RTP?
> >
> > -----Original Message-----
> > From: Vladimir Yanover [mailto:vladimir.yanover@alvarion.com]
> > Sent: Tuesday, June 24, 2003 12:29 AM
> > To: 'Itzik Kitroser'; Changhoi Koo; stds-802-16-mobile@ieee.org
> > Subject: RE: stds-802-16-mobile: Handoff and Sleep Mode Ad-hoc:
> > Continuati on of discussion
> >
> >
> > Hello,
> > I support the Itzik's view: Sleep Mode functionality should be separated
> > from flow control. But may be we should add / change some text in
> > 802.16 QoS
> > definitions
> > from the prospect of Sleep Mode operations. For example, we may
> > decide that
> > max
> > system delay specified as service flow parameter is valid for
> non-sleeping
> > state
> > and we need an additional parameter which is service acquisition delay
> > that incorporates latency of wakening.
> >
> > I would like also to use an opportunity to ask a question on
> contribution
> > IEEE C802.16e-03/31:
> > what is "PDU sequence number" that appears in 2.2.1, and then
> in following
> > tables etc.
> >
> > Vladimir
> >
> > -----Original Message-----
> > From: Itzik Kitroser [mailto:itzikk@runcom.co.il]
> > Sent: Monday, June 16, 2003 2:18 PM
> > To: Changhoi Koo; stds-802-16-mobile@ieee.org
> > 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.
> > > > > > >
> > > > > >
> ******************************************************************
> > > > > > ******************
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
> > 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.
> > ******************************************************************
> > **********
> > ********
> >
>
>