> However, it seems to me that what you said on
authorization
> and security for
> MBS is very very complex.
>
If I follow your scenario, the MSS shall perform the current
> network
entry
> procedure always whenever the MSS moves multiple BSs.
[VY] I don't understand sentence "the MSS moves multiple
BSs", so cannot comment on this part.
I don't understand also what is "my scenario".
> You can not obtain Macro Diversity since the user-specific
security
> mechanism is applied to the MBS.
[VY] My interpretation of above is: you're saying that if
upper level security mechanism is applied,
diversity combining cannot be used. If this interpretation is correct, I'd
like to say that I don't understand
why diversity combining cannot be used. If several BSs transmit same
content and it is encrypted at upper layer with same key,
then in the air we shall see same transmissions [MAC PDUs]. Same is correct
for encryption at MAC level:
if two BSs use same key [for encryption of MAC PDU
payload], combining is possible, otherwise it is not.
> Accordingly, your proposal using current normal operation
>
does not have any
> performance improvement on receiving MBS
content.
> Moreover, your proposal is very heavy and overhead to the
BS
> and MSS because
> BSs shall know how many MSSs are currently
receiving the specific MBS
> content,
> how many MSSs are sleep mode
currently, and MSS shall join
> the specific MBS
> content at the
network whenever MSS wants to change his MBS
> application
>
channel.
>
> Conclusively, your scenario following the current
normal
> operation is based
> on current multicast service using
IGMP on IP and above layer.
[VY] Yong, I didn't say a word on IGMP or IP multicast
service.
I would appreciate if you read my letter more carefully.
Thanks
> The current standard can provide what you have in your
mind
> at the sacrifice
> of performance improvement(e.g., Macro
Diversity), simplicity(e.g., BS
> management, MSS join and leave
procedure)
> and generality(e.g., regardless of the MSS's
mode).
> Repeatedly speaking, our simplified MBS proposal does not
>
effect on the
> current normal operation.
>
##################
>
>
> > > >
> > >
>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]
>
> ##################
>
[YONG]
> As I said earlier, what you said in the above is fine to
me.
> Now, we are waiting for another company's comment for
harmonization.
> ##################
>
> > > >
>
> > >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"].
>
##################
> [YONG]
> I do not understand what you are
proposing.
> MBS-MAP extended IE is for the prediction when the next MBS
frame is
> transmitted.
> Why this feature should be bound with
MSS's Basic CID?
> MBS_MAP IE is not relevant to the MSS but relevant to
the
> Multicast CID of
> MBS content.
> This MBS_MAP has
already covered normal operation. Don't need
> to limit to
> the
Idle Mode only.
[VY] Let me spell out my suggestion.
1. Define IE of same structure as you suggest
2. Make it not specific to MBS. It means allow to use it for
all CIDs, not only for those carrying multicast content.
3. Change it's name
Hope, this helps better understanding
> ##################
>
> > > >
> >
> >Other concepts are more less covered by existing
> > >
constructions. For example
> > > >virtual connection / "MBS Zone"
functions are covered by
> Service Flow
> > >
>concept
> ##################
> [YONG]
> For the virtual
connection concept, I can be willing to harmonize your
> concept because
most of companies
> agreed with the concept that MBS connection infomation
shall
> be the same
> over multiple BSs.
>
> MBS Zone is
applicable to tell the Macro Diversity Zone and regional
> specific
deployment
[VY] So you do agree to replace "virtual connection"
with Service Flow?
I would appreciate that
> ##################
>
> > > >
> > >
>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.
> >
>
**************************************************************
>
**************
> ********
>
>
>
>
>
> 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