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