Re: [STDS-802-16-MOBILE] [Harmonization] MBS Harmonization
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.
************************************************************************************