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