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

Re: [STDS-802-16] [STDS-802-16-MOBILE] [Harmonization] MBS Harmonization



Thanks, I am completely satisfied
Vladimir

> -----Original Message-----
> From: Roger B. Marks [mailto:r.b.marks@ieee.org]
> Sent: Friday, August 13, 2004 5:00 PM
> To: Vladimir Yanover
> Cc: stds-802-16@ieee.org
> Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS Harmonization
>
>
> Vladimir,
>
> I've edited the file, striking out your name.
>
> I've also noted in the index that "Vladimir Yanover has been deleted
> from the author list at his request."
>
> Let me know if you have any problem with this solution.
>
> Roger
>
>
> At 12:54 +0300 2004-08-13, Vladimir Yanover wrote:
> >All,
> >
> >I was surprised to find my name in contribution
> H80216e-04_005. It makes
> >wrong impression that I basically agree with its content.
> >I never saw this document before publication and was never
> asked to sign on
> >it. So I cannot be responsible
> >for content of the document as well as for statements
> expressed in the
> >document from the name of Alvarion.
> >
> >I find this way of actions inappropriate and request to
> remove the document
> >from 802.16 WEB site or at least to publish another version
> without my name.
> >
> >
> >My view on multicast services is the following.
> >1. Requirements
> >- ability to receive MC content while in normal operations [not Idle]
> >- ability to employ power saving, at least while in normal operations
> >- MC content will be available only to authorized MSSs
> >
> >Ability to receive MC content while in Idle Mode should be a
> separated
> >capability.
> >
> >2. To satisfy above requirements actually no additional MAC
> features needed.
> >What we need is few informative sentences:
> >- Some of DL Service Flows are for distributon of multicast content
> >- While the MSS is in normal operations mode [not Idle], all
> procedures are
> >performed as in 6.3.13 [establishment of connections], usual
> >authorization/security stuff
> >is applicable. The MSS may go to sleep and be wakened by
> TRF-IND with
> >reference to the CID associated with multicast service
> >
> >3. Ability of MSS to receive MC content while in Idle mode
> should be a
> >separated capability. In this case authorization should be
> supported by
> >upper layers.
> >For example, the content may be encrypted and only
> authorized MSSs will have
> >the key. Mapping of MC SFIDs onto CIDs shall be known to all BSs
> >in the network and to all relevant MSSs [mechanism is out of
> scope of 16e]
> >
> >The only issue remains power save while in Idle mode. To
> provide that,
> >MBS_MAP Information Element may be useful, but I would make it more
> >general: allow any CID to be encoded including Basic CID of
> some MSS. Then
> >such IE would signal to relevant MSS[s] that there will be
> no DL traffic at
> >the CID within certain time interval [so the MSS may save
> power, go for
> >scanning etc.] Accordingly the name should be changed [e.g. to "Idle
> >interval IE"].
> >
> >Other concepts are more less covered by existing
> constructions. For example
> >virtual connection / "MBS Zone" functions are covered by Service Flow
> >concept
> >
> >Vladimir
> >
> >>  -----Original Message-----
> >>  From: Beomjoon (BJ) Kim [mailto:beom@LGE.COM]
> >>  Sent: Thursday, August 12, 2004 11:31 AM
> >>  To: STDS-802-16-MOBILE@listserv.ieee.org
> >>  Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> Harmonization
> >>
> >>
> >>  Dear Yigal
> >>
> >>  You mean that every BS will be able to support Macro
> >>  Diversity in PHY level.
> >>  Am I right? If so, we agree with you in that the negotiation
> >>  procedures are not necessary.
> >>
> >>  Also, if you have another comment or answer, please give me a
> >>  feedback.
> >>
> >>  Thank you
> >>
> >>  Regards,
> >>
> >>  BJ
> >>
> >>  ----- Original Message -----
> >>  From: <owner-stds-802-16-mobile@LISTSERV.IEEE.ORG>
> >>  To: <STDS-802-16-MOBILE@LISTSERV.IEEE.ORG>
> >>  Sent: Thursday, August 12, 2004 10:40 AM
> >>  Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> Harmonization
> >>
> >>
> >>  > Dear BJ,
> >>  >
> >>  > I am not aware that there currently exists a possibility
> >>  that a BS will not
> >>  > support the MBS zone in the PHY level, and I'm not sure we
> >>  want to promote
> >>  > BS that do not support this very important capability, so I
> >>  don't think a
> >>  > negotiation is required.
> >>  >
> >>  > BR,
> >>  > Yigal
> >>  >
> >>  > -----Original Message-----
> >>  > From: owner-stds-802-16-mobile@listserv.ieee.org
> >>  > [mailto:owner-stds-802-16-mobile@listserv.ieee.org]On
> >>  Behalf Of Beomjoon
> >>  > (BJ) Kim
> >>  > Sent: Wednesday, August 11, 2004 2:03 PM
> >  > > To: STDS-802-16-MOBILE@listserv.ieee.org
> >>  > Subject: Re: [STDS-802-16-MOBILE] [Harmonization] MBS
> Harmonization
> >>  >
> >>  >
> >>  > Dear Yong Chang and all involved in MBS
> >>  >
> >>  > I'm BJ from LG Electronics.
> >>  > We want to clarify a few things and our position regarding
> >>  the issue in the
> >>  > uploaded contribution by Yong Chang.
> >>  >
> >>  > 1) Basically, we agree to that Pre-Advermisement may not be
> >>  necessary under
> >>  > the assumption of Macro Diversity.
> >>  > Therefore, NBR-ADV message may not include MBS Zone ID of
> >>  neighbor BSs (if
> >>  > there is no need for an MSS to perform HO under the assumption).
> >>  >
> >>  > 2) However, when an MSS attempts to enter network at a BS,
> >>  it is necessary
> >>  > for the MSS to negotiate MBS capability with the BS whether
> >>  or not the BS
> >>  > can support MBS based on Macro Diversity. It is because all
> >>  BSs may not
> >>  > support MBS with Macro Diversity. So, we have proposed that
> >>  Mode Support
> >>  > Indication (MBS support) should be included in
> REG-REQ/RSP in our
> >>  > contribution (H80216e-04/01).
> >>  >
> >>  > 3) Also, we have proposed a Backbone message to manage the
> >>  BSs included in
> >>  > MBS zone.
> >>  > We want to hear your opinion about the backbone message.
> >>  > (Alvarion people seem to think it may be out of scope.)
> >>  >
> >>  > Additionally, we have a question.
> >>  >
> >>  > Under the environment where Macro Diversity is supported,
> >>  we understand that
> >>  > there is no need for an MSS receiving only MBS traffic to
> >>  perform Handover
> >>  > procedures.
> >>  > However, there may be a case where an MSS starting to
> >>  receive MBS traffic
> >>  > from BS 1 moves to BS 2.
> >>  > In this case, BS 2 does not know the MSS is in its coverage
> >>  because the MSS
> >>  > did not perform HO procedures.
> >>  >
> >>  > In this situation,
> >>  > Q1: If there is DL traffic addressed to the MSS, how can
> >>  either BS1 or BS2
> >>  > trasmits the traffic to the MSS without any session
> >>  information of the MSS?
> >>  > If the MSS is in Idle Mode when the DL traffic arrives (at
> >>  this time the DL
> >>  > traffic will arrive at BS1),  the DL traffic may be
> >>  delivered to the MSS
> >>  > using the existing procedures of Idle Mode.
> >>  > However, if the MSS is in Normal Mode or Sleep Mode, it is
> >>  impossible to
> >>  > deliver the traffic to the MSS.
> >>  >
> >>  > Q2: If the MSS has UL traffic to transmit, should the MSS
> >>  perform Initial
> >>  > Network Entry at BS2?
> >>  >
> >>  > Thank you
> >>  >
> >>  > Regards,
> >>  >
> >>  > BJ
> >>  >
> >>  > ----- Original Message -----
> >>  > From: <owner-stds-802-16-mobile@listserv.ieee.org>
> >>  > To: <STDS-802-16-MOBILE@listserv.ieee.org>
> >>  > Sent: Wednesday, August 11, 2004 4:44 PM
> >>  > Subject: [STDS-802-16-MOBILE] [Harmonization] MBS Harmonization
> >>  >
> >>  >
> >>  > > All,
> >>  > >
> >>  > > I have uploaded the initial draft for MBS Harmonization
> >>  on the upload
> >>  > > server.
> >>  > > I showed in this draft how many comments on MBS were given.
> >>  > >
> >>  > > For conference call of MBS only, what I heard from
> the chair of
> >>  > > Harmonization is that
> >>  > >
> >>  > > Time: August 5(Thursday), 3:30 PM (PST)
> >>  > > Bridge Information: Chair will give information ASAP.
> >>  > >
> >>  > > If anyone have a contribution with MBS, then please
> >>  upload it on the
> >>  > server
> >>  > > before the meeting.
> >>  > >
> >>  > > Thank,
> >>  > >
> >>  > > Yong Chang/Ph.D
> >>  > > Samsung Electronics, LTD
> >>  > >
> >>  > >
> >>  > >
> >>  >
> >>  >
> >>  >
> >>
> >>
> >>  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.
************************************************************************************